Spring RTS Engine

AF wrote:overhead

zwzsg wrote:I lay more hope into lurker's promise of adding Lua hook to pick tiles by index, than to your idea, because it would allow ingame redoing of map.

But ultimatly, both idea are pointless since 95% of mappers just feed mapconv with a huge rendered pictures, disregarding the tile system entirely, following the lines of though that hard drive are cheap enough that releasing another 70Mb file for a new DSD tweak is considered the way to go.

Have you realised that for instance since 60b1 (four years ago), the .smt can be shared between maps, and as far as I know this ability was used only once!

AF wrote:Currently we have a tonne of stuff that goes into a program and out comes a complete map.

Instead what if we had a compiler that partially compiled a map, so we'd have a blank black map completely level that e 'inserted' or compiled portions into it? This could allow tweaks of existing maps or for huge maps built from lots of little textures, and would allow extensions added to the edges of maps without decompiling, resizing and recompiling.

This kind of compiler would also allow the completion of a full map compiler that was parallelized, aka distributed/multithreaded, allowing much faster compilation times.

SMT (the 32x32 pixel tiles, each one 680 bytes):
     1       2
+-------+------+
| water | land |
+-------+------+

SMF (just numbers referencing the SMT, each number 4 bytes)
+---+---+---+
| 2 | 2 | 2 |
+---+---+---+
| 2 | 1 | 2 |
+---+---+---+
| 2 | 2 | 2 |
+---+---+---+

AF wrote:Loading times could increase by as much as a minute?!

AF wrote:Loading times could increase by as much as a minute?!

D00d, I'm talking about rebuilding a map when devving it.

But that's with a horrible algorithm. Just have lua pass in a table that gets stored in the tile mapping and you can do this in a fraction of a second.

Look, I made a map that redo its entire heightmap at startup, and the heightmap is 4x4 more detailed than the tileindexmap (assuming 32x32 tiles). You can try that map, the loading time increase isn't even felt.

Beherith wrote:Who cares about memory use for compiling? I never ever found it to be an issue with even just 1gb ram.

Trademark: mapconv has -q, although it seems to be broken.

zwzsg wrote:Unfair in the sense tile-index-map would be way faster, yes.

There are 16 time less tiles index to be changed than height points, and there is no need to repathing, apply damage, etc, since it's purely visual.

There is another aspect to compression in a SMF/SMT, which is useful to know about, because it is adjustable, and is probably the time bottleneck for large maps. It is basically duplicate tile removal. If there are two (or more) tiles on the map that have identical or similar pixels, only one 32x32 tile will be put in the SMT, and this single tile referenced two (or more) times by the SMF. This is where the compression variable used by mapconv comes into play, it affects how tiles are compared to determine if they are identical or similar, by scaling the mean color values in the comparision, and the border area of the tiles to compare. The more tiles to compare, the slower the process.

Argh wrote:I wish that somebody would sit down with what I proposed as SM4 and see if they can get it to a prototype stage, since there was some general agreement that it might actually work.