Трудно ли программировать спрайтовые движки?

[Romanich]

Приветствую всех!

Не секрет наверное, что я сделал видеокарточку на основе V9990. Что за зверь-думаю объяснять тоже не надо...

В прошлом я сталкивался с программированием 2D-графики на ПЦ. Начинал с софтварной реализации движков, закончил акселерацией "старых" видеокарточек (STrio 64V+, Voodoo2,Vooodoo3, S3 Savage4, RivaTNT M64). Программил естественно под DOS'ом не используя никаких графических библиотек. Пришёл к выводу, что пчти все 2D-движки вышеуказанных акселерированных карточек содержат следующее:
1) Вторичную поверхность - где хранятся спрайты(битмапы)
2) Первичную поверхность - которая отображается на экране
3) Далее идёт либо блитинг поверхностей (с задней поверхности на первую) либо флипинг (когда поверхности рисуемые и отображаемые меняются местами с частотой развёртки дисплея)
4) BitBlt со всеми разновидностями (прозрачность/операции...)
5) Аппаратное Отсечение частей спарйтов(битмапов, выходящих за пределы экрана)
6) Растровые операции при блитинге и битовые маски

При освоении спрайтовых режимов V9990 столкнулся с трудностями - ИМХО неудобно пользоваться спрайтами, так как это на мой взгляд усложняет программирование графики. В памяти VDP есть таблица атрибутов спрайта где указываются: x,y - спрайта, его индекс палитры и атрибуты (mirror/enable /disable,...). Неудобно писать алгоритмы на столкновение двух спрайтов, малое количество цветов на один спрайт, принуждение бить на куски большое изображение итп итд...

Вопрос вот в чем. Может кто-нибудь, кто программил спрайтовые (тайловые) режимы объяснит, как надо писать программы, используя спрайты. В частности интересуют:

1) Как быстрее всего битмап побить на спрайты и оптимизировать цвета при разбиении

2) Как реализовать анализ на столкновение спрайтов

3) Как рулить спрайтами, чтоб удобно выводить большое изображение из них

4) как должен быть построен основной цикл в программе для вывода сих спрайтов

5) и многое другое чего не назвал, но существует в природе

Для V9990 учесть, что 1спрайт=16x16pix, 16 цветов

С удовольствием выслушаю советы и предложения программеров, которые использовали спрайтовую графику :)

[ng_dead]

Как рулить спрайтами, чтоб удобно выводить большое изображение из нихимхо спрайты не предназначены для вывода большого изображения. понятно что не удобно... есть такой прием, если объект большой, то его помещают не как спрайт, а как фон и потом скроллируют и т.п.

[NovaStorm]

По первому знакомству с доками, V9990 для программиста отвратителен.
Для спрайтового движка по-моему тоже не нужно сильно больше чем два экрана, blit'ы с отсечением,color key'ем и альфой.
Картинки бить лучше всего вручную,своей конвертилкой. Хотя я как то встречал подобный софт, универсальности ему не хватало. Так что режь, и уменьшай цвета.
Цикл в общем то измениться не должен. А работа со спрайтами, в том числе и столкновения, обычно требует Z координаты для кусков.
PS:согласно http://msxbanzai.tni.nl/v9990/manual.html у чипа есть "VRAM WRITE ADDRESS" и "VRAM READ ADDRESS" ,но конечно спрайтами быстрее =)

[Romanich]

На всякий случай отмечу, что V9990 имеет 2Д-блиттер, но он настолько медленный, что даже "паршивенькие" видеокарты 90-х превосходили его в десятки раз по скорости.

Инными словами:
1) Софтварный 2Д-рендеринг на ПЦ быстрее блиттера V9990(парадокс но правда)
2) 2Д-движки акселей ПЦшных карт выигрыша в скорости НЕ ДАЮТ по сравнению с 1). Зато офигительно просты в использовании (не надо софтварность самому делать)

справедливо, если писать рендеринг на голом асме ;)

[ng_dead]

Блин, я правильно понял, у v9990 нет флага коллизии спрайтов? или я что упустил?

