RabidHaMsTeR.Org

Long story short, I'm assembling approximately 512 'flying bits' on-screen from 5 distinct pieces each. Needless to say, with a GL scene, this is rather slow.

So, I started re-engineering it to use the bufsave and bufload features to render the individual 'flying bits' only when they change, storing them all to a buffer that's stored between frames. More-or-less rendering all the flying bits once, then using those pre-rendered pieces (which only change every 1-3 seconds) to render the actual flurry with one quad each.

The technique works, and was a very dramatic speedup, but I've just about torn my head out trying to puzzle out the gl.this-and-that to determine how to make a fixed rectangle or square 'fill' the viewpoint that's rendered to. If it was actual raw OpenGL, I'd just assign a fixed view matrix I could calculate off-line, but I don't see a way to set the view matrix directly, only various perspective, ortho, and other indirect viewpoint-setting tools, none of which document their defaults anywhere that I can see, which is making it a stone-cold pain in the ass to puzzle out.

So... any help?

I'm sorry but I didn't understand what exactly you are trying to do. Could you describe more accurately?

What do you mean with filling viewpoint that's rendered to? I'm a bit unfamiliar with the 3d graphics vocabulary.
Do you have four vertices specifying a rectangle and you want it to fill the screen?

512 * 5 flying bits sounds great, please share the scene when you get it working!

Yes, I want a small, compact set of commands that will make the four corners of the screen be four specific vertice values. Any vertices will work, so long as they're something exact (like 3, not 3.12356 or some-such), I just thought someone else might have figured this out already before me.

And when I'm done, sure, I'll post the scene and single texture it runs from. I'm probably not doing things the 'normal' way for R4, but I'm mostly approaching it like I do any other OpenGL programming task.

Not still 100% sure what you mean, but here we go

First, translate so that you get the desired screen coordinates:
gl.glTranslate(0,0, -2.414)
gives x,y = [-1,1]
(or gl.glTranslate(-0.5, -0.5, -2.414 * 0.5) gives x,y = [0,1])
The magic number -2.414 comes from 1/ tan( pi/8 ).

Now, the screen corners are specified simply by the coordinate system at distance 0:
(-1,-1,0)
(1,-1,0)
(1,1,0)
(-1,1,0)
If you want the x coordinates to be corrected for aspect ratio, let the gl.aspect be 1 (default). This will result in a rectagular coordinate system.

If you want the texture to be stretched to the whole screen horizontally, set gl.aspect = 0.

Did this help help you out?

Yes, that helped. I'm used to dealing with the view-matrix directly as, well, a raw 4x4 matrix of transformation values for the XYZ<->Screen coordinates.

And now to sort out actually using the looped-buffer texture for the actual flying-bits part...

I found keeping the alpha channel caused me some strange problems - this may have changed now I have stuff mostly sorted so I'll try and have a look.

As for multiple buffers, nothing stops you from using as many as you want - and you can even swap the buffer handles around between them on the fly.

Unfortunately OpenGL is broken on my PC at the moment (I installed ATI's new drivers to stop something else dying ) so i can't take a look just yet.

Tried the Omega ATi drivers?

Look up the BlendFuncSeperate() function call. This will allow you to control the alpha-channel blending function assigned seperately from the normal blending function.

Generally, GL_ONE,dstBlendMode works quite well when rendering billboard textures.

I.E.1: If the script assigns GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA, the alpha channel would have GL_ONE,GL_ONE_MINUS_SRC_ALPHA.
I.E.2: If the script assigns GL_ONE,GL_ZERO, the alpha channel would have GL_ONE,GL_ZERO.

Oh, and a quick note as to why the slightly-modified blending mode for Alpha rendering...

When you're layering alpha-masked textures to render a billboard, handling layered alpha values can get complicated, when you have to maintain a usable alpha value for the final texture.

If you apply the same blending mode to the alpha channel as to the rest of the image, you end up 'washing out' the alpha channel, resulting in a badly-transparent final render. This is because the alpha channel doesn't contribute enough to the actual final buffer, because when you multiply an alpha channel by itself, you're guaranteed to reduce the final value by comparison, for the same reason that the square of a number greater than 0 and less than 1 will always be reduced. So, that dictates GL_ONE for the first half.

Re-using the normal 'final' blending mode will work in the most common cases (GL_ONE,GL_ZERO, and GL_ONE,GL_ONE_MINUS_SRC_ALPHA) though they can break down in odder cases (like GL_ONE_MINUS_SRC_COLOR) because the blending mode doesn't have a very appropriate analogy.