How ground-elevations are graphically represented...

Started by Sauffaus, January 24, 2010, 03:02:20 AM

Previous topic - Next topic

Sauffaus

I just made this map: Bubblegum Road, which isn't posted at present time (uploaded, but not posted yet).

I wanted to make some cool ground-images in Photoshop, but my efforts was foiled by the way the game process the image-data to represent the 5 different ground-elevations.

As far as I can tell, it does the following:
Elevation 1 = Minus 70% brightness
Elevation 2 = Minus 19% brightness
Elevation 3 = Plus 7% brightness
Elevation 4 = Plus 25% brightness
Elevation 5 = Plus 39% brightness

PS: These numbers are backward engineered by me, so they might not be entirely accurate.

Anyway, what this effectively mean, is that the gamut (http://en.wikipedia.org/wiki/Gamut) for Elevation 1 is compressed to a gamut of RGB 0 to 138 (out of 256 possible values). In other words, Elevation 1 becomes very very dark, and you can have NO bright colors what so ever.

Similarily with the other brightness-conversions... they all reduce the effective gamut of your image, making crisp background-imagery impossible.

What I suggest is one of two options:


  • Make the Elevation-brightness controllable for each map, directly in the editor. i.e. simply make a Elevation-brightness-slider, that determines the basic value to add/subtract for each Elevation... and make Elevation 3 to be ZERO (full gamut) all the time.
or...

  • Make each Elevation hold its own complete image, and then have NO brightness changes at all. This will make map-creation easier for ppl with graphic skills, but harder for “non-techies” (they have to find/create 5 different images)... but I know this will probably also demand more development time.

Anyway... Just a suggestion, to make a cool game great :)

knucracker

Thanks for these ideas.... I'll look into this to see if it could be supported without too much trouble.  The background is rendered once at the start of the mission and for each elevation the red, green and blue values are multiplied by m, where m = 0.25 + terrainHeight / 4.5.

This, as you have noticed, lets people slap any old image as the background and then 'draw' a terrain without too much trouble.  But it also has its limitations.  Your idea of allowing the map designer to tweak this value per terrain level (meaning they could set them all to '1') is probably something easy to add.

Capn Trey

I don't like most custom backgrounds. The few I played annoyed me so if I see one I don't download it.

Karsten75

Quote from: Capn Trey on January 24, 2010, 06:30:41 PM
I don't like most custom backgrounds. The few I played annoyed me so if I see one I don't download it.

Isn't a free society wonderful?

Siccles

Quote from: Karsten75 on January 24, 2010, 07:00:26 PM
Quote from: Capn Trey on January 24, 2010, 06:30:41 PM
I don't like most custom backgrounds. The few I played annoyed me so if I see one I don't download it.

Isn't a free society wonderful?

no it isnot... its like democrazy, good in theory but stupid

knucracker

Sorry, I just can't resist the perfect opportunity to quote Churchill:
"Many forms of Government have been tried and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time."

As for custom backgrounds in maps... indeed most efforts are valiant efforts but many do fall short of their mark.  The effort it takes to do a good background is rather high.  This was one of the reasons for the system I have in place... let people pick simple textured backgrounds and then paint over them with modified RGB values.

But I want to do what I can to support those who try to climb the custom background mountain.


Aurzel


Kamron3


Sauffaus

#9
@ virgilw...

It will be very rewarding to implement an “Elevation-brightness-controller” into the map-editor... Thanks a million for looking at this :D

Now, while you are at it, it would also be rewarding to implement a similar solution for controlling the “Edge-brightness” (i.e. the Edges between different Elevations), which basically displays the same gamut-problem, as described for the Elevations.

Edge-gamut is however, not as crippling as the Elevation-gamut, but would still be a “very-nice-to-have-thingy”.

If you think “Edge-gamut-control” is over the top, perhaps you could just relax the built-in values a bit, so the Edges become less pronounced, and especially the darkest value gets lightened a bit.

Again... thanks for taking this seriously!


Sauffaus

With the risk of sounding as an ungrateful impatient moron:

If you can implement these changes relatively easily, then when would that be part of a release?.. you know... a circa date.

I'm only asking, because I have a couple of maps in the pipeline, and want to make custom graphics for those... but if the gamut-control is arriving soonish, I would love to wait for that.

TheBuilder

im not sure but, i think he does an update whenever he feels that there is enough changes from the last update to make it justify itself, but before he does make an update available he usually has his beta testers give it a good run through to make sure that there are no bugs left in it
Not even death can stop the truly determined.

I told them, "I want to add to the world."
They said, "Then learn how to use the editor."
I asked, "What is the editor?"
They said, "Life."

Aurzel

@sauffaus, because he's working on the expansion which he's already said will be the next release