[Lethargeek]

Имхо на сегодняшний день юзать всякие спрайтовые движки - чистый мазохизм.
А так наверно надо поискать в сети доку на тему "Как написать любительскую игру на Sega" или что-то в этом роде (именно по всяким приемам и стандартным решениям). Наверняка там будет что-то общее для всех спрайтово-тайловых режимов.

Упоминания на collision detection в доках V9990 я тоже не нашел, и почему-то меня сей факт совсем не удивляет... :v2_sleep:

[ng_dead]

Упоминания на collision detection в доках V9990 я тоже не нашел
Ну тогда ручками коллизии вычислять - единственный выход = куча лишних проверок при каждом цикле.
2Romanych. попробуй поискать инфу на MSX-форумах, там много примеров с алгоритмами проскакивает.

[newart]

Блин, я правильно понял, у v9990 нет флага коллизии спрайтов? или я что упустил?
А чем этот флаг проще чем ручная проверка Box'ов спрайтов?
Апаратная коллизия полезна если только учитывает прозрачные пиксели (коллизия с точностью до пикселя).
Тема какая то очень странная, на спектруме писали все ручками и не парились, а тут почти все делает видео проц и возникают такие элементарные вопросы.

[ng_dead]

А чем этот флаг проще чем ручная проверка Box'ов спрайтов?
Позволяет исключить лишние проверки из основного цикла. Вместо того чтобы обсчитывать все коллизии (даже если их нет!), просто проверяем флаг. если 1 уходим на обсчет.

[Romanich]

Тема какая то очень странная, на спектруме писали все ручками и не парились, а тут почти все делает видео проц и возникают такие элементарные вопросы.


нифига она не странная - просто не работал я со спрайтами и всё...
поэтому прошу помочь...

на счёт флага коллизий V9990 - его просто нет

[ng_dead]

на счёт флага коллизий V9990 - его просто нет
Ну тогда коллизии обсчитываем программно, а тут все зависит от типа игрушки и мастерства программиста:)

[Vladimir Kladov]

если спрайты должны содержать больше 16 цветов, это совсем нетрудно организовать несколькими соседними/накладывающимися спрайтами. И удобно делать отдельно анимацию головы/ног/рук. А если прозрачность есть, то вообще, какие проблемы. Удваивается число цветов - элементарно. А потом утраивается, учетверяется, и т.д. Разжевать?

[NovaStorm]

"какие проблемы"? А там же небось кол-во спрайтов ограничено, не на сканлайн, так вообще...

[Robus]

В прошлом я сталкивался с программированием 2D-графики на ПЦ. Начинал с софтварной реализации движков, закончил акселерацией "старых" видеокарточек (STrio 64V+, Voodoo2,Vooodoo3, S3 Savage4, RivaTNT M64). Программил естественно под DOS'ом не используя никаких графических библиотек.

Вау ... Мне нравится !!! А ты можешь поделиться наработками или описаниями как именно программировать эти приколы. Я, вообще-то, тоже как-то STrio 64V+ ковырял на эту тему, но после того как уидел, что другие карты не поддерживали акселераций, то забросил. Но мне было бы очень интересно посмотреть как на низком уровне всё это делается ??? Какие порты, точки памяти... А V9990 я не встречал никогда, или не знаю, что встречал. Но если смотреть вообщем, то не вижу особых проблем программировать спрайты. И их просчёт столкновения то же, вроде, просто. Просто прцессором сравнил коорднаты, или я не понял. Сссори, что за оффтоп.

[Romanich]

Вау ... Мне нравится !!! А ты можешь поделиться наработками или описаниями как именно программировать эти приколы.


Наработки таковы:
1) S3 Trio 64V+ 2D engine
2) S3 Savage4 2D engine (на 3D engine инфы к сожалению не нашёл)
3) Voodoo2 2D+3D (аксель программируется довольно сложно -из-за большой инициализацией всего и вся)
4) Voodoo3 2D+3D (полная противоположность Voodoo2 - лехко ;)
5) Riva TNT M64 2D - и то только блитинг БЕЗ ЦВЕТОВОГО КЛЮЧА (самая глючная аппаратная модель движка - регистры ни к чему не привязаны)

