Spring RTS Engine

And what I mean by that is, the Texture and feature layout was done by Nixa, link here: http://springfiles.com/spring/spring-ma ... -remake-v1

Key differences between nixa's and my versions...

SSMF
Height ranges much lower (makes the terrain look a lot better and much better gameplay imo)
Lighting is normal (Nixa's uses a very harsh lighting element which I suspect came directly out of tabula)
Uses featureplacer and mapoptions (the feature layout is the same, just this one is using featureplacer for it)
6 geovents on the entire map (the original and Nixa's both had only 3 iirc)

@nixa, feel free to take this, change the lighting and heightranges and re-release yours with the ssmf sexyness!

It's worth noting that if your game calls spring features as a dependency, you can use this map with your game (This goes for all EvoRTS maps).
Links: http://code.google.com/p/spring-features/
SD7 for Spring Features: http://springfiles.com/spring/tools/spring-features

Screenshots of this map:


Download map linkeh: http://springfiles.com/spring/spring-ma ... red-divide

Map originally by Caydr

looks great; the contrast between the rock and grass is very nice. features look like they are used appropriately and realistically...

my one worry: please tell me you made the ground perfectly flat to avoid that reveal effect where you can see where the enemy base is... biggest drawback of the original version IMO

KaiserJ wrote:looks great; the contrast between the rock and grass is very nice. features look like they are used appropriately and realistically...

All Nixa's doing (his texture, I did lighting and texture adjustments with ssmf, but 95% of what you are seeing is Nixa's great work)

KaiserJ wrote:my one worry: please tell me you made the ground perfectly flat to avoid that reveal effect where you can see where the enemy base is... biggest drawback of the original version IMO

Nah. That would be an issue on any map without perfectly flat ground tho. I personally have never used that trick because it equals out to being a cheat. I think, now that you mention it, that in evo I will use a gadget to bind f1 to a non-existent command (or maybe that could be bound to the help screen).

next spring release will very likely have unsynced heightmaps, which are meant to solve exactly this problem. you would only see hieghtmap changes that your ally team had LOS on.

Holy crap, really? That is awesome! (I imagine it will actually cause an engine speedup too won't it? Already in the 83.x testing versions you've put up it seems as tho there is a significant speed increase)

i am pretty sure that speedups in the test release are not related to this feature. most likely the changed pathfinder, i guess. in current spring release, there is only one height-map, the actual/current/real one. in master, this same heightmap still exists, and is still actualized as it is in the release version, but in addition, we have one heightmap per ally-team, which is used for rendering (an other unsynced stuff).
so this feature eats memory and CPU cycles. maybe it gives a minimal speedup in rendering, because the heightmap is less often updated there, but alltogether, i would guess it is more a slowdown then a speedup.