flipCode - Tech File - Adam Robinson [an error occurred while processing this directive]
Adam Robinson
(aka Iok)
Click the name for some bio info

E-Mail: Iok@bigwig.net
Website: http://www.furryfoxy.freeserve.co.uk

   09/14/1999, Update 3

The End

I'm leaving home and going to university quite soon so I doubt I'm going to be doing a large amount of coding for the next month or so. Probably more. Oh God. If anyone can think of a good reason for studying Physics please tell me.

Descent 3

I bought Descent 3 last week and it has a terrain engine similar to mine [the polygon density is higher because it runs through 3D acceleration]. Descent does not interpolate between Lod levels creating a weird 'popping' effect in the land graphics while you're moving. My engine does run the interpolation but I'm not sure it looks better for doing so. In my engine some moutains seem to 'grow' as you move towards them and this is less obvious with the non interpolating system because of the sudden steps.

Descent relies on zbuffering to handle the internals of its 'rooms' and their links to the land [I think via a portal system]. I can't use zbuffering since I'm running in software and getting everything drawing correctly using the cbuffer is very difficult. I am currently using 2 concurrent cbuffers, one handles the land polygons and any large polygons above the land and the other [which is not completly separate] handles the portal systems that are under the land. This is nessecary because cbuffers store no z information. This is not ideal because currently sectors cannot be above the land surface and draw correctly.

[you can learn a lot about how this game works by downloading and looking at the include files in the D3SDK. I think you can get it on http://www.planetdescent.com ].

2D accelerated graphics

I am not a fan of 3D accelerated rendering on PC's [the API's, card features e.t.c. are a complete mess] and won't be until the whole 3D card thing is sorted out [which is going to be many years away]. I was thinking about something I read in a interview John Carmack gave in 'Edge' [the best computer magazine I've ever read]. He was talking about how it was a 'bad engineering descision' not to use all the hardware you possibly could in a particular machine. He was refering to 3D accelerators and voxel graphics that started me thinking about the 2D accelerators that are in virtually every PC.

I know that there are accelerated blitting facilities available but after reading the specs for Directdraw->Blt it seems that alpha blending and stretch blitting facilities are available. Using accelerated alpha blending and stretch bliting would enable me to do fast transparent coronas and particles e.t.c. The Problem is that I do not know how many cards these facilities are suppored on and I suspect that its only the 3D cards that have them. If anyone knows how widespread the features are email me! I need to know about P200+ type machines.

Even without the blending features I can still make the transparancies fairly fast if the card has a dma/background system memory to video memory blit. Although again I'm not sure how many video cards can do them.

AGP and Win95 950/950a

