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?

allegro has trans blender functions.

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

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

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

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.

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

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.

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.

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.

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.

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.