Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. osu!
  3. Development
  4. Feature Requests

Storyboard commands features request

posted
Total Posts
3
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +2
DarkProjector
308 posts
Joined January 2012
Topic Starter
DarkProjector
for animation objects ,there are some commands for changing animation frames
_FS,start_time,start_frame_index,end_frame_index,is_reset_current_frame_index(T/F)

Animation,Background,Centre,"SB\Player\momo.png",320,240,13,120,LoopForever
_FS,1000,10,12,T //Set frame displaying from index 10 index 12 in start_time=1000 and reset current frame index

So,a animation object can be token as a whole sprite and not neccessary to create more animation object for difference action:
Animation,Background,Centre,"SB\Player\momo_stand.png",320,240,5,120,LoopForever
_F,0,0,1000,1
_F,0,1000,,0
Animation,Background,Centre,"SB\Player\momo_move_start.png",320,240,5,120,LoopOnce
_F,0,1000,1600,1
_MX,0,1000,1600,320,350
_F,0,1600,,0
Animation,Background,Centre,"SB\Player\momo_move_loop.png",320,240,5,120,LoopForever
_F,0,1600,3000,1
_MX,0,1600,3000,350,400
_F,0,3000,,0
Animation,Background,Centre,"SB\Player\momo_move_end.png",320,240,5,120,LoopOnce
_F,0,3000,3600,1
_MX,0,3000,3600,400,330
_F,0,3600,,0

So use "_FS" we can do this:
Animation,Background,Centre,"SB\Player\momo.png",320,240,20,120,LoopForever    //Load 20 frames
_F,0,0,3600,1
_FS,0,0,4,1,T //Set stand loop
_FS,1000,5,9,1,T //move start
_MX,0,1000,1600,320,350
_FS,1600,10,14,1,T//move loop
_MX,0,1600,3000,350,400
_FS,3000,15,19,1,T//move end
_MX,0,3000,3600,400,300
Endaris
5,282 posts
Joined June 2010
Endaris
Hm, I'm not really convinced by this.

I think setting it up like you did here is the proper way to do it.

DarkProjector wrote:

Animation,Background,Centre,"SB\Player\momo_stand.png",320,240,5,120,LoopForever
_F,0,0,1000,1
_F,0,1000,,0
Animation,Background,Centre,"SB\Player\momo_move_start.png",320,240,5,120,LoopOnce
_F,0,1000,1600,1
_MX,0,1000,1600,320,350
_F,0,1600,,0
Animation,Background,Centre,"SB\Player\momo_move_loop.png",320,240,5,120,LoopForever
_F,0,1600,3000,1
_MX,0,1600,3000,350,400
_F,0,3000,,0
Animation,Background,Centre,"SB\Player\momo_move_end.png",320,240,5,120,LoopOnce
_F,0,3000,3600,1
_MX,0,3000,3600,400,330
_F,0,3600,,0
Reason is simple: Technically these are all separate states momo can be in and you want to be able to recombine them as fit. The syntax you suggest makes this harder to read and identify which part does what as comments are removed upon compiling afaik. You basically need to know inside out which frame number does what in order to understand this code.
You also have to be very careful because there's currently no way to tell the loop when it should repeat as the amount of frames during a command is no longer specified.
Looking at your example, frame 0-4 would be displayed from 0 to 1000 and frame 5-9 from 1000 to 1600. With that, the frametime does no longer seem to be constant within the animation or if it is you have to set up your animation sprites in a way that makes it appear like more effort than splitting the animation command.

tl;dr: It is much easier to read when you separate the states into different animations.

What I agree with though is that there should be a way to properly group commands that belong together but that should happen in a way where you can still identify what's going on.

Also one note:
Your example for the FS command shows 4 parameters but in your example you use 5. You might want to make that consistent.
DarkProjector
308 posts
Joined January 2012
Topic Starter
DarkProjector

Endaris wrote:

Hm, I'm not really convinced by this.

I think setting it up like you did here is the proper way to do it.

DarkProjector wrote:

Animation,Background,Centre,"SB\Player\momo_stand.png",320,240,5,120,LoopForever
_F,0,0,1000,1
_F,0,1000,,0
Animation,Background,Centre,"SB\Player\momo_move_start.png",320,240,5,120,LoopOnce
_F,0,1000,1600,1
_MX,0,1000,1600,320,350
_F,0,1600,,0
Animation,Background,Centre,"SB\Player\momo_move_loop.png",320,240,5,120,LoopForever
_F,0,1600,3000,1
_MX,0,1600,3000,350,400
_F,0,3000,,0
Animation,Background,Centre,"SB\Player\momo_move_end.png",320,240,5,120,LoopOnce
_F,0,3000,3600,1
_MX,0,3000,3600,400,330
_F,0,3600,,0
Reason is simple: Technically these are all separate states momo can be in and you want to be able to recombine them as fit. The syntax you suggest makes this harder to read and identify which part does what as comments are removed upon compiling afaik. You basically need to know inside out which frame number does what in order to understand this code.
You also have to be very careful because there's currently no way to tell the loop when it should repeat as the amount of frames during a command is no longer specified.
Looking at your example, frame 0-4 would be displayed from 0 to 1000 and frame 5-9 from 1000 to 1600. With that, the frametime does no longer seem to be constant within the animation or if it is you have to set up your animation sprites in a way that makes it appear like more effort than splitting the animation command.

tl;dr: It is much easier to read when you separate the states into different animations.

What I agree with though is that there should be a way to properly group commands that belong together but that should happen in a way where you can still identify what's going on.

Also one note:
Your example for the FS command shows 4 parameters but in your example you use 5. You might want to make that consistent.
Thanks for your reply ! :D
I just want to simplify the entire process which design a animation like a sprite(likes cocos2d) and set them easy.I agree the opinion you pointed which that's make harder to read and understand animation commands.but this command is optional (animation object keep it as is if not use them) and sb authors use them in their storyboard programming.
Please sign in to reply.

New reply

0
1 / 3