Betty (http://www.mrio-software.com/info.php?id=bbb) is approaching alpha so I begun doing some performance testing. After much tweaking of the sprite engine, the game is playable in a Pentium/100 with 32 MB of RAM, with almost every sprite drawn with alpha blending and lots of sprites moving at the same time.

However, a problem remains : load time. The sprite engine provides huge flexibility when loading images, for example, most of the graphics are stored as jpeg or 8-bit indexed BMP with their alpha channel in a separate 4-bit BMP, all of this read from a compressed resource file. The savings are huge - all the graphics so far (the bar, 27 animated characters and Betty) fit in 530 KB.

But this has a price; in particular, loading a separate alpha channel and "mixing" it with the color data is quite slow.

I've taken some measures. In my Athlon XP 1800+, the game goes from the first line of main() to playable state in 1.10 seconds. In the early mentioned P100, it takes 32 seconds.

I'm thinking of performing a post-install one-time preprocessing stage, decompressing all the bitmaps and storing them in a less efficient but faster loading format (and maybe computing color keyed bitmaps based on an alpha treshold, for really slow machines). So the user would pay an one-time penalty (say, 2 seconds in an XP, 60 seconds in a P100) and get faster load times every time they play (I estimate 0.7 and 24).

Question 1 : Will users wait for 32 seconds staring at a "Loading" screen?

Question 2 : Is a P100/32 a reasonable "low end" target, or am I aiming too low?

Question 3 : Is the post-install preprocessing acceptable for the user?

Thanks a lot!

Question 1 : Will users wait for 32 seconds staring at a "Loading" screen?

I wouldn't. I would just think the game had crashed. Even if I did have the patience to wait it out the first time, I'd probably get tired of it pretty quickly if I played the game a lot. I think you need to aim for something more in the range of 10 seconds.

Question 2 : Is a P100/32 a reasonable "low end" target, or am I aiming too low?

I was just talking with the guy who runs a computer store in town and he gets a lot of his business from people upgrading their old machines. At the same time, however, he says he still does a brisk business in selling old Pentium-based systems. I say the lower the better unless you really have to start sacrificing features.

Question 3 : Is the post-install preprocessing acceptable for the user?

I think as long as it's automatic it shouldn't be a problem (unless the preprocessing takes a long time--I'm not sure how long is "too long" though).

Originally posted by kerchen
Question 1 : Will users wait for 32 seconds staring at a "Loading" screen?

I wouldn't. I would just think the game had crashed. Even if I did have the patience to wait it out the first time, I'd probably get tired of it pretty quickly if I played the game a lot. I think you need to aim for something more in the range of 10 seconds.


You could load the grafx in the background and present the story in the front.

How can converting some bitmaps be that slow? Sounds really weird to me unless it's written in VB4...
Your first step should probably be to optimize the code :)
If you are unable to get it faster, post your bitmap conversion inner loop here and i'll take a look =)

I would not wait until the user launches your game the first time to do the processing. I'd configure your installer to do the processing itself, or maybe launch your game with a commandline parameter telling it to perform the processing. I think delaying gratification on the first run will leave a sour taste in a few mouths.

Good luck! I really dig the screenshots you posted earlier!

I think you'll be fine, especially for a one time processing, i have a game like that and there's a one time 5 mn processing. I had no complains.( i made a little cute looping animation during the loading, with a message explaining that it was a one time processing )

I'm pretty sure that most people will have cpu > 233 mhz so that half the wait.

pat.

It's definitly imparitive for a shareware game to have as fast as possible load-and-run times. Get as much of the time to the installer as possible, even if it means making a 20 MB footprint on the hard drive. People won't care much about a measily 20 MB but they will care if they have to wait 20 seconds every time they want to go play a game for a few minutes.

But that said, I think a P100 is shooting way too low these days. A P/233 is a safer target if you want to go 'low.' And a P2/400 is probably a better target if you're looking for people who actually have money and/or desire to spend it on games. :)

And yes, it sounds to me like there must be a way to get that code quite a bit faster. If you would like I can help you with optimizing your code. I find that usually there are very simple tweaks that can be made to per-pixel loops that result in major speed gains... stuff that shouldn't take more than a couple minutes to do. If you are interested drop me an email or PM and we'll see what we can figure out.

- Air

I was going to say the same thing. Decompress the images as part of the install. Users expect things like this to be done during the install.

Maybe you can make the graphics quality adjustable. If they have a fast machine default it to high, and if they have a low machine default it to low.

I think the one-time processing the first time they run the game will be adequate. Add a progress meter of some sort so that the user knows something important is happening and they'll probably never notice.

Still, you might want to revisit the loading/processing code. Run it through a profiler so you can at least know where your real bottlenecks are.

-David

Have a look at this game it could give you an idea when loading.

http://whales.greenpeace.org/kids/game.html

This is a great Greenpeace game by the way

32 sec for a shareware game? I would probably give up, but then again I wouldn't be using a p100 nor would most people these days i hope?

I think the preprocessing idea wouldn't bother anyone as long you made it sound like a positive thing. It reminds me of different download accelerators. Some update the bandwidth rate and the total transfer with more digits, (or more often) making it look like it's happening faster. I like to see things like that even though I know it may not be any faster. If you decide to opt for a long loading time, you might be able to find ways to make it seem shorter, or less boring.

You could have a progress bar running with some text indicating that this process is for "optimizing graphics configuration" or something like that. You could also let them know that it is a one-time event. In this case, the choice of words and the presentation you use may make a significant difference in your customers' patience. Doing it as part of the install process sounds like a good idea too. You could even break down a long progress bar into separate "progress" events making it seem shorter.

My suggestion would be to break up the image processing into units and do them over time. Load the graphics for your frontend first, then simply spin in a loop unpacking one graphic every frame or so (so it doesnt choke the rest of the game).

Then all you need to do is disable the "play game" buttons before you actually start any game before the pre-processing is complete.

Never ever ever have someone wait for 30 seconds at a loading screen, especially a static one. Hell, thats a fail even on a console.

Better to pre-process than take a hit like that.

Phil.

ISTR creatures 3 took forever to load up the first time, after the install process... but it did say something about doing graphics processing and promised it would never take this long to load again.

Which was true, but it was still annoying, and would have been more annoying if I hadn't already paid for it. :) I tend to consider downloaded games more casual and don't expect them to make me sit through this sort of torture.... :)

