Here are some important suggestions for reducing the strain that a storyboard can put on a player's computer. I apologize that this is a bit wordy, the actual ideas aren't that complicated, I just talk a lot. I'll bold the important bits.

Tip one: Disable your background image:

By default, the background that you choose for your map is displayed in the background through the entire song, even if you make a storyboard in front of it. This works great if you have a minimalist SB, or if your background image is shown as the background throughout your SB.

However, if you start storyboarding in other backgrounds in front of your background, this is a problem. See, osu! keeps drawing your background even when there's stuff in front of it, and the more layers you have going on, the more that osu! has to process, so if you have hidden layers, you're wasting system resources.

So what do you do?

osu! has a redundancy-eliminating feature that will automatically disable your background image from displaying throughout the song if you use that same image anywhere in your storyboard. So if your background image is being used as a background for just one "scene" of your storyboard, or if it's part of a slideshow-type deal, just call your image into the SB in the same way as you call all the other images, and everything will be fine.

But if you're going to have different storyboard elements going on throughout the whole map, and just want to add an image that will show as a background on the song select menu, and as a thumbnail on the website, then what you do is set the image as a background normally, and then add a single line of SB code under the "//Storyboard Layer 0 (Background)" heading of your .osb (or .osu, if you're doing different things on each difficulty). The line simply calls the background in, and then doesn't do anything with it.

Just replace "background.jpg" with the filename of your image in the following line:

Sprite,Background,TopLeft,"background.jpg",0,0

And that's it! Your background will be replaced with a solid black wall, which uses next to no processing power to draw. Especially compared to drawing a fullscreen background, and then drawing a fullscreen black.png in front of it, this is a huge improvement!

Tip Two: Avoid empty space in your images

For every png that you use in your storyboard, osu! has to draw the entire thing. Even transparent pixels need to be "drawn," so images with a lot of empty space place a lot of unnecessary stress on the computer. This is an easy one to fix, generally:

1. Trim your images as much as possible. Photoshop actually has a tool that will do this for you. Just hit Image -> Trim and it will give you a few options for cropping away empty space around your edges.
   
   
2. Make use of the different "origin" options that storyboarding gives you. Lets say you have a sprite of a character whose head bobs up and down. In most of the frames, there's a chunk of empty space at the top of the sprite, because you want all the frames to line up, right? But if you set the origin to BottomCentre, then it won't matter how tall the sprite is, it will always be aligned from the bottom. So you can eliminate the empty space at the top.
   
   
3. Multiple small images may be better than one big image. This can be pretty situation-specific, but let's say you have a big sprite that just has five little stars in it. Trimming that sprite might leave a bunch of empty space in the middle. Breaking the sprite into a bunch of little sprites may seem inefficient, but since osu's strain comes from the number of pixels rather than the number of files, it can actually be a big improvement.
   
   Similarly, if you have a full-screen "frame" image, with a big window or screen looking through to the rest of your SB, consider chopping that into 4 images, one for the left side, one for the right side, one for the top, and one for the bottom. Now instead of drawing nearly a full screen's worth of clear pixels, your empty space is actually empty, as only the border is drawn. You probably want to have just a bit of overlap at the corners to avoid gaps appearing when the map is played at certain resolutions, but try to keep the overlap as slim as possible.

Bonus tip: Don't forget that you can recolor images using SB coding.

I'm just mentioning this because I don't see this effect used much in storyboards, but check out the "colour" event code in the Scripting thread. You can make cool effects by making a grayscale or light-colored sprite, and overlaying different colors onto it during your SB. There might be some cases where you're fading in a whole separate background image when you could just change the color this way, for skies and stuff. Just something to consider.

Hopefully these tips are of some use to people. I know a lot of people don't know about the background disable feature, so please spread the word, especially if you see somebody using a big empty black image to hide their background image.

I think you should add in:
1.The BG size limit/SB element size
2. The conflict of the time loading SB element ( SB element end/load at the same time points)
3. What is the SB load limit allowable and exception for it
4. How "gameplay" resolution related to SB load

That all I can think for now~

Thank you, these are interesting tipps which will surely help to reduce my storyboard load in some maps. It's especially helpful how you describe some storyboard processing of osu!, I think this is important to understand the dos and don'ts of storyboarding. :3

This is good stuff. <3

Ayeen wrote:

I think you should add in:
1.The BG size limit/SB element size
2. The conflict of the time loading SB element ( SB element end/load at the same time points)
3. What is the SB load limit allowable and exception for it
4. How "gameplay" resolution related to SB load

That all I can think for now~

1. Well, that's more of a rule/guideline, and it's sort of been mentioned over in the Storyboard by Scripting topic already... I don't recall that there's any place that mentions the current dimension limits in public though...? O_o Anyway, the preferred size is 640x480 for static images, and for scrolling images, the maximum is 640x1440 and 1920x480.

2/3. That'd be an interesting can of worms to pop out. If it makes a small chip into the red zone but quickly gets itself out, I don't think it'll be that much of a problem. It also does depend on certain scenarios (such as having billions of small objects vs. a few larger ones)...

4. All based on 640x480, but the SB Load is based on any translucent image on the screen (Anything that doesn't have its Fade setting at 0). I don't know if it has been corrected yet (and I'll need to check that soon), but I recalled months ago that an object in the -x and -y region of the screen doesn't count for the SB Load, but the lag would still be apparent if it was something demanding...

Also, LH, I corrected a small thing in your OP. I changed Edit > Trim to Image > Trim, as that's where my Photoshop has it located. If it's somewhere else in another version or something, let me know!

And for the Bonus Tip, I don't want to be a shameless plug or anything, but my latest storyboard utilizes this heavily. I basically changed the whole atmosphere by simple color commands on three virtually monotonous images. Here's a link to it to see how this color optimization's been done.

http://osu.ppy.sh/s/31119

I have a question about loops and SB Load. I have the following event, for example:


The last few lines in both sections could be turned into a loop, but would running two loops at the same time have a higher SB Load than if I left it like this? Does it just depend on how fast the loops loop? Will I get bashed by an SB Modder about not using a loop?

EDIT: I did it myself and the SB Load is the same.