Ok I''ve tried all the tricks in the book for speed optimization (keeping math down to simple math like +-*/ by using lookup tables, good state mgmt, calllists, etc.) is there any surefire way to speed up your programs? I have about 3 or 4 objects in my scene as it stands and it''s going way to slow. I can post the code it''s very very beta though.

Hmm... not much I can suggest other than to look at the methods you''re using: are they the best methods, could you be doing it with less operations? You could also have a look at www.intel.com -- they have a thing that lets you check where your processing power is going, then concentrate on bumming the parts of the program which consume the most speed.

I''m not sure if that helps, but if you use Visual C++ and run your programs in debug build, try building it for release and run it. Debug builds are very good at finding errors but they can make a program pretty slow.

My suggestion is to get rid of as many if statements as you can in any inner loops you have. If necessary perform a bunch of arithmetic and logical operations on your variables if this will do it... For instance if you know var is either 0 or 1 the following code is better than an if statement in general;

newvalue = var * value1 + (1 - var) * value2;
is faster in general
if(var)
newvalue = value1;
else
newvalue = value2;

Of course... only start optimizing when its necessary.. as a previous poster stated premature optimization is the root of all evil. And optimizations like the above tend to confuse people for an unnecessary gain in performance. The above method can work wonders though where it works... I was writing a driver this summer and was able to double performance by removing 2 if statements in my inner-most loop. It was an easy situation to optimize ... I knew 99% of the cpu time was in 20 lines of code... but still a wonderful improvement.

Oh... and lookup tables aren''t as good as they once were since modern computers have relatively slow access to main memory. Think about it... a 500 Mhz CPU... 100 Mhz RAM. 5 CPU cycles per memory cycle. About 4 memory cycles to read a datum in memory = 20 CPU cycles just to get a value. Cache helps this problem... but if your lookup table is bigger than your cache you''ve just screwed yourself.

David

I didn''t even think to use the Release instead of Debug, god I feel like an ass now!!! Anyways, delta-z if I can do opengl code in full assembly language I think that would be the point where people start thinking I''m an android. (:

Give Microsoft a few years and we''ll probably have Visual ASM, won''t that be the day. (:

Well ok I just ran it under Win32 Release, I think I''m probably the only one who would notice the speed difference since I''ve compiled it about 21734271563412674537216543.2 times, but I have all my textures and state changes are grouped as best as they can be. The main bad thing is that I''m using glusphere in the program but I don''t know how you would make your own code to be the same as
glusphere(quadratic,vector[3],3,2); where vector[3] is incremented 0.003 each time through. I took out the lookup tables too but no speed difference, any other suggestions?