I am unsure of how much images actually impact performance. I think we can tell by strangeprogram that SB Load has little to do with it, and using a 2000x2000 image will only ever add 1.0 to the SB Load, making it somewhat useless as a determinant.

A lot of people use 1024x768 images as their backgrounds. In order to decrease the filesize of the beatmap, they might use that background in the storyboard. Well guess what? They can't according to these rules, since the "max" is 800x600. But then "scrolling images" are allowed 1920x480. For that reason, we shouldn't base it on some dimensions, but rather a number of pixels. Like, for example, 1920x480, which is 921600 pixels. That would mean the maximum image sizes are:
1920x480
640x1440
960x960
1108x831
Certainly you may think some of these numbers are a bit strange, but that's because they don't exactly fit into the method, but they all share the same maximum pixel value. What if you want to make a circular scrolling image, not a linear scrolling image? Or a diagonal one? You would be limited to the 800x600 value. What if you want a better quality scrolling image? 1536x600 is against the rules too, even though it has the same number of pixels.

There might also be a maximum dimensions (1920 length and 1440 height for example) to prevent a 912600x1 image, but in that case setting a maximum of 2000 for any dimension will work. It will stop any real abuse without removing any creativity.

So here's my revised rules

[Storyboarding]
Storyboard images must be at a reasonable size for their usage. For most uses (e.g. full-screen images), the maximum is 1024x768 pixels, although 640x480 is highly preferred. The editor is 640x480 at default, so there's really no need to use anything larger for full-screen purposes.
The maximum size of a scrolling image is 921600 pixels (1920x480, 640x1440, 960x960, etc...). This is for the sake of gameplay performance, image loading time, and filesize.

The first rule could actually be moved, as it is a guideline, not a rule, and the second rule can cover it easily.

Avoid going over a 5.0x storyboard load to help prevent lag on older computers. Resizing some of your storyboard images may help with this.

As I said earlier, the actual size of the images in the storyboard has nothing to do with SB load. Should just link to this: Tips on reducing SB Load (to eliminate lag!)

the max sb load is an actual non-spoken (strangely enough) guideline/rule

SB Load and SB File Sizes can be a bit conflicting with setting the ideal standards with. That's why what is said about it on the rules & guidelines is normally applied. Though, I thought there was more info on this as well. I'll have to check more into it again later...

Though, even with that 2000 x 2000 image adding another 1.0 load, it won't mean it can't cause major lag due to the data mass of the object. There has to be a reasonable size in file occupation space and dimensions. And then to add with that, there's also the amount of objects used at once for the SB. There was a map that had a 2.50 ~ 3.50 load but had MAJOR lag since there was +20 small objects active for the SB on that section. Compare that to another map with about 3 - 5 objects in the proper shapes (wallpaper dimensions) that makes the load jump up to the 5.00 mark with little lag.

The game will draw anyway anything with Fade > 0 anyway. So the max dimension rule is no sense or better, it only go helping the file size,not the load. 2 1x1 Scaled to 800x800 have about the same load of 2 800x800 images

ziin wrote:

[Storyboarding]
Storyboard images must be at a reasonable size for their usage. For most uses (e.g. full-screen images), the maximum is 1024x768 pixels, although 640x480 is highly preferred. The editor is 640x480 at default, so there's really no need to use anything larger for full-screen purposes.
The maximum size of a scrolling image is 921600 pixels (1920x480, 640x1440, 960x960, etc...). This is for the sake of gameplay performance, image loading time, and filesize.

The first rule could actually be moved, as it is a guideline, not a rule, and the second rule can cover it easily.

I agree with your revised rules, and especially the maximum being 1024x768 for full-screen purposes !
Although, it shouldn't really be "most uses", as most uses don't include full-screen purposes very often. Obviously, common sense should apply, and you shouldn't be using 1024x768 pictures for, say, strobes or the like - rather, it should be used for detailed static images, such as a background being used in the storyboard, or in cases where a storyboard uses several backgrounds throughout the song (did I just accidentally repeat myself ?).

However, I always have, and I will still disagree with 640x480 being preferred. Obviously, while there are still people using low resolutions, there are also those who like to play osu! in higher resolutions, so in my opinion, 800x600 should be preferred over 640x480. Again, common sense should apply, and there's no need for this if your images aren't much more than a gradient or the like. For things that aren't full-screen, you can easily go even lower, and still keep a good image quality in high resolutions.


This one is, if you ask me, already quite efficient with the 1024x768 picture, and I don't see why something like it shouldn't be rankable; It uses the "actual" 1024x768 background for a scrolling image in the beginning, then switches over to the transparent one in the screenshots, with effect/text images being appropriately smaller.

TL;DR: I agree with ziin's post !

let me say .. the 1st resolution is higher... right? anyway, for image with gradients, compression create quite many artifacts (banding is the one more seeable in that image...).
As now only 1% of peoples have a resolution lower than 1024x768 so it's time to upgrade, right?

Arise, thread long since dead and serve my dark purpose.

I need an icon of some sort for closure on this one.

bump again

since the size of screen is always 1680x1050 or 1920x1080, i suppose larger images are reasonable. and about sb load, i'm not very sure about old computer but to myself, i ever tryed 50x SB load and my FPS is still over 800+ (intel i7 2600k + sapphire 6950 toxic), so maybe 10x SB load is acceptable.

osu has it's own window size I have to say. Also it would be ridiculous if SB pics(except scrolling pics) are allowed to contain more pixels than the largest BG can have (786432)

I agree to more flexible sb size tho

LKs wrote:

I agree to more flexible sb size tho

M2.