Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Trixt0r last won the day on January 1 2017

Trixt0r had the most liked content!

About Trixt0r

  • Birthday 11/19/1990

Contact Methods

  • ICQ

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Trixt0r's Achievements


Newbie (1/14)



  1. 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
  2. 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
  3. 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
  4. 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
  5. Its fixed, but the problem, was the fact, that Math.signum has been called on the scaling, which is removed now. - Trixt0r
  6. 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
  7. 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
  8. 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
  9. 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
  10. Can you share the JavaFX implementation with us? Would like to put the parts into the examples folder. - Trixt0r
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  • Create New...