Реальные минусы Vulkan?

Есть целевые платформы поддерживают вулкан, то норм.

Производительность важна!

java

Шашечки или ехать?

ехать надо

Тогда лучше переехать с явы.

Просто у джавы синтаксис удобный, классы, логика (всё есть файл), платформо-независимость, сборщики мусора. Понимаю язык не молниеносный, но выдать пару соков можно.

Так же хочу сделать IDE для моддинга, не хочется внедрять условный луа в условный си.

синтаксис

C-подобных, почти у всех такой.

классы

Много где есть.

логика (всё есть файл)

huhh, это что я читаю?

платформо-независимость

Если это про write once, debug everywhere, то такое не очень интересно на десктопе. JVM приносит тормоза.

сборщики мусора

Приносит тормоза.

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

Напомню, что единственное популярное приложение на жаве (кубач) уступает своему клону на c++ и по производительности, и по популярности. И это несмотря на то, что клон моложе и имеет меньше фич.

Напомню, что единственное популярное приложение на жаве (кубач) уступает своему клону на c++ и по производительности, и по популярности.

Вообще не аргумент. Так получилось что аудитории бедрока (сишного кубача) и ява версий различается. Бедрок это консольные казуалы и дети, ява версия для тех кто в модосборки играет, свои сборки делает и моды пишет. И внезапно среди этих игроков дяденьки и тётеньки 30-40 лет встречаются. И в бедрок они играть не будут. И количество играющих в сборки посчитать сложнее чем играющих в бедрок.

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

ТС, не парься из за мнений фанатиков ЯП, используй тот ЯП который ты знаешь и на котором тебе комфортно писать. По поводу Вулкана — в теории это более низкоуровневая штука чем GL. Не уверен что уже есть библиотеки нативно юзающие Вулкан. Трансляторы GL в Вулкан есть...

По полочкам! Более того дополню что код багрока днище ещё какое. Испортить хорошую базу (примерно версия 1.8 бедрока). Понапихать ненужные маркетинг фичи, полностью закрыть и закупорить код. В джаве вижу модульную систему - где всё понятно. Ясно что за что отвечает, сам язык в освоении проще, так что и мод комьюнити больше. Сравнивать Джаву и Бедрок несообразно. Не сравнивайте открытую платформу, код и возможности которой улучшается с каждой версией и магазин - где главное обёртка.

Если

ТС, не парься из за мнений фанатиков ЯП, используй тот ЯП который ты знаешь и на котором тебе комфортно писать.

По полочкам!

То, точно также это работает и с GL vs Vulkan. LMAO.

Причем тут бедрок? Речь про minetest

на жаве (кубач) уступает своему клону на c++

и по популярности.

Ну если под этой популярностью имеется ввиду миллиард кривых клонов майнкрафта в гугл плее - то да, оно так. И какая польза от этого?

Отказ от Жабы.

Хотелось бы, но Minetest вообще никуда не годится.

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

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

И да, регистрант сверху прав, майнтест страдает от вечной недоделанности и ошибок дизайна. И при живом ява майнкрафте критическую базу разработчиков и мододелов не наберёт. Вот если за моддинг ява версии Микрософт начёт по судам таскать, как Рокстар, тогда возможно шанс появится. И всё равно вряд ли, скорее всего форкнут и перепишут какой нибудь релиз ява майна, и будут его развивать, именно потому что разработка на яве.

на джаве

Бери libgdx и сосредоточься на более важных вещах

Используй JS и делай игру в браузере. В нем WebGL и WebGPU есть

Так C# тоже самое по сути. не?

Вулкан во всём лучше GL. Но если точнее, то это внутренности GL, вывернутые наружу, чтобы можно было преодолеть некоторые ограничения GL (многопоточность по CPU, возможность использовать несколько GPU), в которые не так чтобы часто инди игроделы упирались. Но возможно для экспериментальных движков и вокселей самое оно.

Переходить трудно, особенно если активно не использовал последние версии GL и всё ещё помнишь что такое glBegin glVertex3f glEnd.

Производительность важна!

Почему ява а не плюсы?

но выдать пару соков можно.

Жидкости/физику твердых тел тоже на ней планируете?

