Оптимизировал проверку столкновений, на тестовой карте удалось снизить ежекадровый collision calls с ~1275 до ~25-30

DominaN, Цитата DominaN:

---

Oak, я с гитом не особо дружу, вот нетбинс кое-как настроил напиши подробнее чо там и как добавить. Ну тебе никто не мешает использовать отдельные пакеты движка, если ты можешь обеспечить их корректноеЕсли ты про `git config`, то при коммитировании укажи свой username и email в полях под окном сообщения о коммите. Оно сохранится и в следующие разы будет использоваться уже установленное.Картинка для иллюстрации.

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

glLoadMatrix(FloatBuffer buff) тебе нуженНет (пруф) такого метода в текущей версии LWJGL — для того, чтобы избежать таких ситуаций, как раз и используют системы управления зависимостями — такие как Maven/Gradle.

А пока пара вопросов по коду — зачем ты по всему коду используешь String.concat вместо "+" — первый вариант не более эффективен, чем второй. Думаю, что даже если использовать StringBuilder с хорошо подобранными значениями initialCapacity, то выйдет более эффективно.
Затем я бы порекомендовал создать коллекции для примитивных типов. Потому что боксинг/анбоксинг — медленно. К примеру, в файле Engine можно было бы написать вместо И получать из списка/класть в список примитивные значения, минуя автобоксинг.

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

Ах, и да, коммить почаще, пожалуйста Если в коммите 70 изменённых файлов, то это не очень правильно.

Oak, а я думал надо наоборот, набрать достаточно изменений и потом выкладывать
По поводу матриц - и правда, перешел сейчас на Nightly сборку, там действительно сделали эти методы более логичными. Тогда тебе нужен glLoadMatrixf(FloatBuffer buff)
По поводу конкатенации - http://korzh.net/2010-01-konkatenaciya-strok-v-java-bystree.html
По поводу коллекций - в смысле создать? С нуля класс написать?

Для коллекций примитивов есть библиотеки. Trove или Koloboke навскидку

DominaN, По поводу конкатенации - http://korzh.net/2010-01-konkatenaciya-strok-v-java-bystree.htmlДа, действительно быстрее, но на большом количестве строк, конечно, лучше использовать пресозданный StringBuilder.
По поводу коллекций - в смысле создать? С нуля класс написать?Угу, в LibGDX тоже так сделали. Иначе будешь очень много времени терять на автобоксинге.
Если неохота писать свои версии, то можно использовать сторонние библиотеки — например, HPPC.

Oak, 4 мегабайта? NET. spasibo

По поводу строк, я добавил свой метод объединения в StringUtils :
Что думаешь? Оправдано ли использование переменного количества аргументов?

DominaN, 4 мегабайта? NET. spasibo Ну, тогда пиши сам.
Оправдано ли использование переменного количества аргументов?да, нормально.
Такое дело — я бы вообще рекомендовал по максимуму использовать CharSequence. И String, и StringBuilder его имплементируют, поэтому если локально используешь StringBuilder-ы, то можно не вызывать .toString, который создаёт новую строку.

Oak, вообще по всему движку заменить чтоли? Не очень себе это представляю.

Последняя версия демки потребляет около 110 мб оперативы (java.exe). Вопрос, это много?

DominaN, вообще по всему движку заменить чтоли? Не очень себе это представляю.Я имею ввиду скорее методы drawString, там же всё равно внутри происходит итерация по символам.
Последняя версия демки потребляет около 110 мб оперативы (java.exe). Вопрос, это много?Нет, это лучше ожидаемого, если не происходит утечек памяти.

Обновил исходники. Добавил новый метод соединения строк. Еще оптимизировал коллизию, примерно как в Box2D, то есть можно задать точность проверки