Re: [AD] float positions

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


--- Elias Pschernig <elias@xxxxxxxxxx> escreveu:

> 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.
> 

If you (or someone/something else) just cut away the fractional part
(or round it), so it will be very pointless to transform everything in
float. Letting the drivers decide what to do with the fractional part
doesn't seems to be a good idea because that will create trouble for
people which would use non-integer pixel positions because they need to
pay attention about if the driver will or will not accept the
fractional part.

EG:
putpixel_f(bmp, color1, 2., 3.);
putpixel_f(bmp, color2, 2.5, 3.5);
putpixel_f(bmp, color2, 2.99999999, 3.9999999);

The behavior of that will be different depending if the fractional part
is cutted, rounded or used deep down.

However we could implement putpixel (by hand, without OpenGL) with
something like this:

void putpixel_f(BITMAP *bmp, int color, float x, float y) {
  int rx = (int) x, ry = (int) y;

  /* Shortcut for integer x and y. */
  if ((float) rx == x && (float) ry == y) {
     putpixel(bmp, color, (int) x, (int) y);
     return;
  }

  /* Coordinates are fractional,
     get the neighborhooding pixels to blend. */
  int a = getpixel(bmp, rx, ry),
      b = getpixel(bmp, rx, ry + 1),
      c = getpixel(bmp, rx + 1, ry),
      d = getpixel(bmp, rx + 1, ry + 1);

  /* Discover how many to blend in each pixel. */
  float u = x-rx, v = y-ry;
  float q1 = (1-u)*(1-v),
        q2 = u*(1-v),
        q3 = (1-u)*v,
        q4 = u*v,
        red = (float) getr(color),
        grn = (float) getg(color),
        blu = (float) getb(color);

  /* Put the pixels, blending with the neighborhood ones if needed. */
  if (q1 > 0)
      putpixel(bmp,
        makecol((int) (((float) getr(a)) * (1 - q1) + red * q1),
                (int) (((float) getg(a)) * (1 - q1) + grn * q1),
                (int) (((float) getb(a)) * (1 - q1) + blu * q1)),
        (int) x, (int) y);

  if (q2 > 0)
      putpixel(bmp,
        makecol((int) (((float) getr(b)) * (1 - q2) + red * q2),
                (int) (((float) getg(b)) * (1 - q2) + grn * q2),
                (int) (((float) getb(b)) * (1 - q2) + blu * q2)),
        1 + (int) x, (int) y);

  if (q3 > 0)
      putpixel(bmp,
        makecol((int) (((float) getr(c)) * (1 - q3) + red * q3),
                (int) (((float) getg(c)) * (1 - q3) + grn * q3),
                (int) (((float) getb(c)) * (1 - q3) + blu * q3)),
        (int) x, 1 + (int) y);

  if (q4 > 0)
      putpixel(bmp,
        makecol((int) (((float) getr(d)) * (1 - q4) + red * q4),
                (int) (((float) getg(d)) * (1 - q4) + grn * q4),
                (int) (((float) getb(d)) * (1 - q4) + blu * q4)),
        1 + (int) x, 1 + (int) y);
}

Warning: Untested, i writted that exactly now.
That would/should putpixel in fractional positions, so something like
putpixel_f(bmp, color, 5.75, 6.8) would put 5% of the pixel in (5, 6),
15% in (6, 6), 20% in (5, 7) and 60% in (6, 7), blending with the
pixels already there.
Of course, that is horribly slow. It may be optimized to something
faster, but it will still be very slow if not HW accelerated, OpenGL'd
or something.

> > 
> > 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
> 

Oh, i forgot about the event based systems. Was thoughting only in GFX,
sorry.
However about that graphics API proposal, we still are very, very far
of that. Trying to implement everything at once is exactly what was did
when allegro 5 was planned: It takes us to nothing.

Doing things step by step is still much better.

Victor Williams Stafusa da Silva

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 




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