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. 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. 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. 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). 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. 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. 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. 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. 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. 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. 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. Well, I have some bad news after poking around with everything this weekend and trying to see if I could figure out a solution. 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. 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. Just seems odd, given the amount of runtime libraries provided, that there isn't one already for SDL. 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.Īre these the only two major steps it would take to using a Spine skeleton in pure C++/SDL?Īnd if anyone has already done any of this and would be willing to lend me a hand, I'd be much appreciated. 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. 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. 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). Implement the "extension" functions as indicated in the extension.h include, namely the _spAtlasPage_createTexture, _spAtlasPage_disposeTexture and _spUtil_readFile functions. These are the things I believe I would have to do: I'm wondering if anyone who is able can check my head as to whether or not I'm beginning to understand this properly. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |