ZenGL Update (30 стр)

Mirrel
>откуда такие выводы? )))

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

А если ты блэк металлических нот в демке испугался, то напрасно - там не сатанинская музыка, а христианская, с лучом света в ужасном мраке - есть и такое направление в тяжёлой музыке. Вот тебе образцы:
https://www.youtube.com/watch?v=YO2Z9xA4e0E&list=PLhRkQZ8X0g5ZnxU… kEGC&index=11
И на русском:
https://zvyki.com/song/104767012/Against_Death_-_Poshyol_Von_Go_Away/

>если ты чисто про частицы, то я их ещё не перебирал, если ты про ZenGL вообще, то извини, но перебирать код приходится, по простой причине, что меняю взаимодействие движком. При таких изменениях ни куда не убежишь от изменений, которые ломают совместимость.

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

>Там есть 19-я и 20-я демки, которые показывают полный функционал, вне LCL.

Они тоже не собрались пока статическую линковку не врубил. У тебя там так настроено, что в собранных либах для динамической линковки не хватает зависимостей для опенгл, потому нужно подключать статическую чтобы собралось. Смотри, как 19 демка по умолчанию у меня собирается:

Skvoznjak
> Смотри, как 19 демка по умолчанию у меня собирается:
да это я понял. Зависимости я изменил, а маке-файлы не исправил... (или исправил, но не все).

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

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

  Твоя демка помогла мне увидеть некоторые вещи, которых либо не хватает при работе с частицами, либо надо реализовать на том что уже готово. И мне надо это всё пересматривать. Мне надо знать, насколько правильна твоя реализация и можно ли её оставлять в том виде что ты предоставил, или реализовывать что-то подобное?!

Mirrel здарова бро! Я вот недавно вышел с зоны! Освободили меня

Mirrel
>Ещё раз повторяюсь, не берусь я за частицы по той причине, что на это надо выделить время! И не малое время!

Ещё Андру в мохнатые годы сделал частицы и написал: не используйте их. Лет прошло много, а воз и ныне там. Рассматривать как сделать красиво и полнофункционально можно долго, а между тем, если пользоваться движком, то может возникнуть потребность сделать чтобы "трах-бах и в продакшен". А размышлять, как это сделать красиво и полнофункционально, можно уже потом.

>Твоя демка помогла мне увидеть некоторые вещи, которых либо не хватает при работе с частицами, либо надо реализовать на том что уже готово. И мне надо это всё пересматривать. Мне надо знать, насколько правильна твоя реализация и можно ли её оставлять в том виде что ты предоставил, или реализовывать что-то подобное?!

Так я тебе сразу сразу расскажу что надо сделать чтобы пользоваться было удобно, потому что прошёлся по этим граблям. Перво наперво, нужно иметь возможность зарегистрировать эмиттер двумя способпми, но с одинаковым результатом: простынёй кода и загрузкой zei. В результате нужно получить не какой-то обдолбанный указатель, a

type
dududu_2 = record
i2: longint;
q3: byte;
end;

var
kniga_castic: array of dududu_2;

индекс "x" массива kniga_castic.  kniga_castic[x].i2 это будет индекс массива эмиттеров, к которым можно обращаться без всяких указателей:

А kniga_castic[x].q3 будет флагом проигрывать его твоим движком частиц в кадре или нет. если =0 то не проигрывать. А если больше, то проигрывать и чем больше, тем больший приоритет, то есть раньше проигрывать. Если емиттеров с однаковым приоритетом несколько, то больший из них тот, у которых индекс "х" меньше. По умолчанию, после создания эмиттера kniga_castic[x].q3=1;

Длина массива kniga_castic самостоятельно может увеличиваться, но уменьшаться не должна, чтобы программист не вылетел за пределы. Но сам он может эту длину уменьшить - она всегда должна отслеживаться движком при использовании, не уменьшилась ли.

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

MicroEx, привет, привет. Мои поздравления.

Skvoznjak, я посмотрю.

MicroEx
Главное, теперь файловую систему не пиши.

Skvoznjak
> zgl_config.cfg(246,6) Error: User defined: Preparation for manual use of OpenGL (OpenGL ES) is required.
а я даже не подумал, что ты читать не будешь что там написано. )))
  В файл загляни с ошибкой, увидишь проблему, я её специально выставил.

Mirrel
Наверно ты думал, что я все 7 штук этих файлов буду проверять и ловить привидений в makefile, когда знаю как скомпилировать. Нормальной логикой здоровых людей не всегда возможно предсказать с чем make линкует, копаться там, когда собирается - себе дороже! Если по другому расположить каталоги, то собираться будет вообще без make, просто коротким скриптом, для каждой платформы своим. А если make этого требует, то это какой-то странный гибрид.

Skvoznjak
> zgl_config.cfg
Ни чего не говорит? Макефайл только производит сборку. А человек обычно смотрит, что за ошибка, особенно если она расписана.

  Ну вот, я у себя проверил, всё работает. Ну и сразу правки внёс, если вдруг каталога вывода не будет существовать.

Извините, а тут поддержки html5 не планируется? я на данный момент только на вебе работаю. для меня очень актуально эта платформа!

MicroEx, нет, не планируется. По крайней мере пока не планируется.

Mirrel
окей понял!

Mirrel
>zgl_config.cfg
>Ни чего не говорит?

Когда расположение не очевидно, то на такие вопросы отвечает kfind, а он их 7 штук находит. Причём угадать, который из них мне нужен, с первого раза не получилось.

>Макефайл только производит сборку. А человек обычно смотрит, что за ошибка, особенно если она расписана.

Макефил производит сборку хз чего хз с чем, потому что в них часто имеется бардак и не самое лучшее угадывание нужных либ на целевой системе. А когда такие сборочные системы совсем не в состоянии решить свою задачу, то применяется autoreconf -i чтобы они переколбасились и хоть что-то собрали. О контроле за сборкой тут речь не идёт, это просто кака, пришедшая из мира си (а там сборку делают на специальной сборочной ОС, в которой перед сборкой устанавливаются только нужные библиотеки и заголовки) и нужная для красивого оформления релиза, а для проектов от неё нужно избавляться, потому что паскаль собирает и без этого. И посему макефиле и рассматривается как временное зло, тратить силы на которые следует лишь в крайнем случае, а из попытки переделать код под статическую линковку уже известно, каким ключом добавляются зависимости opengl, потому хватает разбора части сообщения об ошибке, а дальше не разбирается, ибо там написанное относится к неизвестному файлу - он же не один, а какой именно, это надо по их коду устанавливать - так сишные и их потомковые сборочные системы понятно сообщают что хотят для сборки. В стиле прорицателей и астрологов.

>Ну вот, я у себя проверил, всё работает.

Поздравляю. А частицы как были прикованы к координатам при их запуске, так и остались:)

Skvoznjak
> Когда расположение не очевидно
использовать чистый FPC твоё решение. Большинство используют среду разработки, которая прямиком открывает нужный файл, если он указан в проекте.

> А частицы как были прикованы к координатам при их запуске, так и остались
я и не писал, что занимался частицами... были устранены баги, которые явно критичнее чем модификация частиц. Например проблема, когда загружается много ресурсов, и вдруг приложение падает ни с того, ни с сего...

  Не, ну думаю ты прав, надо было всё же частицами заниматься... )))

Mirrel
>использовать чистый FPC твоё решение. Большинство используют среду разработки, которая прямиком открывает нужный файл, если он указан в проекте.

А у меня среда разработки - линукс:)))) С разными редакторами, а лазарус лишь один из них. А кто там большинство, это вопрос философский, потому что может кто-то сторонний открыть и попытаться демки собрать и желательно чтобы одной командой все сразу собрались. Тем более что для "пускания пыли в глаза" у тебя динамические библиотеки приготовлены. С ними бинарники получаются мелкие, показательные. А тут какая-то невозможность найти свои файлы в консоли вылезает. Как ни посмотри, а это недоработка, портящая презентацию, makefile должен был сам с ней разобраться.

>были устранены баги, которые явно критичнее чем модификация частиц. Например проблема, когда загружается много ресурсов, и вдруг приложение падает ни с того, ни с сего...

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

>надо было всё же частицами заниматься... )))

А что там ими заниматься? Для создания новых эмиттеров редактор есть, потому модификаторы их работы уже не особо и нужны, подвижности и режима включить/выключить только и не хватало. Второе решается неиспользованием для этих эмиттеров pengine2d_Draw(); и pengine2d_Proc(dt); - тут и патчить не обязательно, достаточно поискать демки года так 2011 и посмотреть, как там работало персональное включение каждого эмиттера, раз уж в новой демке такого примера нет:) А что-то сильно сложнее, это уже шейдеры.