Slick Forums

Hey,

another idea that promises little advantages and massive amount of works.

The idea is all about the isolation and abstraction of the backend that is used by Slick. Currently LWJGL. Doing this is "simple". You just have to isolate all dependencies to LWJGL inside of classes that are used in the rest of Slick only though interfaces. Slick is not that far away from such a state. But its still a crap load of work.

What would the advantages be?

• A clearer internal structure as the dependencies to OpenGL get isolated
• The security that Slick will not die in case LWJGL drops dead
• Better possibilities to merge Slick-AE with the core of slick
• Possiblity to support multiple backends (LWJGL, libGDX, JOGL, Java2D, ASCII )

Disadvantages:

• Larger overhead when launching the game (because the backend needs to be selected)
• Additional development work (as multiple backends need to be maintained)

In my opinion it wouldn't be the worst idea to put something like this in place. Step by step. Changing everything around would be a bad thing I think.
It would give Slick2D a real advantage. IF a game is created solely with dependencies to Slick2D and not to the backends like Slick2D, its possible to change the used backend without changing the application. Offering unique possiblities to compare the different backends and avoid problems the different backends might have.
As example, a long time ago when the game I create did not use Slick it had a multiple-backend graphic engine. Supporting both LWJGL and JOGL. LWJGL proved to have the better performance on Windows systems but did not stand a change against JOGLs NEWT on Linux operating systems.

With the possibility to change the backend it would be possible to test exactly that and even to distribute the same game with different backends on different operating systems, to take the full advantages of what the OpenGL bindings out there have to offer.

Whats the general opinion on that one?

Nitram

_________________
http://illarion.org

Initially Kev created Slick2D as a simple 2D game wrapper on top of LWJGL. So that's more or less the "base statement" of Slick's existence.
Kev explicitly voted against supporting different backends. He already created such a library waaaaay back in the past that did just that, together with Endolf if I remember correctly. It supported Java 2D and OpenGL. It died.

The problem with supporting multiple backends is that you have to make too many compromises regarding features. You'll end up writing huge amounts of glue code or feature simulating/replicating code and basically always have to live with the least common denominator.

But is it really worth the effort? How often do you change the backend? Why would you?

The only additional interesting backend I see is the Android one via libgdx. And even there it's a separate project because certain "features" of libgdx and limitations of Android/Dalvik make it very complicated to have a single high level codebase.

In my opinion the Android version of Slick (based on libgdx) would be the only other backend (next to LWJGL) worth supporting and where we should try to have a common code base if possible.

Just my 2 cents (and maybe one or two from Kev ),
Tommy

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

Sorry, but this is not something Slick should ever try to do IMO. It causes too many problems, places too much onus on the game developer to abstract their rendering, etc.

And, no offense, I don't think any of the current devs have a deep enough understanding of OpenGL/Android (or even Slick itself) in order to make this work. Surely, the outcome would be lightyears behind LibGDX.

I also don't think Slick-AE should be introduced into the main Slick codebase as it requires much different needs and would limit the feature set of Slick (e.g. abstracting touch input, mouse cursors, Sound.setPosition(), etc). Slick-AE is right now basically just an experimental/buggy/messy wrapper around LibGDX -- if somebody really wants to make an ambitious Android game, they should just learn LibGDX.

Developers should program their game and engine based on their target's needs. If they are targeting Android, then they will be using smaller sized art assets, less fancy shaders/effects, careful memory management, minimal CPU usage for battery life, accelerometer/touch input, etc. If they are targeting a medium-end computer, you can have beautiful graphics that scale well even at 1080p, lots of keyboard commands, lots of shaders and fancy effects, surround sound, etc. You can't just click a "Convert to Android" button and expect everything to work.

Okay. Thats the reason I wrote [IDEA]

If Slick is supposed to be a collection of helpers for LWJGL that it makes no sense to support anything like backends.

Nitram

_________________
http://illarion.org