I've been wondering for ages why the throughput of my 3D card was so bad. I was reading some driver specs at the weekend and found out to my suprise that under the first 2 versions of Windows 95 AGP cards do not work any faster than PCI cards! I'm now trying to upgrade to Win98. [I NEVER thought I'd say that].


Very important. In fact, this is the most important feature a good 3D engine must have. Use a BSP. Or Portals. Or a cbuffer. Or don't bother and market your game for PIII's.

Culling nodes via cbuffer

Works - most of the time, try it.

Triple buffering

Allows you to have flips aligned to the verical blank without the frame rate being locked to a harmonic of the monitor refresh.

System to Video ram dma blits

There is apparently a way to do these on all cards and I REALLY need to know how. Anyone who knows email me!

Forgotton art of asm

[I wrote this before I knew about the disscussion thingy - I'll leave it here anyway].

Why do so many programmers not know assembly language?! I've been downloading a lot of other peoples source code lately and have found so many examples of 'computer scientist' coding [You can blame all problems with computers on them][I hate computer science]. 3D / graphics programmers need to know assembler, even for programmers not doing that sort of intensive programming, learning and being good at assembly language is good for you, you'll understand the machine far better once you have - apart from that coding in asm is cool. Try it. Even better try writing a complete Win32 program in asm - its fun!

Remember - you can probably get a 2 to 3 times speed increase in your lighting code [for those of you using hardware rendering] writing in asm instead of C/C++. Most compilers are terrible at high level optimising and are just as bad at low level optimising. [If you don't beleive me look at disassembled code of your own programs - most of the time for any sort of maths intensive code compilers are crap at optimising]. You can get the greatest speed increase by writing 'inner loops' in asm but you get another large speed up by rewriting anything called more than 100 times or so a frame. Of course you should always 'high level' [algrythmically] optimise as much as you can in C/C++ first before you try writing a routine in asm.

Compilers are also terrible at cache optimisations - I think that the cache is probably the most important thing to optimise for in a PC. Even in assembler it's still quite hard to cache optimise everything but it's worth the effort.

[don't flame me about this]

Benifits of a 32bit zbuffer

I use 24 bits for Z information and the top 8 bits to make sure I only have to wipe the zbuffer once every 256 frames. This leads to the possibilty of dynamic zbuffer usage. Only transparancies and models need the zbuffer in my engine - using a sort of 'dirty rectangle' scheme I should be able to eliminate most of the zfilling the land and portal systems have to do - this should make my 32bit zbuffer much faster than a 16bit zbuffer! [I already have stopped zfilling the sky].

Something else that is very important with integer/fixed point zbuffers - if you operate a 1/Z buffer [as you should if you want it to look right] you must tweak the equations generating 1/Z values from Z values so that they make good use of the range of numbers you have. The problem is that the change in 1/Z is non linear with respect to Z and its most non linear when Z is small. If you don't scale/tweak z then you lose far too many of the possible zbuffer values right up close to the camera. 1/1 is one [or 65536 in 0:16] - 1/2 is one half [or 32768 in 0:16] - i.e. the change in z from 1 to 2 looses you HALF the values an integer zbuffer can have!

Draw a 1/x curve with x from 0 onwards - what you really want to do is move your z values a little along the curve [+x] so the change is less non linear. I know that this makes the solution less 'correct' but the small change is not really noticable i.e. its still a huge amount better than a plain Z buffer.

[Are 1/Z buffers called W buffers?]

Bump mapping in one pass

I've been working on getting simple bump mapped textures working in my engine - they are not properly bump mapped. You can define regions of a textures palette that will act when a polygon is lit as if the normal of the polygon is perturbed in different directions. The polygons that are to be bump mapped have their palette modified before they are rendered depending on the polygon direction. This works fine for a single light source but when you have several lightsources you have to approximate [This is because we are only running a single pass and as for specular lighting you have to run one pass per light source if you are doing it correctly.]

Specular lighting via environment mapping

This has been used in many demos and I think in Gran Turismo on the Playstation. In software making this fast requires a multi pass routine similar to the one I'm using for my interpolated lighting. The problem with this type of lighting is again that to do this properly we have to do an extra pass per light source shining on the polygon + we have to light the environment texture [ I suppose we could modify the palette again].

Full Motion Video

As well as Descent 3 I bought Tiberian Sun [which I've completed]. The FMV in Descent 3 is annoying and not particually well done where as the FMV and story in Tiberian Sun made me stay awake for almost 4 days playing [I'm a little obsessive when it comes to computer games]. A good/involving story can really add a lot to a game.

MMX and 64 bit boundaries

Very important to try to make most of your mmx memory access from 64bit boundaries it speeds up memory access and optimises cache usage, especially important for pci/agp video access.

Wher hey!

I completed FZeroX on the master setting! And got the Invincibility cheat on Goldeneye! [I play games far too much].

My web sites up!

Yes it is. Definatly. http://www.bigwig.net/mooshtack_boorai/

- Adsy [#KliX#] -

  • 04/01/2002 - Tech File Update
  • 03/08/2001 - Tech File Update
  • 02/11/2000 - Tech File Update
  • 01/06/2000 - Adsy Loves Microsoft...
  • 10/27/1999 - Gone For A Burton - Or Not - Maybe.
  • 09/14/1999 - Update 3
  • 08/23/1999 - Update 2
  • 07/23/1999 - In the Beginning

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]