Just wondering if anyone knows of an implementation of a Spine runtime for SDL (more specifically, SDL2). I believe that I might be able to use or rewrite the C runtime if I wanted to incorporate Spine support in my project (it's just a simple C++ /SDL2 game atm), but I'm wondering if that's already been done, as the documentation for the runtime is a little lacking (no examples whatsoever). I think I'd be willing and able to purchase and use Spine if it had SDL support, or if I could easily figure out what I'd need to tweak in the existing C runtime.
SDL Runtime?
- Edited
Update After attempting to read through the C runtime on Github, I believe I am starting to wrap my mind around how I would need to go about implementing Spine in raw C++/SDL2. I'm wondering if anyone who is able can check my head as to whether or not I'm beginning to understand this properly. These are the things I believe I would have to do:
Implement the "extension" functions as indicated in the extension.h include, namely the _spAtlasPage_createTexture, _spAtlasPage_disposeTexture and _spUtil_readFile functions. With SDL, I'm guessing that the createTexture function would require that somehow I would have to create an SDL_Texture to somehow associate with the AtlasPage "object" (struct). Dispose texture would free the texture, and the readFile function...well, not sure what it does, really, as in the included example it just returns a character pointer from some other likely macroed function that's defined somewhere else.
Write a custom SkeletonRenderer class that would essentially loop through all skeletal slots and get the texture from the region of the atlas as required, at which point I could render the texture to an SDL_Renderer object inside the pipeline of my game. As I have some familiarly with libgdx, I looked at that implementation of SkeletonRenderer in the GitHub repo, and that seems to be essentially what the respective Java class in that implementation does.
Are these the only two major steps it would take to using a Spine skeleton in pure C++/SDL?
And if anyone has already done any of this and would be willing to lend me a hand, I'd be much appreciated. Just seems odd, given the amount of runtime libraries provided, that there isn't one already for SDL.
Side note (the only other issue stopping me from deciding to use Spine) As it is now, paying $60 for a license to a piece of software that I know I'm going to have to potentially write a substantial amount of code to bridge into my project seems like it might be a waste of time when writing my own tool from scratch may be a more practical option. Granted, the GUI interface for Spine is nice and all, but for something I'd spend a good chunk of short-term money, and potentially a much larger chunk of long-term money for, I'd kind of want it to work "out of the box" so-to-speak. Thoughts?
AFAIK, no one has shared Spine implementation for SDL yet, sorry.
You're on the right track to extend spine-c and implement rendering. You can look at spine-sfml which does this for SFML:
https://github.com/EsotericSoftware/spi ... /src/spine
This is closer than spine-libgdx to what you will be doing for SDL.
It's true you'll need to write some rendering code since SDL isn't an official runtime (120 lines of code for SFML). Going with Spine means you don't have to write the rest of the runtime (what spine-c provides) and you don't have to write animation tools, which would be a huge amount of work even if you don't aim for Spine's level of polish. I like to think about it like this:
If you can find a tool that costs "C" that does (or almost does) what you want, do the math:
1) T = Guess of time savings.
2) Account for opportunity cost: 2T
3) How much is my time worth: E
4) If 2TE >= C: buy and move on to important stuff.
- Edited
Haha true enough, compelling argument I think I'll probably take a crack at seeing if I can write the SDL runtime first, and then if I can I'll go from there. Since you can't export with the trial version, are there any just generic rigged models that exist that I could download for the sake of testing a runtime? UPDATE Nm
saw that there are some example projects in the source of these runtimes.
Sure, there are a number on GitHub. I should really collect them and put them somewhere they are more easily found. Until then...
Packed spineboy and goblins example assets:
https://github.com/EsotericSoftware/spi ... ibgdx/test
Packed goblins example assets, premultiplied alpha:
https://github.com/EsotericSoftware/spi ... blins/data
Packed dragon example assets, premultiplied alpha, two page atlas:
https://github.com/EsotericSoftware/spi ... ragon/data
Unpacked spineboy example assets:
https://github.com/EsotericSoftware/spi ... -love/data
You can download the GitHub repo to more easily get the files:
https://github.com/EsotericSoftware/spi ... master.zip
Very cool, thanks man. I'll try to mess around with this a bit, and if I'm able to write a functional SDL runtime, I'll share it for posterity.
I would almost kill to see a working version of the spine runtime in SDL!
It was one of the first Game programming Libraries I played with when I first started out!
I also helped port Spine into D/DSFML and it was a blast to work on, So I know how cool/hard this is!
Good luck man!
- Edited
Well, I have some bad news after poking around with everything this weekend and trying to see if I could figure out a solution.
SDL unfortunately lacks a critical function that would make it relatively straightforward to duplicate the SFML extension functionality: namely, the ability to render textured polygons. There is actually an SDL library called sdl_gfx that grants that functionality, but unfortunately the function that facilitates that only takes SDL_Surface pointers to represent the texture itself, and as some of you may know with SDL2, there is now a hardware-accelerated version of surfaces called "textures" that is sort of replacing surfaces. So in theory, one could use the sdl_gfx library to accomplish a Spine SDL extension, but only by using the old-school surface blitting rendering method. For myself, I have gone the way of hardware accelerated textures in my game engine, which would mean that I would have to rewrite my rendering itself in order to build the Spine extension, and in so doing I would be essentially reverting to a less efficient rendering method.
SDL2 does allow for rendering rotated textures, so if rotational/anchor point data was used for the textures displayed at sockets, it could be done. Conversely, I'm sure someone who's better at math than I am could probably write some code to covert the skeleton vertexes to rotation angle/anchor points, although I'd guess that would be a mighty bottle necking calculation.
Long story short, I just don't think I'm going to be able to pull it off given the current state of SDL2 and the SDL2_gfx library. If the guy who's responsible for maintaining SDL2_gfx someday switches things up to use textures as opposed to surfaces, then I would have the ability and interest in doing it (I suppose I could just fork his code to make that happen, but I suspect that again there would be some math involved there that would be a bit tricky). So while in theory it might be possible, I think it's a bit above my skill level, and instead I think I'll have to look at other solutions for 2d skeletal animation. Good luck to anyone who attempts an SDL2 Spine extension, and hopefully this info is at least a little useful at getting started, and thanks to everyone for the convo and info.
UPDATE: I quickly looked through the source to sdl_gfx to see what his textured polygon function does, and weirdly enough it actually converts the surface to a texture, although I think I understand why he does it that way. He can get raw pixel data from the surface, and perhaps not from the texture.
Another method you could take is just using SDL to render directly to OpenGL primitives, but again that's kind of not a direction I want to take. As much as is possible I like to try to use these engines sort of "as is" without hacking them up too much. Perhaps, for me, it's reason enough to consider changing directions altogether again back to libgdx, who knows.
http://wiki.libsdl.org/FAQDevelopment
Says you can use OpenGL or Direct3D along with SDL, so it shouldn't be a problem to draw a textured quad (or polygon). This seems to be the suggested way to do just about anything non-trivial. The easiest way to go would be to use immediate mode and GL_QUAD. What OSes are you targeting?
Yeah I thought of that as well, but I'm just not sure I want to do too much direct opengl rendering...kind of pondering the options atm. I'd like to target PC to start, and I've been looking at the complexity of doing Ouya/Android as a secondary option. I think I'll mull it over a bit...I'm not real strong with direct OpenGl stuff, but maybe I'll let the option sit in my brain for a bit and give it a crack eventually. Still just kind of thinking it all over in total.
OpenGL is supported on desktop and Android, though I only assume SDL provides a layer that makes your GL code work in both places. Rendering in immediate mode is trivial:
glEnable(GL_TEXTURE_2D);
glEnable(GL_BLEND);
glBegin(GL_QUADS);
glColor4fv(r, g, b, a);
glTexCoord2f(u, v);
glVertex3f(x1, y1, 0);
glColor4fv(r, g, b, a);
glTexCoord2f(u2, v);
glVertex3f(x2, y1, 0);
glColor4fv(r, g, b, a);
glTexCoord2f(u2, v2);
glVertex3f(x2, y2, 0);
glColor4fv(r, g, b, a);
glTexCoord2f(u, v2);
glVertex3f(x1, y2, 0);
// ... more quads
glEnd();
Ever think about libgdx?
Haha yeah I've actually used libgdx on a different game project that I still have kicking around. You're the guy who made libgdx, right? I actually quite like it, it's just that from my experience doing Minecraft modding, I'm a little leary of how easy it is for people to decompile Java programs. Plus I just really like the feel of c/c++, as it feels like I have a little more direct contact with data. As far as game programming goes, I'm a little green overall, so I tend to bounce around from tool to tool.
As far as this little SDL problem goes, the major issue I forsee is that I'm not sure how SDL2's "regular" coordinate system correlates to actual OpenGL coords. I probably have to do some reading to understand it a bit, as I know that with the newest SDL version there's some automagic coordinate stuff that happens with virtual screen sizes and stuff.
And who knows, maybe if I bang my head against the wall with this stuff long enough I'll just concede and go back to libgdx to make the pain go away, haha
Aye, Mario and I are founders but there are 150+ other contributors to libgdx.
SDL seems like it mostly just handles window creation and a minimal API.
I would not worry that your game can be compiled. People have been cracking native apps for quite a while. Plus, if your app is cracked it means you have something successful. Until then, it isn't a problem that deserves attention.
Hi guys,
I modified the spine-sfml runtime to use SDL2 instead of SFML using the new long-sought geometry render API (i.e. SDL_RenderGeometry).
It's similar to what https://github.com/GerogeChong/spine-sdl did four years ago but with no OpenGL, only straight SDL.
It's also similar to a proof of concept https://github.com/rmg-nik/sdl_spine_demo did a few months ago.
I'm sticking as closely as possible to the original spine-sfml implementation. I'd say more than 70% of the code matches on a file compare. I'm providing spine-c and spine-cpp versions as well as working examples (matching the spine-sfml folders).
Come and get it: https://github.com/royalstream/spine-sdl
PS: The editor is not letting me use the url BBCode, probably because I just subscribed to the forum. So, you'll have to copy/paste the link. Sorry for the inconvenience.
Oh, that's awesome! I added it to the list of runtimes here: Spine: Runtimes: SDL
I didn't know SDL added geometry rendering. Looks pretty neat!
Mario wroteOh, that's awesome! I added it to the list of runtimes here: Spine: Runtimes: SDL
I didn't know SDL added geometry rendering. Looks pretty neat!
Yes they added it a few months ago, it's pretty recent. I've been waiting for something like this for years.
Thank you for adding it to the list of runtimes. I was wondering if some people could look for it under the C/C++ section and may miss it though.