Было это давно... (2004-2005гг)
Что найду у себя зарезервированным на CDR, то выложу :)

Самая классная прога под Voodoo2 и Voodoo3 - полностью портированный туннель Jan'а Horn'а (надеюсь чел известный - пишит OpenGL демо)... И заметьте, я не стал ковырять Glide и прочее - а написал скупое подобие OpenGL

Сорри за оффтоп, но чувствую народу интересно!!! :)



но после того как уидел, что другие карты не поддерживали акселераций, то забросил.


вот это главный недостаток всех акселей. Оптимально было бы сделать так - в биосе спец-функция прерывания - получаем указатель на структуру, состаящую из энтрипойнтов аксель-функций. Вызовы смотреть в шитах и усё! И п*здабол тот кто говорит, что аксель доступен только в защищённом режиме CPU, есть плоский реальный(FLAT) режим - так вот DOS на нём фурычит нормально (в 16-битном режиме доступны 32-битные обращения к памяти - причём все адреса физические, а не линейные как в DPMI)



Но мне было бы очень интересно посмотреть как на низком уровне всё это делается ??? Какие порты, точки памяти...


Относительно старенькие карточки имеют регистры акселя отображенные на порты - такчто можно и в реал-моде к ним лезть :)

Более новые - регистры отображены на 32-битное адр.пространство памяти.

Если найду специикации в .txt - тоже выложу... Для Voodoo2/3 пдфки довольно много весят (их можно в инете найти). Линки постараюсь выложить.

[deathsoft]

Какие порты, точки памяти...
В свое время заказал на S3 печатную документацию на S3 ViRGE (разных моделей), пришли 2 фолианта (страниц по 500) и 2 тонких книжки с отличиями DX2 и GX2 моделей, там подробная дока про 3D с картинками и описание всех memory mapped регистров.

[deathsoft]

получаем указатель на структуру, состаящую из энтрипойнтов аксель-функций.
Был стандарт VBE AF (vesa bios accelerated functions), но на него все забили, т.к. дос сдох к тому времени (поддерживал он только 2D акселерацию). Из прог поддерживающих его знаю только scitech display doctor www.scitechsoft.com (прога досих пор доступна на их ftp)

[Romanich]

Был стандарт VBE AF (vesa bios accelerated functions), но на него все забили, т.к. дос сдох к тому времени (поддерживал он только 2D акселерацию). Из прог поддерживающих его знаю только scitech display doctor www.scitechsoft.com (прога досих пор доступна на их ftp)


Ага! На Allegr'е такая хрень была. Загнулась из-за того что небыла поддержана видеокартостроителями - их просто жаба давит давать доки на свои движки! А VBE AF писалась на основе того ЧТО ИЗВЕСТНО ИЗ ТОГО ЧТО ПРАВДАМИ И НЕПРАВДАМИ УДАВАЛОСЬ ДОСТАТЬ! С приходом ати и нвидиа узнать что-либо стало вообще невозможно!!!

Это раньше можно было спокойненько Glide ломать и подглядывать за его линуксовыми исходниками. Или в VGADoc 1,2,3,4 .txt - смотреть расширенные регистры PCI-карточек. Счас время этого к сожалению прошло :(

Завтра постараюсь выложить кое-что по 2Д/3Д акселерации :)
Проги писались на TMT Pascal, работают под DOS,Win98

[Robus]

Проги писались на TMT Pascal, работают под DOS,Win98

TMT это лучшее, что сделано на ПиЦи из языков !!! Я на нём и сейчас ВСЁ пишу, кстати, у меня есть TMT 4 !!! Сложно было достать !!! Пришли мне, пожалуймта, свои наработки !!! [email protected]

[Romanich]

Господа! Мы отклонились от темы. Про ПЦ эт хорошо, но что-то спрайты обсуждаются как-то вяло! А ну программеры, ну-ка тряхнём кодом ;)

[Romanich]

