Alpha sprites

[lillo]

Ok, I just finished adding more complex ALPHA mode to PUT in gfxlib...

Here's how PUT works now:

Code:

PUT [buffer,][STEP](x,y), arrayname[(idx)] [,mode[,alpha]]

Note the alpha parameter at the end. If mode is ALPHA, you can optionally specify an uniform alpha value, ranging 0-255.
That is:

Code:

PUT (x,y), sprite, ALPHA

Will get alpha values directly embedded in the pixels of your sprite; you must be in 32bit mode for this to work, otherwise it'll behave like the PSET mode. Since you have a real alpha channel to play with in this case, PUT will not skip mask colors; use an alpha value of 0 for those pixels you don't want to be drawn.

Code:

PUT (x,y), sprite, ALPHA, value

Here value will be used as alpha value for all pixels of your sprite. Mask colors are skipped in this case, and infact if you specify a value of 255, this will behave exactly like if you used the TRANS mode. When an uniform alpha value is specified, the ALPHA mode will work in 15, 16, 24 and 32bit color depth, otherwise it'll behave like the TRANS mode.

Ok people, now you have a new toy to play with   The little disadvantage (!) is your EXEs will be 2-3 Kb larger than before when using PUT...

[Z!re]

Nice..


Now add some hardware accelleration, and we'll have a really powerful lib to play with (not that it isnt already)

[Jofers]

Wow!

Just out of curiosity, how much code is crammed into the PUT function, or does it link to different ones, depending on how many arguments are used or something?

EDIT:  Nm, I need to learn how to read  And why would # of arguments matter if that's just another mode?

Zire's right, alpha's pretty slow in software mode, judging by Allegro's routines.  Shame hardware acceleration would bloat PUT up even more.  Really, alpha blending might be doing it already, but it's a useful thing to have, perhaps in its own function.

[gunder]

lillo you are great.  Thank you so much for all the work you have done and continue to do on gfxlib.

[barok]

just wondering, how much more speed would you get if you add hardware acceleration, lillio?

[lillo]

Thanks people

I haven't benchmarked the routines, but I'd not be surprised they're faster than Allegro's... To do blending, Allegro calls a "blending function" for each pixel to be drawn; this allows for custom blending, but also slows things down a lot. In gfxlib there are only 2 different routines I've coded, each doing only a specialized thing: the first only works in 32bit mode and does alpha blending via the sprite own alpha channel; the second works in 15, 16, 24 and 32bit mode and blends the sprite on the background according to an unique alpha value passed to the function.
In addition, MMX is used all over the place, so...
About size, all PUT routines (both C and MMX versions) are linked in only if you use PUT in your programs. I've just looked at the real size increase under Win32, with the following program:

Code:

dim sprite(1000)
screen 13
put (0,0),sprite
sleep

(Ok it's badly coded and does nothing, but it's just a test)
This compiled with latest fbc snapshot produces a 47104 bytes EXE. By commenting out the PUT call, the EXE is 40960 bytes. 7K, not much for what it offers IMHO :wink:

Ok, hardware acceleration is a completely different beast in term of speed. But adding it would be a tremendous hack on top of the lib, because gfxlib was never conceived to support it... Never say "no", but don't expect it anytime soon, as it'd require a partial rewrite of the library core... What would be nice would be to code a new lib in FB using OpenGL calls to blit sprites. Gfxlib supports OpenGL, so if you really need acceleration, why don't you go that way?

[lillo]

Ok, now for 0.5K more, we also have custom blenders support, like Allegro  :bounce:

Code:

PUT (x,y), sprite, CUSTOM, @MyBlender

Where MyBlender must be a function of the form:

Code:

FUNCTION MyBlender (BYVAL src AS UINTEGER, BYVAL dest AS UINTEGER) AS UINTEGER

This will be called for each pixel of the sprite, will receive the source sprite pixel and the destination pixel where it is going to be drawn, and must return the new pixel color to be drawn. Color values this function deals with are always in the same form as used by other gfx primitives, that is, indices if in paletted modes, or &hRRGGBB values if in hi/truecolor mode.
For example, here's an additive blender:

Code:

FUNCTION MyBlender (BYVAL src AS UINTEGER, BYVAL dest AS UINTEGER) AS UINTEGER
r = (src SHR 16) + (dest SHR 16)
g = ((src SHR 8) AND &hFF) + ((dest SHR 8) AND &hFF)
b = (src AND &hFF) + (dest AND &hFF)
MyBlender = RGB(IIF(r>255,255,r), IIF(g>255,255,g), IIF(b>255,255,b))
END FUNCTION

May not be really fast, but does the job if you need custom blending...

[Neo]

Looks nice.

lillo... I'd like a chat with you about this if you don't mind. I hope to be on irc when you're there.

[SotSvart]

Very nize!    Keep up the great work!

[lillo]

Neo, my ISP (named Fastweb) provides me with a dynamic IP, and it seems the whole range has been banned lately from the EFnet network... Dunno when the ban will be removed; until then, I cannot access it. Either we meet on #freebasic at FreeNode (the official FB channel, even thought almost never used by anyone since people prefer #badlogic, where FB discussions originated), either we meet on #badlogic once I go to work on Monday (there the IP isn't banned).

[Jofers]

- Allegro calls a custom function for EACH pixel?  No wonder it's slow!

How do you specify an alpha channel with ALPHA?  I'd be glad to benchmark the two routines for you.

[lillo]

When drawing, use the RGBA macro instead of RGB...  :roll:
Seriously, the alpha channel is stored in bits 24-31 of each 32bit pixel... You may want to do some low-level access to the pixel data to create your own alpha channel.

[Jofers]

Righto (me <- never done used FB much).  Heh, I always thought that channel as something only windows ever used.

Buuuut, it looks like tortoiseCVS and Windows 95 aren't good friends so I'll be waiting until I get back to college on tuesday to try this out.

[v3cz0r]

Angelo's gfx lib is a great piece of software, too few people may realize that. You won't find an easy to use, fast and portable gfx lib like that in any commercial BASIC compiler/interpreter/whatever. Or they are simple directx wrappers, or depend on 3d cards, or are too damn slow, and the list goes on..

The assembly sources are nuts, you must be some kind of a machine to read and code using AT&T syntax without a single comment ;)

[Jofers]

True dat

Lillo - you've worked on Allegro.  Do you know of any patches/routines for it (excluding AllegroGL) that contain a faster Alpha blender?  I drew some graphics for a 2d C++ project that presently needs an Athlon 1800+ to run with alpha blending on.