GLX, попытка номер два :)

[bad_duck]

Дрова атишные (последние, хваленые ) стоят, однако картинка даже на 10 фпс не тянет:

[00000750ms]engine: Start in windowed mode: 800 x 600 x 32
[00000817ms]engine: ### XF86VidModeQueryVersion v.2.2
[00000818ms]engine: ### XF86VidModeGetAllModeLines count = 41
[00000818ms]engine: ### Current Resolution = 1280x1024
[00000819ms]engine: ### Current Dir = /home/badduck/Temp/bin/
[00000819ms]engine: Successful creating of window:
[00000844ms]engine: Successful initializing of OpenGL
[00000916ms]engine: ### Mode to set = 1280x1024[0]
[00000923ms]engine: GL_VERSION: 2.0.6958 Release
[00000924ms]engine: GL_VENDOR: ATI Technologies Inc.
[00000924ms]engine: GL_RENDERER: RADEON X800 GTO
[00000924ms]engine: GL_DIRECT_RENDER: TRUE
[00000925ms]engine: GL_ARB_texture_compression: TRUE
[00000925ms]engine: GL_EXT_bgra: TRUE
[00000926ms]engine: GL_MAX_TEXTURE_SIZE: 2048 x 2048
[00000926ms]engine: GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT: 16
[00000970ms]application: Successful loading of font: [ ../data/Font.png ][ /home/badduck/Temp/bin/../data/FontInfo.ofi ]
[00001018ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/background.jpg
[00001032ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/left.jpg
[00001033ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/player.gif
[00001038ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/monster1.gif
[00001038ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/bullet.gif
[00001065ms]application: Successful loading of texture: /home/badduck/Temp/bin/../data/boom.jpg
[00004983ms]engine: Successful stopping of timers[2]
[00004983ms]engine: Successful freeing of fonts[1]
[00004984ms]engine: Successful freeing of textures[7]
[00004984ms]engine: Average FPS: 29
[00004985ms]engine: Shutdown...

[Thread]

Запустил и я. Запускал на x86-64, никакой ругани про libomega.so не заметил. Так работает, однако жрёт 200% ЦП и через каждую секунду подвисает на 0.3-0.4 сек, если сильно елозить мышью.

лог:

Код: [Выделить]

### XOpenDisplay - good :)
### glXQueryExtension - good :)
### Choose Double Buffer...
### glXChooseVisual - good :)
Set app_DesktopModeGet...
1280
1024
begin hide mouse...
end hide mouse...
html-лог в аттаче

[вложение удалено Администратором]

[Andru]

bad_duck

Дрова атишные (последние, хваленые idiot2 Angry) стоят, однако картинка даже на 10 фпс не тянет:

Что-то подобное наблюдалось на Radeon 9000 в связе с Mesa, но проблема решилась использованием фулскрина, попробуй этот исполняемый файл(замени им тот что в папке bin)

a-v
Ну загрузка проца полная, т.к. двиг входит в мертвую петлю while чтобы постоянно обрабатывать вывод графики, под оффтопиком по другому никак сделать нельзя вроде(чтоб не потерять фпс), да и в Linux другого выхода тож пока не нашёл. Попробуй тоже фулскрин плиз.

[Thread]

1. Обрати внимание - 200%, а не 100 - один while на такое не способен
2. А если первые 10 секунд измерять фпс, а потом после каждого фрейма спать соответствующее время?

[Viewizard]

Ну загрузка проца полная, т.к. двиг входит в мертвую петлю while чтобы постоянно обрабатывать вывод графики, под оффтопиком по другому никак сделать нельзя вроде(чтоб не потерять фпс), да и в Linux другого выхода тож пока не нашёл.

Как я вижу ситуацию.

1) На самом деле фактическое кол-во прорисовок/обновления графического отображения игры будет равно частоте обновления экрана... даже если ты не привязываешься к v-synh, все равно - забивается буфер хоть 7000 раз (т.е. ты делаешь 7000 выводов на прорисовку), сольется этот буфер на экран только "значение обновления экрана" раз.

2) У тебя 2д игра, _не 3д_, т.е. положение объектов фактически целочисленное (ширина и высота экрана дробными быть не могут, я думаю это понятно), в тоже время скорость объектов относительно низкая (у меня было что-то там 700фпс, не думаю что у тебя что-то движется со скоростью 700 пикселей в секунду).
Что получаем - при 60 фпс у тебя просчет положения снаряда скорость которого 20 пикселей в секунду (к примеру) соотв. вычисляется 60 раз, т.е. с учетом округления к целочисленным фактическим координатам снаряда на экране, компьютер будет делать работу в 3 раза большую чем требуется (после округления в целочисленные значения положения, снаряд будет иметь те же координаты что и до того).

Вывод: не морочь себе голову, просчитай сколько тебе реально надо просчетов в секунду (исходя из размера экрана и максимальной скорости у объекта) - это и будет твой необходимый фпс, и уже на базе этого фпс сделай учет времени последнего цикла (т.е. чтобы цикл просчетов+прорисовка проходил не чаще чем нужно), в остальное время - отпускаешь процессор (делаешь sleep/delay/wait на 1 милисекунду, или как-то по другому - тебе решать).
В итоге у тебя будет, допустим "оптимальные" 80 циклов в секунду (заметь, мы не привязываемся к частоте обновления экрана!!! т.к. нам нужно корректно считать математику, мы формируем бэк буфер 80 раз, а когда системы его прорисует - не наша забота) + менеджер приоритетов потоков ОСи будет нормально работать , в случае если игра на компьютере работает медленней чем 80 циклов в 1 секунду, она будет работать в том же режиме что у тебя сейчас (т.е. будет постоянно обрабатываться цикл "просчет+прорисовка").

Ну, все конечно мое имхо, так что прошу не принимать близко к серцу... 

[Andru]

a-v
Хм, двухядерник? Или глючит системный монитор с показом значений? )))

