Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Плохой человек © (2003-06-17 16:09:00)

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Kelegorm

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

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

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

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

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

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

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

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

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

2 Kelegorm:

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

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

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

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

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

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

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

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

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

2 Omar2002:

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

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

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

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

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

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »