VC++ does not optimize greatly until you tell it to optimize, despite recent people in a thread saying that VC++ sucks. It does not suck, and perhaps if you investigated compiling specifics, you would find out that it can optimize but by default it doesn't because it is making it easy for debugging. There are certain optimization flags that VC++ gives you that you must specify if you want to optimize (I usually do this when I am finishing my project, or testing to see how fast my game will go when the compiler optimizes my code), this can be done in the IDE if you do it under the "Project>Settings>Link>Project Options". The flag is something like /Ox and /Gx where x is a various option (ie/ you can optimize and it specifically optimizes for a certain CPU, you can control certain optimizations), another reason it is slow is because it is Compiling it for Debugging, you must also turn that off in the Project options. Here is what the Project Options says for me when not optimized. "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ddraw.lib dsound.lib dinput.lib /nologo /subsystem:windows /incremental:yes /pdb:"Debug/BltThis.pdb" /debug /machine:I386 /out:"Debug/BltThis.exe" /pdbtype:sept" First it secifies all the libraries to link, but lets take that out, now look at this "/nologo /subsystem:windows /incremental:yes /pdb:"Debug/BltThis.pdb" /debug /machine:I386 /out:"Debug/BltThis.exe" /pdbtype:sept " First.... Notice that it is using incremental linking, it is a windows program. Specifies some output directories. Specifies to link with debugging. Specifies that any optimizations will be for a 386!! Try removing the /debug and adding stuff like /GB, /O2 and /Ot (/O2 and /Ot optimizes for FAST code), possibly /Ox since it maximizes optimization. Trust me, VC++ will make your code optimized if you compile it right. So please don't say VC++ sucks unless you know how to use it right. E-Mail me if you still don't know how to do this stuff. - Tom Just wanted to add to my post and say that all this is documented in MSDN, check it out at msdn.microsoft.com/library look up some of these flags, or find the Compiler Reference which gives all the possible flags =) Edited by - olp-fan on 7/26/00 1:14:03 PM

Alright, alright.. I''ve heard enough of this! Nobody SAID in that thread that VC sucks except Stoffel and he was kidding of course! That''s your imagination playing with your thoughts.

Anyways... The thing was that hand-optimized ASM will ALWAYS be better than VC++''s generated ASM code, if the person that codes the ASM code can get his way around it pretty well. Give Michael Abrash the code that VC++ generates, and ask him if it''s optimized. I''ll be curious as to what his answer would be!

Now, stop daydreaming, and get some work done. I understand my mistake, and why it didn''t work the first time.

Hoipefully, this thread will be a good reference for me, and everyone else interested in knowing how to MAKE VC++ optimize for SPEED. I don''t want to see anymore flames wars or whatnot!

Thanks for the reference!

-------------------------------
That's just my 200 bucks' worth!

..-=gLaDiAtOr=-..

Sorry dude, didn''t mean to flame you or anyone, most people don''t know about the underworld of Visual C++ and all its optimization perks. And I agree that it may not generate super speed code by Michael Abrash''s standards, but then again, you aren''t going to code an entire game in Assembly since it will take much longer than if you did it in C/C++. And for time critical sections, you should use _asm { }, to improve speed since it can never hit the speeds that you can hit if you made it yourself (as long as you know what you''re doing).

- Tom

quote:
First.... Notice that it is using incremental linking, it is a windows program. Specifies some output directories. Specifies to link with debugging. Specifies that any optimizations will be for a 386!!

as far as i know, WinNT would be optimized for a 386 also.....
*rofl*, i don''t think so... *G*

cya,

Phil