Performance optimizations?

#1 One thing you could try is turning VBL syncing on. I changed line 28 of your prefs.cs file to:

$pref::Video::disableVerticalSync = 0;

and my CPU usage while playing Fashion Fable dropped from over 100% - 110% (dual CPU, so full would be 200%), to about 40%, without affecting gameplay.

And yeah, it can be challenging sometimes to get download and news sites to spell and say things the way you want them to. Particularly in my case where I use capital letters and punctuation differently (aquadot!red and angelFrogGames). When contacting download/news sites I usually have to say up front that other people have made mistakes in the past and I'd like to point out specifically that I spell things oddly. It mostly seems to work, except for download.com, who are a huge waste of time anyway (at least from the Mac perspective).

#2 A good idea. My guess is that won't really decrease the minimum requirements, though, since the decrease in CPU usage you see is probably the excess your machine has above what's necessary (since it's idling between renders). A machine already sputtering wouldn't get much better, but I might give it a try.

I appreciate the sympathetic ear, and glad to hear you've successfully pre-empted some mishaps with your names and titles. :)

#3 Are you sure your game needs that fast a CPU? It does not do much physics (not moving sprites produce nearly zero overhead), particle calculations should be rather trivial. I guess the limitations you have to consider are more on the graphics side. I tested my upcoming little game on my girlfriends laptop and it was kind of slow (15-30 fps compared to 450 - 550 on mine). I ran the profiler for a while and discovered that 70% of the time was used just for rendering. The laptop has only has onboard-graphics (with a quite limited fill-rate I guess). I don't think a faster CPU would make the game run really faster.

#4 I'm basing that minimum around my Mac Mini (1.2ghz) and my old test PC (800mhz). It runs ok on the Mac, but really chugs and sputters on the PC. Maybe I can fine tune things more. The same things were said about my previous game, Little Gods. ("It's a pong game, why does it need blah blah, very unoptimized, etc blah barf.")

I don't think 1ghz is that monstrous of a computer these days. Even my mom and mother in law have in excess of that on their machines. :) I've had no complaints from paying customers, so I guess I should ignore the alpha geek trolls.

#5 I'd say that too. I don't know anyone with a PC slower than 1ghz. And if you look at Switchball by Atomic Elbow for example: It is a puzzle game essentially but it uses shaders and PhysiX and therefore is quite demanding in terms of hardware. Why should it not be allowed to look great just because it is a puzzle game. It is not like only sports cars got an engine and the rest is still pulled by horses.

#6 Well, the game "idled" at 180 megs of ram for me, so I'm guessing that the minimum requirement of 256 megs is probably pushing it and is most likely causing quite a bit of swapping. You're best bet to satisfy the critics may be to try and optimize your memory usage a bit.

I've spent the last week on our game trying to bring the memory requirements down. Once we have audio and such going, I can't say we'll be much better off than that, but we have found quite a bit of savings so far. We've been much more aggressive with preloading/unloading... getting rid of every feasible preload and allowing a lot more unloads. It's always a trade off, and needs to be handled carefully, but it might help knock down the memory utilization to the point where it won't cause as much swapping.

We also went back and analyzed how our textures were being packed to see how we could be more memory efficient. TGB is great in that it handles all the details for you, but there's a lot of memory savings out there if you look inside the black box. Anyway, I was thinking about writing up our experience with memory in TGB. Even though the docs for imagemaps are great, I think a practical faq/checklist is needed.

In terms of suggestions for TGB - maybe a bit of "help" in terms of tuning would be helpful - such as some runtime analysis to find unused textures and such. There are probably a lot of tools for doing this already, but I've had to handle it pretty manually... so maybe a document on how to use the tools would be good.

Anyway, hope that helps.

-Andrew
theoreticalgames.com

#7

Quote:Anyway, I was thinking about writing up our experience with memory in TGB.

Andrew - this kind of information based on your experiences would be very valuable.

#8 It's been posted here. Hope that helps. Please throw in any additional tips if you've got 'em. Thanks!
-Andrew

#9 Andrew, awesome write-up. Thanks, that's very useful! Did that article get linked from any of the mainline entry points for TGB on TDN? I think it should be.

Jason, it sucks you're experiencing performance problems. I'm a big fan of your games... I like this new one, and really enjoyed Little Gods too (you also did Argus teaches, right?).

If the performance problems are due to something in the engine itself, we'd definitely want to fix it. However, there could potentially be lots of issues with the particular game code itself. Andrew pointed out a lot of art-related potential issues. Anything from his article that you could apply to your game? Have you tried, and did it help at all?

Also, from seeing your game being played, it seems to me that a potential issue is resource loading... for example, when you a GUI pops up for the first time, are the graphics / images being loaded from disk?

Also, what is your code for checking the board for matches like? What's the time complexity of the algorithm you're using, and is it written in script or C++?

Do people seem to have problems in OpenGL or D3D mode particularly? Do problems seem to get worse when increasing the resolution of the game, or does that not affect it much?

Most importantly, have you profiled the game a lot, on various machines? If so, where do you see the processing time being spent the most?

Even for simple games, no matter how good the underlying technology, you can end up shooting yourself in the foot, performance-wise. Loading resources (graphics and sound data) is a classic and common area that trips people up.

Please understand, I'm not saying that the issues you're experiencing are definitely in your game code. If you've already considered all of the above issues (and more, that might apply to your game particularly), and you've already done a lot of performance profiling and tried to fix the performance issues you've seen... then we should look at it and see if there's something amiss in the engine itself. So, let me know.

Regardless, I think it'd be smart for us to do more docs like Andrew started... how to track and hunt down performance problems, common areas of performance concern, etc.

#10 Thanks Josh. You can find it under TGB>FAQs>Image and Sprite Questons ... if someone wants to see it someplace else, let me know but I didn't know if it really qualified as, say, a Features Guide and didn't want to put it too high up in the heirarchy with it being my first article and all...
-Andrew

#11 Great doc Andrew...

@Jason McIntosh: I think you have it right, it's good to take constructive criticism and even non-constructive criticism, but those posts I read seem like they are just blowing smoke.



ADD: Not to say that the concern isn't a truth though, Josh detailed it better than I could so I figured I'd post my impression of those comments that you linked, especially if some of them didn't even try the game.

#12 @Josh: I'm not actually experiencing problems, per se, and I'm sure it's my own fault for the issues that exist. I thought there were plans to improve the rendering system, but that could be misunderstood communications in my foggy mind. A possibly long while back there was talk of adding batching to improve rendering performance, so I thought that might still be relevant. I don't know what the decision or evaluation was of that suggestion, since it may not really help that much. I'm just glad I don't have to think about that stuff. :)

Thanks for the suggestions. I have done a decent amount of optimization before release (the game previously wouldn't run with less than 512mb because it was trying to load everything at once before I switched from an alpha to the 1.1 final). The allowUnload and preLoad datablock fields really saved me. We also converted some art to larger groupings/sheets, and the game does require a lot of art in RAM all at once because of all the clothes.

Having talked to a few more users, the game runs decently on low-midrange (ie, the minimum requirements I set for the game). It runs well on my Mac Mini (1.2ghz, 512mb) although it twitches/pauses sometimes for reasons I have yet to determine (possibly caching/uncaching art, I dunno).

@Andrew: Nice to see your experience with the engine. I'm sure that will be handy for lots of people, including me.

@Matthew: I'll just thicken my skin and accept that you can't please everyone.

#13 Hey Jason,

Its all good man, and I'm glad you got things worked out pretty well. Like I say, I dig your games, and am looking forward to more!

Re: the batching stuff, indeed, we were considering that for a while. In fact, we've taken two stabs at implementing it, and neither paid off a great deal, performance-wise, in real-world usage scenarios. So, we opted not to touch it more in the immediate future. That's encouraging though, it means the rendering system is pretty nice as-is.

As for the hitching, I usually suspect resource loading / unloading in those scenarios. RAM / swap file paging is also a common culprit, if you're game is eating lots of RAM. But if you're not on the most recent codebase, there was actually a fix for hitching that we introduced about 2 months ago. There was a bug in the low-level Torque platform high-res timer code on Windows that got fixed up, and a couple related problems. All clear now though, AFAIK.

Hope this was all helpful. And we'll look forward to your next releases!

#14 Thanks, Josh. I appreciate your support and professionalism.

I guess when an engine this good is already doing so much voodoo with no effort from me, it's hard not to expect miraculous things on a whim. :) I will try to control myself better in the future.