[SDL] writting a doom-like game

Bob Pendleton bob at pendleton.com
Mon Jan 10 06:43:45 PST 2005

On Sat, 2005-01-08 at 17:53 +0100, Nicolai Haehnle wrote:
> On Tuesday 04 January 2005 16:22, Bob Pendleton wrote:
> > There are a lot of things that were done in DOOM that are not worth
> > doing now. For example, DOOM used fixed point arithmetic, but modern
> > processors (486DX and above) do floating point math very well, so there
> > is no need to deal with fixed point arithmetic.
> There are still some niches where fixed point is valuable. Whenever you need 
> to store some vector that is supposed to have equally distributed precision 
> across its entire range, and you're not doing seriously heavy math with 
> this vector, you might want to consider fixed point.
> In one 3D environment, I was reaching the range limits of the 32 bit float. 
> Well, not exactly the range limit, but once you're too far from 0 (i.e. the 
> world origin), the precision got so bad that round-off errors in simulation 
> were unacceptable. There were two choices: Use double, which takes twice 
> the memory, or store the actual coordinates as 32 bit fixed point. I chose 
> the latter, and it works perfectly fine. Note that I still use float during 
> the actual simulation, but that works out fine because during the 
> simulation, only small (difference) vectors will be used.
> To give a more well-known real-life example, Half-Life sends player 
> coordinates as fixed point across the network. This is obviously done in 
> order to save space while guarantueeing that the precision at which player 
> coordinates are transferred is everywhere the same.

Yes, in a completely different context than the one I was talking about
fixed point still has a place. But, you wouldn't seriously suggest that
he write and entire rendering pipeline based on fixed point arithmetic,
would you?

			Bob Pendleton

> cu,
> Nicolai
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

More information about the SDL mailing list