Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Игры";
Текущий архив: 2004.01.16;
Скачать: [xml.tar.bz2];

Вниз

Так в чём же всё-таки писать аркады?..   Найти похожие ветки 

 
Плохой человек   (2003-06-17 16:09) [0]

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

Пишу тут что-то, а всё тормозит. В общем, OpenGL и DirectX чистый пока использовать не хочется. Пробовал DelphiX - стало страшно тормозить на альфа-блендинге, пришлось отказаться. Пробовал PowerDraw - он что-то у меня не пашет. Кстати, PowerDraw намного быстрее DelphiX??? А то может подолбаться и попытаться починить? Пробовал Graphic32. Пока использую, но всё медленнее и медленне пашет и большая зависимоть от забитости процессора.

А есть ли ещё средства????


 
NailMan   (2003-06-17 16:21) [1]

Для аркад и шутеров самое подходящее - чистый OpenGL и DirectX.

Имхо, всякие обертки - это дополнительная тормозня, в которой если хочется что-то модифицировать - гемор пострашнее чем написание с нуля.

Я сразу начал писать на чистом директе, хотя были всякие варианты.

Сейчас в проекте ~200 ФПС, это при том что пока полностью на статические буферы не перешел - есть некоторые косяки, и для рендера юзаю ID3DXMesh, который довольно тормозной. Да к томуже для игры надо максимально юзать фичи железа, как например SIMD-расширения процов(я юзаю 3DNow!).

Вобщем я за чистоту, скорость и еограниченные возможности DirectX или OpenGL.


 
Плохой человек   (2003-06-17 16:35) [2]

Хорошо, тогда встречный вопрос. Есть ли инфа в нете очень простая для самых неумеющих?


 
Плохой человек   (2003-06-17 16:52) [3]

> Сейчас в проекте ~200 ФПС, это при том что пока полностью на статические буферы не перешел - есть некоторые косяки, и для рендера юзаю ID3DXMesh, который довольно тормозной. Да к томуже для игры надо максимально юзать фичи железа, как например SIMD-расширения процов(я юзаю 3DNow!).

Т.е. ты используешь DirectX? А если я буду использовать чистый OpenGL, то не проиграю в скорости DirectX"у???


 
Nibelung   (2003-06-17 17:16) [4]

Тут все дело в разумном использовании всяких врапперов.
Тот же DelphiX хорош при инициализации (обычно куча кода на голом DirectX), при работе с простейшими базовыми функциями (вывод спрайта без клиппинга, без альфа и т.п.). Но он не запрещает пользоваться интерфейсом DX напрямую (Surface, Mesh). И если вопрос
пошел о использовании только голого DX, то не надо забывать, что в самом DX, например до сих пор идет война между Retained и Immediated режимами D3D.


 
Карлсон   (2003-06-17 17:36) [5]

для неумеющих DirectX и OpenGL есть книги Краснова.
"DirectX Графика в проектах Delphi".
не знаю, может и есть ее сетевой вариант.
PowerDraw быстрее DelphiX, но он немного сложнее.
я думаю, что если нужны альфа-блендинг и прочие фичи, то использовать надо PowerDraw (если на чистый DirectX не хватает сил).


 
NailMan   (2003-06-17 18:29) [6]

Хорошо, тогда встречный вопрос. Есть ли инфа в нете очень простая для самых неумеющих?
Краснова приводили - правда книжка довольно бездарная, даже описания стандартного модуля с D3DX-функциями нету. Вобщем ее я не буду советовать. Я лично качал примеры(правда на C++) с gamedev.ru.

Толковых дельфевских книжек я сосбно не видел. На руках есть только SDK для 8.0 и 9.0 директа(Самое смешное для DShow более полная версия - от DX9.0)

Вобщем SDK - самый толковый товарищ. Тем более там немало
примеров(которые я тоже пробовал в Delphi перевести и небезуспешно).

