Программирование графики на ассемблере?

Question

Я разработал работающий Super Mario Sprite с использованием Visual C ++ 6.0 и DirectX. Но это меня не очень устраивает (изнасилование 3D-мультимедиа-фреймворка для отображения только 2D-спрайта), поэтому я хотел бы иметь возможность программировать анимированный спрайт, используя только C и ассемблер.

Итак, при взгляде на старые игры (например, Wolfenstein) большая часть игры написана на C, и каждый раз, когда дело доходит до вывода графики, используется ассемблер.

К сожалению, при попытке использовать этот старый ассемблерный код всегда появляется сообщение об ошибке «NTVDM.exe обнаружил недопустимую инструкцию», поэтому в настоящее время это не работает.

Есть ли какое-нибудь руководство по графическому программированию на ассемблере, которое все еще полезно?

(Я не хочу использовать раздутые фреймворки или библиотеки, я просто хочу все разработать самостоятельно. WinAPI был бы в порядке для создания полноэкранного окна и для захвата пользовательского ввода, но не для графики, потому что я читал GDI слишком медленный для быстрой графики.)

Я использую WindowsXP и MASM или A86.

Answer 1

Похоже, вы используете только Ассемблер, потому что вы, кажется, думаете, что это необходимо. Это не тот случай. Если у вас нет другой причины для этого (т. Е. Хотите узнать это), не используйте здесь Ассемблер, если вы точно не знаете, что делаете.

Для обычного графического движка программирование на ассемблере совершенно не нужно. Особенно, если речь идет о 2D-спрайт-движке в стиле Super Mario. Даже «медленные» языки сценариев, такие как Python, достаточно быстры для таких вещей в наше время.

Кроме того, если вы не очень точно знаете, что делаете, Ассемблер будет не быстрее, чем С (фактически, скорее всего, он будет медленнее, потому что вы реализовать существующие функции C менее эффективно).

Answer 2

Я полностью согласен с samcl

Основная причина, по которой вы больше не используете ассемблер, заключается в том, что вы больше не можете получить доступ к Videomemory. Еще в первые дни (вы упомянули Castle Wolfenstein) существовал особый режим видео под названием 0x13h , где ваша графика была просто блоком памяти (каждый пиксель представлял собой палитру цветов в диапазоне от 0 до 255 <- 1 Байт) Вы смогли получить доступ к этой памяти через этот конкретный режим видео, однако сегодня все гораздо сложнее </p>

Сегодня у вас очень быстрая Videomemory, и использование вашего ЦП для доступа к нему просто снизит всю производительность, поскольку ваш ЦП подключен через PCI-Express / AGP / PCI / VESA-LOCALBUS / ISA (<- кто-нибудь помнит !?) </p>

Графическое программирование - это часто доступ для чтения и записи (считывание пикселя, проверка прозрачности, умножение на альфа, запись пикселя и т. Д.) Современные интерфейсы памяти намного медленнее, чем прямой доступ внутри графической карты. Вот почему вы действительно должны использовать шейдеры, как предлагает Роберт Гулд. Таким образом, вы можете писать код быстрее и проще для понимания, и это не остановит вашу GFX-память.

ЕСЛИ вас больше интересует программирование GFX, вы можете увлажнить свой аппетит с помощью shadertoy , сообщества, посвященного эффектам на основе шейдеров в сочетании с исполнением Shadercode на основе WebGL.

Также ваш код для начинающего ассемблера будет довольно слабым. по качеству как по производительности. Доверьтесь мне. Для оптимизации такого примитивного кода нужно много времени. Таким образом, ваш скомпилированный код C / C ++ легко превзойдет ваш рукописный ассемблер.

Если вас не интересует Ассемблер, попробуйте написать что-нибудь вроде доступа к диску. Это где вы можете получить много производительности.

Answer 3

Полагаю, если вы уже используете C с DirectX, скорость не имеет значения, и это скорее учебное упражнение. Для 2D под Windows C и DirectX действительно будут очень быстрыми, и, как отмечает Конрад Рудольф, ассемблер с ручным управлением вряд ли будет быстрее, чем высокооптимизированный SDK.

С чисто образовательной точки зрения это интересная деятельность, но довольно сложная. В первые годы существования домашних компьютеров и первых компьютеров PC графический экран представлял собой практически блок памяти, где байты соответствовали одному или нескольким цветным пикселям. Изменяя значение экранной памяти, вы можете отображать точки, а следовательно, и линии, и спрайты и т. Д. На современных ПК это обычно не вариант, поскольку вы программируете видеокарту, обычно через SDK, для сделать ту же работу. Затем карта выполняет тяжелую работу, и вы получаете намного более высокий уровень абстракции. Если вы действительно хотите почувствовать, как это было в тот день, я бы порекомендовал эмулятор. Для современной игры используйте ваши SDK.

Answer 4

Можно запрограммировать собственный 2D-движок в последней версии Directx, если вы хотите исследовать этот путь. Вы можете создать выровненный многоугольник по «экранному пространству», без коррекции перспективы, текстура которого сопоставлена. Затем вы можете нанести ваши спрайты на попиксельной основе на эту карту текстур.

Что касается режима 13h (Питер Паркер), он возвращает некоторые воспоминания!

__asm
{
mov ax,0x13
int 10h
}

Я бы старался избегать ассемблера с полюсом баржи, это может быть особенно трудно отладить и поддерживать; однако, если вы хотите изучить этот предмет более подробно, я могу порекомендовать Черную книгу по программированию Михала Абраша Он немного староват, но хорош для чтения и даст вам некоторое представление о методах графического программирования до 3D-оборудования.

Answer 5

Моя рекомендация - экспериментировать. Возьмите свой спрайт-код и напишите в нескольких формах, начиная с C / GDI и C ++ / DirectDraw. Пока не беспокойтесь об ассемблере.

DirectX - ваш лучший выбор для быстрой графики. Изучите это, затем выясните, как оптимизировать микро с помощью ассемблера. В общем, ассемблер не собирается делать ваши вызовы API быстрее. Это откроет гибкость для более быстрых вычислений для таких вещей, как 3D вращение, наложение текстуры, затенение и т. Д.

Начните с DirectDraw. Вот FAQ . Технически, DirectDraw устарел после DirectX 7, но вы все равно можете использовать его и учиться на нем. Это позволит вам напрямую модифицировать кадровый буфер, что вы, вероятно, и ищете.

На TripleBuffer Software .

есть несколько полезных руководств и форумов.

Также рассмотрите возможность обновления вашего компилятора до Visual C ++ 2008 Express . VC ++ 6 имеет глючный компилятор, который может быть проблематичным при попытке скомпилировать определенные библиотеки C ++.

Answer 6

Ассемблер для графики был из-за того, что в то время большинству людей не хватало видеокарты с поддержкой 3d, поэтому это нужно было делать на процессоре, а не больше. В настоящее время речь идет о шейдерном программировании. Языки шейдеров позволяют обниматься с голым металлом. Так что, если вам что-то нужно попытаться закодировать в качестве основы для шейдера 2-мерной графики, этот опыт будет иметь ценность как навык карьеры.

Попробуйте CUDA для начала.