Компляторы

[wilah]

Зачем тогда херню писать?

 

[Heitem]

Не секрет, что игры редко пишутся на java, с тем, чтобы выйграть в скорости

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

Просто так сложилось, что раньше уж приходилось экономить почти каждый байт, поэтому java отпадала сама собой, да, тогда твоё заявление было актуально. Это привело к тому, что на C выросла популярная база наработанных технологий и библиотек полезных для геймдева. И ни для кого не секрет, что С++ имеет обратную совместимость с С. А это означает автоматическое перетекание всей наработанной базы к С++, быстренько заполонившему почти всю нишу геймдева.
К Java толком никто и не притрагивался, потому что на разработку базовых технологии и библиотек ушло бы слишком много времени, да и зачем, когда уже всё есть? А ещё есть куча специалистов (прогеров) в области геймдева, которые приноровились писать игры на С++.

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

И вообще, Java - говно. Котлин в массы.

Да JIT - хорошо, сейчас в гугле тоже почитал, убедился.
Но что тогда с майном? Был бы на плюсах не лагал бы!
[merge_posts_bbcode]Добавлено: 21.06.2016 20:05:26[/merge_posts_bbcode]

Java жрет много!

 

[Oldestkon]

Ты бесполезен.

 

[Asd73]

Скорость работы игр с текущим уровнем развития технологий зависит от выбранного языка ровно никак.

Наглядное подтверждение: minetest и StarMade. minetest на C++ (плагины могут быть на lua) и тормозит. StarMade на джаве, дальность прогрузки огромная по сравнению с майнкрафтом и ничего не тормозит.

 

[Heitem]

Я лишь отстаиваю свою позицию! Asd73 как то давал ссылку, на том сайте, после некоторых тестов, выявлены результаты, C(gcc) на "удивление" быстрее джавы, пусть использовалось и разворачивание цикла, ибо как я уже говорил пользователю не до этого дела.

 

[wilah]

Удваиваю коня. Были б у тебя мозги, давно молчал. Майн лагучий из-за его "крутого" кода. Даже я знаю пару дыр(хотя бы TCP, ибо для игры он особо не катит). Ну и GL11... Ах, шедевр.
VBO в сравнении с вызовами glBegin/end работает раза в 4. И где тут проблема в джаве?

 

[Oldestkon]

TCP для кубача вполне катит, не надо тут. Это тебе не first person FPS шутан. Имхо с UDP больше проблем оберешься.
Хотя, в общем, этот пункт спорный. Тут надо приводить какую-то статистику, а не устраивать перепалку словами.

Спойлер

Вот для сталкрафтика неоч)0

glBegin\end кубач не использует
там glDrawArrays, который не сильно-то отличается по производительности от вбо
Вбо - не волшебная приправа при использовании которой у тебя вырастает фпс, она лишь гарантирует гораздо большую гибкость, соответственно, можно эффективнее управлять данными, обновлять только необходимые участки данных, сокращать общий объём данных, да что твоя душенька пожелает. Но скорость работы зависит строго от твоей реализации. Не умеешь управлять данными - вбо будет медленнее drawArrays или того же callList.
GL11 для поддержки говнокомпов.
Да и вбо ввели по-моему уже давненько. Не вникал в реализацию правда.

Вот шейдеры и структура fbo введёные в 1.7.10 поистине бесполезны, там толком даже буфер глубины не вытащить, ибо можанги решили НАОПТИМИЗИРОВАТЬ, забив на текстурку-атачмент для буфера глубины, и оставив для него просто renderbuffer, который write-only. В итоге мы можем писать только бесполезные шейдеры, которые обрабатывают только цвет пикселя, кому нужна глубина сцены)
А реализованные шейдеры накладываются только на итоговый полноэкранный квад, где 4 вершинки. И два шейдера за кадр тоже не активируешь, опять же, нужны свои костыли. Писали ради баловства, видимо.
Так что нормальные шейдеры только велосипедировать.

 

