Why is my software renderer slow?

Started by
9 comments, last by foolish_mortal 19 years, 10 months ago
quote:Original post by foolish_mortal
I haven''t used one of these before. How do they work? Are there any free, easy to use ones that you''d recommend. I am using MS Visual C++ .NET standard edition to compile my code.

Compuware DevPartner Profiler integrates with Visual Studio .NET. It works quite well, but it makes your application even slower (while profiling). Intel VTune is the best tool there is, but it''s shamefully expensive. AMD CodeAnalyst is for free, and works for most part on Intel processors as well!
quote:Well it is, I''m in Release Mode, not Debug mode, but this is VC++ Standard Edition, which means it is a non-optimising compiler. Is that likely to make a big difference in this kind of situation?

Absolutely! Even with my software renderer, where all the rendering code is in assembly, performance is less than half when optimizations are turned off. Microsoft recently made it''s optimizing compiler available for free in the Visual C++ Toolkit 2003.
quote:How would you Blit to the screen smartly? I use the function SetDIBitsToDevice from the Win32 API. The FillScanLines function that I showed you fills a screen buffer (pBmp) which is an array of floats, three floats per pixel (for the RGB values respectively). Before I blit it, I have to go through all these floats and convert them to chars and copy them to the bitmap buffer which is blitted to the screen. This step might be open to optimisation. Also, my Bitmap isn''t actually 4-byte aligned, it''s 3-byte aligned, maybe that would help, I will give that a go.

Definitely use directdraw, and render directly to the video memory with 32-bit colors. Have a look at swShader''s FrameBuffer class.
quote:I would quite like to learn assembler better, even though it does scare me a bit, just to prove I can.

Ah, it''s actually a lot of fun.
quote:Is it bad to use inline assembler? I''ve heard that it can be ''slow'', although I have no idea why it would be. If I can''t use inline assembler, how else would I integrate it with my c++ code? (see I told you I''m a newbie with assembler...)

Inline assembly is perfect. It frees you from worrying at what memory locations your C++ variables are stored. You can just use their C++ name. It isn''t slow, but you should try to write big blocks. Visual C++ has less freedom in how it optimized the code before and after an inline assembly block. It''s not terrible, but you should avoid writing blocks with only a few instructions. Don''t just write the inner part of a loop in assembly, but the loop itself as well.

This topic is closed to new replies.

Advertisement