Alpha parameter is Float, all else is Integer

[seclorum]

As reported by an early adopter (pmprog) of LOAD81 in the Open Pandora forum here:

http://boards.openpandora.org/index.php?/topic/7405-here-is-a-pnd-for-load81/

"One thing I've just noticed that looks a little weird - in the "fill" command, RGB are 0-255, but alpha seems to be floating point. Am I reading that right? Seems a little bizarre to mix up the parameters."

Perhaps this is a hold-over from Codea compatibility?

[antirez]

Sorry this is Codea heritage, and probably it's too late to change it?

Cheers,
Salvatore

[seclorum]

Its up to you and the strategy for supporting float on ARM, which traditionally has poor support for hardware floating point.

[antirez]

@seclorum it's just a matter of API actually, the ARM poor support for floating point is not an issue from the point of view of argument passing to fill(), it's too little work even for the slowest of the floating point maths ;)
But it may be misleading that everything is 0-255 except alpha.

[seclorum]

Well for the sake of consistency I would say change the API. This has the benefit of making it easier to use bit-shifting for adjusting alpha values in a game .. ;)

[antirez]

Ok. If we need to do that, better to do that ASAP actually... and I think it's a good idea. Doing it right now.

[seclorum]

Maybe do a quick scan for other such opportunies ..

[antirez]

Sorry I changed my mind, reverted to 0 - 1.0, it's pretty standard in computer graphic and I don't feel like changing it now. Thanks for sharing your point of view.

Btw there is a much bigger problem with alpha blending, the implementation of SLD_gfx is very bad and just "adds" components apparently in some broken way. Try the "paint.lua" example now and before SDL_gfx. Probably we'll need to go back to our drawing functions if I can't find a solution :(

[seclorum]

Yikes! If you don't want to change it, I'll do it .. it will bite us later when someone makes a program that does a lot of fills, and we'll see a big performance change.

And, I'm not seeing the problem you're describing with paint.lua.

[seclorum]

Oh, now I see it. filledEllipseRGBA() -> Alpha is Uint8, but you're passing int. Gotta watch that! In fact, I'm noticing an almost catastrophic mixing of types throughout load81, now I look for them ..

[antirez]

Strange that you don't see the same behavior. Example:

http://antirez.com/misc/sdlgfxalpha.png

Try this to reproduce: paint some blue, then press mouse button to switch to red and do a lot of filling staying both inside and outside the blu circles, and you'll see that the red is not able to overwrite the blue in the background no matter how many times you pass over it. This is not the expected behavior IMHO.

[antirez]

@seclorum I'm passing an int in the range 0-255, so it is unrelated. It is a matter of the bad algorithm used in the implementation. This algorithm is faster but does not work as expected I think.

I see what antirez sees too. But, isn't this because when the mouse stops we keep filling over top of the same x,y position? After a while, it should become solid.

[antirez]

Yes but eventually the component of the circle you are drawing should become dominant, if the algorithm is R = (R1*alpha)+(R2*(1-alpha)) (the same for G and B). Here there is some speedup going on that is not mathematically equivalent unfortunately. Also even stranger the blue circles are instead able to completely cover the red ones...

The good thing is that if we revert to our own drawing primitives I'll do the setPixel variant to write in the 8, 16, 24, and 32 BPP variants so that we don't have to change the kind of SDL surface needed. This should make our code almost as fast as gfx with some luck (but not as fast as we need to do the full math for alpha blending to avoid this problem).

[seclorum]

Have a look here:

http://www.ferzkopp.net/Software/SDL_gfx-2.0/Docs/Screenshots/SDL_gfxPrimitives.jpg

http://www.ferzkopp.net/Software/SDL_gfx-2.0/Docs/html/index.html

http://www.ferzkopp.net/Software/SDL_gfx-2.0/Docs/html/_s_d_l__gfx_primitives_8c.html#a33595ad996dd0dcccde3abbcef540eec

I think this is expected behaviour.

I thought you were talking about the solid circle, but you are talking about the magenta area. I don't see that problem.