PDA

View Full Version : Return RGB value up to 127 as byte



waldoo
03-09-2002, 12:47 AM
I am only able to get up to 127 return RGB value from glReadPixel. Do you know whats wrong with it?

Waldoo

Bob
03-09-2002, 02:14 AM
Are you getting the value as a GL_BYTE? That is a singed byte, and the range is [-128, 127]. Try get it as GL_UNSIGNED_BYTE, which has the range [0, 255].

Bob
03-09-2002, 02:17 AM
Oh, and also make sure you explicitly declare the storage variable (where you want OpenGL to store the result) as an unsigned char, to avoid some potential sources of trouble.

waldoo
03-09-2002, 09:46 AM
I have trouble trying to get unsigned byte from glReadPixel RGB return value because VB only give me limited options which is pxlBitmap, pxlByte, pxlFlost, pxlLong, and pxlShort. These options was given inside glReadPixel. I only get up to 127 from pxlByte. Is there a way around it?

I am able to declare variable as glubyte it is gl unsigned byte. But the problem is that glReadPixel's limited output is glbyte and these options.

Waldoo

zed
03-09-2002, 10:13 AM
add 127 or 128 to the result thus going from -127-128 -> 0-255

waldoo
03-09-2002, 12:24 PM
the problem is that byte output is only positive value.

Waldoo

waldoo
03-09-2002, 01:22 PM
I think I need to make new data type for it. If you know please post it here

richardve
03-09-2002, 04:19 PM
- Why did you create a new topic with almost the same question?
- Why are you using Visual Basic? (it doesn't even support unsigned types??)
- What's a "slur"?

waldoo
03-09-2002, 04:50 PM
glReadPixel does not have unsigned byte option in VB. That is why I made a new topic asking people for some help to make new data type for it.

Slur is like vulgar. Some people who didnt understand they posted offensive msg in my other topic. I am trying to make opengl to fully compatible with VB just like opengl in VC++. I think the only problem VB had with opengl is the byte type. Other than byte, everything worked fine in VB with opengl script including alpha.

Waldoo

zeckensack
03-09-2002, 05:06 PM
It doesn't matter. OpenGL does never write to data types, it writes to memory. There's no automatic clamping going on just because you use that ugly language. If you want to move large blocks around, just disregard VB's idiocy. If you need to compare single values, read up on two's complements for creating the equivalent signed value. Or just have OpenGL write a to the low order byte of a 16bit integer type.

*juvenile comment on forum behaviour withdrawn*

[This message has been edited by zeckensack (edited 03-10-2002).]

waldoo
03-09-2002, 06:05 PM
Zen,

it was my topic for others who want to share. If you dont like it thats fine you dont need to post your slur msg here, it is for those who want to help to find the solution. I am still studying to make new data type for VB to take in large block of byte.

Waldoo

zed
03-10-2002, 08:00 AM
didnt i already reply to this?
-128,127 -> 0,255 = +128

Korval
03-10-2002, 11:22 AM
didnt i already reply to this?

Yes, but you seemed to have missed Waldoo's reply:


the problem is that byte output is only positive value.


BTW, Zeck, there's no need to qualify all your statements about VB with things like "that ugly language" or "idiocy". If you don't like the langauge, fine, but there is no need to attack what Waldoo is doing by attacking the language he is using. You've made your point; we know what you think of VB already.

zeckensack
03-10-2002, 06:45 PM
Excellent, but I also offered what I consider a serious approach to the problem. To repeat myself:
For large blocks, ignore language specifics.
For single pixel comparisons, ignore language specifics, if 140==140, the signed byte comparison will yield the same results.
For getting a true unsigned value, have gl write it to the low order half of a 16bit integer instead of an 8bit integer.

BTW, Korval, maybe this sounds better to you:
A language without unsigned types imposes an unacceptable restriction upon its users. This is especially painful when it comes to manipulation of pixel data. Despite your best efforts, you might want to consider a different programming language for these tasks.

[This message has been edited by zeckensack (edited 03-10-2002).]