hi, i'm working on a simple 3D engine. I've spent a lot of time studying the mathematics and algorithms and now I'm ready to start coding. I'm starting from scratch, so my first problem is just figuring how to draw to the screen. I feel kinda dumb that i hit a snag here, because it makes me sound like i'm clueless (perhaps?). I made a post about the SDL library and it looked pretty promising. I'm using it to access the framebuffer and update the screen. I was pleased with the speed of my putpixel function and now I'm testing a line function. It's a lot slower despite using a fast algorithm (Wu), but I may have screwed up somewhere. My thoughts are that using SDL (I've used DriectDraw too) is probably not a great method for getting access to the frame buffer, at least not for my purposes. I'm still learning assembly but I've looked into usin 13h mode. That's pretty cool, but I was hoping to have a higher resolution blah blah. So how do the pros do it? (Actually, I'm looking over my DirectDraw code again, and compared to the same task in SDL, it's much faster. I wish it could be cleaner though). [edited by - chipmunk1886 on December 24, 2002 12:14:01 PM] [edited by - chipmunk1886 on December 24, 2002 1:02:07 PM]

If you want to start working at a 3D engine, then by all means, look at OpenGL or D3D (I like the former). Drawing points/lines by yourelf is NOT the way, at least not in 2002

Height Map Editor | Eternal lands

Those API''s didn''t come out of thin air. People had to design them, and the principles behind them have been documented quite thoroughly. I''m trying to work my way from the gruond up, then maybe I''ll do more with OpenGL, but not until I have something like this under my belt.

I really don''t think this will pay off. But, anyway, if you want to do that, you might want to take a look at Quake 1&2 source code, they both support software only rendering.

Height Map Editor | Eternal lands

1) 99.9% of the "pros" use OpenGL or Direct3D these days to expose **hardware** 3D acceleration rather than going for software rasterisation. It''s been that way since 1997, and some consumer level 3D acceleration of the rasterisation and texturing was available even earlier.

2) If you still want to do a software rasteriser it WILL teach you a lot of things, many of which you''ll never need again (using hardware).

3) You should do ALL software rasterisation in system memory, with all resources such as textures in system memory - NEVER try to do any extensive scan conversion/rasterisation direct into video memory (e.g. a locked Primary/Secondary surface).
I''d advise creating a system memory DirectDraw surface to represent the screen, lock it and do ALL your rasterisation into that, then use IDirectDrawSurface*::Blt() to transfer it to the primary surface on the graphics card. Using Blt() lets you take advantage of any accelerated system->VRAM DMA transfers provided by the hardware.

4) Forget mode 13h - it''s an easy trap people fall into - they think "assembly will make things faster", then look for tutorials - most of which were written in 1992 before most PCs had any form of graphics acceleration. You can use assembly withe DirectDraw/SDL etc if you really must, but it definately doesn''t mean you HAVE to use DOS/BIOS calls/interrupts. On the flipside, you don''t have to use asm to use mode 13.

5) Crucial to a fast software rasteriser is understanding how modern CPU caches work - if there''s one thing to understand it''s caches. You don''t need to code in ASM for maximum cache efficiency.

6) Other CPU things such as branch prediction (what the CPU "guesses" your loops are going to do - if the CPU guesses incorrectly, you get a performance hit - you can help it guess correctly.), instruction pairing and pipelining etc.

7) For your rasteriser you can pretty much assume MMX support on most CPUs these days. MMX can help a great deal and its introduction was intended for things like software rasterisers (Multi Media eXtensions).

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

thanks S1CA for advice. i''ve actually been looking into some code for VGA modes and i''ve failed to get any simple examples to work, so I''ve dropped that idea. So far I''ve been discouraged from attempting this project, but it''s something I''ve been wanting to try for a while.

the reason why all your dos/bios/ect interupts don''t work is beacuse they are for use in 16-bit real mode, not 32-bit protected mode. which is where your app is running (even if its a "console app"... its not realy a console app its a Win32 program that looks like a console).

If you want to get around this get djgpp (free) it will let you switch back and forth between PM&RM... the only problem is that NT/2K/XP don''t have a full VM setup for dos programs so your program will still not run.

If you still want to give this a go use SDL/DD or whatever to set the video mode & and push the pixels to the screen for you.