• Advertisement

Archived

This topic is now archived and is closed to further replies.

Need For Speedy Graphics...

This topic is 5405 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is not really graphics based but will be... I need to know is it faster to use tons of if()..., else if() statement or switches? I am making a special visual program based on a music beat. So it needs all the speed i can get. also is it faster to render with DX or OGL? and can u give a routine to use... Then final of all can u make this vertex thing smaller... (faster) struct Vertex3 { float x, y, z; // 3D Coords }; Vertex3 g_Vertex[numVertex]; // numVertex is loaded from a file is that the best? or can u think of a better way? thanks to all who help...

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by SomePerson
This is not really graphics based but will be... I need to know is it faster to use tons of if()..., else if() statement or switches?


Depends. Chances are, that those won''t even be close to a bottleneck in your code. That''s why you should profile, before thinking of optimizing.

quote:

also is it faster to render with DX or OGL?


Pretty much the same. On very small objects, with few faces (<300), OpenGL tends to be faster. It has less setup overhead when changing and drawing vertex arrays. On larger objects, the differences fade away.

quote:

Then final of all can u make this vertex thing smaller... (faster)

struct Vertex3
{
float x, y, z; // 3D Coords
};

Vertex3 g_Vertex[numVertex]; // numVertex is loaded from a file

is that the best? or can u think of a better way?


Again, depends. It''s pretty much the standard way to represent a vertex. You can range compress it into shorts, and decompress it in a vertex shader. But that''s probably a bit overkill for a beginner.

Conclusion: you''re thinking too much about performance Are you planning to write a Doom3-like 3D engine with millions of faces and tons of special effects ? If the answer is yes, then by all means optimize wherever you can (such things as range compressed vertices become very important). If the answer is no, then don''t worry about those things just yet - they will have such a minimal impact, you won''t even notice it. If you still do, profile your code, and rewrite/optimize the critical parts.

Share this post


Link to post
Share on other sites
I''ve always taken the approach of finishing things before I optimize them. If you''re adding lighting, for instance, to your engine, add it in, then go back and see where you can make it faster. I think others would agree...

Share this post


Link to post
Share on other sites
Well, I know it is still too early for optimizing for my program ,but i was just wondering.

Cause it will need all the optimizing it can get.
Well i plan on getting it to read music cds, and playlist off the HardDisk. While working in the background... On top of that
one can have visualations move to the beat of music on the desktop, a window, or fullscreen. So in end it is ment to be cool but also alow the user to do other thing also...!!!

Share this post


Link to post
Share on other sites
quote:
Original post by SomePerson
Well, I know it is still too early for optimizing for my program ,but i was just wondering.

Cause it will need all the optimizing it can get.


What you listed above is commonly referred to as ''micro-optimization''. Or in other words: code optimization - rescheduling of code, removing ''if'' statements, perhaps even going ASM. This type of optimization can be important for extremely performance critical applications. But generally, your compiler will do an excellent job optimizing all that for you. You typically don''t have to worry about it.

The other thing is ''macro-optimization''. That one is really important, and should be considered from the beginning on: it affects your choice of algorithms, data structures, etc.

You''ll quickly notice, that micro-optimization typically gives very little gain: around 5% to 10% maximum. If your background application doesn''t use more than eg. 10% of the CPU/GPU anyway, then that will be a performance increase of 0.5% ! Hardly worth the effort. Macro-optimization, on the other hand, will greatly influence your performance: the scale can be anywhere between 0 and infinity. So, choosing your algorithms wisely (eg. using vertex arrays instead of IM in OpenGL) is going to give you huge performance boosts. Micro-optimization won''t, and should always be considered as a very last resort.

Share this post


Link to post
Share on other sites
quote:

By Michael Abrash
Optimalisation is the root of all evil



And he''s right. Use something you''re comfortable with and don''t waste time getting a few cycles extra speed.


-------
ni·hil·ism ( P ) Pronunciation Key (n-lzm, n-)
n.
Philosophy.
An extreme form of skepticism that denies all existence.
A doctrine holding that all values are baseless and that nothing can be known or communicated.
The ultimate truth.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Countach
quote:

By Michael Abrash
Optimalisation is the root of all evil


And he''s right. Use something you''re comfortable with and don''t waste time getting a few cycles extra speed.



Wrong quote, completely wrong person. See http://www.c2.com/cgi/wiki?PrematureOptimization

Share this post


Link to post
Share on other sites
The correct quote is ''Premature optimization is the root of all evil.'' That extra word at the beginning is key - optimization is not a bad thing, trying to optimize too early is.

Share this post


Link to post
Share on other sites
Regarding the original question, if your compiler is worth the hard drive space it chews up, you won't notice a difference between an if() else() block and a switch() block.

[edit] Nor is there any memory or speed difference between a struct and an array for storing a 3D point.

[edited by - ApochPiQ on July 3, 2003 11:33:14 AM]

Share this post


Link to post
Share on other sites

  • Advertisement