Spring RTS Engine

Yes, but I was saying the sin aren't the issue.

BTW I just realised I mistakingly left LevelHeightMap where I wanted to replace it by SetHeightMap. Doing that already cut lots of CPU load. Edited previous post-attached widget.

Auswaschbar wrote: 1.
2. ...
3. lua

Was it the lua of that gadget, or the overall C.A. and IceUI lua?

1. map damage recalculation (dunno what it does)
2. ...
3. ...

Argh wrote:Isn't MapDamage triggered any time a heightmap square changes at all?
Uh? What's that?

Also, no pathing in the top 5? Was my information source so wrong?



Plus, I wanted to say that there is a little bug, the heightmap used to determine visibility is the original heightmap and not the current heightmap. So if the map has an initial height of 1000 and I set it to 100, then when I zoom in a bit the map texture disappear. Or if the map has an initial height of 200 and I set it to 600, when I have the camera fairly horizontal the map texture at the bottom of my screen gets eaten.

edit by Auswaschbar: sorry, pushed the wrong button and edited your post

zw, what happens if you change the height to under the water level? Could periodically raised bridges be feasible with this?

zwzsg wrote:Was it the lua of that gadget, or the overall C.A. and IceUI lua?

Engine can not know, so one of the lua-profiler widgets would be needed. Not that it really matters, thought...

Argh, have a look at this:

http://github.com/spring/spring/blob/59 ... Drawer.cpp

zwzsg, I would seriously consider switching from gif to apng, it'd be prettier, clearer, and smaller (filesize probably but the rest definately)

In the meantime, this is wierd, hope we see more continuously moving map heightfields like this, it'd be great for maps with glaciers or other ice stuff to ahve the heightfield actually change over time.

Would it be possible to do a similar thing with water levels? For example, you could have a map with big beaches surrounded by water but then as time progresses, you could have the tide coming in and the beaches going under water. Effectively, you could flood maps ingame, would make for interesting gameplay, would stop players porcing at waters edge and being forced to expand in :)

Changing the water level is at this moment much more CPU intensive, because throughout the engine the water level is taken to be at height 0.

That means to change the waterlevel you need to raise/lower the entire heightmap, making it an operation which you will notice as performance drop.

(It's a similar thing as the map borders, someone's got to go through a lot of simulation code and check for places where < 0 and > 0 checks are used to check for below / above water level, and replace them with a </> waterLevel check.)

Wouldn't it make more sense to make a water map and make it a completely separate map element? This could come with a few bonuses such as being able to decide where you want water on your map and ability to change water settings throughout a game.

If you did it similar to the height map, you could even have water on different parts of the map, regardless of height. Like water in high up basins and none on lower ground below it.

This would be more efficient in my opinion.

JAZCASH wrote: If you did it similar to the height map, you could even have water on different parts of the map, regardless of height. Like water in high up basins and none on lower ground below it.

this is impossible without a ridiculous amount of recoding

23MB animated gif. WTF.