Трудно переходить?

https://github.com/KhronosGroup/Vulkan-Hpp

Кубик: https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/samples/15_DrawCube/15_DrawCube.cpp

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

Manipulation detected.

Производительность java ниже. Точка.

Хорошую игру, которая приносит удовольствие, можно писать хоть на bash. Это не аргумент в пользу того, что производительность java не ниже.

Там основная часть в «../utils/utils.hpp», а не в Vulkan-Hpp.

Да, кэп! Так точно, кэп!

https://magnum.graphics

Light­weight and mod­u­lar C++11/C++14 graph­ics mid­dle­ware for games and data visu­al­iz­a­tion.

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

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

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

Java версию писал Нотч на коленке, Bedrock уже профессиональные программисты на С++, разница в производительности даже не 50%, когда Project Valhalla вкатится в основную Java, то разрыв еще сильнее сократится.

слой абстракции который позволит работать с вулканам как гл’ем

Называется Zink.

не понравится какая нибудь гл’е подобная фича - ничто не мешает писать свою?

Там не то чтобы гл фичи заменять можно. Скорее собери всё из элементарного конструктора сам. Узнаешь сколько гл делал под капотом грязной работы и как сложна синхронизация. К примеру там где были glClear; glUniform; рисуем; glSwapBuffers; повторяем, теперь нужно аллоцировать свопчейн на сразу несколько кадров, так как твой код может формировать задания на следующий кадр, пока рисуется предыдущий, а предпредыдущий показывается. И юниформы под каждый кадр будут свои, так как предыдущие могут быть всё ещё заняты GPU. Короче, синхронизация это теперь полностью твоя головная боль, раньше это всё было неявно размазано по множеству gl команд и оно само там ждало и аллоцировало копии буферов когда надо.

Java версию писал Нотч на коленке

Вот прям на коленке? Без компа? А Bedrock версию проф прогеры, а вот что значит проф? На проф компе что-ли?

Давай не будем в сотый раз спорить про перф java vs c++, есть херова гора тестов, почитай.

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

А Bedrock версию проф прогеры, а вот что значит проф?

С опытом в оптимизацию в контексте геймдева. Там вообще другая архитектура, их некорректно сравнивать.

Давай не будем в сотый раз спорить про перф java vs c++, есть херова гора тестов, почитай.

Тесты бывают разные, вот например С++ сливает C# и SBCL, я на Java переписывал пример, он выигрывал у всех трех. Нужно посмотреть на свойства двух языков, как исполняется код, я вот не вижу причин для того что бы Java в несколько раз тормозила в среднем. Примеры очень по разному можно написать.

Тесты бывают разные Garnet - кэш от Microsoft, написан на C#, делает и Redis, и Dragonfly (комментарий)

Да, один хитровы*****ый (или просто незнающий плюсы) написал херню на плюсах и гордо заявил, что они медленнее. А когда пример исправили, все начали петь, что это очень сложно и нужно сравнивать наивный код. Как обычно куча оговорок.

Там не было исправления, показывался пример работы с множеством независимых объектов чье время жизни определяется во время работы, что очень похоже на игры. Пример который появился позже имеет совсем другую логику и не может считаться «исправлением», это просто другая программа, объекты в нем не могут жить по отдельности, а находятся в едином векторе, ты бы хотел что бы все сущности в твоей игре, один раз попав в вектор, больше никогда не выгружались?

Реальный минус только один - он сложный и низкоуровневый.

И довольно кривоват с точки зрения сравнения с аналогичной архитектурой от MS, т.е. DirectX 12 - поэтому, наверное, я какую игрушку не возьму, с поддержкой вот новых фич - то на D3D12 она работает нормально, а на вулкане глючит.

Короче вывод: тест на плюсах должен быть написан через жопу, т.е. «правильно», и тогда он покажет «правильный результат», а иначе это, вы все, плюсовики, неправильные тесты пишите.

• а почему это правильно так делать?
• да потому что иначе они слишком быстрые получаются

С опытом в оптимизацию в контексте геймдева

Вовсе не факт, что они этот опыт применяли в полной мере. Сроки, продакт менеджеры, все дела…

