Trixt0r

This looks like the origin of your sprites is not applied/renderer properly, i.e you don't calculate the pivot points correctly. It also looks like your y-axis is pointing down, i.e. it grows to the bottom while Spriter's y-axis points upwards. - Trixt0r

Okay... I am done... except for the LWJGL implementation, which I won't implement now, since it takes more effort to code a usable one and it seems that everyone uses LibGDX anyway. Every specific implementation has its own project: Generic, required by every implementation: https://github.com/Trixt0r/spriter LibGDX: https://github.com/Trixt0r/gdx-spriter Slick2D: https://github.com/Trixt0r/slick2d-spriter Java2D: https://github.com/Trixt0r/java2d-spriter

Hey Guys! After a little break, I am currently cleaning up the whole project, so dependency management with gradle or maven is easier. I am splitting the project up into multiple git projects, so the actual generic imlementation is free from any LibGDX, Slick2D or LWJGL dependencies. The LibGDX part is already migrated, which means all GDX guys can use a clean library which is only requiring the spriter library and libgdx. The project lives here: https://github.com/Trixt0r/gdx-spriter All previous tests, which are based on LibGDX, live exist under https://github.com/Trixt0r/spriter-examples There you have an example for your LibGDX projects. As soon as I migrated the other implementations into seperate git repos, I will merge gradle-migration into the master branch. In a next step I will try to add variable and audio support. Btw, the generic implementation and the gdx implementation get built into the "mvn" branch, so make sure you add https://raw.github.com/Trixt0r/***/mvn/ to your repository configuration. - Trixt0r

Why are you creating two animations, when the only difference is the normal map? There are various ways to achieve dynamic lighting with Spriter. Instead of creating a new animation with normal maps, why you do not use character maps, and render the animation once with the sprites and once with the normal maps? You could calculate the animation render the sprites, switch the character map and render it again. This way you save CPU time, since you only need to calculate one animation. I really don't know how C2's rendering pipeline and your dynamic lighting works in detail, but another way would be to pass the normal map for each rendered sprite to the shader and do the dynamic lighting. Is your lighting based on deferred rendering? If so, you could simply go with the way I described before. - Trixt0r

Its fixed, but the problem, was the fact, that Math.signum has been called on the scaling, which is removed now. - Trixt0r

Good job. Yes. The Java2D renderer renders the animation not correctly ( the Slick2D renderer also), while LibGDX and LWJGL do it properly. The problem is, that the y-axis in Java2D is inverted while in Spriter it is not. I will push the fix today. Thanks for figuring it out. - Trixt0r

Sorry, I did see your message, but forgot to answer back -.- Are you using the Java2D renderer, I implemented or your own? If not mine, can I see the code? Is the character rendered correctly with LibGDX, Slick2D and LWJGL? - Trixt0r

Hi systemExklusiv, the hardest part, to get Box2D working with the Spriter API is the fact, that you have to create correct joints between the sprites. If you have bones for an entity, this should be rather easy (depends on how bones are meant to work for an entity) and an automated process for creating the joints could be implemented. But if you do not know how a sprite is related to another one, you have to define the joints manually, which may cost you some time (depends on the complexity of an entity). However, if you know how to connect the Box2D objects, it should not be a problem to let Box2D manipulate the sprites. The inverse kinematics part of the library does a similar thing. The current transformation of each object/bone gets read and then manipulated. The trick is, to let the player first update itself, then manipulate the transformation of each spriter object and draw the actual result to the screen. The logic would look like this: // Update player, can actually be skipped if the box2D bodies are already initialized.player.update();// Setup box2D bodies and joints, has to be called only oncespriterBox2DFetch(player);// Simulate physicsbox2DWorld.step(1/60f, 6, 2);// Set the transformation of the spriter objects to the one of the box2D objectsspriterBox2DTransformation(player);// Draw the resultdrawer.draw(player); I may try to add an example to the test suite for this case, this week. - Trixt0r

Hi Roberto, Well this makes sense. Why do you then open it 12 times? Load the data once, and cache it anywhere. These lines scmlHandle = Gdx.files.internal("data/spriter/"+image+"/"+image+".scml");reader = new SCMLReader(scmlHandle.read());data = reader.getData(); loader = new LibGdxLoader(data);loader.load(scmlHandle.file());drawer = new Mydrawer(loader, stage.getBatch()); have to be called only once, when you are doing your whole asset loading. You are wasting a lot of memory if you are loading the SCML file again on each coin creation. If I get back into the code, I will try to add some utility classes which should prevent you guys from doing such things. - Trixt0r

Can you share the JavaFX implementation with us? Would like to put the parts into the examples folder. - Trixt0r

Thanks for reporting these problems. I will have a look into it next week. @jaunusa You are using the Spriter class, which uses reflection and that is not supported in GWT yet. Don't know why this works for you in superDev mode? A workaround for your problem would be to replace all generic parts in the class with the LibGDX parts, i.e. every method which contains "getDeclaredConstructor" has to me re-implemented. Should be fairly easy... - Trixt0r

