Torque 2D Pro - Lean compile
by Krisztian Brizs · in Torque Game Builder · 08/11/2011 (3:16 pm) · 3 replies
For someone that does not do too much programming, but occasional customization - can someone recommend a procedure to make a lean compilation of the game exe. I might do a simple platformer or maybe a Zelda style rpg. I want to have as fast an exe as possible. Since the engine divides everything up into components, I did not think recompiling would make a difference, but if you did make the exe leaner, could you post some tips in here?
About the author
#2
I think trying to get a "lean compile" fits in a more general "optimisation" context (not necessarily low-level, this touches "project management" as well, to some extent) where you want just what you need for your game to run, and you want it to run nicely and fast.
I believe there are 3 things to consider: the compilation process, the compiled .exe itself, and the runtime performance of your application.
1.
The first one, the compilation process, is mostly related to the management of your "solution" (as per VS-terminology, collection of source files, the way these files are organised, structured, etc.)
I personally changed the default TGB structure to use VS2010 property sheets, and I created more libraries from the existing code base (TinyXML, etc.). That gives much better control over each module, and you can easily add or remove libraries, exclude things, or change options on a project-basis with just a few clicks, etc. This makes "solution management" much faster.
In my example, the game I'm working on doesn't use physics or networking, so when the time comes I'll probably try to extract and disable these bits. I'm expecting some difficult-to-untie coupling here and there with the sim objects, but apparently people have successfully swapped the default physics for Box2D and the network for RakNet ; disabling these should be doable with a few headaches...
This is not really about "trimming" the game environment at this point, this is really about disabling bits of the engine you don't need.
Depending on the nature of your game, it might be possible to save some bits or not (smaller exe, faster init, etc. ? )
A simplified main script will give you a minimal framework, but your default .exe is still packed with hundreds of kb of features you might not need.
2.
The next stage is to make sure the code generated is optimal for your target ; this is not about adding/removing bits to get a "lean compile" strictly speaking, but you want to make sure the generated code runs as efficiently as possible.
Depending on that platform you're targeting, you may want to hint the compiler at favoring speed over size, or vice-versa (keeping in mind that smaller size can lead to better speed gains where instructions can fit better in the L1/L2 caches, etc.), use whole program optimisation, use extended instructions sets (SSE2 on PC), checking for safe floating point models and RTTI where not needed, etc.
All of that is fairly low level, and is a programmer's job, but can ensure the code generated from your "tweaked" solution is as efficient as possible.
The next stage is to use the reporting modules (memory reports, console outputs, etc.) to analyse the behaviour of the application during start up, shutdown, etc. You want to instrument your code (engine and script) to trace the logic, understand all the stages, and ensure a smooth setup.
3.
Most of the runtime performance and memory savings are going to come from algorithms and data structures ; low level optimisations and compiler switches won't do miracles when the code is "naive" (read "poor" for "release" standards) and highly inefficient in its form, or when the data is not pre-processed properly (lots of non-^2 textures not packed into atlases, non-compiled "verbose"-xml description files that take ages to parse at runtime, etc.)
Further instrumentation and profiling will reveal bottlenecks, so that you can optimise for speed and memory where it's needed (and find the right balance for your main target platform)
So... I'd say 1. organise your solution/project so that you understand what's included and what's not, 2. get the best of your engine with appropriate code generation rules suitable for your hardware target(s), 3. sort runtime bottlenecks with profiling
All of that goes beyond the simple "lean compile", but I think that fits in this global approach of getting the most of your framework !
'hope that helps !
08/15/2011 (7:04 am)
Hi there -I think trying to get a "lean compile" fits in a more general "optimisation" context (not necessarily low-level, this touches "project management" as well, to some extent) where you want just what you need for your game to run, and you want it to run nicely and fast.
I believe there are 3 things to consider: the compilation process, the compiled .exe itself, and the runtime performance of your application.
1.
The first one, the compilation process, is mostly related to the management of your "solution" (as per VS-terminology, collection of source files, the way these files are organised, structured, etc.)
I personally changed the default TGB structure to use VS2010 property sheets, and I created more libraries from the existing code base (TinyXML, etc.). That gives much better control over each module, and you can easily add or remove libraries, exclude things, or change options on a project-basis with just a few clicks, etc. This makes "solution management" much faster.
In my example, the game I'm working on doesn't use physics or networking, so when the time comes I'll probably try to extract and disable these bits. I'm expecting some difficult-to-untie coupling here and there with the sim objects, but apparently people have successfully swapped the default physics for Box2D and the network for RakNet ; disabling these should be doable with a few headaches...
This is not really about "trimming" the game environment at this point, this is really about disabling bits of the engine you don't need.
Depending on the nature of your game, it might be possible to save some bits or not (smaller exe, faster init, etc. ? )
A simplified main script will give you a minimal framework, but your default .exe is still packed with hundreds of kb of features you might not need.
2.
The next stage is to make sure the code generated is optimal for your target ; this is not about adding/removing bits to get a "lean compile" strictly speaking, but you want to make sure the generated code runs as efficiently as possible.
Depending on that platform you're targeting, you may want to hint the compiler at favoring speed over size, or vice-versa (keeping in mind that smaller size can lead to better speed gains where instructions can fit better in the L1/L2 caches, etc.), use whole program optimisation, use extended instructions sets (SSE2 on PC), checking for safe floating point models and RTTI where not needed, etc.
All of that is fairly low level, and is a programmer's job, but can ensure the code generated from your "tweaked" solution is as efficient as possible.
The next stage is to use the reporting modules (memory reports, console outputs, etc.) to analyse the behaviour of the application during start up, shutdown, etc. You want to instrument your code (engine and script) to trace the logic, understand all the stages, and ensure a smooth setup.
3.
Most of the runtime performance and memory savings are going to come from algorithms and data structures ; low level optimisations and compiler switches won't do miracles when the code is "naive" (read "poor" for "release" standards) and highly inefficient in its form, or when the data is not pre-processed properly (lots of non-^2 textures not packed into atlases, non-compiled "verbose"-xml description files that take ages to parse at runtime, etc.)
Further instrumentation and profiling will reveal bottlenecks, so that you can optimise for speed and memory where it's needed (and find the right balance for your main target platform)
So... I'd say 1. organise your solution/project so that you understand what's included and what's not, 2. get the best of your engine with appropriate code generation rules suitable for your hardware target(s), 3. sort runtime bottlenecks with profiling
All of that goes beyond the simple "lean compile", but I think that fits in this global approach of getting the most of your framework !
'hope that helps !
#3
Have fun !
08/15/2011 (7:11 am)
please note that I *did* read your initial statement ("For someone that does not do too much programming"), but I think it's best to expose the options, and then depending on your experience, time available, etc. you can decide what is worth bothering with, and what is probably best left as it is.Have fun !
Torque Owner Jonathon Yurth
http://www.garagegames.com/community/resources/view/21030