Spring RTS Engine

Yep, I said when I released Asia Pacific I'd be working on a new map with Europe and Africa in it.

So I thought I'd post a sneek peek at the map and see what the reaction is. Not that I care, with almost 40 hours into the map so far I've really gone the extra 10 miles with this map. I have another 20+ hours at least.

The only thing is, I wish I knew exactly how the water height is determined. And by that I mean, given the max height, and the max depth, what grey value the water will be at. That would help ensure the map is rendered accuratly.

So here's the current state of the map:



Needless to say, once Spring has a few more wrinkles ironed out this will be an epic battle map. I'd like to see the max LOS distance increased so many units can see as far as they shoot. :-D

-Buggi

.
.
.. The map looks GREAT ....

Can't wait til its release ....

I might need to add another Gig of memory to my system
to play this bad boy ...

Just kidding ... I needed a reason to up my system memory
anyway ...

How big is it? The main thing I hate about real maps is the scale... Commanders as large as cities and crap like that... it just ruins the whole experience for me :\

It's planned to be a 32x32 map.

In other words... HUGE

I'm going to be doing the sandy shoreline trick again to avoid trees in the water.

-Buggi

Are you rendering it in terragen?

Looks like he's modifying the NASA BlueMarble images slightly like the Asia map...

Is it just me or is there a chunk of the US + Canada + Russia + the East in general missing ?

Well DUH
The map is meant to be of EUROPE AND AFRICA
Prehaps for a WW2 style battle?

Durandal wrote:Is it just me or is there a chunk of the US + Canada + Russia + the East in general missing ?

Panama had to go too. :D :D :D

Lets just say, I am trying to be as CLOSE to the real thing as I can be while maintaining very high playability for Spring. Some small lakes and such have had to go for example. And countries if you try to find Panama @.@;;

Whoever controls Spain controls the navy's of all the armies inside that area.

And if you want Asia, download my AsiaPacific map. :-/

This sucker is an 800 meg Photoshop file. ^_^;; I've got about 40-50 hours into it already. Getting close to trying to compile it for the first time. I just wish someone overhauled the mapconv to ensure support for large filesizes. @.@;; And, and to those who don't like trees, this map has two (TWO) areas of rainforest, so trees will be plentiful. I like trees.

-Buggi

Amen brother on the waterlevel thing!!!

I've actually done tests and cannot figure out a solid metric...

One word of wisdom (from my many hours doing what your doing, before you started doing it:

Sealevel isn't a constant all over the globe.

Damned if you do.... Damned if you dont

How about creating an additional "sea level" map and adding the function to mapconva nd spring?

Nothings going to happen unless the mysterious bug in MapConv can be solved.

I have a machine with 1.5 gig of ram on it and it still doesn't work.



-Buggi

Well its settled then, MORE RAM!

I suggest we setup a fund dedicated to buying buggi more ram to make rediculously large spring maps.

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))

For instance, if you use:
mapconv -c 0.5 -x 400 -n -100 -o "NewMap.sm2" -m "metal.bmp" -a "height.bmp" -i -t "color.bmp"
then the sea level should be:
-255 * (-100) / (400 - (-100)) = 255*100/500=51
as in color index 51 made of R:51 G:51 B:51

If it doesn't work, just use trial and error to find the exact perfect value.

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 It's on crack, but I do get somewhat close to the right sealevel...

And of course if I don't run it as 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')

mother wrote:Erm so basically.... n/x'ths of 255

Nope, n/(x-n)'th of 255 basically. With a few more negative sign thrown around.

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.

Try dichotomia!

1:1 heightmap is mad. The current heightmap squares are roughly the size of the paw of a fido. Are you trying to make sure the shorelines of the whole earth is accurate up to the point of grain of sand or what?

Yes, obviously you'd better not used -L if you're trying to make a pixel-perfect heightmap.