А если я буду использовать чистый OpenGL, то не проиграю в скорости DirectX"у???
Этот вопрос аналогичен Delphi vs C++. В принципе они равнозначны.
Но я настоятельно рекомендую делать игру под один единственный API, так как только с одним из них ты сможешь наиболее оптимально построить движок. Если будешь делать и под то и под другое - тебе хош не хош придется писать враппер - а это лишний гемор, тем более глюки ловить во внешней DLL как-то сложновато немного будет.

Я делаю только под DirectX и затачивать буду только под последние карточки(GF2 и выше).


To -> Nibelung
(обычно куча кода на голом DirectX)
Обычно в этой куче кода я держу кучу проверок и веду продробный лог что и с какими параметрами создается.


 
Плохой человек   (2003-06-17 23:32) [7]

Спасибо, что-нить надумаю. А из книги Краснова вроде бы у меня есть проекты по OpenGL, вот архивчик:

http://www.hot.ee/mvps2/opengl.rar


 
k-man   (2003-06-18 11:20) [8]

Купил я вашего Краснова почитал первые страницы и бросил в самый дальний угол библиотеки, так как увидел банальный перевод Хелпа. Во-первых я сразу для себя решил что никакими GLScene && DelphiX пользоватся не буду. Оставим это Кену. Стал думать что лучше Dx или GL.(DirectX or OpenGL)
Вечный вопрос, не так ли? Тут вспонилось что Кармак не стал пользоватся всякими навороченными Dx и стал писать на OpenGl.
Я конечно далеко не Кармак но к решению прислушался.
Дополнительно пощелкал линки на форумах где почему то было напиано что Dx для тех кто боится OpenGL(не знаю правда почему так).
УЗнав также что ничего серьезного на Делфи написано не было
я решил перейти параллельно на С++.
Переход был безболезненным. Сначала язык не понравился
но потом постепенно онимаешь всю его красоту и изящество.
Через неделю сходил купил себе Френсиса Хилла по OPenGL
и сейчас постепенно изучаю в свободное время.
Всем советую только очень уж дорогая книга.
Но я не жалею.


 
cyborg   (2003-06-18 11:47) [9]

Книгу могу посоветовать: "Программирование игр для Windows, советы профессионала" второе издание Андре Ламот. С CD диском на котором имеется DirectX 8.1 SDK + примеры + некоторые программы + статьи, правда на английском языке. Примеры в книге на С++.

Рассматриваются темы: работа с окном программы, DirectDraw, DirectInput, DirectDound и DirectMusic, алгоритмы, ИИ, физическое моделирование.

Около 300 рублей стоит.

http://www.williamspublishing.com/Books/5-8459-0422-6.html


 
Плохой человек   (2003-06-18 16:47) [10]

Да, я как раз собирался покупать книгу, потому как образовательные скачки у меня всегда были связаны с книгами. Сейчас я покумекаю с DirectX, попытаюсь себе накропать там чего-нить. Если что - вы всегда есть :).


 
Плохой человек!   (2003-06-18 21:13) [11]

Такой удачи давно не было. Нашёл сайт, там около 10 статей про DirectX в Delphi (не DelphiX) со всякими примерами. Сижу изучаю:

http://vaktyjd.besthost.ru/vr-online/vr.htm

P.S.: Там по числам, про DirectX в более поздних числах.


 
Juster~   (2003-06-18 22:40) [12]

Все дело в том, что для OpenGL много документации, в отличие от DX. Это все решает для таких людей как мы. А профессионалы чаще всего выбирают DX...


 
Плохой человек   (2003-06-18 23:40) [13]

Но надо учитывать и то, что инфа по OpenGL огромной частью про 3D.


 
Omar2002   (2003-06-19 13:31) [14]


> Плохой человек (18.06.03 23:40)
>Но надо учитывать и то, что инфа по OpenGL огромной частью про 3D.


Точно. Только я по свему опыту понял, что проще всего аркадки делать на основе компонентов DelphiX, да и документаций и примеров для них дофига, на том же DelphiGFX !


 
Плохейший человек   (2003-06-20 22:21) [15]

