How to get $FFFFFF type of value from ReadPixel() command

[Bugala]

Heres the problem. (longer version)

Im making this Point n click type of game.

System is, that i have two different pictures. One is the picture shown to player (picture-1), another is the picture not shown to player (picture-2) that shows the Areas that mouse is supposed to react at when pointer moves over.

It works so, that it reads the value of MouseX and MouseY and then uses ReadPixel(x,y) command on Picture 2 to see what color there is.

If its white ($FFFFF) then nothing happens, if its any other color, then it might display text like "Look at Trees".


Problem is this (short version)

When i use ReadPixel(x,y) it doesnt give me $FFFFFF type of answer, but rather gives me number like 16777654.

1. So first of all, how do i get ReadPixel to give me $FFFFFF type of value, instead of numerical value?


Secondly, Hollywoods manual mentions that it will give different answers depending wether screen mode is on 16. 24 or 32-bit mode.

This is unacceptable. I need a way that it returns same $FFFFFF type of value no matter what bit screen you are using.

2. How do i get ReadPixel to give me same answer no matter how many Bit screen player is using?

[jalih]

When i use ReadPixel(x,y) it doesnt give me $FFFFFF type of answer, but rather gives me number like 16777654.

1. So first of all, how do i get ReadPixel to give me $FFFFFF type of value, instead of numerical value?

Secondly, Hollywoods manual mentions that it will give different answers depending wether screen mode is on 16. 24 or 32-bit mode.

This is unacceptable. I need a way that it returns same $FFFFFF type of value no matter what bit screen you are using.

2. How do i get ReadPixel to give me same answer no matter how many Bit screen player is using?

1. Why do you need the return value of ReadPixel() in hexadecimal format? You can use hexadecimal format when comparing variables anyway.

2. Not possible, but you can use GetRealColor() as a helper function.

[Bugala]

I tried thta GetRealColor() function too, but it didint help me much. It still gave me numbers.

I am just trying to have some system that returns same value no matter if its 16-bit, 24-bit or 32-bit screen.

When using this ReadPixel and even with GetRealColor() - function (which i didnt quite get what it actually does or helps from manual) if i have 16-bit screen, value for White is 65 557 or something like that. When i use 32-bit screen, value is something like 16 777 753, tose are clearly not vey comparable.

What I am hoping to achieve by using hexadecimal value is that I am hoping that be it 16-bit sccreen or 32-bit screen, i hope the hexadecimal value would return $ffffff in both cases if its maximum white.

So any hlep here?

You mentioned something about being able to compare them to hexadecimal values anyway. How does this happen?

I suppose you mean that i can take that value of 65 557 or 16 777 753and when i compare them to hexadecimal they both return $ffffff, right?

And how?

[jalih]

System is, that i have two different pictures. One is the picture shown to player (picture-1), another is the picture not shown to player (picture-2) that shows the Areas that mouse is supposed to react at when pointer moves over.

It works so, that it reads the value of MouseX and MouseY and then uses ReadPixel(x,y) command on Picture 2 to see what color there is.

If its white ($FFFFF) then nothing happens, if its any other color, then it might display text like "Look at Trees".

I think that if you use brush with 32-bit image as an output device instead of screen by using SelectBrush(), you always get the same result from the call to ReadPixel() despite of the screen mode?

So, just use 32-bit collision map.

[airsoftsoftwair]

I think that if you use brush with 32-bit image as an output device instead of screen by using SelectBrush(), you always get the same result from the call to ReadPixel() despite of the screen mode?

Only on Mac & Windows. Hollywood on Mac & Windows will always work in 32-bit mode just because these machines are usually fast enough to do that efficiently. On Amiga, however, it all depends on the color depth of the screen Hollywood is running on. This can be 32bit, 24bit, 16bit, and 15bit. 32bit and 24bit are compatible and will both return $FFFFFF, but 16bit and 15bit will give you different colors. 15bit uses 5 bits per color component, 16bit uses 5 bits for red and blue and 6 bits for green. So you could actually do a manual comparison if you check against the colors in all three different formats (32, 16, 15). But as Jali said, GetRealColor() is much easier and is thus the recommended way to use when comparing color gotten through ReadPixel().

I tried thta GetRealColor() function too, but it didint help me much. It still gave me numbers.

Hexadecimal values are numbers, too. They just use a base of 16 instead of 10 for decimal numbers. You can compare the return value of ReadPixel() against hexadecimal values, too.

[jalih]

Only on Mac & Windows. Hollywood on Mac & Windows will always work in 32-bit mode just because these machines are usually fast enough to do that efficiently. On Amiga, however, it all depends on the color depth of the screen Hollywood is running on. This can be 32bit, 24bit, 16bit, and 15bit. 32bit and 24bit are compatible and will both return $FFFFFF, but 16bit and 15bit will give you different colors. 15bit uses 5 bits per color component, 16bit uses 5 bits for red and blue and 6 bits for green. So you could actually do a manual comparison if you check against the colors in all three different formats (32, 16, 15). But as Jali said, GetRealColor() is much easier and is thus the recommended way to use when comparing color gotten through ReadPixel().

Ah.. I just made a quick test on my Windows machine with 32-bit and 16-bit screen modes and got the same results when testing with DebugPrint(). Next time I will also test with my AmigaOS 4.1 machine before replying and making assumptions.

[Bugala]

Thanks from all the help.

I actually figured out the solution thanks to your brush comment. For it made me realise that i can actually drop the colors down to such small amount (i dropped to 21) that i can get it to work that way.

i used fixed color indexing on gimp and then i made small boxes of each color to the top of screen. At start it takes that color information from each box and stores them to "colors"-table. That way no mattter what screen mode you are using, result will always be correct one. Even if in future someone would be using 256-bit screen and it would give totally different numbers, it would still work.

this things slowed me down for quite some time. For Gimp gave me some extra trouble by changing the color codes and all and i had to learn to use gimp a bit before i was able to do that reducing of colors and color indexing even and get forward to the programming problem.

Good thing anyway i got it fixed now.

Thanks again jalih and Andreas.