You could also simply set the component frame rate to whatever is required for a specific sequence (if it actually needs to be different), when that sequence plays.
Wouldn’t that work just as well, without requiring extra “play data” on the sequence?
Also, you don’t want every animation in the game to run at the same FPS, right?
Having a frame rate per component (per object, in other words) would not result in that - All the sequences in a given component would play back at the fps set for that component, and each component can have a different fps.
It doesn’t really seem natural to have a frame rate for each individual sequence; It seems to me that the sprite sheet itself should basically define the relative speed of any action, and then if I want to go faster, I should just generally animate faster (set the component frame rate to something higher), instead of having to twiddle with each “sequence frame rate”.
I mean, if you have a sprite sheet for a character, where the fps is required to be different for each sequence, just to have normal-looking playback, wouldn’t it be better to simply fix the sprite sheet, so that all sequences normalize to a base frame rate?
What are the other issues?
The clean seperation between what a sequence is (a collection of frames), and how it is played (fps, looping, etc) would be muddied, and that may lead to additional complexity, or general inelegance in the long term.
If having per sequence fps is really that crucial, for you as an artist - Ok, I guess we need it, but we should still take the time to really think about our assumptions before we commit to anything.
Maybe you want to start a timer on the last frame, or something, and having “blank copy” animations could stack up quickly. Especially so if you have to transition to them manually in a callback function. That’d be a lot of
if (animation == “Slide”) animation = “SlideFinish”;
if (animation == “Jump”) animation = “JumpFinish”;
copy-pasta, if I understand you.
There are no “blank copies”, and there are no callbacks. There would be a TexAnim.onLastFrame() method, which would return true whenever the last frame of the currently playing sequence is displayed:
class AnimControl extends Component{
private TexAnim ta;
public AnimControl(GameObject g){
super(g);
ta = g.texAnim;
}
private State onGround = new State() {
public void main(){
ta.sequence("Standing");
if (Bdx.keyboard.keyHit("space"))
ta.sequence("Jump");
state = jumping;
}
}
private State jumping = new State() {
public void main(){
if (ta.onLastFrame()){
g.movement.jump();
state = inAir;
}
}
}
private State inAir = new State() {
public void main(){
if (g.velocity().z > 0)
ta.sequence("MovingUp");
else
ta.sequence("Falling");
if (g.onGround())
state = onGround;
}
}
}
Logically, you’re talking about two sequences, even if “MovingUp” or “Falling” were just single, or even same frame sequences, they’re still different from “Jump” (conceptually). I would say the same for slide/sliding -> Isn’t it more sensible to have a “Slide” sequence, and then to transition into a “Sliding” sequence when “Slide” completes?
Looping sequences seem to be the core fundamental, so I don’t know … Can you think of some scenarios where a “play and stop” sequence has clear benefits?
That’s cool, but I wouldn’t go the “write more code for another tool” route when I could just solve a simpler problem, so to speak. That problem is, in a nutshell, “How to do sprite / texture animation in BDX?” I think it would be ideal not to involve multiple tools or add-ons for this, though I definitely see the advantage and use in Sprycle to visualize animations.
I might be misunderstanding you, though.
Yeah, I wasn’t clear enough:
TexAnim is designed to work with data in the Sprycle format, not specifically files produced by Sprycle. So, if you can generate relevant data in the same format, directly via Java, you don’t need Sprycle.
That’s how simple-mode works for BGE playback: I just use Python to generate the data in the same format that Sprycle would typically export.
Something similar could be done with TexAnim, to provide the features you require, on top of existing code.
Ah, I had to move it to the init() function rather than the main() function. Is that due to scenes having to exist before the engine runs or something? I could think of use cases where people might want to add scenes to a game dynamically.
It should also work in main … I think. If it doesn’t, it’s a bug, so feel free to make an issue (if there are any errors, be sure to include those).
