Choose OpenGL (texture) format API ?

Hello,

I just saw something interesting on the Java side of opengl things ?

It had something with "capabilities" in it's now and "choose capabilities".

Might be a nice idea for opengl to get out of the "format mess" !

I am good programmer believe me I can program whatever I want the way I want
it... not sure if it will be usefull for gpgpi programming but maybe...

I can imagine the following:

1. 8 bit fields for 8 bit fields
2. 16 bit fields for 16 bit fields
3. 32 bit fields for 32 bit fields.

So to say it simply: I could split up my data into multiple textures.

Some textures would be 8 bit, some would be 16 bit some would be 32 bit.

They could even be 3 bit or 6 bit or whatever... if that makes the graphics
card happy/faster than so be it ! I'll be happy too ! As long as it gives
me more speed !

Mixing textures might not be possible ? Mixing fields might not be possible
? Could be an interesting option for the future ?

Maybe future hardware can support it so I can write something like the
following code which is supplied to the gpu:

"Texture format per element":
Fields
Fields
Fields
Fields
end;

So for example:
Texture element format:
mID : 3 bits;
mILikeYou : 4 bits;
mINEEEDTHIS : 8 bits;
end

Then the texture would be:

Texture[Height][Width] of Texture element.

Would be cool if the hardware could handle flexible textures like that...

For now I will assume this is a pipe dream and will not be possible

For now I am not sure if using multiple textures is a good idea might not
be...

The maximum I probably need is 16 bits...

So for now I would be content with 16 bit textures... however or **** it I
say...

I ll keep it short here is the **** load/down:

ChooseOpenGLFormat
ChooseOpenGLTextureFormat
ChooseOpenGLTextureInternalFormat

Whatever !

Bye,
Skybuck.

Actually I am not sure what ammount of bits I need... euhm let me rephrase
that...

I do know what ammount of bits I need...

But I don't know how many bits will be available inside the floating point
16 bit format...

Some bits will be integer some bits will be fraction...

I need full 16 bits for integer...

So I guess 16 bits too little ?

So I might need 32 bits after all ?!?

For now I will take it on the safe side... and maybe go 32 bits ?!?

But then again it's kinda weird... because the pixel operations will perform
32 bit floating point on RGBA values ?!?

Which are just 8 bits inside my own code ?! Kinda strange...

Most definetly... maybe I would have to alter my texture as well to for
example 32 bits as well... that could solve some issue's...

Then I can pretend the shaders work on 32 bit floating point units and
actually the problably do that...

It's kinda strange for me as a programmer to think in R,G,B,A as being all
32 bits ?! So that's 4x32 bits is 128 bits ?!

Normally an R is 8 bits... but now 32 bits ?! HOLYSHIT BATMAN !

It will be interesting to find out if I can really work with 32 bits per
color component ?!?

Bye for now,
Skybuck.

Ok,

The last part is becoming clear to me as well:

"
format

Specifies the format of the pixel data. The following symbolic values are
accepted: GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB,
GL_BGR, GL_RGBA, GL_BGRA, GL_LUMINANCE, and GL_LUMINANCE_ALPHA.

type
Specifies the data type of the pixel data. The following symbolic values are
accepted: GL_UNSIGNED_BYTE, GL_BYTE, GL_BITMAP, GL_UNSIGNED_SHORT, GL_SHORT,
GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_UNSIGNED_BYTE_3_3_2,
GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5,
GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4,
GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1,
GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8,
GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, and
GL_UNSIGNED_INT_2_10_10_10_REV.
"

A simple example would have made this immediatly clear to me... or some
concept code... I already suspected it was working like this but now I am
pretty sure:

I'll try to explain in my own words:

The (pixel) format specifies what color components follow and in what order.

The (pixel) type specifies what the type is of each color component.

Maybe "color component" is a better term to use for the future ?!

But then again it's a bit more lengthy isn't it ?!

Anyway here is a conceptual example of the situation:

mPixel :TPixelFormat : TPixelType;

or better put:

mPixel : begin
mRed : float;
mGreen : float;
mBlue : float;
mAlpha : float;
end;

The floats are the pixel type
and the pixel structure itself is the format.

At least that's what I know believe ?!

So sometimes explaining by example is an easier way to explain things !

Bye,
Skybuck.

On Sep 29, 8:51*am, "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
>
> I am good programmer believe me...
>

No, good programmers know how to read documentation
and find all this stuff.


--
<\___/>
/ O O \
\_____/ FTB.

http://www.topaz3d.com/ - New 3D editor for real time simulation

> No, good programmers know how to read documentation
> and find all this stuff.

You suck you stupid ****.

OpenGL documentation is incomplete HAHA

And that's even an under statement !

Bye,
Skybuck

"Skybuck Flying" <> wrote in message
news:63585$4ac2344a$d53372a9$ b.home.nl...
>> No, good programmers know how to read documentation
>> and find all this stuff.
>
> You suck you stupid ****.
>
> OpenGL documentation is incomplete HAHA
>
> And that's even an under statement !
>
> Bye,
> Skybuck

Complaint sent to:



--
Charles E Hardwidge

Skybuck Flying wrote:

> You suck you stupid ****.

Seeing someone accusing fungus of being a "stupid ****", specially in a post to c.g.a.opengl, is one of the
daftest things I've ever seen.

Well, it's practically still September.


Rui Maciel