Обдумываю проект простенькой игры. Предпологается среда разработки — VS, язык Visual C++.
Предпологается полноэкранный режим работы, поддерживающий различные разрешения и форматы экранов (должно легко масштабироваться).
Вся графика двухмерная, спрайтовая. Т.е. просто есть набор маленьких картинок, из них мы формируем одну на весь экран. Но таких слоёв будет много (одна картинка сформированная из спрайтов, потом местами с прозрачностью накладываются ещё спрайты, поверх ещё и потом ещё).
Никогда не работал с графикой (выводил на экран картинку с помощью DirectDraw и рисовал на Canvas у визуальных компонентов в Delphi).
Подскажите что вообще использовать для работы с графикой: для вывода сформированных из спрайтов изображений на экран и для формирования самих картинок из спрайтов?
Что я думаю по этому сам:
Для вывода графики:
Почитал я про OpenGL, так как я понял (возможно плохо читал, ткните хорошими ссылками) он используется исключительно для 3d графики и его использование для двухмерной будет извращением (какие-то страшные вещи с расположением объектов в пространстве, с освещением — мне этого всего не нужно), но бибилиотеки эти есть и под win и под *nix, это плюс.
DirectDraw — я так понял это виндовский механизм для быстрой работы с видеопамятью, я неможко с ним поковырялся, сделал что-то типа слайд-шоу, но так толком и не понял как с его использованием можно делать нечто серьёзное (читал на firststeps.ru, перед этим вообще что это такое где-то ещё читал (куда поисковик показал)).
Что ещё можно использовать? Как работаете с графикой вы?
Для подготовки картинок из спрайтов:
В винде с GDI... очень медленно... Но как иначе? У меня есть bmp-шки допустим размерами 16х16 точек, а мне из нужно быстро собирать картинки 1200х1024, да ещё и с масштабированием, накладывать одни на другие с прозрачным цветом и вообще с прозрачностью (просвечивающие)...
Подскажите пожалуйста, как это по-людски делается?
Вся работа с графикой у меня сводиться к следующему:
из маленьких bmp-шек собираю картинки (сразу масштабирую или потом, когда уже собрал),
накладываю их одну на другую с разными настройками "прозрачного" (которого не будет вообще) цвета и с общей прозрачночтью (всех цветов, чтобы под верхней картинкой просвечивала нижняя),
рисую это всё на экране.
Буду рад советам, ссылкам, рекомендациям и пинкам, направляющим на верный путь — как сделать чтобы это было красиво для глаз пользователя в конечном итоге и чтобы работало быстро (не супер быстро, но не как с GDI).
Здравствуйте, Green Chest, Вы писали:
GC>[SKIPPED]
DirectDraw — устаревшая технология, современная двумерная графика делается на Direct3D/OpenGL. Прошли те времена, когда прямая работа с видеопамятью и фреймбуфером для вывода спрайтов была быстрее вывода текстурированных треугольников.
Рекомендую обратить взор на SDL — кроссплатформенную библиотеку для разработки игр и им подобных программ. Предоставляет библиотеки для работы с вводом (клавиатура, мышь, джойстик), звуком, сетью, помимо этого есть кроссплатформенный способ инициализации OpenGL. Есть и способ вывода графики в стиле DirectDraw, но, как уже было сказано, при наличии 3D-ускорителя это использовать бессмысленно. Если не выходить за рамки предоставляемого библиотекой API, программа может быть портирована на Linux и MacOS путем простой пересборки.
Direct3D или OpenGL без вариантов. С видюхой гоняться совершенно не реально. Даже если она дешовая и встроеная.
Натягиваешь текстуру на 2 треугольника и получаешь масштабирование, повороты, альфу,... с сумашедшей скоростью.
Освещение и тп можно не использовать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Не повторяй мою ошибку. Бери сразу OpenGL. Я начал писать игру на SDL потом начали вылезать такие задачи как клиппинг (написал свой клипер), потом игровая логика, потом большие куски перерисовки. И в какой то момент времени всё это хозяйство начало подтормаживать, а хотелось ещё и ещё навернуть. В результате начинаешь понимать что в этих рамках больше сделать ничего не получиться.
Благо писал всё за своим интерфейсом, так что переход на OpenGL сделал за несколько дней.
Вылезли правда другие проблемы, например я так и не сделал до сиих пор blur эффект, потому как ориентируюсь на слабые карты, но зато аппаратное ускорение, дало больше возможностей. От SDL в проекте осталась только системная прослойка (клавиатура, мышь, главное окно).
Здравствуйте, WolfHound, Вы писали:
WH>Direct3D или OpenGL без вариантов. С видюхой гоняться совершенно не реально. Даже если она дешовая и встроеная. WH>Натягиваешь текстуру на 2 треугольника и получаешь масштабирование, повороты, альфу,... с сумашедшей скоростью. WH>Освещение и тп можно не использовать.
Спасибо, что не прошли мимо. Так вот, мне самому хочется на OpenGL это сделать... Но во-первых я ничего подобного не могу найти нигде, во-вторых смущает само действо — вы предлогаете организовать некое псевдо-2d и использовать объёмные объекты, их текстурирование для 2d графики.
Михаил Фленов в "DirectX и C++ Искусство программирования" (2006-ой год!) пишет (см. стр. 47) что когда DirectX используется для вывода уже готовых изображений (а у меня такой случай и есть — я формирую сразу из спрайтов несколько картинок — а потом их уже надо одну на другой показать на экране), то "тяжеловесный Direct3D" использовать не имеет смысла, а куда выгоднее использовать "DirectDraw и его интерфейс IDirectDraw" (хоть и оговаривается что DirectDraw стар, но при том в нём есть всё необходимое). Далее в книге он хорошо объясняет как выводить спрайтовую графику с его использованием и с прозрачностью примеры показывает, когда.
Я сколько ни читал, в инете везде, где нашёл что-либо про OpenGL идёт работа с исотничками света, вращением, расположением объектов в пространстве, туманами, какими-то причудливыми отражениями одних объектов в других, фантастическими тенями и прочим... Я пытался найти как создать просто плоскость и применить на ней готовую текстуру (что кстати не избавляет нас от каких-то мучительных собираний спрайтов в одну готовую картинку) — с использованием DirectDraw я дня за два разобрался и сделал это, а вот с OpenGL — я даже близко никаких примеров найти не могу, на нём я так понял вообще никто подобного не делает и никому этого не нужно, а используют что-то иное для 2D. Но вот что...
Помогите мне пожалуйста, покажите (или дайте ссылки), как мне выводить готовые картинки на OpenGl или Direct3D c наложением одна на другую с прозрачностью всех цветов и использованием польностью прозрачного цвета (фонового) и как делать анимацию поверх этого.
Хоть что-нибудь!
Перво на перво стоящая задача до идиотизма проста:
Есть массив однобайтных целых допустим 75х64 (двумерный он), заполнен некими значениями. Есть 256 картинок, они уже в памяти, в удобном для дальнейшего использования виде, в отдельном классе, отвечающим у меня за работу со спрайтами.
Заполнить экран спрайтами, соответствующими значениям массива, если array[0][0] равно 0, то берём из класса нулевой спрайт, его масштабируем до размера (текущая_ширина_экрана/75) — таким образом формируем картинку.
Это первый слой. Земля, вода всякая.
Дальше поверх этого слоя делаем второй слой — травинки, зверинки, лесинки-осинки — спрайты-то квадратные, поэтому часть этого слоя должна быть полностью прозрачной.
Дальше ложим третьи слой — главный герой и его друзья (тоже спрайты, тоже местами полностью прозрачны).
И наконец, ложим четвёртый слой — всякие затемнения, помутнения поверх (аля туман войны) всего этого — теперь мы используем частиную прозрачность.
А ещё надо выделить героя моргающим, меняющим цвета кружочком.
Я знаю как это всё сделать с исп. DirectDraw (что не знаю, то написано у Михаила Фленова в книге).
Но мне не нравится DirectDraw, блокирование кусков памяти для прямой с ними работы, отсечение не влазящих поверхностей и прочие странности... Да и это решение под винду лишь.
Помогите примитивнейшим образом это сделать на OGL. Хоть какие-то наброски, ссылки, советы.
Спасибо.
Здравствуйте, nen777w, Вы писали:
N>Не повторяй мою ошибку. Бери сразу OpenGL
Спасибо огромное за ответ.
Потом:
Да, я вот всё на эти библиотеки слюни и пускаю, но блин, не могу я разобраться, как мне с 2d работать. Она заточена под страшные вещи (освещение, тени, вращение-размещение объектов) — а мне нужно-то в три слоя картинки спрайтов нарисовать и на них юнитик один кружочком маргающим выделить.
За два дня я разобрался с DirectDraw и смог хотя бы картинки рисовать на нём, но OGL!!! Даже примеров какого-нибудь псевдо что-ли 2d (смешно, раньше делали псевдо 3d, а сейчас вот мне в другой ветке тут предлагают делать объёмные фигуры и их одной текстурированной гранью показывать) не могу найти...
Я в соседней ветке этой темы
Здравствуйте, Сергей, Вы писали:
С>DirectDraw — устаревшая технология, современная двумерная графика делается на Direct3D/OpenGL.
Делается? Вы умеете У меня нифига не делаются Помогите примерами, в соседней ветке этой темы
подробнее описал и попросил. Офисный софт (эконом., бух.) в моих руках делается вроде хорошо (значит ближе к плечам они у меня растут, что в свою очередь значит, что я смогу наверное понять ваши примеры и советы (мб ссылки)), а свою детскую мечту — простенькую игрушку не могу сделать исключительно из-за того что не могу нормально осуществить работу с 2d графикой.
С>Прошли те времена, когда прямая работа с видеопамятью и фреймбуфером для вывода спрайтов была быстрее вывода текстурированных треугольников.
Хм, а чем вы руководствуетесь? Я сам с графикой не работал, только пару дней разбирался с DirectDraw и день с OpenGL, но вот читал книгу Михаила Фленова в 2006-ом году вышедшую, где он писал, что DirectDraw для 2d значительно выгодней, чем Direct3D. Я подробно описал это другому участнику обсуждения, давшему подобные вашим рекомендации, в соседней ветке этой темы
, ответьте пожалуйста там.
С>Рекомендую обратить взор на SDL — кроссплатформенную библиотеку для разработки игр и им подобных программ.
Спасибо, обратил
Здравствуйте, Green Chest, Вы писали:
GC>Я сколько ни читал, в инете везде, где нашёл что-либо про OpenGL идёт работа с исотничками света, вращением, расположением объектов в пространстве, туманами, какими-то причудливыми отражениями одних объектов в других, фантастическими тенями и прочим... Я пытался найти как создать просто плоскость и применить на ней готовую текстуру
Да ладно.
Нашол за несколько кликов. http://www.opengl.org/resources/code/samples/redbook/
GC>(что кстати не избавляет нас от каких-то мучительных собираний спрайтов в одну готовую картинку)
Что там мучительно натянуть текстуры на треугольники?
GC>- с использованием DirectDraw я дня за два разобрался и сделал это, а вот с OpenGL — я даже близко никаких примеров найти не могу, на нём я так понял вообще никто подобного не делает и никому этого не нужно, а используют что-то иное для 2D. Но вот что...
OpenGL или D3D.
Вот например: http://www.enkord.com/games/clashnslash/download/
Работает на сколько я понял через Direct3D. Если что yxiie поправит.
С какой скоростью это бы работало если бы это попытались сделать через DDraw лучше не думать.
GC>Есть массив однобайтных целых допустим 75х64 (двумерный он), заполнен некими значениями. Есть 256 картинок, они уже в памяти, в удобном для дальнейшего использования виде, в отдельном классе, отвечающим у меня за работу со спрайтами.
Загоняешь эти картинки в одну (или несколько если в одну не влазят) текстур.
И загружаешь это один раз в видео память.
GC>Заполнить экран спрайтами, соответствующими значениям массива, если array[0][0] равно 0, то берём из класса нулевой спрайт, его масштабируем до размера (текущая_ширина_экрана/75) — таким образом формируем картинку.
Скармливаешь видюхе треугольники с правильными координатами и текстурными координатами и все.
GC>Дальше поверх этого слоя делаем второй слой — травинки, зверинки, лесинки-осинки — спрайты-то квадратные, поэтому часть этого слоя должна быть полностью прозрачной.
Замечательно.
Делаем также только текстуры с полупрозрачностью.
GC>Дальше ложим третьи слой — главный герой и его друзья (тоже спрайты, тоже местами полностью прозрачны).
Таже фигня.
GC>И наконец, ложим четвёртый слой — всякие затемнения, помутнения поверх (аля туман войны) всего этого — теперь мы используем частиную прозрачность.
Тоже самое.
GC>А ещё надо выделить героя моргающим, меняющим цвета кружочком.
Делаешь текстуру с кружком и...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Green Chest, Вы писали:
GC>(смешно, раньше делали псевдо 3d, а сейчас вот мне в другой ветке тут предлагают делать объёмные фигуры и их одной текстурированной гранью показывать)
Раньше небыло на каждом компе по специальной железке которая ну ооооооооооочеееееееееееень быстро рисуют текстурированные треугольники.
А что умеют последние видюхи их уже даже не по назначению начали использовать... математики на них всякую фигню считают... ибо ну очень быстро они чиселки молотят.
И не объемные фигуры, а просто 2 треугольника.
Или вобще один. Но тут текстура будет не экономно расходоваться.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Да ладно. WH>Нашол за несколько кликов. WH>http://www.opengl.org/resources/code/samples/redbook/
Да ладно
GC>>(что кстати не избавляет нас от каких-то мучительных собираний спрайтов в одну готовую картинку) WH>Что там мучительно натянуть текстуры на треугольники?
Дак ведь не одна текстура, а спрайты... Не представляю вообще как это будет.
Ладно, уйду смотреть ссылки, как насмотрюсь — вернусь.
GC>>А ещё надо выделить героя моргающим, меняющим цвета кружочком. WH>Делаешь текстуру с кружком и...
Так есть возможность накладывать много раз текстуры на текстуры?
Здравствуйте, Green Chest, Вы писали:
WH>>Делаешь текстуру с кружком и... GC>Так есть возможность накладывать много раз текстуры на текстуры?
Да, расширение GL_ARB_multitexture.
Здравствуйте, Green Chest, Вы писали:
GC>Михаил Фленов в "DirectX и C++ Искусство программирования"
Достал книжку. После прочтения законов "оптимизации" становится ясно что автор "крутой хацкер" в худшем смысле этого слова.
Причем он временами пишет правильные вещи и тутже на следующей строке полный бред.
Здравствуйте, Green Chest, Вы писали:
GC>Дак ведь не одна текстура, а спрайты... Не представляю вообще как это будет.
А спрайт это текстура натянутая на 2 треугольника.
GC>Так есть возможность накладывать много раз текстуры на текстуры?
1)Есть.
2)Можно и не накладывать. Просто рисуешь еще 2 треугольника поверх.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Green Chest, Вы писали:
GC>Обдумываю проект простенькой игры. Предпологается среда разработки — VS, язык Visual C++. GC>Предпологается полноэкранный режим работы, поддерживающий различные разрешения и форматы экранов (должно легко масштабироваться). GC>Вся графика двухмерная, спрайтовая.
Могу предложить посмотреть на hge Получаешь аппаратное ускорение через DirectX8, очень простой интерфейс, разобраться с которым можно за пару часов, а с другой стороны при желании всегда можно чуть влезть под капот (хотя совершенно не обязательно)
Разбираться сейчас с OpenGL и Direct3D, когда уже хочется писать игру — нафига? Тебе чего хочется, разбираться или игру делать? Кстати пока сделаешь многие вопросы сами собой закроются.
Ну ты ошибаешься что на OGL никто ничего не делает.
Во первых, OGL позволяет кроссплатформенность, это не маловажно, по карйней мере для меня.
Во вторых. Не хочеится разбираться со API возьми уже готовый движок, например OGRE (он умеет рисовать и OGL и DX9)
В тpетьих. Если тебе нужно только 2D. Вот простой пример, настройки ортогональной проэкции с (0,0) в верхенм правом углу:
Что бы понять код достаточно заглянуть в MSDN и почитать справку. Всегда помни что OGL это машина состояний.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Green Chest, Вы писали:
GC>>Михаил Фленов в "DirectX и C++ Искусство программирования" WH>Достал книжку. После прочтения законов "оптимизации" становится ясно что автор "крутой хацкер" в худшем смысле этого слова.
Законы оптимизации там вполне нормальные, банальные так скажем.
Но, про список книг "глазами хакера" и вообще про книгу — действительно видно, что не профессионал этого дела пишет.
Так же вы писали:
"Вот например: http://www.enkord.com/games/clashnslash/download/
Работает на сколько я понял через Direct3D. Если что yxiie поправит.
С какой скоростью это бы работало если бы это попытались сделать через DDraw лучше не думать."
Увы и ах, программа запустившись и показав чёрный экран намертво вешает ОС (под VMWare запускал, в winXP prof sp2, half-life 2 работает кстати под ней)...
Могу только погуглить чего-нибудь, на большее просто времени нет.
GC>а свою детскую мечту — простенькую игрушку не могу сделать исключительно из-за того что не могу нормально осуществить работу с 2d графикой.
Может, в таком случае проще взять готовый движок?
С>>Прошли те времена, когда прямая работа с видеопамятью и фреймбуфером для вывода спрайтов была быстрее вывода текстурированных треугольников. GC>Хм, а чем вы руководствуетесь?
Современные (начиная с четырех-пятилетней давности) видеокарты очень быстро рендерят треугольники, с текстурой и альфа-каналом. При этом на борту несут достаточное количество памяти для полной загрузки всей нужной растровой графики. Реализация даже простейшего альфа-канала мощностями CPU через DirectDraw будет в десятки, если не сотни раз медленнее.
GC>Я сам с графикой не работал, только пару дней разбирался с DirectDraw и день с OpenGL, но вот читал книгу Михаила Фленова в 2006-ом году вышедшую, где он писал, что DirectDraw для 2d значительно выгодней, чем Direct3D. Я подробно описал это другому участнику обсуждения, давшему подобные вашим рекомендации, в соседней ветке этой темы
Здравствуйте, Green Chest, Вы писали:
GC>Законы оптимизации там вполне нормальные, банальные так скажем.
Я бы сказал глупые. Автор не знает что даже древние компиляторы умеют заменять умножение/деление на степень двойки на сдвиги.
Да и циклы раскручивают все кому не лень.
Если уж что и оптимизировать это работу с кешем процессора. У меня получалось до 100 раз разгонять алгоритмы укатывая их под кешь процессора.
GC>Увы и ах, программа запустившись и показав чёрный экран намертво вешает ОС (под VMWare запускал, в winXP prof sp2, half-life 2 работает кстати под ней)...
Это к yxiie. Но скорей всего из-за защиты ибо это шароварка.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Green Chest, Вы писали:
GC>Буду рад советам, ссылкам
обрати внимание на PopCap Framework..
лично мне он нравится сильно больше, чем тот же самый hge.. имхо hge написан не самым вкусным образом..
по функциональности попкап умеет делать:
1. рендер (софтовый и аппаратный), на 3Д не ориентирован, то можно сделать(проверял).. по умолчанию используется DX7(в hge DX8).. авторы обещали переписать на DX9, но пока не торопятся выкладывать новую версию..
2. звук (DirectSound, BASS и FMod)
3. управление (мышь, клавиатура)
3. управление ресурсами (графика, звуки, тексты).. При росте проектов многое дописывается или заменяется..
4. может слать http-запросы, но видимо это только для записи рекордов
5. может запускать флэш.. но на большом разрешении это будет тормозить, т.к. рисуется через gdi.. на мелком разрешении всё нормально..
всё сделано на достаточно простом уровне, чтобы научиться с ним работать за день-два.. есть простые туториалы..
Здравствуйте, neFormal, Вы писали:
F>обрати внимание на PopCap Framework.. F>лично мне он нравится сильно больше, чем тот же самый hge.. имхо hge написан не самым вкусным образом..
Спасибо, посмотрим-с.
у меня игра на directdraw написана, использующая два буфера, переключающихся через flip. теперь решил её полностью на direct3D переписать. но подходящей литературы на русском нет. так что приходиться изучать английский и смотреть в сторону gamedev.net
не знаю, нужно ли программисту понимать, как работает direct3D на низком уровне — как выполняется проецирование, накладываются текстуры, освещение.
в любом случае удачи в этом непростом геймдэве.
Я не спец в графике, но всегда думал что для 2D всегда можно использовать AntiGrainGeometry (http://www.antigrain.com/).
Почему никто не предлагает эту библиотеку?
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Green Chest, Вы писали:
M>Я не спец в графике, но всегда думал что для 2D всегда можно использовать AntiGrainGeometry (http://www.antigrain.com/). M>Почему никто не предлагает эту библиотеку?
Здравствуйте, Аноним, Вы писали:
А>А кстати, какое у неё назначение? Спрашиваю безо всяких подколок и издевок — просто дейтсвильно интеренос когда юзать AGG а когда OPenGL
agg — векторная графика, высококачественная. софтварный рендер.
opengl — это все же больше 3D библиотека. "дверь" к видеокарте и аппаратному ускорению.
И как следаствие тормоза на больших объемах данных (например 10000 градиентных прямоугольничков)
8>opengl — это все же больше 3D библиотека. "дверь" к видеокарте и аппаратному ускорению.
И как следствие на болших объемах данных надо юзать его?
Все это я говорю про 2D — ясно что в 3D лезть с AGG не надо
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, 8bit, Вы писали:
8>>agg — векторная графика, высококачественная. софтварный рендер. А>И как следаствие тормоза на больших объемах данных (например 10000 градиентных прямоугольничков)
Да, а как же без этого, но тут все от цели и задачи зависит.
8>>opengl — это все же больше 3D библиотека. "дверь" к видеокарте и аппаратному ускорению. А>И как следствие на болших объемах данных надо юзать его?
Опять же, это смотря какие цели и что вообще вам нужно. Может оказаться что будет наоборот,
еще медленне чем с софтварным рендерингом, да и качество может оказаться намного ниже.
Современное железо ведь ничего кроме как треугольники рисовать не умеет. Рисовать на нем
"вектор" ох как не просто.
Здравствуйте, Green Chest, Вы писали:
GC>Здравствуйте!
GC>Обдумываю проект простенькой игры. Предпологается среда разработки — VS, язык Visual C++.
Я бы брал HGE либо PopCap framework
Re[3]: Что лучше для двухмерной графики?
От:
Аноним
Дата:
20.10.08 12:57
Оценка:
Здравствуйте, Green Chest, Вы писали:
GC>(хоть и оговаривается что DirectDraw стар, но при том в нём есть всё необходимое)
Здравствуйте, dmSoketov, Вы писали:
S>Я бы брал HGE либо PopCap framework
Чтобы нарисовать пару десятков текстурированных треугольников? Народ, да вы что? Такой "движок" ваяется за час-полтора и содержит пару сотен строк кода (причём большая часть из них — код инизиализации). Берёте в зубы DX SDK и курите там раздел, посвящённый инициализации (или тупо копируете из сэмплов), и раздел, посвящённый рендерингу (чтобы знать, что такое Vertex buffer и текстура и как всё это хозяйство скормить дровам). Собственно, всё.
Звук на DS тоже делается в два счёта — в простом случае покатит тупое проигрывание из памяти безо всяких извращений типа кольцевых буферов (хотя конечно если предполагается фоновая музыка, то для неё лучше бы заморочиться — ибо 50-60 МБ памяти, которые съедает типичный 5-6 минутный аудиотрек, лишними не бывают). С другой стороны, музон можно и системными стредствами играть (дабы не геморроиться с раскодировкой на лету), ибо 3D-эффекты тут, как правило, не нужны...
Короче, моя рекомендация — забей на движки и просто покури пару-тройку часов DX SDK — благо там весьма вменяемо всё описано, и есть куча сэмплов, демонстрирующих разные фичи (тебе оттуда понадобится разве что код инициализации всего этого добра). После этого ты будешь в состоянии сваять движок, удовлетворяющий твоим требованиям.
Здравствуйте, koandrew, Вы писали:
S>>Я бы брал HGE либо PopCap framework K>Чтобы нарисовать пару десятков текстурированных треугольников? Народ, да вы что? Такой "движок" ваяется за час-полтора и содержит пару сотен строк кода (причём большая часть из них — код инизиализации).
пруф?. +)
K>Берёте в зубы DX SDK и курите там раздел, посвящённый инициализации (или тупо копируете из сэмплов), и раздел, посвящённый рендерингу (чтобы знать, что такое Vertex buffer и текстура и как всё это хозяйство скормить дровам). Собственно, всё.
и получаете в итоге трэш, который надо как то использовать..
K>(хотя конечно если предполагается фоновая музыка, то для неё лучше бы заморочиться — ибо 50-60 МБ памяти, которые съедает типичный 5-6 минутный аудиотрек, лишними не бывают).
и тут пошли нюансы, на которые уходит большинство времени..
K>Короче, моя рекомендация — забей на движки и просто покури пару-тройку часов DX SDK — благо там весьма вменяемо всё описано, и есть куча сэмплов, демонстрирующих разные фичи (тебе оттуда понадобится разве что код инициализации всего этого добра).
потом пару-тройку дней поотлаживай это добро..
K>После этого ты будешь в состоянии сваять движок, удовлетворяющий твоим требованиям.
ему игру сделать надо или движок написать?.
гуй ему тоже самому делать?.
а управление ресурсами?.
а систему окон?.
а поддержку разных форматов?.
а ..........
Вы так говорите, как будто это пара-тройка лет. Пара-тройка дней долбления головой об стенку при освоении новой технологии — нормальная штатная ситуация для программиста. Если это пугает, лучше вообще не браться.
Здравствуйте, Панда, Вы писали:
F>>потом пару-тройку дней поотлаживай это добро..
П>Вы так говорите, как будто это пара-тройка лет. Пара-тройка дней долбления головой об стенку при освоении новой технологии — нормальная штатная ситуация для программиста. Если это пугает, лучше вообще не браться.
Все кто чего-то достигли стояли на плечах предшественников. С таким подходом можно и операционку для своей игры написать или даже компьютер сконструировать.
А насчёт того, что можно за пару тройку дней написать аналог базовой библиотеки hge — это неправда, если нет опыта работы с DirectX. Что-то сделать можно, как раз за пару дней, а потом, когда будет игра, полезут проблемы. Потому, что у индивидуального разработчика — один, два компьютера, и далеко не всегда он, например, отладит мультимониторные конфигурации. Просто не подумает о проблемах с переключением на другие приложения (а такие проблемы регулярно бывают даже в коммерческих играх).
Здравствуйте, neFormal, Вы писали:
F>пара-тройка дней, если не вылезает каких либо экстенных проблем с пониманием..
F>оценки создания адекватного движка были слишком оптимистичны..
Выделенное слово здесь ключевое. Что автору нужно от движка (как я понял):
1. перечисление допустимых видеорежимов
2. Загрузка спрайтов (читай — текстур). Одна строчка кода (в D3DX есть такая ф-ция, если мне память не изменяет)
3. Фоновый слой — тут 2 треугольника с натянутой текстурой (текстура должна быть достаточно большая, дабы не проявлялись артефакты фильтрации)
4. Передний слой — тут по 2 треугольника на спрайт + матрицы трансформации (в общем-то тоже детский сад, особенно если помнишь институтский курс линейной алгебры)
Собственно, всё. По поводу звука — тут тоже в общем-то всё несложно (примеры опять-таки есть в СДК, в том числе для DS3D, хотя я с трудом представляю, зачем это может понадобиться в 2D приложении). Инпут — обойдётся виндовыми сообщениями, хотя и подцепить DI тоже не ахти какая сложная задача.
Итого в худшем случае имеем день-полтора активного курения СДК + экспериментов и ещё максимум день собственно написания движка + тестирование. То есть 1-2 weekend'а должно быть более чем достаточно.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, neFormal, Вы писали:
F>>пара-тройка дней, если не вылезает каких либо экстенных проблем с пониманием..
F>>оценки создания адекватного движка были слишком оптимистичны..
K>Выделенное слово здесь ключевое. Что автору нужно от движка (как я понял): K>1. перечисление допустимых видеорежимов K>2. Загрузка спрайтов (читай — текстур). Одна строчка кода (в D3DX есть такая ф-ция, если мне память не изменяет) K>3. Фоновый слой — тут 2 треугольника с натянутой текстурой (текстура должна быть достаточно большая, дабы не проявлялись артефакты фильтрации) K>4. Передний слой — тут по 2 треугольника на спрайт + матрицы трансформации (в общем-то тоже детский сад, особенно если помнишь институтский курс линейной алгебры)
Очевидно, что этого недостаточно, т.к. также нужно как минимум еще создать окно и инициализировать DirectX Если честно, то из документации к DX SDK как это сделать так, чтобы заработало везде — попросту неясно (если говорить о DX8 (а уж DX7, это вообще), в 9 вроде бы проще стало, но я бы для простых игр пока на 8 ориентировался). Кроме того надо, хоть и не столь обязательно, обработать переключение между приложениями, не давать системе заснуть, пока игра крутиться, в общем не забыть о куче всяких нюансов. И оттестировать всё это сильно по разному работающее на разных системах и компьютерах дело, на соответственно разных компьютерах и системах, чтобы потом не было мучительно больно отвечать на вопросы типа "а у меня игра не запускается, говорит нет такой-то dll, причем установка последнего DirectX не помогает".
K>Итого в худшем случае имеем день-полтора активного курения СДК + экспериментов и ещё максимум день собственно написания движка + тестирование. То есть 1-2 weekend'а должно быть более чем достаточно.
А можно за это время уже gameplay начать отлаживать
Здравствуйте, Рома Мик, Вы писали:
РМ>Очевидно, что этого недостаточно, т.к. также нужно как минимум еще создать окно и инициализировать DirectX Если честно, то из документации к DX SDK как это сделать так, чтобы заработало везде — попросту неясно (если говорить о DX8 (а уж DX7, это вообще), в 9 вроде бы проще стало, но я бы для простых игр пока на 8 ориентировался). Кроме того надо, хоть и не столь обязательно, обработать переключение между приложениями, не давать системе заснуть, пока игра крутиться, в общем не забыть о куче всяких нюансов. И оттестировать всё это сильно по разному работающее на разных системах и компьютерах дело, на соответственно разных компьютерах и системах, чтобы потом не было мучительно больно отвечать на вопросы типа "а у меня игра не запускается, говорит нет такой-то dll, причем установка последнего DirectX не помогает".
Инициализация DXG разжёвана в СДК просто до предела. Далее, использовать что-то древнее DX9 не вижу никакого смысла (ибо я за последние пару-тройку лет не видел десктопов без DX9). Дистрибутив версии DX, на которой проект точно заработает, берёте из СДК и поставляете вместе с игрой — тогда гарантированно отсутствие проблем с дллками. Не давать системе заснуть — хм, я бы давал. Просто надо нормально обрабатывать пробуждение То же касает корректного восстановления после сворачивания. Опять же, в нашем случае можно тупо переинициализировать систему — этого будет вполне достаточно.
РМ>А можно за это время уже gameplay начать отлаживать
Агащаззз. Просто вместо вопросов "как установить текстуру в DXG" будут вопросы "как сделать А на движке Б?". Если первое легко находится в СДК, то со вторым есть определённые проблемы...
Здравствуйте, koandrew, Вы писали:
F>>оценки создания адекватного движка были слишком оптимистичны.. K>Выделенное слово здесь ключевое.
разумеется
Что автору нужно от движка (как я понял):
цитата: "Обдумываю проект простенькой игры."
игра — это немного больше, чем несколько треугольников, пара сообщений ввода и немного звуков..
K>Собственно, всё. По поводу звука — тут тоже в общем-то всё несложно (примеры опять-таки есть в СДК, в том числе для DS3D, хотя я с трудом представляю, зачем это может понадобиться в 2D приложении).
ну, эффекты разные (в т.ч. EAX), использование баланса (лево-право).. это то, что можно применить в 2D игре..
Здравствуйте, koandrew, Вы писали:
РМ>>А можно за это время уже gameplay начать отлаживать K>Агащаззз. Просто вместо вопросов "как установить текстуру в DXG" будут вопросы "как сделать А на движке Б?". Если первое легко находится в СДК, то со вторым есть определённые проблемы...
зависит от А..
вопросы в обоих случаях будут.. никогда еще документация не спасала на 100%
Толком никто из нас не знает для чего человек делает эту свою игру.
Поэтому ваш спор не имеет смысла
з.ы.
Вот делает он например супер хит казуальный, и весь ваш предыдущий пост "не правильный",
да и вообще желание делать свой велосипед как-то тоже выглядит странным.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Рома Мик, Вы писали:
РМ>>Очевидно, что этого недостаточно, т.к. также нужно как минимум еще создать окно и инициализировать DirectX Если честно, то из документации к DX SDK как это сделать так, чтобы заработало везде — попросту неясно (если говорить о DX8 (а уж DX7, это вообще), в 9 вроде бы проще стало, но я бы для простых игр пока на 8 ориентировался). Кроме того надо, хоть и не столь обязательно, обработать переключение между приложениями, не давать системе заснуть, пока игра крутиться, в общем не забыть о куче всяких нюансов. И оттестировать всё это сильно по разному работающее на разных системах и компьютерах дело, на соответственно разных компьютерах и системах, чтобы потом не было мучительно больно отвечать на вопросы типа "а у меня игра не запускается, говорит нет такой-то dll, причем установка последнего DirectX не помогает".
K>Инициализация DXG разжёвана в СДК просто до предела.
Значит я такой тупой
K>Далее, использовать что-то древнее DX9 не вижу никакого смысла (ибо я за последние пару-тройку лет не видел десктопов без DX9).
А я видел Как стоит XP, на который никто обновления не ставит, так сразу нет DX9. Если речь идет не о хардкорном игроке или даже о рабочем компьютере просто, то такое сплошь и рядом. XP шёл с DX8, вот на него и стоит ориентироваться, если не хочешь проблем. Когда XP не останется, тогда можно будет на DX9 переползать.
K>Дистрибутив версии DX, на которой проект точно заработает, берёте из СДК и поставляете вместе с игрой — тогда гарантированно отсутствие проблем с дллками.
Т.е. надо с игрой распространять ещё и дистрибутив DX?
K>Не давать системе заснуть — хм, я бы давал. Просто надо нормально обрабатывать пробуждение То же касает корректного восстановления после сворачивания. Опять же, в нашем случае можно тупо переинициализировать систему — этого будет вполне достаточно.
Т.е. есть и над чем подумать и что делать.
РМ>>А можно за это время уже gameplay начать отлаживать K>Агащаззз. Просто вместо вопросов "как установить текстуру в DXG" будут вопросы "как сделать А на движке Б?". Если первое легко находится в СДК, то со вторым есть определённые проблемы...
Не вместо. Вопрос, как сделать А, будет и там, и там, а вопрос, как установить текстуру, будет только в DX
Здравствуйте, dmSoketov, Вы писали:
GC>>Обдумываю проект простенькой игры. Предпологается среда разработки — VS, язык Visual C++. S>Я бы брал HGE либо PopCap framework
Точно, HGE рулит! Отличный простой бесплатный 2D-движок + всё что нужно (фонты, саунд, инпут).
Если нужно сосредоточится на игровой логике и не забивать голову аппаратной/низкоуровневой частью, то для несложного проекта под Win — выбор практически идеальный.
Единственная проблема — не нашел как работать с пикселями (получать цвет конкретного пикселя).
Здравствуйте, Рома Мик, Вы писали:
РМ>Значит я такой тупой
Я этого не говорил
РМ>А я видел Как стоит XP, на который никто обновления не ставит, так сразу нет DX9. Если речь идет не о хардкорном игроке или даже о рабочем компьютере просто, то такое сплошь и рядом. XP шёл с DX8, вот на него и стоит ориентироваться, если не хочешь проблем. Когда XP не останется, тогда можно будет на DX9 переползать.
Тогда уж на DX10 Вообще девятка ставится, например, вместе с некоторыми аудио/видеодровами. Или с софтом, ориентированным на редактирование этого дела. В общем, ИМХО с большой долей достоверности можно считать, что DX9 уже имеется в системе.
РМ>Т.е. надо с игрой распространять ещё и дистрибутив DX?
Можно воткнуть бутстраппер к веб-инсталляции.
РМ>Т.е. есть и над чем подумать и что делать.
Нет — всё уже подумано за вас Вам осталось только почитать СДК и сделать так, как там рекомендуют.
РМ>Не вместо. Вопрос, как сделать А, будет и там, и там, а вопрос, как установить текстуру, будет только в DX
Не будет — ибо в СДК это описано так, что, по-моему, полный кретин поймёт, как это делать. IDirect3DDevice9::SetTexture() — что может быть непонятно в этом одном вызове А, ну да — номер тексуры. Но если не юзать мультитекстурирование и шейдеры, то можно забить и передавать 0
Вообще, чтение СДК полезно ещё и тем, что там даётся необходимый минимум теоретических сведений. И их всё равно придётся где-то взять (ну и, конечно, было бы очень неплохо хотя бы в общих чертах вспомнить институтский курс линейки — в частности про матрицы Якоби и матрицы трансформации) — чтобы не было вопросов типа "почему translate+rotate != rotate+translate", "что такое видовая матрица и матрица проекции", "какие бывают и чем друг от друга отличаются виды проекций" и т.п. Плюс там есть масса best practices а-ля почему лучше иметь одну большую текстуру и маппить её фрагменты на геометрию, чем иметь много мелких текстур, почему рисовать надо сначала удалённую от камеры геометрию, а потом более проиближённую, почему лучше использовать матрицы трансформации вместо того, чтобы каждый раз перерассчитывать и загонять в видеопамять геометрию...
Ну и ещё конечно же есть либа D3DX, которая из себя представляет что-то типа констуктора "сделай сам графический движок", автоматизируя почти все типовые операции (загрузка объектов/текстур/эффектов, генерация некоторых геометрических примитивов, hit-test и т.д. — там много чего есть). При этом (я считаю это важным преимуществом) тебе не навязывается архитектура приложения — тут есть простор для творчества. В том же TGE(A), с которым я работал одно время, с этим имеются определённые проблемы.
P.S. так и подмывает сваять этот движок уже Если бы были до конца понятны требования — уже тестировали бы вместо этих пустопорожних дебатов
Здравствуйте, neFormal, Вы писали:
F>цитата: "Обдумываю проект простенькой игры." F>игра — это немного больше, чем несколько треугольников, пара сообщений ввода и немного звуков..
Ага, ещё это карты, сценарий и ресурсы. Всё это нужно вне зависимости от того, используешь ты сторониий движок или самописный. Кстати и тут можно наткнуться на ограничения движка (вот например мы упёрлись в проблему реализации прозрачного роуминга между серверами, а TGE(A) этого не поддерживает А разбираться в десятках метров навороченного C++ кода чё-то как-то не очень хочется... При том, что схема реализации такой штуки нам ясна, и, используй мы свой движок, уже наверняка чё-нить придумали бы. А сейчас если заняться разработкой движка, то во весь рост встаёт проблема миграции (конвертация ресурсов, переписывание того, что уже было написано и т.п.)
F>ну, эффекты разные (в т.ч. EAX), использование баланса (лево-право).. это то, что можно применить в 2D игре..
Эффекты можно пререндеренные использовать (убил бы того, что EAX API разрабатывал ), баланс делается на счёт раз-два с помощью DS3D (если очень хочется — там всего несколько строк кода)...
Здравствуйте, neFormal, Вы писали:
F>неужели велосипед проще?. F>а модификация запрещена лицензией?. или исходники не все открыты?.
Нет, не запрещена, но тут есть другие проблемы — огромный объём кода и обновление (мёрджинг)
F>и правда ли, что у torque безумная лицензия: 1,5 килобакса за девелопера в месяц?.
Конечно неправда. Это один из самых дешёвых из коммерческих движков (Инди-версия стоит всего $150). См http://www.garagegames.com/products/browse/torque/?sort=popular
F>я использовал BASS.. поэтому проблем с EAX API не было вообще ^____^
Здравствуйте, koandrew, Вы писали:
F>>и правда ли, что у torque безумная лицензия: 1,5 килобакса за девелопера в месяц?. K>Конечно неправда. Это один из самых дешёвых из коммерческих движков (Инди-версия стоит всего $150). См http://www.garagegames.com/products/browse/torque/?sort=popular
Shareware licence: €100
The "shareware" licence allows the usage of BASS in an unlimited number of your shareware products, which must sell for no more than 40 Euros each. If you're an individual (not a corporation) making and selling your own software (and its price is within the limit), this is the licence for you.
purchase
Single Commercial licence: €950
The "single commercial" licence allows the usage of BASS in a single commercial product.
purchase
Unlimited Commercial licence: €2450
The "unlimited commercial" licence allows the usage of BASS in an unlimited number of your commercial products. This licence applies to a single site/location.
F>Shareware licence: €100
F>The "shareware" licence allows the usage of BASS in an unlimited number of your shareware products, which must sell for no more than 40 Euros each. If you're an individual (not a corporation) making and selling your own software (and its price is within the limit), this is the licence for you.
F>purchase
F>Single Commercial licence: €950
F>The "single commercial" licence allows the usage of BASS in a single commercial product.
F>purchase
F>Unlimited Commercial licence: €2450
F>The "unlimited commercial" licence allows the usage of BASS in an unlimited number of your commercial products. This licence applies to a single site/location.
Ну вот ещё полторашка зелени...за поддержку EAX?? Да за такие бабки я лучше EAX API помучаю
извиняюсь, сглючил.. спутал с другим движком, там $150 в месяц..
K>Ну вот ещё полторашка зелени...за поддержку EAX?? Да за такие бабки я лучше EAX API помучаю
Здравствуйте, koandrew, Вы писали:
K>почему рисовать надо сначала удалённую от камеры геометрию, а потом более проиближённую,
А мне всегда казалось что нужно в случае с непрозрачной геометрией нужно делать наоборот.
Ибо если сначала отрисовать то что близко то быстрые проверки по Zбуферу отсекут медленный рендер того что реально не видно.
А в случае с прозрачной наоборот. Ибо при альфабленде обычно используют простую и не правильную функцию при применении которой имеет значение порядок бленда.
Причем сначала нужно отрисовать все не прозрачное, а потом отключить запись в Z буфер отрисовать все прозрачное. Отключать запись в Z буфер нужно чтобы пересекающеяся прозрачные треугольники таки отрисовались хоть и не очень правильно из-за не правильной функции в альфабленде.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, neFormal, Вы писали:
F>для казуалок удобная либа..
Ну может быть, но лично я за такие бабки лучше EAX SDK помучаю. Он конечно замороченный, но не настолько, чтобы платить кучу бабок за либу вокруг него. Собственно главная проблема, что халявно досупен тока SDK EAX up to 2.0, для более новых версий бапки платить придётся... И что-то мне подсказывает, что EAX Enchanced HD aka EAX 3.0 и выше этим BASS'ом тоже не поддерживается...
Здравствуйте, Леонид, Вы писали:
Л>а как насчет PlayGround Л>живой форум, документация. бесплатный. Л>плюс осваивается получше popCap... это конечно не TGB но зато с++...
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Леонид, Вы писали:
Л>>а как насчет PlayGround Л>>живой форум, документация. бесплатный. Л>>плюс осваивается получше popCap... это конечно не TGB но зато с++...
F>пг хуже попкапа..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Леонид, Вы писали:
F>>>пг хуже попкапа.. Л>>а можно аргументы услышать?
F>аргумент один: недоделанность
F>да и у попкапа возможности шире.. хотя пг сейчас может уже доделали до более вменяемого состояния..
Если свет клином не сошёлся на C++, то поглядите Microsoft XNA (набор фреймворков и библиотек к C#).
Современная технология, тонна примеров, потрясающий язык, возможность деплоить проекты на XBox.
XNA берёт на себя все проблемы с графикой, загрузкой, звуком, инпутом и сетью.
Там к комплекте идёт пример 2D аркады платформенной — поглядите для интереса.
На TechDays есть куча видеокастов с уроками по XNA.