Ark wrote:
Don't drivers provide backward compatibility with openGL ?
If I'm developping a quite big game going on for PC only (about 20k lines of codes), should I start porting it to LibGDX now, or keep using slick and eventually port it later, when the openGL compatibility really becomes an issue ?
If your game uses 20k LOC I would not be using Slick. That's my own opinion; I think a "big game" would benefit (for aesthetic and performance reasons) from more involved graphical techniques like shaders, sprite batching, and dynamic geometry -- things that Slick doesn't really offer. Effects like
per-pixel shadows (using shaders) or
dynamic 2D shadow geometry (using meshes + shaders) are not easy to implement efficiently in Slick.
Here is another example of what you can do with shaders and Meshes. If you want to do any of these things in Slick, you'll need to call low-level GL directly, which can be a problem since Slick doesn't guarantee any GL states and therefore might give you some nasty bugs down the road.
Then there is the question of tools. LibGDX has extremely powerful tools for
texture packing,
particle editing,
skeletal animation, etc. It also has a powerful built-in GUI (IMHO better and easier than TWL), box2D integration, extensions for dynamic 2D shadows, strong support for map editors like Tiled and GLEED2D (Slick's Tiled API is a bit of a disaster), cross-platform unicode font support, etc.
Slick's polygon rendering and render-to-texture is somewhat buggy and not always reliable, so basically all you should be expecting to do reliably with slick is rendering images to the screen using startUse/endUse/drawEmbedded. And, honestly, if you just want a way to draw sprites to the screen, using a little library
like this will be many times more performant (and more flexible for shaders etc) than Slick, since it uses batching.
Quote:
What sort of information do you have or can point us to that talks about possibility of poor support from drivers? When you say poor support, I'm leaning more towards to the "unusable" side.
These functions are marked as "deprecated" because they are planned to be removed from the API in future versions. And that's what is happening, as the technology moves forward. This means that new drivers are being built with OGL 3+ and the programmable pipeline in mind, rather than trying to optimize toward fixed-function and immediate mode rendering. To put it in perspective: Slick is targeting OpenGL version 1.1, which was released in 1997.
Things like polygon smoothing, glLineStipple, glLineWidth, etc. are already poorly supported in most drivers, and sometimes non-existent on OpenGL ES. If you want reliable line thickness and anti-aliasing in the 21st century, you need to use a geometry shader or triangulate the path manually, as explained
here.
More important features like glVertex, glTranslate, etc. will probably stick around for many years on desktop. These are already removed from OpenGL ES, though, so there is no chance of distributing to embedded systems (Ouya / Android computers, iPhone, WebGL, etc).
Like I keep saying: slick is "dead" or "deprecated" or whatever you want to call it. With that said, it's still a great little library and for a long time was the best alternative to Java2D (keep in mind, Slick was developed years ago, when NeHe and immediate mode were still all the rage). If you want to continue using a somewhat buggy and no-longer-maintained library for your games, that's your own decision. But I wouldn't recommend it if you're making a big or commercial game, nor would I recommend it if you're a beginner looking for a game framework that you can use for the next
N years.
Hope this clears up some of the questions.
Login
Register
FAQ
Search