2 Omar2002:

Юзая DelphiX, проигрываешь в скорости.


 
Omar2002   (2003-06-22 20:45) [16]


> Плохейший человек (20.06.03 22:21)


Ты про скорость создания игры или скорость работы самой игры? :)


 
Mihey   (2003-06-22 21:24) [17]

Явно имеется ввиду скорость работы игры. :)


 
Kelegorm   (2003-06-24 20:10) [18]

Люди! Причем здесь Проц? всё дело в видюхе и таймере! ВСЕ НАДО ОТРИСОВЫВАТЬ ЧЕРЕЗ ТАЙМЕР! А то Прыгают с 172 FPS! А ты посмтри, ТЕБЕ ЭТО НАДО? ВСЁ РАВНО ЭКРАН С ТАКОЙ СКОРОСТЬЮ НЕ ОТРИСОВЫВАЕТСЯ! Зачем лишний раз мучить видюху.
Для справок. видеокарта по скорости вывода в 25 раз и более медленее работает, чем проц.


 
Mihey   (2003-06-24 21:33) [19]

2 Kelegorm:

Я (= exПлохой человек) использую Graphic32, который не поддерживает никакой аппаратной поддержки, а значит, вывод графики зависит от процессора и оперативки, что очень просто подтверждается на праткике - одна небольшая загруженная программа снижает скорость на 3 кадра в секунду.


 
Kelegorm   (2003-06-25 11:30) [20]

Скорость ВЫВОДА графики зависит от видюхи. Русует никакой не проц и даже не оперативка, а только видюха. А пользуется памятью для взятия информации на вывод.
Аппаратная поддержка - это может быть, антиалясинг, когда после загруски данных из памяти перед выводом на экран она сжимает изображение в четыре раза (дважды по Х и по Y). В результате получается гладкое изображение почти без пикселей. Соот., данные нужно записывать в виде большого экрана. Можно и самому, алгоритм очень простой.


 
Mihey   (2003-06-25 21:02) [21]

> Скорость ВЫВОДА графики зависит от видюхи. Русует никакой не проц и даже не оперативка, а только видюха. А пользуется памятью для взятия информации на вывод.

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

> Аппаратная поддержка - это может быть, антиалясинг, когда после загруски данных из памяти перед выводом на экран она сжимает изображение в четыре раза (дважды по Х и по Y). В результате получается гладкое изображение почти без пикселей. Соот., данные нужно записывать в виде большого экрана. Можно и самому, алгоритм очень простой.

Зачем сжимать изображение? Можно составить антиальясинг-карту, загрузить её в альфа-канал и наслаждаться жизнью.


 
Omar2002   (2003-06-25 22:43) [22]


> Kelegorm

В чем-то ты прав. Действительно никому не надо 170 FPS, но если ты делаешь 3D, то те 25 явно не подойдет :) Вся динамика пропадать будет- ведь в аркадах именно динамика рулит :)))


 
Mihey   (2003-06-25 22:57) [23]

>В чем-то ты прав. Действительно никому не надо 170 FPS

Мне надо. А уж ограничитель я сам поставлю.


 
Kelegorm   (2003-06-28 21:39) [24]

Да, блин, чуваки! Не ужто не поняли! СТОЛЬКО раз даже экран не успевает оттрисоватся. Нахрен тогда считать на 170 FPS, если информация будет просчитана дважды, а отобразится тлько один раз.

То михей -
Изображение могёт хранится в видеопамяти, или в оперативной памяти. В Видео хранять обычно вертехсшейдеры, а в оперативке - БОЛЬШИЕ текстуры. Так сподручней, так скромней |-)


 
Mihey   (2003-06-29 18:01) [25]

> Да, блин, чуваки! Не ужто не поняли! СТОЛЬКО раз даже экран не успевает оттрисоватся. Нахрен тогда считать на 170 FPS, если информация будет просчитана дважды, а отобразится тлько один раз.

