Re: [AD] float positions

[Andrei Ellman <ae-a-alleg@xxxxxxxxxx>]

Evert Glebbeek wrote:
> My initial response is "eeeew"

My sentiments exactly. However, I'm OK with having two separate 
functions for floats and ints. If we really wanted to abstract the 
co-ordinate paramaters, we could always create a typedef 'al_real' which 
is typedef'd to either float or int depending on whether we want to use 
ints or floats. The problem with that is that if we abstract away the 
co-ordinate type, the user will not know whether or not it is OK to 
assign an al_real a fractional part. Incidenatlly, the Renderware API 
uses a 'real' type that is defined to either a fixed-point or a 
floating-point type depending on which is faster on the target platform.


Elias Pschernig wrote:
> Well, my idea would have bee, to simply cut away anything after the
> decimal point. It would happen in the respective driver - e.g. the
> OpenGL driver passes the float on, a driver who wants into just does
> uses only the integer part.

One thing we must remember is that on x86 platforms, casting from float 
to int causes the FPU to change it's state in order to remain compliant 
with the ANSI C standard. Thus, code like the following:

 float foo = 2.5;
 int bar = (int) foo;

Would cause the CPU to change state in order to get the float->int 
conversion to comply, and then change it back again. We would have to 
implement a function int floattoint(float foo) which is an assembly 
optimised float to int converter (or the equivalent function in some 
standard liberay if it exists), and replace the second line with the one 
below.

 int bar = floattoint(foo);


Elias Pschernig wrote:
> Well, it allows using fractional positions (if OpenGL is set up to make
> use of them) for Allegro primitives. As I said, in my case, I could have
> directly used e.g. al_blit to move my sprite when e.g. interpolating to
> the vsync rate. E.g. if a sprite moves 60 pixels / second, and vsync is
> 75 Hz, you can't get totally smooth movement without anti-aliasing -
> some pixel positions from the 75 different positions in one second are
> displayed twice and others only once. If you anti-aliasing so the sprite
> can also move fractional pixels, it will look like it moves the same
> amount 75 times and be totally smooth.

This would probably work well for truecolour sprites, but I suspect that 
if the developper is using low-colour sprites in order to give their 
game that retro-look, the sprite would look a bit blurred unless both 
it's coordinates were on an integer boundry.

AE.