OpenGL framebuffer library

[Stonemonkey]

1) unsigned int is the correct type for pixels (shifting is ill-defined for signed values - who knew that eh?)
oops, I should've.

2) the type cast can hide errors
cheers Jim, hadn't thought of it that way.

3) by using sizeof *buffer instead of sizeof(int) you remove one more place that you might need to change the code.
Hadn't thought of that either.

Code: [Select]

unsigned int *buffer = new unsigned int [RES_X*RES_Y];
Looks better but is there any difference in how it allocates the memory?


There's sometimes different formats used but tinyptc uses this (although I'm not sure if some different graphics cards need it in a different format):

Code: [Select]


return (alpha<<24)|(red<<16)|(green<<8)|blue;



[Phoenix]

I solved it This is how it's done:

Code: [Select]

//-----------------------------------------------------------------------------------------------------------------
//
//-----------------------------------------------------------------------------------------------------------------
int __cdecl ptc_torgb(unsigned char red, unsigned char green, unsigned char blue)
{
return 0xFFFFFFFFFF000000|(((red<<8)+green)<<8)+blue;
}

However, I have no idea how it works I was testing in the windows calculator converting various ARGB values into hex, and lots of F:s appeared in front of the colors.

[Stonemonkey]

If your ints are 32 bit then the first 8 Fs shouldn't make any difference, as for the rest of it, in this case using + (add) is the same as using | (or) because each of the 8 bit colour values don't overlap and both ways have the effect of writing the 8 bit value into the appropriate 8 bits of the result, and the red bits are shifted by 8 bits twice which is the same as shifting by 16 bits.

It used to be the case that OR was faster than ADD but I don't think it makes any difference any more.

[Phoenix]

You're right It can be shortened to:

Code: [Select]

return 0xFF+(((red<<8)+green)<<8)+blue;

[Stonemonkey]

IF you want to set the alpha bits, it should be

0xff000000

[Jim]

Code: [Select]

unsigned int *buffer = new unsigned int [RES_X*RES_Y];
Looks better but is there any difference in how it allocates the memory?

Yes, you can overload the 'new' and 'new []' operators in C++ so it calls something else.  It can also throw exceptions on failure.
The actual memory still comes form the same place though, but you mustn't mix malloc/free with new/delete.
In this case you'd want

Code: [Select]

delete [] buffer;

Jim

[ninogenio]

jim can the above be done in these conditions in cpp.

typedef struct {
       
          float x;
          float y;
          float z;
}vertex;

typedef struct {
           
           vertex * myvertex;
           blah ..
           blah ..
} entity

entity * myentity;

myentity = new entity;
myentity->myvertex = new vertex[10] ;

delete [] myenetity->myvertex ;
delete [] myentity ;

[Jim]

The last line should just be

Code: [Select]

delete myentity;
It's not an array so you don't need the []

Jim

[ninogenio]

ah cool so it can be used in exactly the same way as malloc and free cheers!

[Allosentient]

Whatever the DirectX speed is, OpenGl will come out pretty much the same.  Somehow you have to hammer 640x480x4x60 bytes per second up to the gfx card.  That's around 80Mb/s, which is a lot.

Jim

I know this is an old post, but wanted to contribute.  I noticed that DrawPixels was mentioned right before this post.  The goal of using the graphics card is to have the graphics card procedurally create the pixels you are talking about here.  You are not sending 80 mb/sec to the graphics card, you are sending a set of instructions for the graphics card to process on the side.  This is why the use of DrawPixels isn't really recommended for the entire screen.

I am not an expert here by any means so please correct me if I am wrong!

[stormbringer]

I also noticed that a lot of OpenGL framebuffer libs here use DrawPixels. This has been marked as deprecated in OpenGL 3.0 (and potentially removed in a few years). It's a very old method of updating stuff in the OpenGL frame buffer and has been left out of hardware acceleration by most drivers (especially on laptops and small systems). For future proof, hardware accelerated bitmap transfers, you should always create textures with glTexImage1D/2D/3D and update the texture buffer with glTexSubImage1D/2D/3D.

Textures can then be used in shaders, can be used for texturing primitives and benefit from the latest OpenGL extensions and of course hardware acceleration.

[benny!]

@Stormbringer:
Thanks for pointing that out!

[hellfire]

you should always create textures with glTexImage1D/2D/3D and update the texture buffer with glTexSubImage1D/2D/3D.

That's essentially what I was doing here, but unluckily support for non-power-of-two textures isn't quite were I expected it to be.
So for a 640x480 image you upload 1024x512 which leads the concept ad absurdum...

[Clyde]

How is this going?

[Rbz]

Status = Closed.

We stopped working on it after having incompatibilities (slow down) on some PC config, and then tinyptc_ext born.

[hellfire]

Another option is to use Direct3D instead as most modern chipsets aim to be compatible with Windows Vista (requiring to support per-pixel floating-point processing) but still fail to read a texel from an arbitrary sized texture using OpenGL.