Anyone have a need for this? If so, I’ll throw it under extras.
Ummm… I added this anyways. Not intentionally but… hey… it’s cool!
Usage: same ol’ constructors
[java]
SpriteElement sprite = new SpriteElement(screen, new Vector2f(50,50), new Vector2f(64,64));
// atlas image
// # of image columns
// # of image rows
// # of frames per second
sprite.setSprite(“Textures/sprite.png”, 4, 4, 14);
screen.addElement(sprite);
[/java]
[java]
currentTrack += tpf;
if (currentTrack >= trackInterval) {
updateSprite();
currentTrack = 0;
}
[/java]
I would suggest changing this to
[java]
currentTrack += tpf;
while (currentTrack >= trackInterval) {
updateSprite();
currentTrack -= trackInterval;
}
[/java]
This way, you will get more stable fps. Might be not noticeable in normal cases, but I would suggest such approach as general practice.
This reminds me of the story from my friend - he was doing visualisations for football (soccer one) for national TV in one of eastern countries in ninenties. Opengl rendering on Silicon graphics, real-time overlay on transmission showing player names, ball trajectory on replays, etc, etc. Quite advanced stuff back then. Anyway, as they were responsible for majority of computer/network job there, they also were showing timer on big display in actual arena. And the code was something like this (for 50fps)
getExternalCameraInfo()
doRendering()
sendToBuffer()
timer += 20ms;
renderTime();
All these operations were really fast… but still had non-zero time. And it turned out that ‘second’ was actually taking bit more than second. For few years, all league football matches in his country were longer for 2-3 minutes because of that (refrees had their own hand clocks, but they were trusting big one displayed a lot more - after all, this is what everybody else was looking at). Finally some judge complained officially, they found a bug and fixed it.
2 Likes
Big ol’ forhead slap… guessing that the discarded time eventually catches up on you =)
I’ll fix this up and track down any other controls that have some for of interval tracking as well.
Soooo… random thought time:
Currently you can disable the sprite and it stops animating, however it has no way of setting the current frame to display. This probably should be added.
Even more random thoughts:
The current cursor effects uses some fairly significant hackery to display a particle emitter as a 2d element with some lacking in the transparency arena. I need to translate the current emitter into a 2D particle emitter, as this would be a fairly useful control for UI’s.
Between the sprite element and a 2D particle emitter, you could potentially use the GUI library to develop 2D games on top of the JME framework with relative easy.
1 Like