Поговорим о оптимизации GLScene.

← →
Санёк (2005-08-25 23:36) [80]

> Fosgen (25.08.05 23:10) [79]

хорошо, положим, ты прав - ХР это отстойная система.
но.
ответь на один вопрос - люди, которые будут играть в твою игру, они что, все под 2000 сидят?
сумневаюсь, ой как сумневаюсь.
дак что делай выводы.

и еще.
по поводу библиотек.

если присмотреться к папке \WINDOWS\system32 , то можно заметить, что там наличествует два файла - atioglx1.dll и atioglxx.dll.
интересно, за что они отвечают, а?

← →
Fosgen (2005-08-26 00:03) [81]

Я подозреваю ответственность этих файлов за "сочленение" встроенного в железе OpenGL со стандартной системной библиотекой. Ведь ни GLScene, ни любой другой (не привязанный к конкретному железу программный продукт) не использует эти atioglx1.dll и atioglxx.dll, а использует opengl32.dll. А последний-то каким был, таковым и остался. У меня например эти файлы вообще называются atiglpf.dll и atiglxx.dll. Так что стандартными универсальными библиотеками они просто не могут быть.
А насчет работоспособности программ под ХР - уберите проверку на версию 1.1 и все дела, только вот fps это под ХР не прибавляет - так что не о том разговор. А разговор о том, что во-первых, похоже докопались мы все коллективно до "заточенности" GLScene под версию OpenGL 1.1. Я правильно резюмирую? Скорректируйте если я не прав. Если же я прав, то встает вопрос - что с этим делать и как оптимизировать GLScene дабы она выдавала свою "проектную" мощность и на версии 2.0? Думаю этот вопрос совпатает с темой ветки...

← →
DeadMeat © (2005-08-26 00:22) [82]

http://www.realtech-vr.com/glview/
позволит многое узнать про то, что у вас там стоит.. И версию.. и возможности.. и т.п..
564 кб.

---
...Death Is Only The Begining...

← →
DeadMeat © (2005-08-26 00:42) [83]

Короче выходит такая бяка..
Опять же только мои предположения.. На истину не претендую.
OpenGL 2.0 это определяет система.. Снесите дрова.. И не будет она это определять..
Ни фич ОГЛ 2.0 ничего от нее не будет.. Это как я понял.

Далее..
Постараюсь найти Win2k с хорошей карточкой.. и потестить там.. Пока такой возможности нет.. но постараюсь.

---
...Death Is Only The Begining...

← →
Coriolis (2005-09-05 21:35) [84]

Дак к какому выводу пришли?
Нужно юзать более старую версию что ли? 09bfull ?

← →
Fosgen (2005-09-05 22:56) [85]

Народ такое впечатление что закралась деза в Ваши ряды. Драйвера МОГУТ содержать библиотеки ОБЕСПЕЧИВАЮЩИЕ СВЯЗЬ железа с СИСТЕМНОЙ БИБЛИОТЕКОЙ opengl32.dll! Но они никогда не содержали самой этой библиотеки! Эта dll-ка ставится вместе с виндой. Т.к. в ХР-шке имеет место быть opengl32.dll версии 2.0, то и поддержка сей версии наличествует. Например у меня под 2000-ой никаких вопросов про версию вообще не возникало. А все потому что в 2000 библиотека версии 1.1, а GLScene проверяет именно на эту версию (либо не проверяет совсем). А с какого перепугу вы решили что драйвера имеют в своем составе opengl32.dll - не понимаю. У меня дома на одной машине ATi, на другой GF6800GT с родными драйверами - ни в одном комлекте системных библиотек не наблюдается. Так что - кончайте глючить народ по поводу драйверов.

Вообще-то система должна работать след. образом: Стоит железяка, поддерживающая OGL 2.0, ее драйвера об этом сообщают стандартной библиотеке что стоит в системе, если сама библиотека понимает версию 2.0, то как результат система и заявляет о поддержке OpenGL 2.0. Если хоть что-то из вышеперечисленного не может сказать о поддержке OGL 2.0, то вы увидите сообщение о том что имеете только версию 1.1.
Пример: У меня GF6800GT с родными свеженькими дровами (думаю не надо пояснять что OGL 2.0 тут как родной). Но у меня стоит 2000-я с библиотекой версии 1.1. Таким образом никаких функций 2.0 я не имею. Надеюсь доступно объяснил?

Да библиотеку можно скачать, да ее можно обновить просто заменив файл в папках system32 и dllcache (файл не относится к ядру - дает возможность перезаписи в run-time). Но я лично так не делал, потому как мне - нафиг не нать. Тем более что старый релиз GLScene работает с родной dll-кой 2000-ой на ура и гораздо быстрее. В общем - пробуйте на свой страх и риск. А дрова оставьте в покое. Слишком много смотрю на них стали стрелки переводить. И вообще 2000-я рулит!

← →
DeadMeat © (2005-09-06 08:40) [86]

Получается что ни одна игра, использующая OpenGL 2.0 не будет работать на Win2k вообще?? И никаких тебе шейдеров?

