Re: [AD] float positions

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2007-01-22 at 15:18 -0300, Victor wrote:

> Converting "int -> float -> int" is indeed a waste of time, except if
> the compiler could optimize that to simple "int". It again could depend
> of what the programmer does and how.
> I assume that the first conversion is did in the parameter passing to
> puxtixel/getpixel/blit/whatever, so where is the second one? If it is
> in deep inside allegro there is no sense to use float there as it would
> always turns into a int. If it's inside OpenGL, i think is ok.

Yes, maybe my impressions are wrong here, but it seems other things take
way more time for this to ever become relevant.

> But, if i use al_getpixel(bmp, 4.5, 3.141592) what it should return?
> What does al_putpixel(bmp, some_color, 1.23, 7.777)?
> How the resulting bitmap of al_blit(bmp1, bmp2, 3.33, 3.141592, 0.5,
> 4.444, 653.21, 1234.567) will look?

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.

> 
> Presently we have the 4.2 implementation renamed to insert the "al_"
> prefix whit a bit of changes here and there. I don't think that the new

No, the al_ prefixing idea was scrubbed. Only new functions will get it.

> API will get so outrageous changes to 4.2. The functions names changes,
> the parameters changes, OpenGL will be used (or not), some new
> functions will be created, some deprecated, but the new API will still
> be 80% to 90% what the old one is.
> 

No, see here: http://alleg.sf.net/future
In particular for graphics:
http://alleg.sourceforge.net/future/gfx-api.txt

Already now in 4.3 Allegro is events based, so e.g. input and timers API
don't have anything in common with 4.2 anymore. So anyway, I'm just
saying, if we want a float based API, this wouldn't stop us.

-- 
Elias Pschernig