Skip to main content
gamedev.net
🔒 Locked

Optimizing Code?

Started by DevLiquidKnight 17 replies 1.2k views
Original Post
DevLiquidKnight
DevLiquidKnight
I was wondering two similar related questions that involve optimization. I am trying to figure out what would be the best solution for these. I want to make a game in 3D; I want to know what would run best and most fastest would it be smarter to use D3D or Open GL for 3D graphics. I''d also like to know if there are any tools out there that just optimize MSVC++ 6 code; I only know of one made by Intel. Unfortunately, it costs more then I can afford so is there any free based programs for optimizing and checking speed time of C++ code? Any help on these topics would be greatly appreciated. Don''t click me! Killer Eagle Software
higherspeed
higherspeed
I would personally recommend Direct3D, but that''s just my preference. I found OpenGL to be slightly easier initially, but D3D to be nicer later on.

To be sure, I''d recommend actually learning both, then deciding later on which to use. You could always add support for both if you wanted, although I really don''t think there''s much point.
kdogg
kdogg
As far as speed is concerned, i find that openGL and D3d are the same speed. The single biggest determinant of your program''s speed is the algorithm you choose. A O(n^2) algorithm will be slower than a O(n) algorithm no matter how optimised the code is and what language you write it in. Generally speaking, the optimization you''re talking about is performed closer to the completion of the project than it is before you begin. When designing a program, you want to focus on the overall algorithms and not worry too much about the low level code. Then, as the AP mentioned, you can go through your program and see where the bottlenecks are. No sense optimizing a piece of code that turns out to be faster than the surrounding code anyways.
Dwiel
Dwiel
It sounds as though you use MSVC++ 6.0 and there is one built right in just go to Build->Profile.. and before that, make sure your project is set to allow profileing.. just goto your project properties and allow profiling will be one of the options...

Dwiel

Dwiel
Ready4Dis
Ready4Dis
quote:
Original post by Anonymous Poster
Optimization should be the absolute last thing you worry about. Get everything up and running then run your game through a profiler. A profiler will assess the application and tell you which functions and parts of your game are taking the longest time to run. You then take that information and try to optimize. If you optimize ahead of time you''ll end up spending days optimizing a peice of code only to squeeze an extra half a frame per second out of it. It''s seriously not worth the time and effort.


Perfect example of a bad idea. Do NOT wait to the last minute to optomize. Do not just get it running, then worry about it. You have to do certain optomizations while programmer, otherwise it will require large rewrites, and tons of problems. Try explaining to your publisher that your game runs, but you need another 3 months to get a few more fps out of it. They will laugh at you, and tell you you''re done now because it works and that''s good enough, so now you have your name on a highly unoptomized POS game all because you just wanted it to work. I optomize from the start, and it works out fine for me. Of course, you can wait to optomize SOME things, but don''t just say don''t even worry about it until you''re done, because that''s not smart at all. So, I will just write a brute for terrain engine, I''ll implement some occlussion culling/frustum culling later... and who needs vertex arrays, i''ll just use primitives, same with models, etc, etc. All the sudden you have a game running at 5fps on a gf 4 ti 4600, and have to re-write major parts of it so you can continue testing, since waiting 5 minutes for loading, and running around @ 5fps just isn''t cutting it for debugging anymore.
Ready4Dis
Ready4Dis
OpenGL and Direct 3D are just interfaces to your hardware. Your hardware is the limiting factor in speed. Direct 3D uses a COM interface, while OpenGL uses regular old function calls, which ARE faster, but I''m pretty sure in the real world, you won''t even notice the overhead associated with d3d and COM.
kdogg
kdogg
I assume that the AP didn''t mean to purposefully write bad code from the beginning. Obviously, you want to use the most optimal techniques right from the start. However, dissecting each function to save a few CPU cycles isn''t a good idea until you know where the bottlenecks are.
DevLiquidKnight
DevLiquidKnight
By question do you have any good websites that talk on how to use the C++ profiler. I have never seen this till now because when you click profiler at first it says that you have to enable it or somthing. I did this and I found a thingy to do profiling I just have no clue how this works ;P.

coder requires 0xf00d before continue().

Don''t click me!
Killer Eagle Software
Sneftel
Sneftel
quote:
Original post by DevLiquidKnight
By question do you have any good websites that talk on how to use the C++ profiler. I have never seen this till now because when you click profiler at first it says that you have to enable it or somthing. I did this and I found a thingy to do profiling I just have no clue how this works ;P.
The best source is your IDE documentation. Profilers are anything but standardized.

How appropriate. You fight like a cow.
Trienco
Trienco
quote:
Original post by Ready4Dis
Perfect example of a bad idea. Do NOT wait to the last minute to optomize. Do not just get it running, then worry about it. You have to do certain optomizations while programmer, otherwise it will require large rewrites, and tons of problems.


but i assume you mean to optimize during programming if you realize that something needs to be optimized and not blindly optimizing every function?
else i agree.. if i have just begun and i am already down to 5fps i wouldnt want to "just make it work" and later realize that my whole architecture was c**p and just cant be fast enough.

quote:

Try explaining to your publisher that your game runs, but you need another 3 months to get a few more fps out of it. They will laugh at you, and tell you you''re done now because it works and that''s good enough, so now you have your name on a highly unoptomized POS game all because you just wanted it to work.


i guess it depends on the size of your project and the publisher, but spending too much time on optimizing and not showing _visible_ progress can probably get the project cancelled. though i cant tell if some publishers are really the idiotic moneybags they seem to be that cant tell apart a game from its graphics.

quote:

So, I will just write a brute for terrain engine, I''ll implement some occlussion culling/frustum culling later... and who needs vertex arrays, i''ll just use primitives, same with models, etc, etc.


hm.. not what i would call optimizing. id rather call that wasting a lot of time with something you already know wont work instead of doing it right in the first place. though i am glad i didnt start with a quadtree because else i might never have found out that brute force culling was much faster ,-)
f@dzhttp://festini.device-zero.de
Skizz
Skizz
Here''s my thoughts on optimisations. Doing optimisation is not a single step in the development of a game (or any program for that matter). It is something that must be considered at all points in the development process, from the initial idea through to final testing. Also, there are many areas that can be optimised: speed, space, security, etc.

At the beginning of your project, during the design and prototyping phase, a lot of the optimisations will be algorithmic in nature and will be entirely based on experience and / or research. As ever, though, there will be tradeoffs - you may have a really fast renderer but exceeds the memory requirements or requires 100% CPU time.

Once you''ve finalised the high level algorithms, and this includes creating an efficient data path to get resources into the game (it''s no good having a kick-ass rendering engine that requires days to pre-process a level), you can then start to look at lower level areas. As always, having meaningful statistics is the most valuable tool. Also, it''s important to look at the whole picture (a lead programmer''s job). You may have a good renderer but it''s being crippled by a slow AI / scripting engine. A common thing to watch out for is memory management: you may require several, each tailored to a specific need. Also, data alignment can be an issue - knowing how the compiler generates the array index code is useful - the x86 can quickly access data that isn''t power-of-2 in size (i.e. the lea instruction can be used to quickly get other multiples).

Finally, you look at micro optimisations, but only after you thoroughly investigated the whole system. You may find that your vertex transformation process is a bottleneck and that converting to assembler to access CPU specific features, such as SIMD, would speed up the code. You''d want to ensure these features are only enabled when specific #defines are set up so the code can be ported easier.

On a final note, it is important to understand the programming language you''re using. For example, in C++ it is very easy to kill the performance by using badly implemented classes. For example, this class:

  
#include <windows.H>
class Vertex
{
public:
	Vertex (void) : x(0), y(0) {OutputDebugString ("Vertex()\n");}
	Vertex (Vertex &rhs) : x(rhs.x), y(rhs.y) {OutputDebugString ("Vertex(rhs)\n");}
	Vertex (int x, int y) : x(x), y(y) {OutputDebugString ("Vertex(x,y)\n");}
	~Vertex (void) {OutputDebugString ("~Vertex()\n");}

	Vertex operator + (const Vertex rhs)
	{
		OutputDebugString ("operator + \n");
		return Vertex (x + rhs.x, y + rhs.y);
	}
private:
	int x,y;
};

void main (void)
{
	Vertex a,b(3,4),c(7,2);

	a = b + c;
}

looks like it would only call the constructor 3 times, but in fact it gets called 5 times (there''s a total of 11 calls to functions in the class), whereas this class:

  
#include <windows.H>
class Vertex
{
public:
	Vertex (void) : x(0), y(0) {OutputDebugString ("Vertex()\n");}
	Vertex (const Vertex &rhs) : x(rhs.x), y(rhs.y) {OutputDebugString ("Vertex(rhs)\n");}
	Vertex (const int x, const int y) : x(x), y(y) {OutputDebugString ("Vertex(x,y)\n");}
	~Vertex (void) {OutputDebugString ("~Vertex()\n");}

	Vertex &operator = (const Vertex &rhs)
	{
		OutputDebugString ("operator = \n");
		x = rhs.x;
		y = rhs.y;
		return *this;
	}

	Vertex operator + (const Vertex &rhs) const
	{
		OutputDebugString ("operator + \n");
		return Vertex (x + rhs.x, y + rhs.y);
	}

	Vertex &operator += (const Vertex &rhs)
	{
		OutputDebugString ("operator += \n");
		x += rhs.x;
		y += rhs.y;
		return *this;
	}
private:
	int x,y;
};

void main (void)
{
	Vertex a,b(3,4),c(7,2);

	a = b;
	a += c;
}

the constructor is called only three times (there''s a total of 8 calls to functions in the class). In total, there are three less function calls in the latter code (that''s 27% less).

So to sum up: optimisation is something you do all the time, and a lot of it is learnt through experience. Very rarely does a programmer have to work in assembler, and even then, only with guidance from profiling tools or to use CPU specific features.

Skizz
Ronin Magus
Ronin Magus
A profiler won''t tell you if your architecture is crap. That''s left up to you.

The example of writing a game using the slowest possible rendering means is not at all pertinent to a profiler, you should decide the best way to do it at design time. If you can''t come up with a good architecture, and then profile it to work out the kinks, you probably need a little more experience..
BriTeg
BriTeg
"The best optimizer is between your ears." - Michael Abrah

Abrash''s book "Graphics Programming Black Book" is a bit dated, but it has some *excellent* stuff on optimization and profiling.

Brianmiserere nostri <font color=#BC

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.