[Icosider]

1. Посоветуйте хорошие компляторы модов 
2. Что за программы specialsource retroguard mcinjector fernflower, нашол в MCreator

Боже, спаси и сохрани. Если ты динозавр то 1.0-1.6.4 это mcp+forge, если 1.7-1.х то Gradlew.
2. Первое хз, обфускатор, хз, декомпилятор(могу ошибаться)

 

[wilah]

TCP для кубача вполне катит, не надо тут. Это тебе не first person FPS шутан. Имхо с UDP больше проблем оберешься.
Хотя, в общем, этот пункт спорный. Тут надо приводить какую-то статистику, а не устраивать перепалку словами.

Спойлер

Вот для сталкрафтика неоч)0

glBegin\end кубач не использует
там glDrawArrays, который не сильно-то отличается по производительности от вбо
Вбо - не волшебная приправа при использовании которой у тебя вырастает фпс, она лишь гарантирует гораздо большую гибкость, соответственно, можно эффективнее управлять данными, обновлять только необходимые участки данных, сокращать общий объём данных, да что твоя душенька пожелает. Но скорость работы зависит строго от твоей реализации. Не умеешь управлять данными - вбо будет медленнее drawArrays или того же callList.
GL11 для поддержки говнокомпов.
Да и вбо ввели по-моему уже давненько. Не вникал в реализацию правда.

Вот шейдеры и структура fbo введёные в 1.7.10 поистине бесполезны, там толком даже буфер глубины не вытащить, ибо можанги решили НАОПТИМИЗИРОВАТЬ, забив на текстурку-атачмент для буфера глубины, и оставив для него просто renderbuffer, который write-only. В итоге мы можем писать только бесполезные шейдеры, которые обрабатывают только цвет пикселя, кому нужна глубина сцены)
А реализованные шейдеры накладываются только на итоговый полноэкранный квад, где 4 вершинки. И два шейдера за кадр тоже не активируешь, опять же, нужны свои костыли. Писали ради баловства, видимо.
Так что если шейдеры только велосипедировать.

Ни скажи. Насколько мне известно, заголовок у датаграммы меньше, чем у "пакета" TCP(там поток вроде, хз). Хотя, там не особо много сжирает майныч. Сервер лагает, но вина разрабов сервера.

Насчёт 1.1.
За минимум 3.3 стоит брать, а не 1.1. 3.3 тоже не новый. Хотя встречал динозавра с 2.0.
Ну и майн прям вообще не чистит объекты, под которые выделена память.(текстуры уж точно. Метод есть, но он не используется).

А что за рендербуффер? Насколько известно, у фбо есть 2 текстуры: глубинная и, собственно, цветовая.

 

[Oldestkon]

А чо ему чистить текстуры? Разве что при смене ресурс-пака.
Основные причины лагающих серваков - небольшие утечки памяти в кубаче, нехилые утечки у форджа (с пакетами), и утечки очень популярных плагинов, у которых сотни тысяч-миллионы скачиваний)0
[merge_posts_bbcode]Добавлено: 22.06.2016 01:30:28[/merge_posts_bbcode]

Я даже ссылочку привёл, ало. Контейнер с write-only текстурками, нативно поддерживающий (или вроде даже реализающий) MSAA. В принципе норм решение, но вместе с шейдерами такое пихать было подло.

 

[wilah]

Знать б, что такое МСАА. Позор мне
А утечки, судя по производительности, не слабые. Насчёт текстур: хз, куда они деваются. Может хранятся в каком-то уголке Вселенной, называемым видеокартой.
[merge_posts_bbcode]Добавлено: 21.06.2016 23:36:02[/merge_posts_bbcode]

Renderbuffer - объект, который может юзаться ТОЛЬКО с FBO. Содержит картинку, в которую можно рисовать. А вот обрабатывать нельзя. Читать тоже.