OpenGL framebuffer library

[relsoft]

I have a similar approach done to my game render. You might wanna check this out.

Using FBGFX to draw to a buffer and blit to screen using GL or sofware.

[TinDragon]

After seeing this I have a feeling I might be able to setup this kind of framebuffer system in bmax since I have full access to the opengl commands. If it's as simple as it appears from looking at the C code then it will enable some of us bmax users to convert alot of tinyptc code over, if I get stuck I will come asking for help 

[Shockwave]

Ok. Heres a question about this for Rbraz and Jim.. I am one of the people who love this lib. What version is the most up to date and stable please?
I want to make sure I use the latest version in my next demo.
Also I'd like to put together some tutorials at some stage in the near future
Thanks.

[Rbz]

You can use that one attached to my first post, you can call it by tiny version, or you can use that last one that Jim have been attached, and you can call it by an extra version.

I hope Jim agree with me 

[Shockwave]

Mmmm. Both have their merits Thanks Rbraz.

[Dr_D]

Here's something that might help. I wrote it as an extension for YAGL. It's relies on extensions, so it might not be suitable for this project. I just thought I'd post it anyway because it might be of use.


EDIT: Errr... sorry. I didn't realize I was posting in the C/C++ forum.

[Shockwave]

No problem, have some Karma for it anyway

[stormbringer]

You could use glTexSubImage2D to load the screen data into a next-power-of-2 sized texture you'd previously created.  So you could make a 1024x512 texture for a 640x480 screen.  Then after that you'd have to render a single GL_QUAD to draw the texture to the screen.  That would definitely work.  glDrawPixels moves the image directly to the screen, so you'd think it would be quicker since it involves one less copy of the data.  Lots of glDrawPixels calls are very, very slow on my PC, but doing just one is fast.  I will definitely check this option later on but tbh, it's blazingly quick anyway.  It would certainly make it possible to do all kinds of feedback/motion blur tricks if you could use the last screen output as a texture in a new scene, which would be very cool.

That leads me to another question.  I know dbf is strongly focussed on doing everything in software.  I like that .  Depending on how much gets added to this lib all kinds of things could be accelerated by OpenGL.  Is that what is wanted from this lib, or just a few special fx?  Perhaps that will require two versions.  A tiny <10Kb lib that does the basic stuff, and a bigger one with all the bells and whistles.  Any comments?

Jim

what Jim said is completly true => avoid glDrawPixels() as much as you can => use glTexSubImage2D() instead with either the next power of 2 sized texture or a rectangular texture (if you use NVidia or ATI extensions)

also make sure the internal format of the texture is the same as your buffer in memory (i.e. same color mode, same bitdepth and avoid RGB to RGBA buffers or vice-versa or similar as it goes through conversions usually done at the driver level, most of the time in software )

[stormbringer]

1: a screendim command.
as this is using opengl now, how about using a blank sprite as a means of dimming the screen?

Here's an example of what I mean.  OpenGL allows an offset and a scale to the colours that are uploaded by glDrawPixels or glTex.
At the top of your program add

Code: [Select]

#include "gl/gl.bi"Then, before ptc_update() do this

Code: [Select]

glPixelTransferf(GL_RED_SCALE, 0.9)
glPixelTransferf(GL_GREEN_SCALE, 0.5)
glPixelTransferf(GL_BLUE_SCALE, 0.1)

The number is the scale amount for red, green and blue, ranging from 0.0 to 1.0.  Numbers over 1.0 clamp to 1.0 for some other odd fx.  Lots more info here

Jim

I would not recommend this technique... it's very slow on some drivers.... render to textures and set the texture mode to modulate, set the color and then render quads or triangles (fastest) => much much faster!

glPixelTransferXXX() functions are legacy! new drivers are optimized for shaders that replace this much more efficiently. In some cases, shaders are not necessary and most effects can be achieved through other tricks...

[Jim]

->Stormbringer.  I agree with everything you say.  My only argument against using shaders or other advanced features directly in this lib is that it is meant to run on everything from the oldest card to the latest $1000 monsters from ATI and nVidia.  If people want more fx, then the best thing is they break away from this lib and learn, with our help, to code their own startup and render routines.

Jim

[stormbringer]

@Jim: you do not need shaders for everything.... glPixelTransfer can be less efficient than in memory lookup tables sometimes... and for the screen dimming, a texture with modulated color is much faster, as long as you draw into a texture. You do not need extensions for that, just draw in the opengl buffer and copy to the texture (sort of virtual screen), then draw a textured quad, etc.

[Jim]

I know, that was just an example of something that might have been added to a deluxe version of DBF PTC.  We never actually did anything with it
Jim

[Phoenix]

Code: [Select]

int* buffer = malloc(RES_X*RES_Y);
memset(buffer, 0, RES_X*RES_Y);

ptc_update(buffer);

Isn't that how it's supposed to be done? I get an unhandled exception when I try to run it.

[Stonemonkey]

Possibly something like:

Code: [Select]

int* buffer = (int*)malloc(RES_X*RES_Y*sizeof(int));
memset(buffer, 0, RES_X*RES_Y*sizeof(int));

ptc_update(buffer);


[Jim]

Right, the problem was that you need to allocate an 'int' for each pixel.  The crash is in PTC trying to read too much data from your array.

If you're coding in C, you're much better off leaving off the type casts.
So I'd write it

Code: [Select]

unsigned int *buffer = malloc(RES_X*RES_Y* sizeof *buffer);
memset(buffer, 0, RES_X*RES_Y*sizeof *buffer);
ptc_update(buffer);
Many reasons for that
1) unsigned int is the correct type for pixels (shifting is ill-defined for signed values - who knew that eh?)
2) the type cast can hide errors
3) by using sizeof *buffer instead of sizeof(int) you remove one more place that you might need to change the code.

In C++, you need to write it like Stonemonkey says, the type casts are essential, but then in C++, you'd probably want to use

Code: [Select]

unsigned int *buffer = new unsigned int [RES_X*RES_Y];

Jim

[Phoenix]

Thanks Jim, that works great

[Jim]

Great to hear!  Are you making a demo?

Jim

[Phoenix]

I don't know what I'm making actually I'm just trying out the library. Perhaps it will become a demo

[Phoenix]

I tried to write a function that converts RGB to a single value, but with no luck:

Code: [Select]

// BGRA
return (blue<<24)|(green<<16)|(red<<8)|0xFF;
What's wrong here? I think there should be a torgb() function included in the lib.

[Shockwave]

It should be easy enough to define something to convert 3 values to rgb.

Use this sort of maths to do it;

Code: [Select]

PIXEL=(((RED SHL 8)+GREEN)  SHL 8)+BLUE