TMT это лучшее, что сделано на ПиЦи из языков !!! Я на нём и сейчас ВСЁ пишу, кстати, у меня есть TMT 4 !!! Сложно было достать !!! Пришли мне, пожалуймта, свои наработки !!! [email protected]

Robus, я на твой мыл написал письмо - Mail Divelery отплюнул месагу о неудачной попытки послать...

Кинь на мой мыл плиз TMT4. mail: [email protected]

[Romanich]

Вот как обещал - кое что из 2Д/3Д движков некоторых карточек!
ВНИМАНИЕ!!! базовый адрес в некоторых программах взят как константа!!! - поэтому либо юзать PCI INT, либо в свойствах Win98-драйвера смотреть базовые адреса (обычно первый-LFB, второй - Graphic Engine Base Addr.)

[deathsoft]

Robus, я на твой мыл написал письмо - Mail Divelery отплюнул месагу о неудачной попытки послать...

Там ошибка в мыле, лишняя буква 'o' после Asm. Мыло надо было из профиля брать (я послал ему сорцы биоса от nvidia, все ушло нормально)

[Romanich]

Проанализировав, я пришёл к выводу, что не так уж плохи эти спрайты. Ведь на тойже NES, SEGA MD, SNES писали же игры и причём даже неплохие! Просто нужно иметь или приобрести "спрайтовый склад ума", чтоб научиться профессионально использовать их... Есть плюсы у спрайтовых хардварных движков а именно:

1) Не нужно заводить буфера и их чистить (экономия времени и памяти)
2) Перемещение спрайтов достигается изменением нескольких единиц байтов, а не всей площади изображения*глубина цвета (даже при хардварном блитинге таки циклы-их не избежать)
3) Цветовой ключ (также как у DD)

Единственно - это грамотно написать менеджер спрайтов. Что-то типа выделить спрайты с такого-то по такой-то на изображение такое-то ...
Правилен ли ход мыслей или будет гимор? :v2_conf2:

[ng_dead]

Единственно - это грамотно написать менеджер спрайтов. Что-то типа выделить спрайты с такого-то по такой-то на изображение такое-то ...
Правилен ли ход мыслей или будет гимор?
Главное расположить правильно данные в памяти... тогда гемороя не будет.

[Lethargeek]

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

Блиттинг круче все равно. ;)

[Romanich]

Тут концепция 2D-движка (мечта игродела) для матриц:

[NovaStorm]

Судя по структуре, видео память не отображается в основное поле? Если да, то плоховато, хотя и не смертельно. Относительно глубины цвета, хорошо было бы иметь спрайты в 32 бит RGBA(ну или др. порядок) которые бы всасывались и, преобразовываясь, складывались бы в видео память в родном формате.
Относительно функций... мне кажется, что много лишнего. Ни скроллинг(тот же BLIT),ни Positive/negative вроде не нужны. Масштабирование/зеркалирование/вращение/извращение тоже как то без надобности, если есть достаточно памяти правда =) да и потянет ли это AVR? Так что остается блиттинг с ключом и альфой, а если не нужно большего, то почему бы и не железный ДМА в ПЛИС?
Но если смотреть всё в целом, получается хороший движок, хотя и "старомодный".

[Romanich]

Моё дело предложить... А дальше уж смотрите... выбирал функции исходя из своих потребностей и увиденного на практике.
Считаю что эффекты(фильтры/размытие/вращение/...) нужны - хотя бы для анимации или спец-эффектов (вспомните теже Super Nintend'овские игры).

Да и вообще неплохо фильтры OpenGL и Smart адаптировать для 2D. Но я не настаиваю... Кстати, ни у кого нет сорцов смарт фильтрации или формул? (на высокоуровневом языке). А то Степин молчит (да и примеры его на асме - ковырять неудобно...)

[NovaStorm]

http://www.ferzkopp.net/joomla/content/view/19/14/
Оттуда SDL_rotozoom и, возможно, SDL_imageFilter. Пользовался давно, по впечатлениям не быстро, но качественно.
PS: Если есть память, ну её mode7 и пр. Даже на GBA подобное не впечатляет.