That is a good idea. Maybe you can just load the menu graphics first and then show the menu and load the rest of your graphics while they decide what game to play, or what level to start at, or whatever.

Think about this:
If you are one of those schmucks who bought a P100, what do you plan to run on it? If you plan to run software written within the past few years, you're going to have long wait times on anything you do (including booting). So guess what? Being a P100 user, you're going to be quite used to having to wait long times for things. I doubt anyone would buy a computer that is 1/300th of current machines and expect new software to run without delays. And if they do, they're probably so clueless that they'll never find and install your software in the first place. In fact, if they have these kinds of expectations, they won't be satisfied with ANYTHING they try to run. So I wouldn't worry about it at all. P100 is an extremely low target. P200 would probably be the lowest I'd aim. And that should come out to be about 15 seconds, no? And even P200 users have got to be used to things running slowly nowadays. I don't think a 15 second, one-time delay would seem unusual to a P200 user in the least seeing as how they're probably used to waiting 3-5 minutes for their system to boot!

Put up a little notice while doing your preprocessing that says "This could take a few minutes...", and when it's done in 15-30 seconds, the user will be pleasantly surprised. If he uses the delay to go to the bathroom or something, it'll be done when he gets back, and again, he'll be pleasantly surprised.

I agree with the comment about p100 users aware that their computer is quite slow and might take sometimes. I would also not put a static screen, but rather a loading progress bar.

Doing much of it during the install is good as well, but someone mentionned ppl wouldnt care you hog 20 megs to save the images. I disagree, i have a p100, and my hd on that machine is 400 megs. So having 20 meg eating by a game which was a 1 meg d/l? I'd delete it.

Smurftra

Yes, that's the thing. Anyone with a p100 is likely to have a tiny harddrive too. Perhaps loading the graphics every time, with a progress bar, would be sufficient. I doubt that p100 owners will really be the bulk of your audience, though, these days. TBH I'd consider it a bonus if a game was playable on a p100 at all these days.

Oh, BTW, a p100 is 1/30th the speed of current machines, not 1/300th (going by the fairly inaccurate measure of speed by clock cycles, that is). Although I would dispute this definition of "current", too...

OK, I implemented a simple preprocessing step (well, it's quite complex, actually) and cut the times to 45%. The whole loading process now takes around 15 seconds, and it can be lowered even more. It doesn't use insane amounts of extra space, either. It will end up being 2x the download size.

I'll also make the loading a background task, executing while the logos and the main menu are showing. There won't be any kind of delay before playing.

Thanks for your ideas!

Originally posted by Anthony Flack
Oh, BTW, a p100 is 1/30th the speed of current machines, not 1/300th (going by the fairly inaccurate measure of speed by clock cycles, that is). Although I would dispute this definition of "current", too...
Whoops! Sorry, got an extra zero on there. By "current" I mean what you get if you go and buy something that's actually *new* at the computer store. Yeah, you could buy a 2GHz machine and it would still be considered "new" I guess.