Heightlines and colors

SinbadEV · Post by **SinbadEV** » 01 Sep 2005, 15:44

If I remember correctly from TA, solar collected used to go up past 30 degrees in some maps

colorblind · Post by **colorblind** » 01 Sep 2005, 22:44

zwzsg wrote:So I'm in favor of keeping the F1 heightmap as it is.

I hear you (and SJ). That's why I've coded the possibility of custom height palettes. I only have to make some changes to settings.exe so you can select which one you want (I already made a 'real' palette and a repeating one). Expect the patch file and some nice pictures on Sunday ...

Gnomre · Post by **Gnomre** » 02 Sep 2005, 00:04

SinbadEV wrote:If I remember correctly from TA, solar collected used to go up past 30 degrees in some maps

Nope. They were always 20 regardless of the map. Wind and tidals varied, but solars were constant.

colorblind · Post by **colorblind** » 04 Sep 2005, 14:38

Ok, time to release a patch file. Get it here.

This patch allows people to choose their own heightpalette, instead of the choice between the colorized or the greyscale elavation map we have now. I have four heightpalettes you can use: a realistic, a simple, a repeating, and a greyscale one. You can get them here.

Applied to The Small Divide, they look respectively as follows:

The last two ones a similar to the colorized and grey elevation map we have now, the first two are somewhat more 'realistic'.
Of course you can go create your own palettes; but I haven't found a (free) program that can do that. And the SY first need to decide whether my patch is worthy enough to be included in the CVS ...

Post by SJ » 04 Sep 2005, 19:37

The problem with this patch is that the repeating patterns repeat frequency is now dependent on the difference between min and max height instead of being fixed as before. This makes it more or less impossible to do any sort of mental calculations based on it.

Make the repeating one have a fixed frequency and also let one iteration consist of the whole palette instead of just a few colors.

colorblind · Post by **colorblind** » 04 Sep 2005, 20:25

You speak in riddles, SJ.

Because I thought that the 'mental calculation' was a tool to see if this point here is higher than that point there. With the first palette you easily check this -- no calculation needed.
But appereantly this isn't what you had in mind. Could you clarify it once more?

And I don't think it's necessary to have more than one iteration of the palette. There are 256 different colors in it, which is more than enough to see the heightdifferences in any detailed map.

Post by SJ » 04 Sep 2005, 20:58

What I meant is that in the old system one iteration through the colors are always 32 high, so if you know that unit x has a firepoint 40 above ground then you know that you can safely place it behind a hill that is one iteration through the colors high.

But with your fix the size of the iterations will vary in size depending on the difference between max and min height in the map.

You could see some banding already with the old palette usage and although it might not be strictly necesary it will certainly look nicer with 256 (or more) colors per iteration (and you will have to do it this way anyway to solve the above problem).

colorblind · Post by **colorblind** » 04 Sep 2005, 21:41

Ah, now I see why you can't be beaten at your own game. Stuff like that isn't in the readme :).

How's this then:
(1) Pressing F1 doesn't only show the heightcolors but also a legend with the colors and their altitudes.
and / or
(2) When placing a defensive building, not only it's range is shown with a red line, but also the places where it can / can't fire.

Option (2) would be a nice addition to the gameplay; then newbies are one step closer to SY-level of play 'cause it will make your calculation redundant.
Option (1) would be nice for the sake of being nice; a heightmap without exact altitudes isn't really a heightmap :).

But the first will have to wait untill the new gui is fully operational. It's pretty pointless to program it in something that's going to get replaced anyway. The latter shouldn't be all that hard to code ...

Post by SJ » 04 Sep 2005, 23:30

(2) would probably be very hard to code since its hard to get the firing point for a unit. Consider for example an annihilator how would one know that the fire point will get significantly higher because the unit will unfold before it fires?

colorblind · Post by **colorblind** » 05 Sep 2005, 00:30

You hit the nail right on the head. I've been trying to find a way to implement (2), but came to the conclusion that it'd take more workarounds than I can handle tonight ...

But let me try and get it straight: before building only the UnitDef with therein WeaponDef is avaible. Whereas you actually want the CUnit -> CWeapon ( -> TryTarget ) information.
So in order to make it work, you'd have to create a dummy unit, have it in its firinging state, and then access TryTarget for an area around the buildposition. Right?

As a sidenote, what did you think of (1) and (2) besides being it hard to code?

mongus · Post by **mongus** » 05 Sep 2005, 01:53

radar like?

colorblind · Post by **colorblind** » 05 Sep 2005, 11:24

Yes, radar like, with the small differences that you see the area of effect before you place the defensive structure.

Spring RTS Engine

Heightlines and colors