Ну а будет ситуация, что fps просто не дотянет до нужных 30 и что тогда??? Уж лучше чтобы было как можно больше и ставить таймер на 30 или 40 или сколько тебе надо, чем заранее делать игру, которая будет натягивать эти 30.


 
J911   (2003-06-29 20:01) [26]

OpenGL в 2d - самая быстрая система.
Туговато писать, но если есть опыт в 3д, то проблем не будет.


 
Mihey   (2003-06-29 20:18) [27]

> OpenGL в 2d - самая быстрая система.

Так-так, меня это заинтересовало. На чём основано это мнение? Есть ли где-нибудь официальное подтверждение, опыты по сравнению DirectX и OpenGL. Потому как это очень важная для меня штука.


 
J911   (2003-06-29 20:33) [28]

Mihey,
OpenGL, DirectX - разница в скорости минимальная( если не нулевая), все зависит от кода, но быстрое приложение проще сообразить на OpenGL, а директ используеться из-за наворотов, OpenGL попримитивней будет.


 
Mihey   (2003-06-29 22:03) [29]

Понятно.


 
Kelegorm   (2003-07-01 05:56) [30]

когда постоянно вызываешь функцию отрисовки - это никак не поможет в увеличении ФПС при загруженном проце. А когда он загружет - нет причин, чтоб по твоему варианту было быстрей работать. Не понимаю я тебя.


 
NailMan   (2003-07-01 13:39) [31]

Так сказать лирическое отступление:

Вообще-то самое тугое по вычислениям место практически в любой современной игре - рассчет коллизий. Это примерно 30%-80% нагрузки процессора. Поэтому необходимо ускорять именно этот процесс.

В своей игре я решил делать коллизии на основе сфер, так как вычисление одной коллизии(сфера-сфера) практически ничего не "весит"(3 раза вычисления квадрата, 1 корень квадратный и 4 суммы и сравнивание результата с числом) и процессор на эту процедуру будет расходовать 3-15%(на все коллизии ессно) в зависимости от архитектуры модели столкновения(принципов отсечения повторных просчетов столкновений).

Теперь о птичках:
Чем больше ФПС тем естесственно лучше. Программист обязан написать программу так чтобы она выдавала максимум ФПС на конкретной машине(Если 170 фпс на 3-х объектах, то чтоже будет на 1000? 0.17?). Этоuj можно достичь как конструкцией кода, так и заточками под железо(в моем случае рассчет коллизии элементарно пишется на 3DNow!, что очень его ускоряет).

Дабы повысить скорость, можно(и нужно) разгрузить проц, тоесть забыть о всех древних TNT-подобных софтварах и писать игру под нормальное железо с HW TnL. Разгрузка процессора просто огромная. Во вторых необходимо правильно конструировать модельки - нужно иметь в виду что все карты имеею эффективное число фейсов отрисовываемых за один вызов(~600-800). Если будет <~100, то процесс отрисовки будет не выгоден, так как время вызова процедуры draw везде одинаково, и время отрисовки примерно одно и тоже.

И самое главное - переложить максимальное счисло рассчетов связанных с геометрией на видеоадаптер, посдедством максимального использования возможностей конкретного API и самого железа.



Страницы: 1 вся ветка

Форум: "Игры";
Текущий архив: 2004.01.16;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.54 MB
Время: 0.011 c
1-49590
men
2004-01-05 14:24
2004.01.16
edit


1-49594
Марат
2004-01-05 13:53
2004.01.16
StringGrid


14-49762
PVOzerski
2003-12-24 10:23
2004.01.16
Федорино горе, или о забавных нелепостях в названиях программ


6-49654
Alex_x
2003-11-17 13:30
2004.01.16
Нужно узнать доступенли комп в сети с заданым именем


4-49803
Erik
2003-11-10 16:49
2004.01.16
Получение лога состояния кнопок в чужом приложении.





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский