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

ZenGL Update (6 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#75
(Правка: 4:29) 4:27, 21 июля 2021

Skvoznjak
> Допустим, с края окна есть управляющая хреновина. Один клик и курсор там, можно
> колбасить, не надо попадать в пиксель. Курсор часто теряется на экране, нужно
> им трясти чтобы заметить, а тут он сам перемещается в нужное место.
как это предоставить пользователю? ))) Всё, что делается, пользователь более-менее должен понимать. Кликнул он в одном месте, а вдруг не довёл? И такая схема не сработала... Пользователь начинает ругаться, что у него не работает что-то.

В таких ситуациях обратные жесты делают. Или клавиатуру.

> Надо. Относительные координаты для перемещения курсора не всегда подходят,
> нужно прописать в ZenGL получение реальных, тем более что они там есть -
> относительные из реальных делаются.
Не надо. ))) Нам достаточно расширить "поле попадания", допустим сделать курсор не "точкой попадания" а каким-то "радиусом попадания". Радиус зацепил область, значит схема сработала.

Палка о двух концах. Пользователь не хотел попадать, но попал... так что такие вещи, только в определённых ситуациях нужны.

> В игре, содержащей выезжающее окошко с кучей хреновин. Нажал на колесо, курсор
> упал вниз, покрутил колесо - окно вылезло, нажал что-то ещё - курсор перелетел
> влево или вправо, можно опять колесо крутить. Мышевозность 200% Это реально
> прикольно.
Да! Такие вещи прикольные! Но когда они понятные пользователю. Потому (как я считаю), проще связать клавиатуру с мышкой, и пользоваться подобными жестами зажав клавишу клавиатуры (что тоже не всегда будет одобрено пользователем на доте проверено, когда пытаешься одновременно и предмет клавиатурой в несколько кликов задействовать и мышкой работать - тут нужна привычка и очень сильная).


#76
15:27, 21 июля 2021

>Не надо

Делай как знаешь. Я тебе показал ништяк, который почти ничего не весит, моё дело сделано.

>Палка о двух концах. Пользователь не хотел попадать, но попал...

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

>Да! Такие вещи прикольные! Но когда они понятные пользователю. Потому (как я считаю), проще связать клавиатуру с мышкой,

Это параллельный, более быстрый, способ достичь результата, хак для продвинутых мышевозников. Если его затормозить клавой, то пользы будет 0. И зачем ты за всех решаешь, какие действия вызовут функцию в движке? Уже игровой редактор, сделал;)

#77
(Правка: 16:16) 16:06, 21 июля 2021

Skvoznjak
> И зачем ты за всех решаешь, какие действия вызовут функцию в движке?
Я в чём-то тебя ограничил? ))) Заметь, я не вводил вообще ни чего в движке, касательно мыши и многого другого. Я только использовал всё, что предоставляет ZenGL и искал решения для мака (и не только), чтоб не вылезали критичные ошибки в библиотеке. Ты вправе взять любую версию ZenGL или написать всё самому. )))

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

есть, например у Кладового, но у него чисто под Windows, решил он это всё под разные системы? Не знаю.

Ты просто не представляешь сколько у меня идей. ))) Блин, да бросить это всё и начать заниматься графикой, ради чего я вообще взялся за ZenGL. Ради того, чтоб поработать с OpenGL. И? Чем я занимаюсь? ))) Провожу тесты кода на скорость, удаляю ненужный код, состыковываю (чуть ли не притираю) каждую команду друг к другу. И всё ради чего?

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

Я даже малой части не сделал, того, чего вообще ни кому не хочется делать. Думаешь так просто было это поле ввода сделать? Возми версию 3.12 и сделай за 5 минут. ))) Понятно дело это не долго. Что там, нарисовал поле, вывел буковки в это поле, мышкой пощёлкал - о! поле готово! )))

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

Костыли потом на это всё ты лепить будешь? Чтоб всякие мелкие глюки убрать? ))))

Займись! Встань на моё место! И поглядим на тебя. )))

> Уже игровой редактор, сделал;)
https://gamedev.ru/code/forum/?id=254161&page=3&m=5311986#m40 - зачем повторяться? ))) Я даже знаю, что это такое. Потому что уже состыковывал движок с редактором карт. И, в данном случае, это очень далеко.

твою дивизию, даже выпустив последнюю версию, в последние дни только и занимаюсь, что какие-то глюки убираю, которые оказались в MacOS, что будет когда я на Android это всё тестировать буду? )))))))) Ещё две тонны косяков убирать? ))))))

#78
18:15, 22 июля 2021

>В данное время, я решаю проблемы общие для всех систем, то, чего нет, практически.

Там практически в базовом функционале звиздец кроется, на всех платформах. Данные грузятся в сишную задницу, за пределы массива, а потом через указатели достаются. Может это и быстрее, но потом очково во время работы видеорежима выгружать данные и подгружать новые, а без этого большой мир с мощным графоном не построишь. Не знаю, почему нельзя в одном потоке грузить и выгружать данные из строк типа rawbytestring. С этим не разбирался. Хотя может ты это уже и сделал, гляну как время будет.

>Займись! Встань на моё место! И поглядим на тебя. )))

Или игры делать, или движок до ума доводить, на всё сразу сил не хватит.

#79
19:40, 22 июля 2021

Skvoznjak
> но потом очково во время работы видеорежима выгружать данные и подгружать новые
это было и будет наверно всегда. Больше от возможностей жёсткого диска зависит. А не от ЯП, или ещё каких-то премудростей. Возможно можно сделать какие-то упрощённые схемы загрузки/выгрузки. Но такими схемами надо будет уметь пользоваться.

Самое сложное это именно распределение загрузки/выгрузки ресурсов. Потому и сделано многое, чтоб одним куском загрузить в память и с этой памятью работать, чтоб в это время был свободен жёсткий. В этом Andru наверно более прав был. Смысла нет юлозить по жесткому (читая файл кусками) и тратить на это время. И получается, надо пользователю объяснить, как работать с данными, чтоб они не "мешали" друг другу. Хотя в последнее время это мало кого заботит... ))) Потому только вторая демка как пример идёт.

Можно извернуться и для каждого уровня свой zip делать. ))) Тогда будет больше времени уходить на распаковку данных. Что быстрее чем загрузка нескольких файлов (но тоже не стоит именно только на этом акцентрировать внимание). Допустим легко-распаковываемый zip, для более быстрой работы.

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

#80
22:10, 22 июля 2021

>это было и будет наверно всегда. Больше от возможностей жёсткого диска зависит. А не от ЯП, или ещё каких-то премудростей. Возможно можно сделать какие-то упрощённые схемы загрузки/выгрузки. Но такими схемами надо будет уметь пользоваться.

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

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

А представь, что у тебя несколько стадий и совпадает в них по 20% контента. И если контент жирный, то зачем грузить сразу весь? По окончанию стадии выгрузили лишний и загрузили следующий. А сейчас вместо этого надо втихаря перезагрузить всё приложение. Подгрузку ресурсов не от хорошей жизни придумали, а потому что всю компьютерную память выжрали - все гигабайты. Сразу все 3д модельки и данатерские прибамбасы в память не помещаются. Если каждый месяц добавлять донатерские шмотки, которые выглядят иначе, а потом их обладатели соберутся вместе, то для отрисовки этого стада попугаев нужно много памяти. А ещё локации в памяти держать надо. А если локацию только одну держать, то и для попугаев памяти может хватить:)

>А вообще, зачастую лучше всего смешивать обычные данные с архивированными.

В этом движке 3д моделек нет, а ogg, ogv, jpg и png и так архивированные, их сильно не ужмёшь, только помешать кому-то лазить по файлам можно. Сохранки разве что зиповать хорошо.

#81
22:10, 23 июля 2021

