Не соглашусь. Половина использует анрил, а там с++. Да и наоборот отлично, когда у тебя внутренние библиотеки в Nau Engine написаны на с++, и ты сам тоже пишешь код на с++. Да и с++ довольно популярный язык.
Максимально передавал 12 изображений для отрисовки разреза поверхности с интересующими объектами внутри. Передавал высотное закодированное 512 на 512 пикселей и к нему 11 изображений 40 на 40. Итого получается 2 114 752 байта. Обновлял каждые 10 секунд, а сам шейдер поворачивался 60 раз в секунду. Фризов нигде не было. QSGNode сдох бы сразу. А как передать гигабайт в 100 мегабайт видеопамяти не знаю)
Такая ошибка у меня была при запуске GUI на QT на линуксе, где неправильно настроено видео окружение. Попробуйте найти как поставить окружение wayland. Могу предположить, что у меня на WSL такую же ошибку выдаст
Да и QT можно использовать как открытый код только для личных проектов, а не как коммерческий проект. Для коммерции у них цена очень большая, в то время как Flutter это open source фреймворк. Так что тут скорее flutter более открыт, чем QT. Про гтк не знаю, но скорее он мало подходит для мобильной разработки. Плюс во флаттере есть веб компиляция. Её завезли и в QT - но опять же, QT как раз проприетарная
Понял. Но это вес всех пнг, а так на экране только девять маленьких картинок суммарным разрешением 1024 на 760. Так что я думаю можно пренебречь здесь уже оптимизацией. Да и у Flame нет никаких трудностей в отображении ПНГ на игровом поле от слова совсем.
Нет, понятное дело. Фаллаут тактикс не написан на flutter) Всё дело в этом. На компьютере даже когда просто заполняю всё неудаляемыми объектами для дебага у меня 80 фпс. На телефоне это будет уже около 15-ти. У меня сейчас тоже всё прекрасно работает с любым количеством слоёв. Просто в самом начале так проще рисовать. И вообще так рисовать именно проще. А что касается красоты - это купленные ассеты, поскольку я СОВСЕМ не художник, я сугубо программист. Поэтому я не могу нарисовать классный пейзаж морской и впихнуть его в игру. Приходится лепить просто из кубиков. А из кубиков такого вот механизма как в аркануме в пустыне ты не сделаешь)
Да и требования - я все тесты делаю помимо своего Самсунга А32 на Xiaomi A1 семилетней давности - и там тоже всё супер быстро работает. Так что требования у меня тоже сейчас смешные) Не говоря про любой ПК, даже супер старый.
Была бы игра для компьютера - я бы делал её на с++, естественно)
Во-первых - в ран тайме компилировать картинку я не вижу смысла - так как у меня карта не меняется. Во-вторых - если карта рандомная - можно заранее сделать различные подложки и прочее, а лабиринт загружать уже походу - это не затратно. Поэтому в итоге Вы всё равно будете рисовать карту, чтобы это было Вам удобно, потому что она никак не повлияет ФПС в игре, потому что превратится просто в картинку. А почему так много слоёв получается - на одном слое земля, на один слой выше - грязь, на один слой выше ведро, на один слой выше - ствол дерева, на один слой выше - гриб для красоты. Ещё слой выше - листья, которые анимированно падают с дерева. Уже 6 слоёв. Допустим - это всё на горе, т.е. все остальные слои должны быть ниже этих. Уже 12 слоёв. Добавляем ещё слои для функции автокарты и в итоге получаем примерно такое же количество) Иначе невозможно сделать интересную картинку
Да, но даже с тюнингом нет вообще понятия столкновение с землёй и какая-то возможность работать с этим. Нет сложения этих сил на тело, нельзя создать любое тело для столкновения и так далее. Всё это не позволяет сделать более менее приятно ощущаемую игру. Надеюсь, что допишите движок. В плане отображения на экране и классов, которые с этим связаны - использовать Flame ну очень приятно. Да и я считаю это основным в игровых движках - именно картинка. Логику ты можешь с нуля сделать под себя и пользоваться
Не соглашусь. Половина использует анрил, а там с++. Да и наоборот отлично, когда у тебя внутренние библиотеки в Nau Engine написаны на с++, и ты сам тоже пишешь код на с++. Да и с++ довольно популярный язык.
Пример более сложный, но принцип тот же, один в один. Решил для статьи взять более простую вещь для понимания
Максимально передавал 12 изображений для отрисовки разреза поверхности с интересующими объектами внутри. Передавал высотное закодированное 512 на 512 пикселей и к нему 11 изображений 40 на 40. Итого получается 2 114 752 байта. Обновлял каждые 10 секунд, а сам шейдер поворачивался 60 раз в секунду. Фризов нигде не было. QSGNode сдох бы сразу. А как передать гигабайт в 100 мегабайт видеопамяти не знаю)
Такая ошибка у меня была при запуске GUI на QT на линуксе, где неправильно настроено видео окружение. Попробуйте найти как поставить окружение wayland. Могу предположить, что у меня на WSL такую же ошибку выдаст
Да и QT можно использовать как открытый код только для личных проектов, а не как коммерческий проект. Для коммерции у них цена очень большая, в то время как Flutter это open source фреймворк. Так что тут скорее flutter более открыт, чем QT. Про гтк не знаю, но скорее он мало подходит для мобильной разработки. Плюс во флаттере есть веб компиляция. Её завезли и в QT - но опять же, QT как раз проприетарная
Понял. Но это вес всех пнг, а так на экране только девять маленьких картинок суммарным разрешением 1024 на 760. Так что я думаю можно пренебречь здесь уже оптимизацией. Да и у Flame нет никаких трудностей в отображении ПНГ на игровом поле от слова совсем.
Благодарю, очень интересно будет посмотреть. В первый раз слышу про такие форматы
Нет, понятное дело. Фаллаут тактикс не написан на flutter) Всё дело в этом. На компьютере даже когда просто заполняю всё неудаляемыми объектами для дебага у меня 80 фпс. На телефоне это будет уже около 15-ти. У меня сейчас тоже всё прекрасно работает с любым количеством слоёв. Просто в самом начале так проще рисовать. И вообще так рисовать именно проще. А что касается красоты - это купленные ассеты, поскольку я СОВСЕМ не художник, я сугубо программист. Поэтому я не могу нарисовать классный пейзаж морской и впихнуть его в игру. Приходится лепить просто из кубиков. А из кубиков такого вот механизма как в аркануме в пустыне ты не сделаешь)
Да и требования - я все тесты делаю помимо своего Самсунга А32 на Xiaomi A1 семилетней давности - и там тоже всё супер быстро работает. Так что требования у меня тоже сейчас смешные) Не говоря про любой ПК, даже супер старый.
Была бы игра для компьютера - я бы делал её на с++, естественно)
Во-первых - в ран тайме компилировать картинку я не вижу смысла - так как у меня карта не меняется. Во-вторых - если карта рандомная - можно заранее сделать различные подложки и прочее, а лабиринт загружать уже походу - это не затратно. Поэтому в итоге Вы всё равно будете рисовать карту, чтобы это было Вам удобно, потому что она никак не повлияет ФПС в игре, потому что превратится просто в картинку. А почему так много слоёв получается - на одном слое земля, на один слой выше - грязь, на один слой выше ведро, на один слой выше - ствол дерева, на один слой выше - гриб для красоты. Ещё слой выше - листья, которые анимированно падают с дерева. Уже 6 слоёв. Допустим - это всё на горе, т.е. все остальные слои должны быть ниже этих. Уже 12 слоёв. Добавляем ещё слои для функции автокарты и в итоге получаем примерно такое же количество) Иначе невозможно сделать интересную картинку
Какие ещё варианты с поддержкой прозрачности? Я знаю только gif, но не смотрел различия в весе файлов
Да, но даже с тюнингом нет вообще понятия столкновение с землёй и какая-то возможность работать с этим. Нет сложения этих сил на тело, нельзя создать любое тело для столкновения и так далее. Всё это не позволяет сделать более менее приятно ощущаемую игру. Надеюсь, что допишите движок. В плане отображения на экране и классов, которые с этим связаны - использовать Flame ну очень приятно. Да и я считаю это основным в игровых движках - именно картинка. Логику ты можешь с нуля сделать под себя и пользоваться
Неплохо, я думал вылезет больше ошибок. А так, в общем-то, практически ничего менять и не пришлось. Круто