8DashP

Not sure if you want to consider the z-order values for those who need them. If so, the following are the changes I made, they could be a little more generic maybe :- In draw_simple_object, just before calling draw_internal, I added :- int zorder = obj1->z_index; Similarly for draw_tweened_object int zorder = ref1->z_index; Then I just added zorder to the paramater list for draw_internal void draw_internal(int folderID, int fileID, float x, float y, float angle, float scale_x, float scale_y, int zorder); You could make it optional in the parameter list I suppose, otherwise it just gets ignored by those why don't need it. Russell.

Thanks for the tips. Shiva development only directly supports Visual Studio at the moment. A my work around is working at the moment, I'm just going to push on to at least confirm the basics all work in Shiva before I look at back-factoring. I've almost got the example playing correctly now. Shiva insists on power of two texture sizes, so I had to do some UV manipulation to get the images lined up. Only thing left now is implementing z_index. Should be easy to do, but I'm curious why there's not already something in the renderer samples. Do SDL/Cocos2D just assume the draw order is sufficient? The issues with Shiva is being a 3D space, overlapping planes do not render in draw order. As I said, should be easy to fix, just wondering is all.

OK thanks. Guess I'm being a little impatient. i'll check things out in a bit more detail. By the way, I should have expanded on the pointer issue. It may be something to do with the shiva plugin environment, but where you are storing pointers to the images in your renderer code was a problem for me. When it got to draw_internal, the pointers were sometimes corrupt. I did find some google references that storing pointers in vectors is unreliable, as vector changes may invalidate existing pointers. I'm not entirely sure what the final issue is, but I changed from using pointers to identfy my images, to a named string, which I then looked up. Not the most efficient, and I will review the code, but just a heads up that this might be another Visual Studio issue.

After a lot of fighting with unreferenced pointers and code revisions, I have something close to playing the example animation. However, it plays the animation once and stops. Is there something specific you have to do to loop it, or am I missing the obvious? I also need to integrate the z-order in somehow, as my images are overlapping and in 3d space, that's not playing nice. Also, my images have gaps between them, but that could be because Shiva is resizing each part to a x2 dimension. Not sure how I'm going to get around that one just yet. Anyway, the main question is on looping, if you can point me in the right direction? Thanks. Russell.

For importing. Export to png is fine as it is, as oddly enough, shiva can do a manual import of .png files, which would be how an animated spritesheet would be used, but importing at runtime via scml, it doesn't handle .pngs properly. Treat this as lower priority if you have other more important changes though, as in the end, as I said, I may need to go the atlas route anyway. Thanks for the feedback.

You could try a batch converting program, such as XnConvert. Thanks for the suggestion. Yes, there are many ways to get to formats I can use, but as I am trying to write a plugin for 3rd party users, to go straight from spriters output to shiva's input, asking everyone to do format conversions is not a nice workflow.

This is probably not a widely requested feature, but what is the option of exporting to other file formats? My particular situation is that Shiva does not support dynamically loading .png files, they need to be .jpg (no transparency :( ) or .tga. So, a .tga would be a solution to my current problem. Long term though, when Atlas's are introduced, and I change the Shiva workflow, other options may be better anyway.

No worries, but while I got it to compile, doesn't necessarily mean it works :) Won't be sure till I test, which will be a little ways off. The filename extraction may not be the most efficient, as it's deleting more than needed, but it's the simplest code I think, and given it shouldn't be a performance critical section, I doubt it matters.

Thanks lucid. It'll take me a while to get up and going anyway, I just didn't want to start with the wrong assumptions. So the SCML format is basically set now, and complete? @Grimfang I've just downloaded the code project so I can have a look at it in Visual Studio 2010. Out of the box, I'm getting compile errors. I assume others have gotten Visual Studio to work, so not sure what I've missed. I'm just using the SCMLpp and the XML files and trying to put them in a wrapper project of my own, to just get it compiled. It's producing the following errors :- 1> SCMLpp.cpp 1>..\..\Sources\SCMLpp.cpp(26): error C2039: 'find' : is not a member of 'std' 1>..\..\Sources\SCMLpp.cpp(26): error C2228: left of '.base' must have class/struct/union 1> type is ''unknown-type'' 1>..\..\Sources\SCMLpp.cpp(26): error C3861: 'find': identifier not found 1>..\..\Sources\SCMLpp.cpp(2370): error C3861: 'c99_snprintf': identifier not found 1>..\..\Sources\SCMLpp.cpp(2511): error C2065: 'M_PI' : undeclared identifier 1>..\..\Sources\SCMLpp.cpp(2512): error C2065: 'M_PI' : undeclared identifier 1> XML_Helpers.cpp 1>..\..\Sources\XML_Helpers.cpp(15): error C3861: 'c99_vsnprintf': identifier not found 1>..\..\Sources\XML_Helpers.cpp(54): warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) 1>..\..\Sources\XML_Helpers.cpp(64): warning C4244: 'return' : conversion from 'double' to 'float', possible loss of data 1> Generating Code... ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== I see there are some tests for Visual Studio in the code, but that's where the first one about std::find is coming up, so I may have my compiler directives wrong. I'll work through the errors and see if I can resolve them, but is there something obvious missing that should maybe be documented for VS users? Thanks. Russell. *EDIT* I've made the following changes to correct the errors 1. Replaced my line 26 source.erase(std::find(source.rbegin(), source.rend(), '/').base(), source.end()); with source.erase(source.rfind('/'), source.length()); 2. Added the following declaration to XML_Helpers.h int c99_snprintf(char* str, size_t size, const char* format, ...); 3. Added the following include to SCMLpp.cpp #include 4. Swapped the declaration of the print helpers in XML_Helpers.cpp as follows // Visual Studio does not support snprintf properly. // This is from Valentin Milea on Stack Overflow. http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010/8712996#8712996 #ifdef _MSC_VER #define snprintf c99_snprintf int c99_vsnprintf(char* str, size_t size, const char* format, va_list ap) { int count = -1; if (size != 0) count = _vsnprintf_s(str, size, _TRUNCATE, format, ap); if (count == -1) count = _vscprintf(format, ap); return count; } int c99_snprintf(char* str, size_t size, const char* format, ...) { int count; va_list ap; va_start(ap, format); count = c99_vsnprintf(str, size, format, ap); va_end(ap); return count; } #else #include "libgen.h" #endif // _MSC_VER 5. And just because I don't like warnings either, I did an explicit conversion for the 2 remaining double to float warnings on setting s and c in SCMLpp.cpp // This is for rotating untranslated points and offsetting them to a new origin. static void rotate_point(float& x, float& y, float angle, float origin_x, float origin_y, bool flipped) { if(flipped) angle = -angle; float s = (float)sin(angle*M_PI/180); float c = (float)cos(angle*M_PI/180); float xnew = (x * c) - (y * s); float ynew = (x * s) + (y * c); xnew += origin_x; ynew += origin_y; x = xnew; y = ynew; } After those changes, I had a clean compile.

Hi, I've just found out about Spriter yesterday, and am still researching, but it looks like you've done a great job on the C++ library. I'm considering making a plugin for Shiva3D to support SCML and your code looks like a good base to start from. Shiva preferably stores all its resources internally however, so some updates will be needed, and the renderer could be quite involved, translating 2D to 3D. One of the big performace gains for Shiva is using texture atlases, which I see you haven't implemented yet. I'm not sure where this sits in the Spriter roadmap, but do you plan to implement it in your library? Thanks. Russell.