Войти
ПрограммированиеФорумОбщее

ZenGL Update (9 стр)

Страницы: 18 9 10 1113 Следующая »
#120
18:01, 1 мар 2022

Mirrel
> ни когда не пользовался, видимо пришло время... )))
сервак украинский. Так что если там где или чё-нить перебьют, то он уже и с впн-ом будет недоступен.

#121
18:40, 1 мар 2022

Mirrel
>А про "нелюбимый огрызок" - это ты зря.

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

>Android 64 не настроен от слова совсем

Вот на него забил ещё больше:)

>Хочешь помочь? Пожалуйста! Возьми протестируй эмиттеры, воткни дополнительный эмиттер, погоняй его по возможности и я воткну его ко всем остальным. Но он должен обрабатывать своё движение тогда, когда происходит это движение, а не тогда, когда он будет прорисовываться. А то окажется, что мы прорисовываем эмиттер, а его не должно быть уже.

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

#122
(Правка: 19:15) 19:15, 1 мар 2022

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

#123
23:04, 1 мар 2022

skalogryz
Для ООП сейчас есть castle, а ZenGL нужен для полного контроля над кодом. Нет никакой сложности впендюрить патч для всех эмиттеров в другую процедуру. Будет он более сложным, только и всего. Тут вопрос обратной совместимости - придётся в эти эмиттеры использующих проектах прописывать инициализацию ещё двух переменных. Тупо записывать в них нули.

#124
0:06, 2 мар 2022

Skvoznjak
> Ты растягиванием на кучу платформ
не растягиванием, а поддержкой. И эта поддержка идёт для любых поддерживаемых платформ. Ведь это не тебе приходится подгонять каждый кусочек кода, чтоб он работал на каждой платформе без проблем.
То, что тебя не интересует поддержка других платформ, это не может быть поводом, что я не должен этим заниматься.

Кстати, как OpenGL относится к куче платформ, не поддерживающим ПК? )))

А вообще, вот тебе подарочек, который был создан давно. Я подогнал код под последнюю версию. Извини, собирал изначально не я, потому только Lazarus (ну или Delphi). Хотя можешь и makefile к нему собрать. )))

> Ты даже не представляешь, каково это взять и сделать ещё один дополнительный
> эмиттер. А вдруг изменение понадобится в другом? Тогда и его дублировать
> придётся.
именно по этой причине, твой код не подойдёт для всех. Я не смогу всем и каждому расписывать каждый момент работы с эмиттерами. Но ты предлагаешь туда ещё и костыль вставить. ))) Чтоб людям легко не жилось.

#125
0:31, 2 мар 2022

Skvoznjak
> Ты растягиванием на кучу платформ
заметь, ты только это увидел! Хотя была работа именно с ZenGL. Менялся внутренний код, убирался ненужный код, исправлялись ошибки. Добавлялись ошибки ))), которые приходилось тут же убирать (надеюсь всё убрал, что успел сотворить). Где-то там, я указывал, что я ускорил работу с текстом. Причём ускорил так, что большинство не заметило изменений. Каждое исправление сделанное в коде, зачастую не замечается, улучшение так же не замечается.
Большинство (не все!) кто пишет обращают внимание на то, что их что-то не устраивает. ))) Иногда даже не могут сказать что именно. Но виноват то я. Ведь это я взялся за поддержку кода. )))

С твоей стороны я виноват в том, что я не занимаюсь эмиттерами. Но ты просто не можешь понять простых вещей. Это не будет просто. Даже найдя уже этот кусок кода, я застряну в изменении кода. Потому что у Andru и у меня разные подходы к работе данными. Они подобны. Но не совместимы.

Простой пример. Для того чтоб остановить звук, надо получить ID этого звука. Пока звук не создан, у него нет ID. Когда создаётся звук, его ID уходит вместе с этим звуком... Познакомьтесь demo14. И получить этот ID можно только через snd_Get с определёнными параметрами...

Ни чего не кажется странным? А такая ситуация со многими данными в ZenGL. И с эмиттерами то же самое.

Я переделываю такие вещи, ведь ID мы должны должны получать сразу при создании звука/эмиттера/таймера/текстуры/(ещё какой-то фигни), а не по определённому запросу.

#126
4:46, 2 мар 2022

Mirrel
>вот тебе подарочек, который был создан давно. Я подогнал код под последнюю версию

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

> Я не смогу всем и каждому расписывать каждый момент работы с эмиттерами.

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

>заметь, ты только это увидел!

Просто не ставил на это акцент.

>С твоей стороны я виноват в том, что я не занимаюсь эмиттерами.

Да нет. Что мне с ними надо было, я уже сделал. Ты сам спросил чего там не хватает. Там  мелочи не хватает, а то, что чувство прекрасного не даёт ограничиться минимальными патчами, ну это не ко мне вопрос.

>Простой пример. Для того чтоб остановить звук, надо получить ID этого звука. Пока звук не создан, у него нет ID. Когда создаётся звук, его ID уходит вместе с этим звуком... Познакомьтесь demo14. И получить этот ID можно только через snd_Get с определёнными параметрами...

>Ни чего не кажется странным? А такая ситуация со многими данными в ZenGL.

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

>Я переделываю такие вещи, ведь ID мы должны должны получать сразу при создании звука/эмиттера/таймера/текстуры/(ещё какой-то фигни), а не по определённому запросу.

Даже не заметил тут проблемы. Если написана процедура, которая включает проигрывание звука и получает потом ID, то для вызывающего эту процедуру обе эти операции происходят практически синхронно - в один вызов процедуры:)))) Ты просто спрятал часть кишок на уровень ниже.

#127
7:16, 2 мар 2022

Skvoznjak
> Для ООП сейчас есть castle, а ZenGL нужен для полного контроля над кодом
я не про внешний интерфейс, я про внутренюю реализацию

#128
8:45, 2 мар 2022

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

> У меня есть собранная старая версия
для меня важнее код, в котором как раз можно увидеть как всё происходит.

#129
17:33, 2 мар 2022

skalogryz
>я не про внешний интерфейс, я про внутренюю реализацию

И я про неё же. При ООП данные плодятся практически безконтрольно и доступ с контролем над ними минимальный. Примерно, как колонии крыс на складах питательных субстратов - ты их туда поместил, а дальше они сами решают, сколько их надо и что им делать:) Без ООП и мусорок в областях с указателями все данные в глобальных переменных плодятся строго по расписанию и ко всем им есть доступ и учёт.

#130
(Правка: 17:42) 17:41, 2 мар 2022

Mirrel
>ну если ты решил вечером помыться, и для этого ты целый день каждые пять минут обращаешься в водоканал есть вода дома или нет, и это для тебя нормально - то тут вопросов вообще нет! )))

Неудачная аналогия. Если в квартире не построен душ, а есть ванна, то мытьё в ней само по себе ответственное мероприятие требующее внимания, чёткого выполнения необходимых действий и подготовки. Например, собрался ты зимой помыться, а там на поверхности воды корочка льда образовалась, а помыться очень надо. Какие будут твои действия?

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

>для меня важнее код, в котором как раз можно увидеть как всё происходит.

И используется он для полировки только старого функционала.

#131
19:11, 2 мар 2022

Skvoznjak
> В случае же с проигрыванием звуков, то количество звуковых каналов там
> ограничено и они все поделены. Просто даёшь нужной процедуре команду проиграть
> нужный звук и она его проигрывает, если есть свободный канал и не выжраны
> лимиты, или не проигрывает. Всё очень просто, слой абстракции решает проблемы
> самостоятельно.
точнее, ты хочешь сказать, что знаешь, как работает ZenGL 3.12 со всеми менеджерами различных ресурсов? ))) Я на 99% уверен, что не знаешь, раз пишешь мне, разработчику ZenGL, вот эту вот чушь. Это не камень в огород Anru, я не знаю причин, почему он так сделал.

Я тебе привёл аналогию, не совсем верную, но отображающую что происходит. Но ты меня пытаешься в этом разубедить.

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

#132
19:47, 2 мар 2022

Skvoznjak
>И я про неё же. ... всем им есть доступ и учёт.
  Интересное утверждение. Тогда получается патерны "god-object" и "god-class" не такие уж антипаттерны? Интересуюсь прежде всего с точки зрения производительности.

#133
20:32, 2 мар 2022

Mirrel
>точнее, ты хочешь сказать, что знаешь, как работает ZenGL 3.12 со всеми менеджерами различных ресурсов? ))) Я на 99% уверен, что не знаешь, раз пишешь мне, разработчику ZenGL, вот эту вот чушь. Это не камень в огород Anru, я не знаю причин, почему он так сделал.

Это не чушь, а характеристика данная после эксплуатации. Загрузка же ресурсов в ZenGL это другой вопрос и сделана она нехорошо и мну это знает. Где-то там есть массивы, которые используются как резиновые - в них грузится данных больше чем есть их объём. Скорее всего автора такого шедевра С/С++ покусали. Ещё так в досе можно было писать, когда не было нормального доступа к памяти в защищённом режиме и нужно было извращаться чтобы откусить чуток EMS или XMS памяти. Это какое-то наследие старых нехороших практик. Мну давно предлагал грузить всё в rawbytestring-и чтобы не было такой порнографии. Пока же, оно работает нормально, только выгрузка ресурсов колбасит, посему при повторном запуске движка приложение нужно незаметно перезагружать. Ну и при закрытии программы плюётся ошибками, но они там технически ни на что не влияют.

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

Вот не надо сказок, это ты пользуешься тем функционалом эмиттеров, которому уже много лет и ничего там не исправил. А там и кроме движения эмиттеров кое что есть, что требует дополнительного тумблера. Откуда я это знаю, если не лез во внутренности?

ArtProg
>Интересное утверждение. Тогда получается патерны "god-object" и "god-class" не такие уж антипаттерны? Интересуюсь прежде всего с точки зрения производительности.

Это как сможешь реализовать. Фича ООП не скорость а автоматизированная копипаста чужих решений: тяп, ляп, бросили чего-то в бетономешалку, оно там само склеилось, разбухло, ожило, выскочило и приступило к работе:) А если писать традиционным методом, то нужно миллион проводочков правильно спаять и сотню тысяч винтиков свинтить - если есть какой-то сверхразум, который это хорошо и быстро сделает, то результат может быть лучше чем в среднем по ООП. Всё упирается в разум и выносливость программиста.

#134
21:50, 2 мар 2022

Skvoznjak
> Откуда я это знаю, если не лез во внутренности?
во внутренности эмиттеров. Основы ты не знаешь. Что и подтверждаешь своими высказываниями, причём практически всеми.

Надеюсь я понятно тебе отвечу. Я не буду лепить костылей в ZenGL. Либо перерабатываешь весь код, и даёшь возможность эмиттерам внутри процедуры обработки этих эмиттеров изменять свои координаты (это процедура proc, а не draw). Либо ждёшь пока у меня до этого руки дойдут.

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

Можешь кстати к Andru обратиться. Он делал эмиттеры, возможно он согласится всё переделать?

Не трать пожалуйста моё время, на обсуждение пустого!

Страницы: 18 9 10 1113 Следующая »
ПрограммированиеФорумОбщее