level of grey of sea shore= - 255 * (value after -n in the mapconv commandline) / ((value after -x in the mapconv commandline) - (value after -n in the mapconv commandline))
Erm so basically.... n/x'ths of 255
If it doesn't work, just use trial and error to find the exact perfect value.
Yeah well I can assure you that doesn't work out so well in practice... Which is basically what has us all going insane.
That and my realising that I cannot do simple division so my previous tests were all flawed
For instance lets say I take my heighmap and make 2 grayscale images
a) 0-127 [black to mid-grey] containing all the bathymetric terrain (underwater)
b) 129+ [mid grey to white] containing all the topographic terrain
then take both and slap 'em into a single grayscale bmp...
run
Code: Select all
mapconv -c 0.5 -x 200 -n -200 -o "NewMap.sm2" -m "metal.bmp" -a "height.bmp" -i -t "color.bmp"
It's on crack, but I do get somewhat close to the right sealevel...
And of course if I don't run it as
Code: Select all
mapconv -c 0.5 -x 200 -n -200 -o "NewMap.sm2" -m "metal.bmp" -a "height.bmp" -i -t "color.bmp" -l
Then it's pretty much a useless map...
This crack-addled behavior is quite obvious when your texture is markedly dissimilar between land and seafloor, heh.
I really think that to make the maps robust will require at the very least 1:2 or 1:1 heightmap resolution.
Blocking will never work correctly so long as maps are compiled with -l (sans adding another map layer), and I think it is what ultimately leads to completely unexpected sealevels.
Da 'Verdict: It is an inherent 'feature' that you cannot have 'good' shorelines. With 1/8th (Plus 1!) heightmap resolution you will never get a complex shoreline to match when you have a high contrast between sea and shore textures. (I can hear it now 'The engine does shading')