[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
--- Elias Pschernig <elias@xxxxxxxxxx> escreveu:
> On Mon, 2007-01-22 at 14:34 -0300, Victor wrote:
>
> > Many programs assume that pixels are integers. E.g:
> >
> > // Changes yellow to blue in some bitmap.
> > int x, y, color;
> > for (x = 0; x < bmp->h; x++) {
> > for (y = 0; y < bmp->w; y++)
> > color = getpixel(bmp, x, y);
> > if (color == makecol(255, 255, 0))
> > putpixel(bmp, x, y, makecol(255, 255, 0));
> > }
> > }
> >
> > If pixels aren't integers, things like that may fail or bug.
>
> As long as int -> float -> int conversion returns the same int, it
> should keep working. So unless you create a 2000000 x 2000000 bitmap,
> there won't be a problem.
>
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.
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?
> > > > It would be better to create new functions to put/get
> non-integer
> > > > pixels and use non-integer blit, without deprecating or
> changing
> > > the
> > > > existing ones. Its important to note that they don't need to
> use
> > > > OpenGL, it's feasible and not very complex to implement they by
> > > hand
> > > > _IF_ needed for whatever reason.
> > >
> > > There are no existing ones as it is yet to be written..
> > >
> >
> > I am not sure if I am misunderstanding what you are talking about
> or if
> > you went nuts. What about putpixel, getpixel, blit, line, hline,
> vline,
> > polygon, circle, masked_blit, draw_sprite, rotate_sprite,
> floodfill,
> > and many, many others which indeed exists for a long time ago?
> >
>
> Yes, I was talking about the GFX API proposal though.. none of its
> functions (e.g. al_line) are implemented yet, so if the first
> implementation is with floats, it has floats. The 4.2 functions have
> nothing to do with it (and the compatibility layer should not have
> much
> problems passing the ints from line() to al_line() either).
>
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
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.
> --
> Elias Pschernig
>
Victor Williams Stafusa da Silva
__________________________________________________
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/