Jump to content
  • Advertisement

Archived

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

desamaru

speed speed speed

This topic is 5277 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

First things first: if I screw up some terminology, correct me. I am very new to this 3D graphics bit. I''m also new to the forum. I am trying to program my own software 3D engine. I am doing well so far, but have come to a point where speed is becoming an issue. I have two methods of drawing polygons, the slow one and the fast one. The slow one is implemented by manually rasterizing (terminology?) the polygon to the screen using some math I came up with. The polygon is then filled in by horizontal lines, starting from top to bottom, filling in pixel by pixel horizontally across. I forget the name; something like scanlines comes to mind. In the process, I am using a z buffer to decide whether or not to actually put each pixel. The z buffer doesn''t store the color information, by the way, just depth, so I can test whether to draw or not later. The fast polygon drawing method uses backface culling, and a triangle filling routine provided by the graphics API I''m using (windows GDI, if it''s important). Windows'' triangle filling routine puts my filling method to shame. Using it, I get around 140 FPS when rendering 16 rotating cubes. The slow method however is only 10-16 FPS. My question is then, how can I speed things up? I know absolutely no assembly, so that''s not possible with my current knowledge. I''m trying to find where the bottleneck is, but that is not going well, since I can''t seem to optimize my code anything further. I wish I could post the entire code, so others may provide advice or criticism... A few other pieces of information that may make answering easier... I use the "float" data type everywhere. I realize that floating point arithmetic is slow, but I don''t know of any other method to use. I also use a lot of matrix multiplication, and math in general. I would prefer to use my own polygon filling method, since the z-buffer is not possible when using a triangle filling routine (I think). If I didn''t make it clear before, I''m doing all of this in a window using GDI (no graphics card tricks...I don''t know any anyway). Any advice is greatly appreciated. -desamaru

Share this post


Link to post
Share on other sites
Advertisement
If speed is a huge issue, windows GDI is not the path you want to take.

Your algorithms are correct, there''s no other way to fill polygons. To speed it up, you''ll have to change how you go about it. You can try using some memcpys if you find that you can indeed use them in your case. However, the first thing I would look at is your rasterizing algorithm. Look over all that math, and see if you can simplify things.

Share this post


Link to post
Share on other sites
How exactly are you drawing your triangles when you do it the slow way with GDI? Are you filling a buffer and then blitting it to the screen or drawing the pixels one at a time with some kind of put pixel function?

Share this post


Link to post
Share on other sites
Monder probably got the main problem. From experience, Window''s GDI pixel-per-pixel drawing functions are horribly slow. If you are not already doing so, try drawing everything in a memory buffer, then blit it.

Share this post


Link to post
Share on other sites
Monder probably got the main problem. From experience, Window''s GDI pixel-per-pixel drawing functions are horribly slow. If you are not already doing so, try drawing everything in a memory buffer, then blit it.

Share this post


Link to post
Share on other sites
I actually am using am memory buffer, though mainly for flicker removal than speed. I use the GDI''s setpixel function to draw the entire scene to the buffer, then blit it to the screen.

I realize that a 3D engine is an uncommon application of GDI, but I have only been doing it to shy away from the daunting DirectX. I suppose that now that I have some of the main concepts down, it shouldn''t be so bad.

Share this post


Link to post
Share on other sites
SetPixel() is evil, at least from my experience; and judging from what others here are saying, it''s a common experience. If you have another buffer and know the pixel format, just write to it manually, probably treating it as an array. You might have to do a little bit of pointer arithmetic, depending on how you go about it.

Share this post


Link to post
Share on other sites
Create a DirectDraw surface, lock it and write to it; you'll get much faster per-pixel operations and blitting since it can be hardware-accelerated. Also, try out someone else's triangle drawing routine (search on Google, there should be many). You shouldn't be getting 10-16 FPS unless you have an insanely large resolution; my software rasterizer in pure Java easily gets 90-100 FPS for ~1000 triangles in an 800x600 window. Chances are that you have some really expensive operations in your inner loop (multiplications, divisions, function calls, allocating memory) and they're slowing you down significantly. A good inner loop should only require some additions, and perhaps a few multiplications for alpha blending and 1 division for perspective-correct texturing.

Some sites I found useful:
- http://www.exaflop.org
- http://freespace.virgin.net/hugo.elias/graphics/x_main.htm#5
- Also, look up the DirectDraw surface functions in the DX SDK documetnation. (Don't know the exact page since I used Java).


[edited by - Matei on June 7, 2004 6:16:28 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by desamaru
I have only been doing it to shy away from the daunting DirectX.


Try OpenGL, it''s much easier

Share this post


Link to post
Share on other sites
quote:
Original post by desamaru
but I have only been doing it to shy away from the daunting DirectX.


heh, you must be the first person to ever essentially say, "this 3D API is too hard. it''s easier to just write my own software renderer and rasterizer".

-me

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!