Need info on alpha buffering!

Hiya folks,

Ive been working away at my game since (feels like) the beginning of time lol. Now its come to the point where Im a bit stuck as to which direction to take, and I was hoping some of the 'programming gods' round here can advise which way to go!

The probem is, that my game is coded in BB2D, and is fairly uptogether. However, I use triplebuffering to increase the screen draw, as I have 2 'layers' of screen blocks, (fore and background blocks): The background is for all normal blocks, and the foreground is for alpha water blocks.

This is where the problem is: Alpha block draw speed.

I have tried the early redirecting bank to imagebuffer hacks that Tom posted years ago, but this technique seems to be broke in the last update, plus Im not sure it will work very well in Vista, which seems to have more security when a program is fiddling about with unauthorised memory space.

I have also toyed with the great Extended Blitz DLL by Patrick Lester, but have lots of language keywords in my code that have not been coded into that DLL.

I have looked at Blitzmax, and from what I can tell so far, theres only a single backbuffer. My code is optimised to only have to draw the background blocks once per screen into an imagebuffer, then draw the rest 'over' that in the backbuffer.Looks like in Bmax I will have to redraw background every frame plus I will also have to draw the foreground over that aswell, which may slow things down alot. (Although, it seems I get fast alpha!).

Been trying all sorts of ideas (even including targa images with alpha extracted), but there seems to be no working fast alpha technique!

Sorry about the long post. Any help would be much appreciated! Thanks

You an do the equivalent in BlitzMax -- there's code knocking around for blitting pixmaps onto each other (see the myPixmap.Paste() method) or you could just construct the scene on the backbuffer initially then grab it into an image.

I'd forget about getting alpha with B2D, TBH.

No. First of all the performance difference between drawing the background every frame, and every other frame, doesn't exist in BlitzMAX. All that matters is the cards fill rate, and the built-in alpha blending will give you such a performance boost, it's not even funny.

BlitzMAX is the way to go on this one.

I say convert it to BlitzMax, even though you have to redraw the whole screen it will be hardware accelerated and I bet it can handle whatever your BB2D version is doing graphically.

Thanks for the replies guys.

Im more worried about the speed drop of drawing 2 layers of blocks (back and foreground) than the once per screen block write optimisation, which slows things down, but not as much as the 2 layers code does. I should have emphasised that more.

Also, wasnt sure if Direct Draw (with BB2D DX7) was actually faster than DX8> DD Emulation.

@big10p: Starting to look that way!

@Mikkel: I havent dealt with 3D (DX or OGL), so was unsure if Blitzmax could read and write to the screen fast enough to give me 2 layers of blocks BEFORE I even think of transparency.

I realize that. It doesn't really read or write to the screen, in the sense that you're accustomed to. Depending on your target hardware and screen resolution tho', performance is not a problem. You can have an absolutely CRAZY amount of graphics (blended or otherwise) on the screen in BlitzMAX before noticing any significant slowdown. And this was on my POS TabletPC. I seriously doubt you'll run into any problems, but of course without knowing for sure what you intend to do, it's hard to be certain.

"Also, wasnt sure if Direct Draw (with BB2D DX7) was actually faster than DX8> DD Emulation."

Depends on the GPU. Some older cards will render Direct Draw 7 sprites faster than newer cards. On my system, direct draw 7 general sprites are much faster than "2d using 3d hardware" sprites. But...

Let's face it, it's 2008. Enjoy alpha blending, additive blending, scaling, rotation, etc, all in hardware. Sure you'll take a slight hit compared to generic direct draw sprites, but the programming advantages are worth it. Plus if you're using some kind of "fixed frame rate, render as often as possible" logic, it won't matter if your game misses a vsync once in a while. This is pretty much how all the popular pc games work now days.

Ive had a good look at this situation, and Ive come to a decision.
Ive taken onboard all the comments, and appreciate that the way to go would be with Bmax. The problem here is that I have most of the game completed now in B2D. Pros and cons of moving to Bmx for me are:

Pros:

1.Cleaner OOP/OOD programming/Design model
2.As much 'alpha time' as I need! (Apparently)
3.Modern cross platform/OS compatibility

Cons:

1.Game would need pretty major rewrite to become OOP
2.Im a hardcore procedural guy.OOP is a bit beyond my scope (lol) ATM.

Ive actually found a solution to the alpha problem, so reasons for the big upheval are much lessened for me, and to be honest, I would much rather have a well implemented procedural code build than a half baked OOP one, as essentially I would be still learning the different design philosophy which object orientation requires.
As well as the complete halt in game progress as I try to get my head round a good system of design.
Again, I appreciate the comments, but I think its a bit too late to change languages on this one. :)

Re: Blitzmax OOP

You don't have to use OOP at all in Blitzmax if you don't want to. The OO stuff has nothing to do with graphics. Procedure (function) based with arrays are commonly used and some Blitzmax coders swear it's faster than using OOP solutions. When I first learned Bmax I didn't use any OOP functions at all. Now I'm re-writing pretty much everything in a OOP fashion to make the move to C++ easier. ;)

I did have a look at the 'convert bb' option (or whatever it was called) in bmax.Did that, but it was far from a complete option. Even without OOP practices I would still have to learn not only the new language, but any 'nuances' that crop up.(Ive got to know them in bb).
I realise the graphics have nothing to do with the OO programming concept, but that seems to be the way everyone is going nowadays. My code is very tight knit with modular functions and arrays. To sacrifice this efficiency and code with what would be a far slacker alternative (as I dont know the language well), would not be the best option.
And I will be honest with you. I started learning BASIC programming on the c-64 in about 1983 and quickly went onto assembly language. Years later, I went to college to learn C++ but couldnt get my head round it.
It wasnt the language as such that was the real problem, but the way I found it to be too 'abstract' and overcomplicated for the end result, which I could produce to a very efficient degree in proc. languages with just modularisation and good array design.
Im not saying OO is not effective, just that its too far removed from whats happening in the CPU for me at this present time, and Im very much in my 'comfort zone' coding this way.