Hello everyone. I've recently been debating weather or not to start working on a completely software 3D engine. I'd appreciate some opinions on where to start and what approaches to take. For instance, I was thinking about doing rasterization first so that I can actually see what the geometry processing ends up with. I'd like to be able to implement antialiasing/multisampling/ansiotropic filtering and all of that other good (slow, heh) stuff. I'd be really interested to hear about your experiences designing a 3D software engine. If you're wondering, the reason I want it done in software is so that I can learn how things are being done. I'm not trying to write Unreal for cell phones or anything, I just want to be able to understand (code) all of that crazy and hard stuff like perspective correct texturing... even if at only 5 fps :alright:
Posted on 2004-07-18 12:07:06 by AlexEiffel
You're crazy man, but I like your style :)
Posted on 2004-07-18 19:23:12 by Homer
Well, bessides being crazy, I think you'ld learn a CRAP load of things, if you ever finish! To begin, I'd suggest Mesa, it's software based OpenGL, and it's open source (C/C++ with a bit of assembler, mainly for MMX & SSE!)! Also, look at Crystal Space for the 3D engine part, particle systems, collision detection etc.

Good luck!
Posted on 2004-07-19 02:24:54 by SubEvil
That's why people like Scronty and myself have been posting examples showing off various MODULES of a game engine.
With the right impetus, a team of us could write a game engine which both takes advantage of the available hardware and is of a modular design with (un)loadable code modules to suit anything in the field.
Posted on 2004-07-19 05:56:37 by Homer
EvilHomer2k - I've noticed the demos, but I haven't *really* looked at them. The biggest reason is that I'm trying to decide what to do first before I start implementing anything. But now that you've mentioned it, I could probably look at them and see how things are being broken up and use that to help me decide where to start. From all of your posts, I thought you had already done all of this stuff, heh.

SubEvil - Finishing is actually one of my biggest concerns, heh. I'll take a look at Mesa as soon as I get the chance.

I've actually been thinking about writing up tutorials as I go. I was thinking about doing one for each big problem. Starting with Line drawing, going to line clipping, to triangle filling, to triangle clipping....etc. Gah, now I'll *really* never finish, hehe.
Posted on 2004-07-19 11:41:18 by AlexEiffel
well, if i were you i wouldn't code it in win32asm. or at least, not in 100% win32asm
Posted on 2004-07-20 05:26:20 by Mbee
I think The Svin has a software render on his webpage. Maybe 16-bit however.
Posted on 2004-07-20 10:51:59 by ThoughtCriminal
xlifewirex - I've thought about that as well, and I agree with you. I would like to do a lot of it in asm though, for the fpu/SSE practice if nothing else.

ThoughtCriminal - Thanks for the info. I'll check it out and hopefully it's 32-bit asm.
Posted on 2004-07-20 15:54:52 by AlexEiffel
yes, but i can recommend to write it first in 100% c(++), and later optimize it. coding it in asm will divert you much from the actual algorithm, and it will save you really much time while developing it. for example, if you forgot a divide by z or something, it will be 2 key hits in c++, but it asm you should maybe have to re-order your fpu stack and other things that take much work.
Posted on 2004-07-21 03:59:09 by Mbee
I've actually thought about the same thing. However, I do recommend that you at least get DirectX up and running. You can still do software rendering/rasterization/texturing, etc., but you will gain the support of being able to be used under Windows.

All you need to do is get access to the back buffer and you are essentially in a DOS32 environment. From there you can write all your functions in assembly.

Also with MMX support it is very possible to write extremely fast software rendering with filtering support. I've attempted this in DJGPP but fell short because I didn't know how to get NASM to work inside of RHIDE (has since been remedied).

If you need help in getting a bare bone's DirectX up and running let me know. From there....it's all software, save for the page flipping. And I complement you for wanting to learn what's going on in modern 3D engines. Believe it or not my software experience has significantly shortened my learning curve in Direct3D. Direct3D uses some of the same techniques the DOS gurus used to use in those days. In fact, we wouldn't be where we are today without those gurus.
Now it's all hard-coded in hardware....but it's the same algos.
Posted on 2004-08-09 10:52:35 by
ASMBubba, thanks for your input. I was actually just doing the DX stuff yesterday. I first set things up in DDraw7. I wanted to get an idea of where I was starting, so I locked the backbuffer and wrote every pixel to the same color just to test the frame rate. For some reason, when I run in FS mode, there is a flicker. I switched to D3D and had the same problem. I was able to fix it by setting the swap effect from D3DSWAPEFFECT_DISCARD to D3DSWAPEFFECT_COPY.

Although I admit it was a quick test in C++ and I didn't optimize it at all, I'm a bit disappointed at the frame rate. 16 bit color at 640 x 480 was running at about 100 fps. I don't want to think what will happen once I start doing some math to calculate lighting, texturing, hidden surface removal, etc..

On a related topic, I've been considering doing a ray tracer with photon mapping instead of a rasterizer. My reasoning is that with the programable GPUs, I think in the next 5 years or so, real time ray tracing will start to become the standard. If I can learn it now, then I'll be ahead of the curve when the PS4 and X-Box3 come out. Anyone have any comments about that?
Posted on 2004-08-09 11:13:32 by AlexEiffel
programming a software 3d engine isn't too hard, i mean thats all we did in the olden days :) the good olden demoscene days
as for realtime raytracer, they rock..
here's a link by some fellow demosceners realtime raytracing engine that i really respect
http://www.realstorm.com/
Posted on 2004-08-09 17:41:56 by klumsy
Yep, I got the same flicker. In order to use it like we want to you must set your flags to D3DSWAPEFFECT_COPY.

D3DSWAPEFFECT_DISCARD and D3DSWAPEFFECT_FLIP do not work as intended.

That will get rid of the flicker.



_sPresentParams.BackBufferWidth = width;
_sPresentParams.BackBufferHeight = height;
_sPresentParams.BackBufferFormat = D3DFMT_A8R8G8B8;
_sPresentParams.BackBufferCount = 1;
_sPresentParams.MultiSampleType = D3DMULTISAMPLE_NONE;
_sPresentParams.MultiSampleQuality = 0;
_sPresentParams.SwapEffect = D3DSWAPEFFECT_COPY;
_sPresentParams.hDeviceWindow = hwnd;
_sPresentParams.Windowed = windowed;
_sPresentParams.EnableAutoDepthStencil = true;
_sPresentParams.AutoDepthStencilFormat = D3DFMT_D24S8;

//This must be set to lock back buffer
_sPresentParams.Flags = D3DPRESENTFLAG_LOCKABLE_BACKBUFFER;

_sPresentParams.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
_sPresentParams.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT;


That should do the trick.
Posted on 2004-08-09 21:27:59 by