← →
Frost (Freak) (2005-09-06 09:48) [87]

2 DeadMeat:
Ну, допустим, шейдеры появились намного раньше второй версии ;)

← →
DeadMeat © (2005-09-06 10:14) [88]

Я про фрагмент и пиксель шейдеры.. короче те, что от второй..
Или я путаю и они тоже до второй версии идут?

← →
Fosgen (2005-09-06 10:18) [89]

Идут, идут. Вообще во второй версии не так уж много добавили... А то что игра ПОДДЕРЖИВАЕТ навороты второй версии - совсем не означает что она не работает с версией 1.1. Так что покамисть у меня все работало. Например ПАРКАН 2, который вообще без пиксель шейдеров не запускается.

← →
Frost (Freak) (2005-09-06 12:47) [90]

2 DeadMeat:
Почитай о нововведениях в OGL 2.0
http://opengl.org/documentation/specs/version2.0/glspec20.pdf

2 Fosgen:
Я бы не сказал, что добавили не так уж много... :)

← →
Frost (Freak) (2005-09-06 12:54) [91]

Особенно радует специальная поддержка аппаратного ускорения DRI в Linux :) Радует, понятно, не жадного Билли ;)

← →
DeadMeat © (2005-09-06 14:17) [92]

Frost (Freak)
Спасибо.. обязательно прочту на ночь.

← →
Warstone © (2005-09-06 23:12) [93]

Ребята, спасайте... Уже неделю как не могу разобраться с частицами. Надо сделать "выхлоп" из двигатеря звездолёта. Пытаюсь провернуть это с частицами, но: Как их заставить лететь от источника, или просто сделать так, чтоб их координаты не были связаны с источником??? (А то при перемешении источника перемещаются и сами частицы.) Использовал TGLParticles.

← →
Coriolis (2005-09-06 23:48) [94]

Как-то ты не по теме...

← →
Fosgen (2005-09-07 00:27) [95]

Честно говоря, отстой эти самые TGLParticles... Я вот свою систему сделал - загляденье. И взрывы обалденные и осколки и выхлопы двигателей вот недавно переработал. Ко всему еще и реализовал горение как в "Ил-2:Штурмовик", да и утечки воздуха из корпуса тож неслабо смотрятся...

← →
Warstone © (2005-09-07 17:09) [96]

А можно твой механизм посмотреть/использовать в своём проекте, а то я уже ничего в TGLParticles не понимаю, а инфы - нету...

← →
Fosgen (2005-09-07 23:18) [97]

2: Warstone - поменяться на что-нить могу. Посмотреть демку взрывов можно на сайте adm.trening-omsk.ru. Там же есть скриншоты с огнем и выхлопами двигателей, туманностями.
Меня лично интересует реализация подобная TGLLensFlare (я сам пользуюсь старым релизом GLScene, там нет этого модуля, а писать самому малость некогда), и может быть (если тут одна идея не получится) спрайтовый интерфейс, который позволяет произвольное расположение кнопок, иконок на экране и обрабатывает клики обоими клавишами мыши.

← →
Coriolis (2005-09-07 23:44) [98]

Красивый взрыв. Правда, заметен минус - частицы ты распологаешь рандомом в пределе квадрата, да? Они и рзлетаются квадратом. А вообще красиво.
Можешь хоть намекнуть, как ты это реализовал?

← →
Coriolis (2005-09-07 23:51) [99]

О, я по поводу оптимизации GLScene хочу спросить:
Оптимизирует ли GLScene текстуры по размеру: т.е. если есть много мелких текстур, то GLScene их помещает в одну большую. Или нет?
(наболевший вопрос :) )

← →
Fosgen (2005-09-08 10:10) [100]

2: Coriolis - Скорее уж я их располагаю в пределах куба. Это и есть намек. :)))
Оптимизацией хранения текстур вроде должен не движок, а программист заниматься. GLScene может хранить все текстуры в одной библиотеке, ее структуру я не разбирал, хотя сомневаюсь что она похожа на "одну большую"...

← →
Coriolis (2005-09-08 15:35) [101]

Да не, я не про осколки. гыгы.
Я про сам взрыв. :)
Я не понял, он у тебя анимацией сделан или генерится каждый раз.

Т.е. GLScene не оптимизирует мелкие текстурки?..
А если их полторы сотни, и они все влезут на одну 512х512?
То будет создано 150 текстур? Всместо одной на 512?
Это же грустно...

← →
Fosgen (2005-09-08 22:28) [102]

Взрыв - однозначно генерится. Вообще-то он использует одну и ту же текстуру (слегка анимированную), и состоит из 14 полигонов :)), но каждый раз получается разным. А в игрухе что я пишу у меня 9 текстур. Вот разнообразие-то...

Как текстуры будешь хранить - так оно и будет. Запихаешь все в одну bmp-шку - будет одна текстура, только разбирай их оттуда уже сам...

← →
Coriolis (2005-09-08 22:48) [103]

Ага, ну я примерно так и думал.

А на счёт текстур - хотелось бы именно автоматом. Вот текстуры модели - это понятно, что одна модель - одна текстура. А текстуры интерфейса? Всякие там кнопочки/рюшечки/палочки/крючёчки, фон окон.
К тому же если размещать текстуры во время загрузки, то получится оптимизация под конкретное видео. Будут создаваться текстуры как можно большего размера, и на них распихиваться картинки.
Это ещё удобно и для художников - им не надо с этим париться - они могут не напрягаясь хранить даже самые мелкие текстуры в отдельных файлах, об их стыковке в одну большую текстуру позаботится сам движок.

← →
Fosgen (2005-09-09 00:19) [104]

И интересно что именно ты "примерно так и думал"? :))) Пока что я не только реализации такой как у меня не видел, а даже намеков на идею не слышал - потому так просто и не колюсь...

И как он тебе об этом позаботится? Нет уж лучше о таких вещах я сам позабочусь чем доверять движку. :))) Насчет интерфейса - тут вообще все зависит от того как ты его организуешь... Да и не факт что одна модель - одна текстура. Вот у меня каждая модель состоит из 3-6 3ds-ок, да еще к каждой по 5 текстур. И рпедлагаешь это все в одной картинке хранить? Да ну нафиг. Надо будет - сложу в один файл ресурсов, да и все дела...

← →
Coriolis (2005-09-09 00:58) [105]

Хех. "Так и думал" - В смысле что ты натянул на полигоны текстуру. Хотя, не знаю, как можно ещё подобное реализовать :) Ну, может с помощью частиц...
А не колишься - и не надо :!

Так, погоди, что значит "Нет уж лучше о таких вещах я сам позабочусь чем доверять движку. :)))" ?!!! Ты не доверяешь коду, тобой написанному? Хм. Нет, я имею в виду что некий менеджер объектов при загрузке раскидает мелкие текстурки в одну большую. Естественно, он будет их раскидывать _оптимально_ по занимаемой поверхности, чтобы как можно больше вместилось.
Ну и этот менеджер будет помнить смещение для каждой текстуры (и, возможно, её поворот), чтобы как только ты к ней обратишься, он выдал тебе текстуру общую и координаты/размер интересующего тебя участка.
А для моделей - я действительно стормозил. Просто припомнились мои заморочки старые, и я ляпнул.
"И рпедлагаешь это все в одной картинке хранить?"
Ты невнимательно читаешь. Я как раз таки и не предлагаю хранить всё в одном файле, ёлы-палы!!! Как раз наоборот: всё лежит по отдельности!!! Одна текстура - один граф файл. Так художникам легче что-то переделать, изменить размерность тектуры например.
Всё вмести уже сам движок соединяет. Причём при загрузке, исходя из параметров видеокарты (максимальных размеров текстуры).
Во время загрузки он берёт все текстуры, самые частоиспользуемые кладёт вместе (например шрифт, элементы интерфейса, курсоры). А остальные - как ты сам задашь(к примеру задать всем текстурам логический вес и отсортировать по убыванию). Цель всего этого шаманства - оптимизация. Ведь если при выводе отсортировать объекты по используемым текстурам, то получится очень-очень мало переключений между текстурами.
Правда, может возникнуть ситуация, когда такая здоровенная текстура будет подключаться к контексту из-за одного-единственного кусочка на ней... но тут уж ничего не сделать. Разве что можно провести статистику для каждого уровня и для каждой текстуры, чтобы посчитать - сколько раз за кадр используется каждая текстура(естественно на стадии тестирования). И это количество брать за "логический вес" для сортировки.

← →
Fosgen (2005-09-09 10:31) [106]

Мда... Так почитаешь твои "наполеоновские планы", так подумаешь, да ну его нафиг такой менеджер... Лучше уж как сейчас - все ручками... Вот именно такому навороченному менеджеру я бы и не доверился... Ну разве уж только мною же и написанному, но вот писать мне его влом...

← →
Coriolis (2005-09-09 12:14) [107]

ГЫГЫГЫ :)
Да, планы-то наполеоновские. Но не из-за их нереальности, а из-за "крутости". Но ведь красиво, а? (нет, я не говорю что идея моя, просто это действительно удобно для всех, и главное - для ГП)
Но и ручками нарезать - неудобно же! Вот налепил ты свои спрайты в кучу, штук так под 30. А потом понадобилось или поменять размеры, или вообще убрать один из них. Не, если ты не художник - то конечно, это не твоя проблема. Но художнику-то каково?..
Всё-таки ручками - дедовский метод! (типа провокация ;))
Мне тоже его влом писать ;)
Поэтому и интерисуюсь - не реализовано ли в GLScene подобного.
Вот, например, в движке халфы как текстуры хранятся? Нужели создаются аппаратные текстуры под каждую картинку? Их ведь дофига там, всяких размеров.

А GLScene хотя-бы сортирует объекты перед рендерингом по текстурам? Чтобы каждая используемая текстура вызывалась только один раз.

Поговорим о оптимизации GLScene. Найти похожие ветки