LINUX.ORG.RU
решено ФорумGames

Вывод пиксельного изображения.


0

0

Я собираюсь исследовать двух- и трёх-мерную графику и надеюсь создавать небольшие игры.
Для этого я буду использовать ассемблер(Привык к fasm).

Генерировать графику кадра будет сама программа
в 32-битном изображении в пространстве оперативной памяти,
и ей требуются только функции вывода готового 32-битного изображения на экран.
В Windows для этого я использовал GDI функцию StretchDIBits,
но она долго работает и переворачивала изображение,
(из-за чего приходилось переворачивать его перед функцией).

Что быстрее в linux-системах: SDL, GTK, Qt, OpenGl, или другие
Какой из способов при компиляции будет работать на большинстве linux-систем
Что быстрее в Windows: GDI, OpenGl, DirectX или другие

Самое главное найти быстрые способы решения проблеммы,
а для разных ОС можно написать несколько разных программ
с использование одного основного кода генерации кадра в памяти.

> Для этого я буду использовать ассемблер

Под линукс на ассемблере не пишут.

PolarFox ★★★★★
()

Во-первых, лучше не использовать для игр ни ассемблер, ни генерацию пиксельного изображения. Лучше таки изучить SDL и/или OpenGL и выводить через них. Но если будете упорствовать, я бы посоветовал sdl.

vkos ★★
()

Не пиши ничего на ассемблере. SDL.

slovazap ★★★★★
()

Плюсую opengl. На асмоненавистников не обращай внимания, fasm тот же. Пиши на чём удобнее, используй glibc.

anon_666
()

OpenGL. Зачем держать битмап в памяти я не понял.

Его можно использовать из GLUT, Qt. Есть привязки для кучи языков.

Задача какая-то примитивная... Посмотри что тебе ещё нужно будет, там смотри из под чего проще дёргать.

wyldrodney
()
Ответ на: комментарий от wyldrodney

>OpenGL. Зачем держать битмап в памяти я не понял.

Его можно использовать из GLUT, Qt. Есть привязки для кучи языков.


SDL тоже позволяет держать битмап в видеопамяти, и использовать OpenGL, и есть привязки ко множеству языков.

cPunk ★★
()

В линуксе ассемблер - очень плохой тон.

Быстрее всех однозначно OpenGL. С большим отрывом.

В Windows если есть дрова OpenGL, то скорость OpenGL и DirectX одинакова. Но при этом OpenGL провоцирует спользовать immediate mode (glBegin/glVertex/glEnd) вместо VBO. Кто поддался на провокацию, у того медленнее чем DX. В DX есть только один метод рисования - эффективный.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Как компилировать правельнее:

fasm lin32.asm lin32.o
?????
# gcc -lSDL -o lin32 lin32.o
# gcc -o lin32 lin32.o `sdl-config --cflags --libs
# gcc -lSDL -o lin32 lin32.o `sdl-config --cflags --lib

Какой отступ у переменной pixels(или как его узнать в программе):
typedef struct SDL_Surface {
Uint32 flags;
SDL_PixelFormat *format;
int w, h;
Uint16 pitch;
void *pixels;
int offset;
...

Если использовать OpenGl то через SDL, GLUT, или по другому?

zheland
() автор топика

Если читать из видео памяти не нужно, то в OpenGL лок текстуры (грубо говоря получить указатель в системной памяти на копию текстуры), обновить ее и отправить (glTexSubImage2D(GL_TEXTURE_2D,...)) в видеопамять. Скорее всего это будет наиболее шустрый вариант.

andreyu ★★★★★
()
Ответ на: комментарий от zheland

> Если использовать OpenGl то через SDL, GLUT, или по другому?

Как клавиатуру/мышь/джойстик обрабатывать будете? Если руками, то хватит GLUT или даже «чистого» OGL.
Но SDL заботится о вас о формировании окна, обработке ввода и прочих «мелочах».
Для игр я использую OGL поверх SDL (ради универсального способа создания окна и unicode-input).

andreyu ★★★★★
()

Спасибо всем,
Думаю попробую побольше вариантов: и SDL, и OGL, ...

В структуре SDL_Surface вычислил смещение относительно начала структуры
переменной-указателя pixels.
Перед ней были два лишних байта, возможно для выравнивания...
Её смещение относительно начала структуры на моей 32-битной машине 0x14.

Как компилировать с SDL думаю нет разницы,
буду использовать короткий вариант:

fasm lin32.asm lin32.o 
gcc -lSDL -o lin32 lin32.o

zheland
() автор топика
Ответ на: комментарий от zheland

Правильней.

gcc `sdl-config --libs` -o lin32 lin32.o

И большая просьба, никому свое поделие, которое не получится собрать на современной архитектуре, не показывай. Такие же вот онанисты написали ZSNES, который отличный (пожалуй, даже лучший) эмулятор snes, но который обречен на смерть только потому что там есть куски на асме, когда использовать этот язык для end-user софта можно в олном единственном случае - для альтернативной реализации узких мест, которые _уже_ написаны на C. Счастливо бесполезно потратить время.

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.