Viewizard
Есть проблема - двиглом пользуюсь не я один, и к нему есть 3D-надстройка(простенькая правда). Из-за того что двиг не только для себя, то надо стремится к какой-нить универсальности, а не заставлять других программеров рассчитывать сколько им фпс понадобится... я раньше пробовал что-то подобное сделать, но потом бросил это дело и под оффтопиком оставил все как есть, пока даже под убитым железом там все работает нормально(или более-менее) В игре также могут наличествовать таймеры(с разношёрстыми интервалами), для обсчёта чего-то дополнительного и их сложно(или лень) синхронизировать с частотой кадров, поэтому могут возникнуть дисинхронизация и пр. геморрой Вообщем я хочу реализовать полную копию функционала того что есть уже под Windowsми, и не делать серьезные изменения в архитектуру движка...

ЗЫ: целочисленные положения не всегда хорошо/красиво, особенно если обьект движется довольно медленно, поэтому можно использовать дробные и OpenGL будет выводить более "плавную" картинку
ЗЫЫ: демка не показатель реальных ситуаций

[Viewizard]

А, ну смотри тогда сам.
Так сказать, все что знал - все сказал 

[Andru]

Так сказать, все что знал - все сказал

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

[Thread]

a-v
Хм, двухядерник? Или глючит системный монитор с показом значений? )))

Два потока

Кстати, Viewizard дело говорит - допустим, у нас желаемый фпс - F. Тогда при старте прорисовки фрейма мы запомнимаем время t0, в конце прорисовки получаем тукущее время t1 и после фрейма спим ((1/F > t1 - t0) ? (1/F - t1 + t0) : 0) времени. А время таймеров логично измерять не в секундах, а в фреймах/F

Ещё - если OpenGL не использует antialiasing, то использование дробных значений никак не улучшит картинку.


******

Заценил фулскрин. Дерганий больше не наблюдается (compiz чтоли?), работает нормально, за исключением того, что я, усердно отбиваясь от врагов, вдруг умер с -1 HP

[Viewizard]

Заценил фулскрин. Дерганий больше не наблюдается (compiz чтоли?), работает нормально

Кстати по теме компиза и игр в оконных режимах.
У меня такое тоже было, еще когда свою игру тестировал с ним, правда я поставил сразу берил... но у тебя наверно сейчас компиз-фьюжен, так что настроек тоже должно хватать.
Были там такие настройки (Advanced Beryl Options), прямо по клику правой кнопки мыши на иконке в трее они отдельно шли строчкой в выпадающем меню, можно с ними поэксперементировать. Общий фпс в моем случае хоть и упал немного после "подстройки", зато никаких подергиваний и рывков вообще не наблюдалось.

[Thread]

Ну, мне это не очень важно, все равно ведь с компизом не добиться такой производительности, как без него, поэтому на время игры я отрубаю компиз вообще, благо что сейчас играю не так и часто

[Viewizard]

Ну, мне это не очень важно, все равно ведь с компизом не добиться такой производительности, как без него, поэтому на время игры я отрубаю компиз вообще, благо что сейчас играю не так и часто

Да, полное выключение - оптимальный вариант для максимального быстродействия игры конечно 
Хотя помню в самом начале компиз вообще не умел игры прорисовывать (да и вообще все 3д), может через год его так от полируют, что в игре производительность не будет падать вообще... будем ждать

[Thread]

Чтобы такое было, он должен освобождать всю видеопамять и переставать работать с остальными окнами, пока работает 3D-приложение. А это влечёт за собой потерю интерактивности - "либо, либо". Хотя, конечно, для фулскрина такое теоретически можно сделать

А вообще, конечно, компиз улучшается быстро. Три месяца назад у меня фпс в q3 с компизом был 20, сейчас - 90.

[Andru]

a-v
Блин, хотел же спросить мол "у тя стоит компиз?" ))) Но подумал раз 7300GS, то вряд ли) Вообщем у меня из-за компиза на старой конфигурации тоже подёргивания были, причём в других играх.

Кстати, Viewizard дело говорит - допустим, у нас желаемый фпс - F. Тогда при старте прорисовки фрейма мы запомнимаем время t0, в конце прорисовки получаем тукущее время t1 и после фрейма спим ((1/F > t1 - t0) ? (1/F - t1 + t0) : 0) времени. А время таймеров логично измерять не в секундах, а в фреймах/F

Не, это сильно поменяет архитектуру движка, плюс неудобно считать таймеры в фреймах/F, т.к. допустим прикрутив физику обсчёты будут ну ооооочень дёрганными

[Thread]

ouch. Я не считаю 7300 GS слабой - фпс во всех играх с максимальными настройками на 1280х1024 не меньше 80-90, в CS вообще несколько сотен 

Хотя результат glxgears действительно отстаёт от новейших моделей - 1783