Re: [AD] float positions

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/