User system requirements (way too high for casual games)

#1 Certainly someone here at GG can help with pointers for optimization, but do keep in mind that, even though it's a 2d engine, it is 3d at heart and uses 3d to render objects. So moving or not, each object uses resources.

The engine pre-dates core technology so it won't be opimized for that.

Looking at the system requirements:
Windows
Minimum
1.0 GHz processor
512 MB RAM
Windows XP
OpenGL or DirectX compatible accelerated 3D video card


I'd guess that it's either severly understated or you are using huge resources in your game.

So what size images are you using for graphics?

#2 I believe those numbers are serverly understated.

All images are alpha transparency pngs.

I have 64 tiles that are 64 x 64px (copies of 8 different static sprites).
There are about 10 overlays, 64x64 as well.

A few 800x600 (alpha pngs) for various layers of background/foreground.

A handful of static sprites that are small icons (source pngs are 64x64).

There are 2 256x256 animated sprites (3 frames - source object is 521x520).

There are also a few panels that are 350x670.

At any given time, there is probably about 4-5MB worth of pngs loaded into the scene.

I don't have the TGB source, but I'm guessing these source pngs (about 10MB total) are loaded into objects in many many ways in order to chew up 200MB right off the bat.

#3 The minimum requirements for game made with TGB in Windows are

500 MHz processor
256 MB RAM
Windows 98
OpenGL or DirectX compatible accelerated 3D video card

@ Aaron what route have your done to optimize so far ?

Aun.

#4

Quote:I don't have the TGB source, but I'm guessing these source pngs (about 10MB total) are loaded into objects in many many ways in order to chew up 200MB right off the bat.

It is actually not like that for the memory, it should be

Imagewidth * Imageheight * ImagecolorBit = mem uses

TGB images for best optimization should be the size of

n power of 2 - 2 (padding)

Trying searching the forum I'm sure you could lower the memory uses down.

Aun.

#5 Hi Aun - for optimization, I've made sure that I am disposing of all resources that aren't seen. As pieces & match particles are dynamically generated, I make sure that every one of them are deleted, and have confirmed that the number of scene objects doesn't grow as we play through the game.

pngGauntlet is used to reduce the filesize of pngs.

sounds are small wavs, and bg music is ogg (1-2MB per file).

Initial resolution was reduced from 1024x768 to 800x600, and that had only a very minor effect on memory usage.

The code that is run in t2dSceneGraph::onUpdateScene(%this) takes only a couple of ms to run according to the echo() tracing that I am doing.

And I don't have any onMouseMove() code running...

#6 The main thing that would hogging the memory would be the imageMaps and the preload sounds.

Using pngGauntlet would save only disk space.

I would dump the imageMap and see what images that would be the most easy to scale down or resize.

In your defaultPref.cs change

$pref::T2D::imageMapDumpTextures = 1;

$pref::T2D::imageMapShowPacking = 1;

Sounds are another thing to watch out for .

Aun.

#7 If you have the Pro version with source code, you can run your game through a profiler and see where your slowing down.

#8 None of the audio is preloaded - it is all lazy loaded.

Aun - I am going through the process right now of addressing the image sizing. Thanks for the tip on:

$pref::T2D::imageMapDumpTextures = 1;
$pref::T2D::imageMapShowPacking = 1;

This will surely reduce the memory usage - my concern is how much will that affect the framerate.

#9 @ Aaron , You're right it won't. I didn't read your post clearly enough to see that you are having problems with the frame rate, I thought it was the memory issue.

For the frame rate issue you'll need to profile your code in main.cs in your mod directory

add

function initializeProject()
{
    profilerEnable(1);
.
.
.

And

function shutdownProject()
{
    
   endGame();

   profilerDumpToFile("profileDumpName.txt");
}

After you run your game the engine will dump the profile process in to a file named "profileDumpName.txt". Open that file withe a text editor and see where your game is slowing down. I went this route and got my frame rates from 24 - 27 to 120+ on my test machince.


Aun.

#10 Aun - thanks for the great info.

FYI - here is the dump from a pc w/a 3D card

Profiler Data Dump:
Ordered by non-sub total time -
%%NSTime %% Time Invoke # Name
29.062 29.062 7215 glFinish
5.442 5.442 7215 SwapBuffers
3.388 3.672 7215 T2D_t2dSceneWindow_onRender
1.538 1.562 18 ProcessInputEvent
0.629 0.629 7216 GetForegroundWindow
0.527 55.107 7216 GameProcessEvents
0.255 0.256 370506 NewFontGetCharInfo
0.199 0.199 491366 T2D_t2dSceneObject_updateWorldClip
8.636 12.308 7215 CanvasRenderControls
5.625 6.259 7216 ProcessMessages_MAIN
0.154 0.154 2639 DispatchMessage
0.475 0.479 2639 OurDispatchMessages
0.532 1.171 7215 ClientProcess
0.341 0.341 7216 TelDebuggerProcessMain
0.159 0.255 191665 T2D_t2dSceneObject_updateLocalPhysics
0.203 0.203 9788 t2dSceneContainer_findObjects
4.546 4.829 7215 SimAdvanceTime
37.512 37.520 7216 TimeManagerProcessMain
0.109 0.109 300539 T2D_t2dSceneObject_calculateMountNodes
0.095 0.095 324601 MemoryAlloc
0.084 0.084 320208 MemoryFree
0.077 0.114 576418 T2D_t2dSceneObject_updateSpatialConfig
0.077 46.914 7215 RenderFrame
0.049 52.975 7215 ProcessTimeEvent
0.039 0.039 191913 T2D_t2dPhysics_updateNetVelocity
0.036 6.981 7216 PlatformProcessMain
0.031 0.031 7216 InputProcess
0.029 0.029 191665 T2D_t2dPhysics_updateSpatials
0.026 0.026 191665 T2D_t2dPhysics_updateGrossVelocity
0.026 0.026 7215 CanvasPreRender
0.022 99.989 7216 MainLoop
0.010 6.269 7216 ProcessMessages
0.008 0.008 7216 GetInputManager
0.008 0.008 4961 T2D_t2dPhysics_generateCollisionPoly
0.008 0.008 7216 TelconsoleProcessMain
0.007 0.007 7215 ServerNetProcess
0.006 0.006 7216 JournalMain
0.004 0.007 551 convertUTF8toUTF16
0.004 0.004 7216 NetProcessMain
0.004 0.004 7216 WinConsoleProcess
0.003 0.003 7216 InputManagerCheckCursor
0.003 0.003 7215 ServerProcess
0.002 0.002 27058 oneUTF8toUTF32
0.002 0.002 7215 ClientNetProcess
0.002 0.002 1535 t2dSceneContainer_BinRelocation
0.002 0.002 4009 MemoryRealloc
0.001 0.001 2639 TranslateMessage
0.001 0.001 2706 T2D_t2dPhysics_generateCollisionCircle
0.001 0.001 8 t2dSceneContainer_addSceneReferenceBlock
0.000 0.000 1 PostEvent
0.000 0.001 2053 t2dSceneContainer_allocateSceneBinReference
0.000 0.000 2053 t2dSceneContainer_freeSceneBinReference
0.000 0.000 60 T2D_t2dSceneObject_setLifetime
0.000 0.000 0 oneUTF32toUTF8
0.000 0.000 0 oneUTF16toUTF32
0.000 0.000 0 convertUTF16toUTF8

#11 Do you have the source code ?

#12 No, I don't

#13 Just an update, I've been able to get the memory down to around 120MB utilizing the recommendations mentioned above. Still working on it though. The FPS on computers w/o a 3D card went up about 1.5 to 2 FPS (to a whopping 6 FPS) ;)

I've got to get it to at least 15 FPS on the min system w/onboard video.

Another thing I've been messing around with is Audio and memory usage. I can play a 1MB ogg file (looping) and it uses about 20MB of memory. Is that normal? Is there a good audio tuning thread/doc somewhere?

Oh yeah, check out this profiler dump on a machine w/o a 3D card:

Profiler Data Dump:
Ordered by non-sub total time -
%%NSTime %% Time Invoke # Name
82.562 82.562 26 SwapBuffers
8.815 8.835 26 T2D_t2dSceneWindow_onRender
4.800 5.091 26 SimAdvanceTime
2.259 2.742 26 ClientProcess
0.487 0.519 3 ProcessInputEvent
0.190 0.326 18396 T2D_t2dSceneObject_updateLocalPhysics
0.157 0.157 46732 MemoryAlloc


82% of the time in SwapBuffers! Ouch. I've got a *lot* of image tuning to do...

This page is fabulous:
http://tdn.garagegames.com/wiki/Torque_2D/ImageMap_Tutorial

Any help would be appreciated with the SwapBuffers or Audio tuning.

#14 I would point you in the direction of optimizing your textures, not your total memory footprint--I can almost guarantee that with your target hardware (you mention "w/o 3D card")--with on board video, they almost certainly are not going to have a high amount of video memory accessable, and of course you also lose with no hardware acceleration.

I'm betting that it's a situation where you are thrashing textures in your video cache almost continuously. Your images aren't optimized for size, so a couple of things are going on:

--tgb will automatically scale an image's size up to the next power of 2--so for example, your 800x600 textures are becoming 1024x768 just to be delivered to your video card (which commonly require power of 2 textures)

--you aren't taking into account the mip-mapping textures that are generated, which is an automatic technique that is intended to speed rendering (provides lower resolution textures that can be swapped in by the video card based on the actual size of the object the texture applies to). Ironically, given such a low level video output target, this causes a loss in performance if those textures are what is being thrashed.

--it's disappointing, but if you are targeting such low end hardware, then you are going to have to drastically reduce the quality of your textures. It's possible that your video buffers are down in the 64-32M size, and while if you are just adding up the raw pixel size based on reported texture size, that doesn't take into account a lot of additional data that gets sent to the video card simply to render the image appropriately.

Looking at your data:

Quote:
I have 64 tiles that are 64 x 64px (copies of 8 different static sprites).
There are about 10 overlays, 64x64 as well.

A few 800x600 (alpha pngs) for various layers of background/foreground.

A handful of static sprites that are small icons (source pngs are 64x64).

There are 2 256x256 animated sprites (3 frames - source object is 521x520).

There are also a few panels that are 350x670.

The 64x64 px sprites are almost certainly being inflated to 128x128 right off the bat. The reason is that the images are first padded by a couple of pixels, and then brought up to the next power of 2. Try cutting them down to something like 60x60, and check performance. Also, you'll have to take a good look at the actual use of the textures in the game--64x64 doesn't sound like a lot of resolution, but are the sprites themselves ever actually taking up 64x64 pixels?

In other words, are you sure that your 64x64 pixel sprites are actually taking up that much screen space? If, for example, they are taking up 50x50, then the video card isn't using all 64x64 pixels of resolution, so the extra pixels are effectively taking up space. This normally doesn't matter in the least (mipmapping, and other video card magic) takes care of it, but since you are shooting for such a bottom end video capability, every little bit matters.

#15 Thanks Stephen.

Just an update for anyone who reads this thread. Last week I was able to tweak with TGB so more and resize some of the bigger textures, as well as change the way I load certain resources. The memory footprint is down un 90MB now, and I believe there is another 20-30 that I can squeeze out of there.

Additionally, dumping the imageMap data has been very helpful in tracking down waste...though not always reliable. That could just be a problem with Torsion though. Sometimes it will just stop outputting the data to console.

The really good news is that average FPS on machines w/onboard video is up around 9.5 and 10.7 - which is actually playable. I am confident that I will be able to hit 15 FPS on the low end machines without a real video card now.
The laptop mentioned in the first test now runs around 140 FPS on average. It also runs around 225 FPS when running the game in fullscreen.
Running in fullscreen on low end machines didn't seem to have any notable on Framerate (maybe 1 FPS).

Also, I would like to apologize for the title of this thread. At a minimum there should be a question mark on the end, but in reality it should be something more like "how can I optimize TGB to run on low end machines".
If it is possible to change the title, can someone please do this? If not, this apology will have to suffice.

And finally, regarding the demo I spoke of last week...it went awesome! We took 2nd place at the Independent Game Conference in Austin. Losing by 1 vote to Guitar Rising. Needless to say, we were very excited by all of the very positive (and especially the critical) feedback that we recieved.

Our goal is to make *fun* games without being shallow or cheesy. Now I'm confident we are on the right track.

Tech note: we ran the demo on a Dell XPS in windowed mode and it was running nearly 800 FPS! too funny.

Thanks to eveyone for your help. I've got tons more questions to come as I learn the ins and outs of TGB and try to squeeze every last bit of perf out of it.

#16 Hi. i have a macbook. will i be able to run my games on it?

#17 What do you mean? You may or may not. As you can see in this thread, getting something going quickly in TGB is easy, but you still have to be diligent in the optimization process to make sure you use the fewest resources possible to deliver the caliber of game you are shooting for.