Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Мнение (только геймерам) (4 стр)

Мнение (только геймерам) (4 стр)

Страницы: 1 2 3 4
Удалёнwww15 апр. 20033:38#45
По поводу разумных требований... Тут пишут про гигагерцы и GF3... А вообще-то в основной массе у народа компы <600mhz, карты GF2MX (а то и RIVA - сам совсем недавно сменил, на GF4MX)... Это для России (для остального мира гигагерцы и GF3 приемлимы:).. Так что чем ниже требования - тем лучше. Аналогично и с размером...
DexusУчастникwww24 апр. 20038:21#46
Насчет попиксельного "затенения":
Я бы ОЧЕНЬ не советовал делать его в видеобуфере, поскольку попиксельный доступ туговат в него, несмотря на AGP.
Использовать blit VidMem->VidMem можно только в примитивных одноцветных (без лайтинга) DirectDraw игрухах.
При выводе одного тайла склеиваются 1-20 спрайтов (использовать инструкции MMX), и на результативный через xlat накладывается новая палитра.
В результате количество обрабатываемой графики (например 2 этажа тайлов) получается порядка в 15 раз больше объема фронт-буфера, с учетом того, что они будут накладываться по несколько раз друг на друга. Это при максимальной насыщенности тайлами. На разрешении 640х480 в полный экран графики (попиксельное затенение) будет обрабатываться на 10 мегабайт. Это - ОЧЕНЬ немало. И если учесть, что кроме попиксельного затенения еще будет идти чтение около 40 мегабайт с самих спрайтов... Конечно, с оптимизацией "плотности" самой местности, спрайтового движка, можно уменьшить эти объемы в 2-5 раз.

Например, в том же x-com сделали такую палитру, адаптированную под разную "освещенность". А насчет теней от объектов, которые будут вечером растягиваться на пол экрана: кому эта бесполезная красота нужна? Лишние нагрузки на проц, которые никакой пользы не несут. Ведь большая часть игр вообще условны по своей природе, и ни о какой близости к реалу речи нет (имеется в виду изометрия). И вообще в данном ракурсе если рассматривать игрушку то лучшим и стильным вариантом будет pixel-graphics безо всяких левых теней. Одна шаблонная небольшая тень наискось - и хватит. И кому какое дело с какой стороны солнце и что тени не вытягиваются как надо?.. не в этом же смысл игрухи, в конце концов :).

Кстати, подобная перенасыщенность "слоёной" графикой, свойственная изометрии, в основном и убивает все ресурсы, и именно по этой причине новые изометрические проекты по типу fallout и xcom до конца редко доходят, хоть и зачинаются с большой охотой.

Если использовать 16битный цвет, то полезность MMX может сильно возрасти. И затенение можно с помощью того же MMX. MMX вообще не использовать глупо, он только в раритетных компах отсутствует.

По поводу вопросов:
1. Сложный вопрос, и скорее да чем нет, хотя это зависит от эффектов, насколько они могут компенсировать отсутствие "темных мест".
2. Меньше 5.
3. Желание скачать может появиться только после появления достаточного количества скриншотов, и хорошего feature list. Объем же может быть хоть 400 метров. Но желательно при этом иметь демку метров в 20, в которой можно было бы увидеть/пощупать скорости и все остальное.
4. Прогрессивные геймеры всегда стараются иметь новейшее железо. Вскоре это уже будет не менее 2GHz и памяти не менее 256. А если расчитывать на более широкий круг, то это от гигагерца и 128 мегабайт.

DM!Постоялецwww24 апр. 200312:45#47
Dexus
Подскажи пожалуйста как можно использовать MMX, в описанном тобой случае на VC++. Или дай плиз ссылочку, где можно про это почитать, желательно по русски.
А на счет шаблонной тени полностью согласен, но надо учитывать что есть еще и анимация (как минимум 5 кадров)
DexusУчастникwww26 апр. 200322:01#48
DM!
Уважаемый, хороших примеров по MMX, да еще и на русском вы вряд ли где найдете.
http://www.gamedev.ru/forum/?action=showtopic&group=5&topic=188 - Вот тут я перевел статью одну, правда староватенькую, но наверно в ней есть кое что полезное.
А вообще я нашел описание ММХ на русском ( http://www.intramail.ru/~dexus/MMX.ZIP )
И один пример с 16битным альфа-блендингом для VC++ ( http://www.intramail.ru/~dexus/ht_alpha.zip )
Прошу еще учесть что все эти операции эффективно можно производить только в системной оперативке, а не в видео.
при работе с 8ми битным цветом есть одно приимущество - работа с 8ми точками за одну операцию. Но при этом нет возможности делать прозрачности и тени, а при 16битах всего 4 точки за раз, причем придется по маскам разбивать цвета по компонентам и обрабатывать отдельно, а потом снова склеивать. Довольно муторно. Но оптимизировать способов достаточно. Главное хорошо подумать. И ядро спрайтового движка писать на чистом асме.
DexusУчастникwww27 апр. 200312:48#49
Кстати, тут появилась идея использовать Direct3D для анимации и отображении персонажа.. (Скины, модельки, движения), хранить графики надо гораздо меньше, если будет большое разнообразие внешнего вида и анимации. Делать RendertoSurface и использовать D3DXMatrixOrthoRH.
Страницы: 1 2 3 4

/ Форум / Программирование игр / 2D графика и изометрия

Тема в архиве.

2001—2018 © GameDev.ru — Разработка игр