Java версию писал Нотч на коленке

Слышала про игру Майнкампф? Её Гитлер в тюрьме написал1

Bedrock уже профессиональные программисты

И озвучивали тоже они.

когда Project Valhalla вкатится в основную Java, то разрыв еще сильнее сократится.

Извините меня-а! Извините меня-а! Я когда, в ноябре прошлого года, до 26 ноября сего года, не было ни-е-ди-но-го разрыва, ещё раз я вам говорю. Или я… Или вы нихт ферштейн, или вам надо по-китайски сказать как-то? Ни единого разрыва не было!

А.Уральский

Не всем дано думать, понимаю. Кстати, а ведь можно сказать наоборот, что тест был исправлен в C# версии. Как тебе такое?

Можно просто изменить условия задачи, и тогда в С++ не выйдет использовать вектор, тебе не хватает понимания о чем тест вообще, иначе бы ты интуитивно понял что не так. Например можно подавать на вход файлы, с заданием распределять объекты на группы, и потом из нескольких групп создавать подгруппы, после чего по списку из id удалять их.

Так же можно переписать пример как в С++ варианте #2 и на Java, C#, но тогда пропадет весь смысл, кстати в таком варианте Java тоже оказывается быстрее.

ты бы хотел что бы все сущности в твоей игре, один раз попав в вектор, больше никогда не выгружались?

Это основной механизм работы с памятью у игр на приставках / консолях. Если памяти не хвататет, грузят ту часть, которая нужна на этот уровень, а на следующий загружают другую.

Это не везде применимо, игру с открытым миром ты не сможешь загрузить заранее.

Это везде применимо, потому что объекты игры я загружу заранее, потом преаллоцирую с запасом массив ссылок на эти объекты + координаты, а уже потом «в открытом мире» будут заполнять преаллоцированный массив ссылками на объекты с координатами в рамках текущего сегмента впопенворлда. Эпизодически проверять смену сегмента и обновлять массив ссылок по необходимости. Это типовая схема реализации «уровня без границ» - никакой дурак не пытается «всё-всё-всё» хранить в памяти, и предзагрузка данных + отсев не нужных данных - это нулевой уровень обучения геймдеву.

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

В работе реального ПО расходы на аллокацию / освобождение памяти в сравнении с расходами на остальные операции обычно совершенно не значительны. В случае с играми - так вообще меньше 1%.

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

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

Лет 15-20 назад подтормаживания родного явовского AWT на обычном GUI были видны невооружённым глазом.

Это везде применимо, потому что объекты игры я загружу заранее

Что есть объекты игры? Текстур и моделей в GTA V более 50 гб. Как ты ее будешь запускать на компьютере с 4 гб памяти?

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

Я с этим и не спорил.

Ява может в целом прекрасно работать, пока речь идёт о байтах в её памяти.

Java может работать с байтами и не в своей managed памяти.

Лет 15-20 назад подтормаживания родного явовского AWT

Они видны и сейчас на любом компьютере.

Повторяю. Тест изначально идиотский. И он так написан, чтобы продемонстрировать якобы тормоза плюсов используя их жопой, а не руками. Давай еще просто слип_фор в плюсах расставим и не будем лицемерить.

Тест показывает что нормальный GC лучше чем его костылизация через подсчет ссылок, и это реальная проблема, Rust как язык вообще на этом построен, и его пользователи часто уверены что никакого GC там нету, и вся проблема решается статически. GC это встроенная возможность Java, умные указатели С++. Можно в С++ реализовать GC, и в любом языке можно сначала собрать нативный код и сделать к нему jmp, и что тогда сравнивать?

Ладно, тебе тест не нравится, какие по твоему свойства Java не позволяют ей нормально работать по сравнению с С++?

Тест показывает что нормальный GC лучше чем его костылизация через подсчет ссылок, и это реальная проблема

Какой был мой тезис?

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

Я тебе не говорил смотреть подлоги вместо тестов.

Ладно, тебе тест не нравится, какие по твоему свойства Java не позволяют ей нормально работать по сравнению с С++?

Ява нормально работает, но менее производительный и более ресурсоемкий по сравнению с плюсами. Что тут обсуждать?

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