Skvoznjak
> А если понадобится загрузить вдвое больше ресурсов, то атас, тушите свет -
> процесс разожрётся почти вдвое.
ты не понимаешь как работает система с диском? Невдомёк, что намного быстрее загрузить один раз, чем обращаться 10 раз к одному и тому же файлу? Иногда, даже проще последовательно загрузить несколько файлов и работать с ними. Исключение файлы, с которыми постоянно работать надо. И, если файл даже несколько сотен килобайт (вполне возможно десятки-сотни мегабайт), то проще загрузить его в память и работать с ним (если нужны все ресурсы или большая часть из них. Точно так же проще и сохранить в память, а потом не заморачиваясь сохранить целиком.
  Чем больше файлов, тем медленнее будет загрузка/сохранение. А вообще, если не нравится как это реализовано в ZenGL, то во второй демке показано как через stream загружать/выгружать файлы.
  Вообще это бесполезное обсуждение, пока нет ни чего поставить в противовес.

> А представь, что у тебя несколько стадий и совпадает в них по 20% контента.
Даже представлять не буду, по той причине, что, надо понимать что ты делаешь в программе. Если не понимаешь что делаешь, то ни чего не поможет.

> И если контент жирный, то зачем грузить сразу весь?
давай ты это гигантам расскажешь, у которых игры грузятся по 15 минут, для того чтоб запуститься. Точно так же, от того что не понимаешь что делаешь, ни чего не поможет.

> Сразу все 3д модельки и данатерские прибамбасы в память не помещаются
открою тебе секрет. Сами можели не так уж и много места занимают. Но вот их разукрашивание непомерное - да. Может и несколько гигов занять. Да всё просто. Делают всё так же как и со всеми программами. "Какая нафиг разница, у нас есть 128гигов памяти, а на остальных наср@ть".

> В этом движке 3д моделек нет, а ogg, ogv, jpg и png и так архивированные, их
> сильно не ужмёшь, только помешать кому-то лазить по файлам можно.
Повторюсь. Мы их закидываем в один файл и грузим разом. Потом работаем с памятью, а не обращаемся каждую сотню раз к диску, ради загрузки очередного файла (нескольких сотен файлов). И, это позволит быстрее работать с этими файлами.

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

#82
1:58, 25 июля 2021

>ты не понимаешь как работает система с диском? Невдомёк, что намного быстрее загрузить один раз, чем обращаться 10 раз к одному и тому же файлу?

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

>то во второй демке показано как через stream загружать/выгружать файлы.

А вот это надо глянуть. Выгрузка в ZenGL болезненная.

>Чем больше файлов, тем медленнее будет загрузка/сохранение.

Для сохранения нужно только глобальные переменные и аналогичные поля из объектов выгружать в текстовик а потом его архивировать. Это же не 3Д редактор, чтобы и картинки с модельками в сохраняемый проект кидать.

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

Это от того, что плюсы не тормозят, они только требуют райд из ССД и топовое железо с самой последней ОС. И машину времени при компиляции. И если разрабы на это наскребли, то и клиенты обязаны, иначе это не их клиенты. Если мы не их клиенты, то в чём можем их упрекнуть;)

#83
7:42, 25 июля 2021

Skvoznjak
> И если разрабы на это наскребли, то и клиенты обязаны
ну тут не поспоришь... )))

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

#84
17:35, 26 июля 2021

Обновил последнюю версию. Исправил все ошибки которые нашёл. Проверил на MacOS - работает.

Исправил давнюю ошибку. Когда можно было нажать две клавиши Shift (Ctrl, Alt, Command) и после отпускания одной из них событие K_SHIFT (K_CTRL, K_ALT, K_SUPER) так же "отжимались" (хотя не должны были). Теперь они сохраняют своё состояние, пока одна из клавиш нажата.

#85
18:09, 26 июля 2021

>Исправил все ошибки которые нашёл.

Ты будешь смеяться, но на гитхубе каталог Zengl_SRC/demos/FreePascal/tmp опять пропал, make ругается.

#86
(Правка: 19:55) 19:44, 26 июля 2021

Skvoznjak
> опять пропал
как обычно у меня... ))) блин, как туда каталог закинуть? Стопудово ещё не одна тонна ошибок подобных найдётся. )))

вроде исправил. )))

#87
13:53, 30 окт. 2021
+ Первые попытки прикрутить клавиатуру к Android

Как и думал, выползло множество глюков и недоработок. ))) Зато теперь могу определиться, как примерно клавиатура будет выглядеть на Android.

...надо ползти и править последнюю версию под Android, нахимичил походу слишком много всего, даже обычные демки не так просто запустить. )))

#88
(Правка: 19:52) 19:50, 30 окт. 2021

Краткий алфавит "о", "п","а","ж" в ведроиде не поместился - слово "счастье" не напишешь, не порядок.

+ Показать

По ходу придётся четырёхрядную клаву мутить, сокращая высоту кнопок.

#89
2:05, 31 окт. 2021

Skvoznjak
)))
Всё решаемо. Я же писал, что клавиатура сама подстраивается под окно. А тут видимо инициализировал клавиатуру раньше инициализации экрана. Хотя странно, почему это могло произойти?

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумОбщее