EDIT: The first version of the engine has been released as open-source. The engine can be downloaded from http://nyphoon.com/games/the-sprite-project/. Documentation is also available. I will be updating it regularly once my exams are over. While credit isn’t really required when using this engine in a game, I’d really appreciate it if you could like my Facebook Page or follow me on Twitter. The full license can be found in the above-mentioned link.
If you have any queries, feedback or problems, please post them here, message me or e-mail me (nyphoongames@gmail.com).
During this past week, I’ve been working on a Sprite Engine. I’ve always wanted to do something similar, and early this week I decided to give it a go. First of all, I’d like to thank @wezrule for pointing me in the right direction. Since asking a question about how to manage a texture, I’ve created the whole base engine and started implementing additional features. For example sprites can be set to loop or not loop, reverse or side-scroll. Unlike other Sprite Engines I found, this one doesn’t use shaders. I’ve posted a dev blog describing the work so far: http://nyphoon.com/sprite-engine-in-the-making/
The engine will be open-sourced for the jMonkeyEngine community, along with documentation explaining how the engine works. I should finish the engine next week, although I plan on continuing adding features as I go along.
@nehon, When I asked about it last week, I was told by wezrule that I didn’t have to use shaders. Since I don’t have a lot of experience with shaders, I found it very easy to implement. Given that not everyone knows how to use shaders, I believe an Engine which doesn’t use shaders could be easier to maintain and reprogram to do what it’s desired to do. I tried to make a 2D game before, but when I learned that I had to learn how to program shaders to use animations and such, and given that I couldn’t find any good documentation, I refrained because I thought the task was too daunting.
Why are you surprised, if I may ask? Are there any negative implications?
@memonick said:
Why are you surprised, if I may ask? Are there any negative implications?
The animation will be done on the UV on the CPU side (I guess), so that implies a lot of buffer writing on every frame. That's the week spot of our particle emitter, IMO.
It won't scale well on android for example, and that's too bad for a 2Dish game feature.
Shaders are hardware accelerated...that's faster, and IMO as easy to maintain.
So starting on a fresh new project I was surprised you chose this path.
I understand your point about shaders, but really...that's not as complicated as people think. That's just a different language (not that different in the syntax than java), that is using concepts that you'll have to know anyway if you're willing to make a game with opengl....
If you want I have a material that does exactly this. I use it for animating flames with a sprite sheet.
It only goes forward though, but I guess you could adapt it.
Tell me if you want it, I don’t want to spoil your effort and motivation. The way you’re doing it right now will work, and is a good learning experience anyway.
Thanks nehon. Without wanting to sound rude, I’d prefer it if you could provide with something which could help me learn shaders - such as how I could change UV Texture coordinates. I spent a lot of time searching online, and only found one ebook which, however, doesn’t really give concrete examples. I was aware that this would be more CPU-heavy, and since I won’t be porting any games for android, I thought I’d give it a go - particularly since I plan on working on something minimalistic which would require few sprites (and almost no animations).
To reduce checks, I will also let Libraries hold a certain type of sprites. For example one Library would only have static (unanimated - is that the right word?) sprites so that the Engine wouldn’t have to go through all of the sprites checking if they’re animated. Another Library would then be able to contain animated and static sprites.
Other than that if you google “glsl tutorials” there are plenty of good resources on basic glsl
Texture coordinates are sent to the shader as attributes (inTexCoord) and sent to the fragment shader with a varying so that the pixel can be fetched in the texture.
Animating sprites is basically having a sprite sheet texture and offsetting uv coordinates over time in the vertex shader before sending them to the fragment shader.
The general rule is to just get it done and worry about optimizations later. Nehons advice is good but as shaders are more low level they will generally take longer to write and there’s more chance to screw things up as fragment shaders are executed per pixel and if u do something silly in them can slow u down a lot, same with vertex shaders, also theres issues with recompilation etc. Shouldn’t be an issue too much as u probably only have 4 vertices. But I would just continue how u are, and then later if ur feeling adventurous u can try with shaders, and post back if there is any performance improvements.
The first version of the engine has been released as open-source. The engine can be downloaded from http://nyphoon.com/games/the-sprite-project/. Documentation is also available. I will be updating it regularly once my exams are over. While credit isn’t really required when using this engine in a game, I’d really appreciate it if you could like my Facebook Page or follow me on Twitter. The full license can be found in the above-mentioned link.
If you have any queries, feedback or problems, please post them here, message me or e-mail me (nyphoongames@gmail.com).
Hi @squizzle, thanks for your input. Yes, you can. The documentation does make it seem as if the guiNode is the only way it could be attached to. I will update it next time. You could attach it to the rootNode (or a node in the 3D space), although then you would probably want to use large sprites so that there’s minimal loss in quality when sprites are seen from up close.
In the past few weeks, I’ve been talking to an individual who will be using The Sprite Project for a University/College project (I don’t know any more details unfortunately). This open-source sprite engine has also received coverage from Game From Scratch and GameDev.Tuts+ in recent times.
Given the fact that this engine was the subject of attention of quite a number of developers, and since I’ve been asked to include further features, I will soon (in about two months’ time) be releasing another version. If you’ve got any feature requests, now’s the time to make them. Some of the features I plan on including in the new release:
Proper in-line documentation to make it easier for developers to expand upon the engine
Improved manual, usage examples and other information to help developers get going as fast as possible
Sprite scaling and other transformation feature introductions
Method overloading to make it easier to move sprites using floating-point numbers, thus facilitating transformations based off of the framerate
Add support for vertical sprites and block sprites
Introduce support of spritesheets using texture bounds
Implement culling of sprites which are off-screen, various options to tweak the effects of such culling
That’s what I was going for @squizzle. I also plan on toying around with slightly more advanced settings, such as rotating around a point. Other updates will include method overloads with different inputs (to facilitate use with tpf), and support for vertical and block sprites. There should also be the introduction of an option which will check whether a sprite is on-screen or not and remove it or its updates if it is hidden. Maybe most importantly, I will also implement sprite bounds to make it easier for developers who prefer to use sprite sheets.
And yes, it really is easy to make 3D sprites! jME does all the work, really, but the sprite itself follows the same concept as in a 2D plane, only adding depth.
I will finish and release this engine (so that at least I will be able to say I finished something using jME3 
) and take a look at them!