And the way I see it, 8-bit means 255 different options. So if the png is 16bit, then it stores 65 535 different values of gray.
That sounds correct, except that the first value you can store is 0 rather than 1, so it's 256 and 65536 different values.
This means that in order to read one number, I need to parse 2 bytes. Should I worry about big-endian stuff or something like that?
I would assume the PNG format has covered that, unless you want to write a PNG decoder yourself. If you load such an image with a library 16bit PNG support, you'll also run into that problem.
There are programs that do this, but what's the logic of that. It seems to me that I will lose precision from 65535 to 255, right?
That sounds likely as generic conversion program.
The question is, is that bad?
I'm doing something very wrong, because it doesn't work, I get wrong values and my character moves like this: /\/\/\/\/\/\/\/\/\/.
Your character is just jumpy :D
I can agree it doesn't look right, but that's about all I can conclude.
You have a long chain of things that you do to make the character aware of its height, and the problem is at least in one of the links of the chain. Question is, which one.
At a somewhat higher level, there are 3 parts.
- The satellite image converted to heightmap, loaded by DeviL, where you loose a factor 200 precision (probably)
- Code that derives the height from the loaded image
- Code that plot the character at the right height.
Any of this code can be wrong. Likely I missed a few steps.
There is also the other option, namely all code does what it is supposed to do, but you didn't realize some of the effects that it has. In other words, the code is ok, your ideas need to change. I name this option "computer outsmarts designer". It's a fun phase, where you get confronted with weird effects that are totally correct, but unexpected.
Before you can conclude the latter though, you need to proof the problem is not in the former chain of code. The usual process for that is called debugging, and it's an art in itself.
So far you have established that the end result is not as desired/expected, but is it wrong in the sense that the code is not doing what it is supposed to do?
Can you get the value that the code reading the height map is producing?
Also, can you get the height of your character?
These should match according to the conversion you implemented. In this way you can check the code that computes the height is doing its job
It will tell you Z=<some value> for your character. If you look at the screen, is the character drawn at the height that you expect? Maybe you want to add obejcts in the world with a known height so you have a reference.
This can tell you whether the drawing code draws things where they are supposed to be drawn.
If this all works, the chain from the image to the plotted height is good, so the problem is perhaps earlier. My next step would be to use a heightmap with known properties that I prepared myself. For example, flat, but one ridge, or some other known pattern.
Load the image, see how the program reacts. Does it do what you think it should do? ( Edit: "should do" in the sense the code does how it is programmed!)
If so, the problem is clearly somewhere in the conversion and/or loading of the satellite image. If it is not, it's time to think hard why a self-prepared image doesn't do what you want it to do.