I'm quite impressed that you managed to implement an algorithm which is able to calculate such an accurate normal map just from a single (diffuse? the pumpkin is already shaded) texture. There are already tools like Crazy Bump out there, but they do not create such a good normal map for 2D sprites and are only useful for textures like walls, floors, etc. I would like to see your tool in action. Will it be for free? Is there already a demo application available? - Trixt0r

I can not support XCF since the converter is based on Java and I do not know of the existance of an *XCF parser for Java or any JVM language. Implementing such a parser on my own would be a bit overkill. PNG does not hold layer information. Converting a single Sprite Sheet to SCML would be quite easy. But the problem here is that it requires more user input than the PSD to SCML converter, if it is a plain image file with no further information (like a JSON file holding bounding boxes, etc.). I think adding such a feature in Spriter itself would make more sense. If I get the time, I may have a look into this a little bit more... -Trixt0r

You can actually set the speed value ony your own. A value of 15 does not mean 15 ms progress in time. It simply means 15 frames further in your animation. This means that your animation is at frame 900 after one second if your fps count is 60. To achieve the same result at 30 fps you would increase the speed to 30, at 15 fps to 60, and so on.So the calculation of the speed in your game would be: var framesYouWantToPlayInOneSecond = 900; //or 1000 or 5000, depends on your animations var fps = 60; //or 30, 90, 120, etc. player.speed = framesYouWantToPlayInOneSecond/fps; I was already thinking about setting the animation speed to a float rather than an integer. Could be benefitial for very slow playback of an animation. Would also work with the case of having higher fps than the animation frames you want to play. At the current state, this would not work. But if your spriter animation has less frames than 30, then you have to overthink the usage of Spriter ;). The flag is simply indicating whether to interpolate the last frame with the frist frame if the last frame's time is smaller than the animation length. Yes. I will have to look into this a bit further. I guess a workaround would be to immediately update the player tweener object after setting the animation, i.e. calling player.update() before player.setWeight(1) -Trixt0r

You could extend the PlayerTweener class, override the setPlayers method and add a PlayerListener to one of the Player objects and also add a default PlayerListener to your extended PlayerTweener. Now the listener for one of the Player objects listens for an animation change and reacts properly to it. The default listener for the extended PlayerTweener overrides the postProcess method, which is just incrementing the weight. I guess there is need for some more examples and maybe some utility classes... -Trixt0r

Have a look at my signature.

If I understand you correctly, you want to apply an animation on only some parts of a skeleton, while the rest keeps the current animation? Maybe this example can help you. It is possible, but you have to keep the structure of bones and objects always the same and the names of the body parts have also to be the same. - Trixt0r

I am very sorry that I am repsonding that late, ArrogaX. Combining those two examples would be definitely possible. But right now I am busy at work, and it is very hard for me to find some time. If no one can do it, I will try to do it, if I get some free time. You could also implement it on your own and I may give you some tipps, if you get in trouble. Just PM me via e-mail, ICQ or Facebook (fb.com/Trixt0r , the other two addresses are already posted in this thread somewhere). - Trixt0r

Hi Andreas Thanks for discovering the bug. Does this problem happen to sprites only or also to bones (just debug draw the player with a ShapeRenderer in case you didn't discover how to do it yet)? Maybe you could send me an SCML file with the two animations and a placeholder sprite. Didn't test the tweener with different scale options… But if the problem only occurs for sprites I may already know hiw to fix it. Btw, it is easier for me to react to bugs if you create an issue on github for it. Even if it is not a bug and you do not know how to make a workaround for your problem, I could add an example for your needs and commit the issue as "fixed". - Trixt0r

Maybe this memory issue can be resolved, using the JSON file format. As far as I know, the JSON parser from LibGDX is maintained better, so there should not be that much memory allocation. - Trixt0r

Looks like the xml format in the scml file is broken. Can you post it? - Trixt0r

Awesome boind, Do you have some approaches to solve this problem? If you have some code, you could send me a pull request on github and I can merge your solutions into the existing sources. - Trixt0r

Hey guys, I was working a little bit more on the psd-to-scml tool and was able to fix some very big bugs. Thanks to Aniketos with helping out with some test files. You can download the new version HERE. - Trixt0r

Hey guys! I created a new tool :D It is again based on Java and can convert Photoshop files (PSD files) to Spriter's SCML file format. So if you are done with creating your graphics you can save your layers as a *.psd file and use this tool. It will export all layers as cropped png images and create a Spriter animation file from it. You do not need to drag and drop each file on your own. Currently you can use it only via command line with: java -jar psd-to-scml.jar "psd filename" "output name". I may add a little GUI with some export options like pivots, offset, entity name, etc. Here you have some screenshots: Your layers in any image manipulation program, like Photoshop, Paint.NET, GIMP, etc. (if your programm cannot export into PSD file format you may have to look for a plugin): And this is what you see then in Spriter: You can test it with the two PSD test files in the zip package. Just call from your console e.g.: java -jar psd-to-scml.jar greyguy.psd And you should get a greyguy.scml file which you can open and edit with Spriter. Make sure you have the newest Java version installed. - Trixt0r psd-to-scml.zip

Regarding the garbage collection issues on Android: I replaced all List dependencies with arrays where necessary in the code. Could you test it again on your devices and give me some feedback? - Trixt0r