Working on my first 3d engine (rasterizer)
Hi,
I'm a senior as of this coming year of High School and I have recently begun work on a 3d rasterizer. I'm making it on the windows gdi since it is the only thing I know how to work well with as of right now. I'm basically just practicing programmming and trying to master perspective math. I have found a good algorithm for a 3d rasterizer which should make collision detection and physics quite a bit easier to calculate than it might be normally with the standard cartesian coordinate system). Anyways, I just wanted to say hi. I don't plan on being a professional game developer, just a normal applications programmer, and I have found that thinking in terms of 3d can really help you in terms of how to think when approaching problems that require abstract solutions. I am making this engine for fun as a summer project, and to prepare for a java class next year. I found the algorithms on my own, not using any sources for help, so that I can fully understand how 3d works. I am building everything completely from scratch and basically using common sense and trying to figure out things myself. What I wanted to ask is if any of you others out there that have built some kind of rasterizer or engine on the windows gdi could give me some idea as to what type of speed (numbers would be great) I can expect out of it. I have seen many people talk about the windows gdi being slow, but how exactly is it slow? Are the functions themselves just plain ineffecient for 3d? Right now I am still finishing up getting all the perspective working (it's all on paper, just have to program the rest of it and set up the objects). If it is the functions themselves that are just plain slow, is it possible at all that I can write my own or somehow bypass as many of the slow aspects of the windows gdi as possible. I don't want it (or expect it) to run like a dream, but I wanted to ask you the experts how I can at least keep things decent. I don't mind reinventing wheels, I would actually prefer it being a relatively new programmer who is still getting used to the thinking aspect of programming. Thanks a lot.
They're barely efficient for 2D rendering, let alone 3D. I built a 3D rasterizer on top of GDI a while ago (about a year now) and I got ~10FPS just rendering 2 spinning cubes (wireframe style, no filling or texturing was applied.) I get ~30FPS rendering some of the more advanced techniques and scenes with Direct3D (just for comparison.)
What language are you using (I think I read java, but I'm not sure)?
What language are you using (I think I read java, but I'm not sure)?
I know you said you don't want any source to help you out, but just in case you start to get frustrated or need ideas...
"Tricks of the 3D Game Programming Gurus" by Andre Lamothe does exactly what you're doing. It builds a software rasterizer from scratch (using 2D DirectDraw, not GDI or Direct3D). Check it out if you change your mind. I've worked through the first half, and it's really good.
-Gauvir_Mucca
"Tricks of the 3D Game Programming Gurus" by Andre Lamothe does exactly what you're doing. It builds a software rasterizer from scratch (using 2D DirectDraw, not GDI or Direct3D). Check it out if you change your mind. I've worked through the first half, and it's really good.
-Gauvir_Mucca
Quote:Original post by Gauvir_Mucca
I know you said you don't want any source to help you out, but just in case you start to get frustrated or need ideas...
"Tricks of the 3D Game Programming Gurus" by Andre Lamothe does exactly what you're doing. It builds a software rasterizer from scratch (using 2D DirectDraw, not GDI or Direct3D). Check it out if you change your mind. I've worked through the first half, and it's really good.
-Gauvir_Mucca
I have the second book in this series and I agree. If you do need sources these are good ones. Also, the game institute Direct3D9 course does this in the very first lesson (using GDI.)
I'd recomend using SDL in place of GDI. It's very easy to setup and use and things should go a lot faster than they do with GDI. As an example I got over 100fps from a simple spinning pyramid (with vertex colour interpolation) from a software rendering I started writing that uses SDL, and that was with no attempt at optimisation (Had I optimised it I reckon it could've gone a lot faster).
Quote:Original post by OCcsdudeLike you, I tried the "let's use common sense and try to write some sort of very very basic software rasteriser" approach, using C++ and SDL. The screenshots are here. Typically, I would be getting 40-50 FPS for those, but the fill rate was very low and any attempts to make a "world" to walk in (even just a cube) would drop the FPS to about 10-15 at 640x480. (That would be filling every pixel). Still, it was a fun project. [smile]
...have built some kind of rasterizer...
As benryves said, problem is in fill rate. Transforming vertices is not a problem, and CPU can do it pretty fast. However, when you start filling pixels, it gets crappy. This is why they start making graphics cards at first place... First 3D card have done only this rasterisation part, T&L (vertex processing on video cards) came many years later...
Problem with window GDI is transfering your "backbuffer" to screen. For example, try using SetPixel() for whole 1024x768 array... [wink]
Reason why fillrate is crap, is that video cards have specific hardware for texture fetches, filtering, etc... When working with software, you have to do it all youself, and it takes many CPU instuctions. And there is no any kind of paralellism like video cards have.
Of course, it is not imposible to get good fps, games like DoomI/II, Duke Nukem, QuakeI, etc. were software only, and they run pretty good...
edit:
I just found some suggestion on flipcode that you should try using SetDIBitsToDevice() for backbuffer->screen transfer. If it can copy whole screen more than 30 times per second (which I hope it can), you don`t have to worry about GDI being slow.
Problem with window GDI is transfering your "backbuffer" to screen. For example, try using SetPixel() for whole 1024x768 array... [wink]
Reason why fillrate is crap, is that video cards have specific hardware for texture fetches, filtering, etc... When working with software, you have to do it all youself, and it takes many CPU instuctions. And there is no any kind of paralellism like video cards have.
Of course, it is not imposible to get good fps, games like DoomI/II, Duke Nukem, QuakeI, etc. were software only, and they run pretty good...
edit:
I just found some suggestion on flipcode that you should try using SetDIBitsToDevice() for backbuffer->screen transfer. If it can copy whole screen more than 30 times per second (which I hope it can), you don`t have to worry about GDI being slow.
Thanks for the help and the feedback. And thanks Bulma for the flipcode I could possibly use, I'll look into SetDIBitsToDevice (). Time to encapsulate everything. Soon I'll have everything clean, and I will approach the fill rate problem. Even if the gdi ruins it a bit, I'll have all the perspective math encapsulated (though it might be custom-made, so-to-speak). I'm gonna make a 3d point class, then off of that a polyhedron class, and off of that a tetrahedron class. I have decided to call the engine FunPain, because this stuff is dam fun but oh so painful at times lol.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement