Qbasicnews.com
November 21, 2018, 02:46:51 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Alpha sprites  (Read 10943 times)
lillo
Guru
**
Posts: 269


WWW
« on: May 13, 2005, 07:05:36 PM »

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  Cool The little disadvantage (!) is your EXEs will be 2-3 Kb larger than before when using PUT...
Logged

ngelo Mottola - EC++
Z!re
*/-\*
*****
Posts: 4599


« Reply #1 on: May 13, 2005, 07:14:37 PM »

Nice..


Now add some hardware accelleration, and we'll have a really powerful lib to play with (not that it isnt already) Cheesy
Logged
Jofers
Been there, done that
*****
Posts: 1040



WWW
« Reply #2 on: May 13, 2005, 09:14:54 PM »

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 Smiley  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.
Logged
gunder
Member
*
Posts: 63



« Reply #3 on: May 14, 2005, 02:22:13 AM »

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

gunder
"I have a perfect body, but it's in the trunk and starting to smell."
barok
Na_th_an
*****
Posts: 1727


How about a tasty lead sandwich?


« Reply #4 on: May 14, 2005, 03:00:12 AM »

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

Jumping Jahoolipers!
lillo
Guru
**
Posts: 269


WWW
« Reply #5 on: May 14, 2005, 05:16:57 AM »

Thanks people Smiley

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

ngelo Mottola - EC++
lillo
Guru
**
Posts: 269


WWW
« Reply #6 on: May 14, 2005, 07:36:40 AM »

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

ngelo Mottola - EC++
Neo
Na_th_an
*****
Posts: 2150



« Reply #7 on: May 14, 2005, 08:12:11 AM »

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.
Logged
SotSvart
Member
*
Posts: 61



WWW
« Reply #8 on: May 14, 2005, 09:18:23 AM »

Very nize!  Cheesy  Keep up the great work!
Logged
lillo
Guru
**
Posts: 269


WWW
« Reply #9 on: May 14, 2005, 12:23:29 PM »

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

ngelo Mottola - EC++
Jofers
Been there, done that
*****
Posts: 1040



WWW
« Reply #10 on: May 14, 2005, 12:30:17 PM »

Shocked - 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.
Logged
lillo
Guru
**
Posts: 269


WWW
« Reply #11 on: May 14, 2005, 12:35:22 PM »

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

ngelo Mottola - EC++
Jofers
Been there, done that
*****
Posts: 1040



WWW
« Reply #12 on: May 14, 2005, 05:56:17 PM »

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.
Logged
v3cz0r
I hold this place together
*****
Posts: 924



WWW
« Reply #13 on: May 16, 2005, 03:16:08 AM »

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 ;)
Logged

Jofers
Been there, done that
*****
Posts: 1040



WWW
« Reply #14 on: May 16, 2005, 09:32:03 AM »

True dat Smiley

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.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!