Исправил отображение мира при выходе камеры за его границы. Теперь автоматически включается клип по реальным границам игрового пространства (раньше, если камера уезжала за пределы мира, объекты рисовались на сером фоне, теперь же они отсекаются границей мира)
Было
Промежуточный вариант (артефакты по краям)
Стало

В целом это можно было бы исправить просто сменой цвета очистки мирового фреймбуфера на черный, но с дополнительным clipRect надежнее

Исправил некорректную работу дебаг переменной r_lightning, раньше она забывала очистить лайтмапу и свет навечно зависал на экране, теперь он отключается как положено (это чисто для отладки, разумеется).

Добавил метод boolean isMoving() в класс Entity, возвращает true, если current_speed не нулевая

Добавил метод Entity[] getCollides() в класс Entity, который возвращает все Entity, с которыми в данный момент столкнулась данная

Добавил метод setUniform(String name, boolean value) в класс Shader, теперь задавать uniform bool стало удобнее (используется для режима grayscale, например)

Исправил нижнюю границу консоли (не отображалась почему-то)

Добавил метод create_int_buffer(int size) в BufferUtils (помимо byte и float)

Добавил показ центра камеры в r_debug (полезно, если используется кастомная камера и нужно ее тонко настроить)

Про исправление физики я уже писал:
В последнем билде улучшил физику, теперь игрока так не колбасит при столкновении и вероятность всяческих глюков с полетами через полкарты намного уменьшилась
Подкорректировал имена переменных, удалил дубль UIFont font из класса Console, кое-где раскидал новые комменты

Также сделал ветку 2.5 дефолтной в репозитории

After Engine GitHub

DominaN, для версий не ветки, а теги делают х.х

Oak, Мне проще так. А зачем тогда ветки?

DominaN, ветки необходимы для обособленной разработки. Например, существует такая методология как Git Flow, когда весь репоpиторий состоит из release-ветки, dev-ветки и множества feature-веток.
В основном, ветки используются для совместной работы, когда работа в одной ветке одновременно не представляется возможной.

Разумеется, ветки можно применять и работая одному. Например, закоммитив что-то, я решил попробовать некую новую экспериментальную фичу и для этого создал новую ветку experimental. Немного поработав с этой фичей, я закоммитил работу и переместился обратно на рабочую ветку. Через какое-то время я могу слить ветку experimental в основную, если уверен, что это то, что я хоте увидеть.

В принципе, подход "ветка на версию" (как в твоем случае), разумеется, не лишен смысла. Легко представить, что в версии 2.5 появился баг а функционале, который в следующей версии уже переписан, поэтому применить исправление из будущей версии не представляется возможным -- тогда можно закоммитить иправление в ветку 2.5. Однако если такого не требуется, то лучше использовать теги -- статические метки на некий коммит в истории.

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

Oak, по сути старая ветка уже deprecated. Там поломана совместимость, слишком много переписано и реструктурировано в новой версии. Так что по сути master ветка начинается с первого коммита версии 2.5

Имеет ли смысл сливать ветки и добавлять тэг v2.5 к первому коммиту новой версии, или же (как мне кажется лучше) снести master под корень и переименовать 2.5 в master?

DominaN, вопрос. Из двига можна сделать онлайн игру?

dimon_net, Можно

Цитата DominaN:

---

dimon_net, МожноЗвучить заманчиво.

На самом деле у dimon_net вполне нормальный вопрос, хотя конкретики не хватает.
DominaN, что сделать онлайновую - это-то понятно. Из любого можно. А поконкретнее? Есть там какие-нибудь штуки для взаимодействия с севером/клиентами?
У тебя же есть репозиторий на гитхабе? Добавь его в ПП