Version française
Home     About     Download     Resources     Contact us    
Browse thread
single-precision floats, etc.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Charles Martin <martin@c...>
Subject: Re: single-precision floats, etc.

>I'm curious to why you need single floats.  It's certainly not for
>speed, because most processors nowadays do not compute over single

I would want single floats for space, not speed!  The history of video game 
development is a fight for space on a limited memory processor.  Single 
versus double is a factor of two in the space requirements for vertex data 
and etc.

I, too, am deeply interested in using FP for video game development.  I 
have seen far too many pages and pages of C/C++ code that could have been 
reduced to a few higher-order functions.  I went so far as to drop by ICFP 
in Montreal for a day this year to meet some of the Scheme/OCaml/ML 
implementors.

On the subject of GC, the GC pause times are the obvious first problem with 
FP in video game development, but the space overhead is important as 
well.  I was interested in the earlier thread on memory overhead for 
various GC schemes; Damien Doligez mentioned that OCaml has a 1.42 times 
overhead.  If your average data structure is three words (two-word pairs 
are half of most FP allocations, I recall reading somewhere), with the 
header word you are paying [(3+1)*1.42=5.68] almost a 90% space overhead.

So using double instead of single floats means that your game as a whole 
will require approximately twice as much space as a non-FP 
implementation.  Of course, you will gain since you (presumeably) won't 
have to engage in typical video game coding stunts like allocating large 
data structures at the maximum possible size used by the game, only to have 
the majority of levels or whatever only require half your allocation.  How 
it all balances out in the mix is an open question.