transparency and scaling
Kevin Epps

I could've sworn that I remember seeing this explained in a thread somewhere, but I can't think of the search word combo I used to get it when I was looking for something not even related to this. Of course. Does anyone know of any efficient ways to add transparency (or translucency, late night) and scaling to a sprite WITHOUT using OpenGL?

A J

allegro has trans blender functions.

else make your own.
i've written very effecient SSE2 blenders.

anto80

As far as I know, with allegro, you can either use rotate_sprite() or draw_trans_sprite() combined with set_trans_blender().
But you cannot display a transluent rotated sprite directly.
One solution is to prerender rotated sprites and keep them in memory as BITMAP*s and then use draw_trans_sprite().

Neil Walker

flbend has a faster transparency function, as far as scaling it does fast double scaling. But there's nothing stopping you mixing the two (scale using allegro then add transparency with fblend).

Kevin Epps

I agree that Fblend tends to work faster. But is there a way to scale it first, then fblend_trans without using clear_to_color?

I would assume you would have to do something like this:

BITMAP *sprite = load_bitmap(whatever);
BITMAP *sprite_buffer = create_bitmap(SCREEN_W, SCREEN_H);

//Drawing Loop
clear_to_color(sprite_buffer,255,0,255);
rotate_scaled_sprite(sprite_buffer, sprite, 0, 0, 0, ftofix(scale));
fblend_trans(screen, sprite_buffer, 0, 0, trans_value);

Am I wrong? Is there a more efficient way than that? I would MUCH rather not use the clear_to_color function inside the game loop because it slows down the FPS on older machine (PII, PIII) by 12 FPS.

Neil Walker

well, you'd be fblending your sprites to the backbuffer before the screen and just doing one blit to the screen, for starters.

Kevin Epps

Oh well, yeah, I know about double buffering, etc. My main point of that post was to focus more on the calls to scale and trans the sprite than anything else. I didn't think that me putting "screen" vs "buffer" would make a difference in my post, since it's for hypothetical purposes only.

Neil Walker

ok. but surely a clear_to_colour() can't be a bottleneck as it's just chucking a wad of data to a memory area.

Kevin Epps

BELIEVE ME. It makes a difference. On older computers anyway. My newer computers aren't affected by it. I'm thinking of just clearing the sprite buffer before I even start the loop, I'll let you know how it works out.

Sirocco
Quote:

ok. but surely a clear_to_colour() can't be a bottleneck as it's just chucking a wad of data to a memory area.

Nothing's free :) Regardless, the clear and clear_to_color functions have an impact on performance depending on how often they are called, especially on older hardware, and for the sake of performance you don't want to call them when you don't have to.

Seriously, you wouldn't think it'd make much of a difference, but if you're operating on a ton of sprites and calling the routine a couple hundred times a frame you'll see a significant improvement by eliminating it.

Kevin Epps

Alright, I have it handled. Since the sprite is actually getting larger in size, there's no need to clear_to_color inside the loop and it works perfectly.

Thread #586629. Printed from Allegro.cc