Slick2D vs Straight LWJGL

Ответ 1

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

Slick существует, чтобы воспользоваться аппаратной графикой и ускорением звука, а также предоставить эту мощь для 2D-игр с набором объектов и классов, которые имеют смысл для 2D-игр (спрайты и фрагменты, в отличие от геометрических моделей и трехмерной координаты пространство). Что это - его миссия, и она построена, чтобы быть потрясающей при решении этой проблемы. Тот факт, что Slick основан на LWJGL, - это просто вопрос, что LWJGL является библиотекой, на которой вы можете создать что-то вроде Slick. В истории людей, пытающихся создавать игры на Java, производительность графики всегда была серьезной проблемой для получения чего-либо качества на рынке. Slick существенно удаляет это препятствие для 2D-игр на рабочем столе (и, надеюсь, на Android, когда-нибудь).

При рассмотрении Slick vs. LWJGL это "правильный инструмент для правильной работы". Если вы строите 2D-игру на Java, Slick - это отличный способ. Если вы на самом деле создаете 3D-игру (или игру с двумерным видом сверху вниз, но у вас есть требование реально визуализировать ваши сцены в 3D), то LWJGL может стать вашей лучшей отправной точкой.

Если, однако, вы строите 2D-игру, и вы думаете, что стоит потратить ваше время на ее создание в LWJGL, 99% того, что вы собираетесь построить, чтобы эта работа была спрайтом, анимация, ввод ключей, поиск путей и звук. Slick уже построил эти вещи для вас - вы в значительной степени гарантированно изобретаете колесо, а также намерены, как и вы, вы не будете это делать, а также разработчики, которые годами работали над Slick. 2D-рендеринг игр является решаемой проблемой - не тратьте свое время. Если вы не серьезно в двигатели рендеринга (я даже не говорю о игровых движках, где вы тратите свое время на разработку игровой игры и механики, но на фактическую технологию рендеринга), вы "Я собираюсь найти его более чем немного разочаровывающим. Разочарование не будет из-за слишком сложной проблемы для решения (вы, безусловно, можете ее решить), это просто, что вы потратите месяцы на ее создание, и когда вы закончите, у вас будет уже некоторое подмножество функций включен в Slick, но нет игры, чтобы показать это. Умные люди, которые сделали Slick, уже решили элементы 2D игрового движка в Java для вас - воспользуйтесь их работой и не тратите месяцы, пытаясь построить что-то, что прямо перед вами.

Чтобы сделать окончательную аналогию, огромный взрыв игр на ПК в начале 90-х действительно произошел, когда DirectX вышла на рынок. Конечно, были видеоигры на всем пути назад к Atari, Apple] [, Commodore и т.д., Но произошел взрыв, абсолютно огромный прыжок в играх и технологиях, когда DirectX вышел на борт и спас разработчиков от написания собственных драйверов для звука и видео. Это буквально то, что разработчикам приходилось делать тогда, если они пишут игры - пишите или лицензируйте отдельные драйверы для каждой звуковой и видеокарты, чтобы они хотели, чтобы их игра продолжалась. DirectX дала разработчикам возможность перестать беспокоиться об этом - только беспокоиться, что аппаратное обеспечение "совместимо с DirectX" с определенной версией и было минимально мощным для обеспечения требуемой производительности, и все.

Трудно объяснить, насколько это было большим - но если вы разрабатываете 2D-игры на Java - Slick (или один из других игровых инструментов) - это ваш DirectX!

Ответ 2

Действительно хороший ответ от нормальности, я просто хочу сказать, хотите ли вы действительно оптимизировать свою сцену рисования в Slick2D, вам нужно знать, чем стандартный метод рисования Slick использует glBegin/glEnd.

С большим количеством спрайтов (~ 10 000) этот метод очень медленный. Чтобы избежать этой проблемы, вы можете использовать метод drawEmbedded на очень большом справочном листе или создать свой собственный метод с LWJGL. Лучше всего сделать рендеринг VBO = > http://lwjgl.org/wiki/index.php?title=Using_Vertex_Buffer_Objects_(VBO).