SDL_DisplayFormatAlpha

[VirtuaSinner]

So a couple weeks back I was on here looking for ways to accelerate my game's performance, and learned about SDL_DisplayFormatAlpha. The end results of applying this command to most of the graphics in the game was incredible - it went from averaging 15 frames per second to up around 60. But, ever since I did it, the game has trouble running on some computers. It still runs flawlessly on mine, and on an ancient laptop I tried testing, as well as the computers of certain playtesters. Others have reported it usually failing during the period where it's loading the graphics (which is where the command is applied), though occasionally, seemingly at random, it gets through that process and runs fine. I'm sure I'm doing something wrong, and probably something quite obvious, at that.

Here's what's happening. I've declared the following global variable: SDL_Surface *tempsurf = NULL; This is the variable I use to store the graphics when loading.

I am loading a lot of graphics, and I know the code is inefficient - I've named each graphic individually, and each surface, so the loading functions execute commands like the following over and over again, hundreds of times to get the graphics loaded. Examples:

tempsurf = IMG_Load("data\\graphics\\UI\\shopscroll.png");
if (tempsurf == NULL) {
fprintf(stderr, "Couldn't load shopscroll.png: %s\n", SDL_GetError());
return;
}
shopscroll = SDL_DisplayFormatAlpha(tempsurf);
SDL_FreeSurface (tempsurf);


tempsurf = IMG_Load("data\\graphics\\UI\\healthbar.png");
if (tempsurf == NULL) {
fprintf(stderr, "Couldn't load healthbar.png: %s\n", SDL_GetError());
return;
}
healthbar = SDL_DisplayFormatAlpha(tempsurf);
SDL_FreeSurface (tempsurf);

Not the cleverest programming, I'll admit, but nothing I can readily spot that would cause the game to malfunction on some computers and not others. Is there something readily obvious to others that could cause this problem?

[helios]

Do you start any threads at any point?

[VirtuaSinner]

Sorry, helios, I don't even know what that means. The code in question, where the crashing is occurring, is literally just what you see above reiterated a few hundred times, one after the other (with different filenames and surface names). The only break in that sequence is that every hundredish iterations I'm calling another function which then embarks on the same process. Essentially I broke what used to be 1 function into about 6 separate functions, because the compiling started taking a lot longer than it used to and I misinterpreted it at first to mean the compiling was failing - then when I tried breaking the function up on the advice of someone online, I inadvertently gave it the time it needed to finish compiling (about an hour now, with the maximize speed option on - it was about 25 minutes before adding the SDL_DisplayFormatAlpha function calls), and falsely attributed the success to the broken up function, so I just kept doing it.

[VirtuaSinner]

Actually, there is one other thing that happens; every fifty graphics are so, it calls to a function which updates the screen with a status bar, and prints some text there, too, to make sure the user knows the game is still loading and hasn't frozen. Though that code is identical to what it always was - the only new components since the last stable version are the SDL_DisplayFormatAlpha calls.

[VirtuaSinner]

It's seeming likely, though not conclusive, that the situation is only manifesting on Windows 8 machines, as opposed to Windows 7. Not sure yet how that would come into play, but it is the one commonality identified so far.

[helios]

Sorry, helios, I don't even know what that means.

So I guess the answer would be "no".

about an hour now, with the maximize speed option on - it was about 25 minutes before adding the SDL_DisplayFormatAlpha function calls

Yikes!
If it takes that long to compile the function that loads the assets, it doesn't seem unreasonable to think that your users have simply ran out of video memory. Have you tried measuring the memory usage once everything is fully loaded. You can use Process Explorer for that. It will also tell you the used video memory.

By the way, is this an open source project? Is there some place I can download the source from?

[VirtuaSinner]

No, not open source. I can try the process explorer, though, I've had it running flawlessly today on a 5 year old, low end laptop with 4 gigs ram and a crappy video card. The people experiencing failures are all on brand new desktops built explicitly for gaming... and that happen to be running Windows 8...

And forgive my improper use of programming lingo. I'm an actor by trade, just program in my spare time for fun. The compilation itself takes about 2 minutes for the whole program. Followed by another 50+ minutes in the "generating code" segment and linking at the end. If I turn off the maximize speed option, the whole compilation takes only 2 minutes. I think it's more a testament to how much work the compiler needs to do to get my sloppy code optimized than the quantity and size of assets.

Does the graphics memory specifically come into play? Isn't it just loading the data into basic RAM?

According to the Process Explorer, the game is using 716,260K.

[VirtuaSinner]

If you're curious, you can see a sample of a very old build of the game at the youtube videos starting here: (Currently working on version 47.00, this is 22.something).

https://www.youtube.com/watch?v=zmcN7xNpLgY

or

https://www.youtube.com/watch?v=FcaAsnBnoVU for more actual gameplay.

[helios]

I've had it running flawlessly today on a 5 year old, low end laptop with 4 gigs ram and a crappy video card. The people experiencing failures are all on brand new desktops built explicitly for gaming... and that happen to be running Windows 8...

Not really sure what to make of it, then. You could try adding StackWalker to the project and asking some of your users to run the modified versions and send you back the stack traces.
http://stackwalker.codeplex.com/
http://www.codeproject.com/Articles/11132/Walking-the-callstack
I've found StackWalker immensely valuable to track down heisenbugs (bugs that don't manifest when the debugger is attached).

And forgive my improper use of programming lingo.

Oh, sorry. My emphasis on the word "compile" wasn't meant as a correction. "If it takes that long [just] to compile the function..."

The "generating code" process spends most of its time doing crossfile optimizations (i.e. optimizations involving calls between functions defined in different translation units). In my experience, crossfile optimization doesn't make that huge of a difference, but of course the benefits will depend on the particular project and code structure. You can greatly reduce development build times by turning them off: Properties > General > Whole program optimization: no whole program optimization. You can turn them back on if you want when making release builds.