Spring RTS Engine

Here is a mini.dds file from the old mapconv util ..



I'm going to test something out and post the results.

I did a test and made a new directory and added the new
build 7 and added the files. I compiled it and the dds file
is correct now. I used this directory to test other versions
of this map.



Looks like I need to make a new dir with every release of mapconv ..
Some how a older dds was added to the map.

I decided to add 2 Geos to the map and I think the
geo bit maps are alittle too big ...






I plan to adding a few custom features too ..

Most likely a small bug ..

no, that is very good, more area for placing geothermal plants, more energy.

i think i know what is the problem, it resizes the geothermal image.

tried versions 0.6b and 0.6c, they have no support for typemaps, but have you tried them?

version 0.7b will be out soon, will have mostly bugfixes, since mapconv is almost done.

eheheheh

those are some large geovents

finished 0.7b, here it is:

http://www.unknown-files.net/spring/4032/mapconv07b/#

fixed geothermals, and fixed some other bugs.

The map built correctly ...

Here is a screenie of the map with Geos



Only 2 other issues to fix ..

My linux system need some work get Spring to work
and a new LCD monitor ...

My 22" LCD just DIED ... also the warranty is up too

mapconv doesnt works in linux.

AFAIK it does. I think qknight actually made a map with it.

Btw, did you actually modify mapconv, or just recompile?
If you did modify, are modified sources in SVN already? If not maybe submit patch

it did work, but in my computer, the functions were giving me alot of problems in compiling, had to remove them, i can remake them.

i modified mapconv, alot, added map rescaling, fixed the line issue,
fixed lots of other issues, made mapconv place trees better, made lots
of bugfixes, and made it run faster, made map ids depend on heightmap.

i posted a patch, it is on page 3, but its old, from that version to this one alot was changed, that patch had the code for 0.6c, at 0.7b the
code was modified to make it easier to understand, i can post a new
patch for this version.

ok, i will remove the old patch from page 3 and upload a new one here.

here is the svn patch for mapconv:

Changelogpls.

Um, I'm having a problem with this. It removes the lines, but it's forcing tiling, even when -c 0 is set.

The map files involved will be available soon as I get done with the World Builder demo. This shows a lot of promise, if the -c parameter works. Kind've important, though, for maps that are hand-painted and where a lot of tiling is immediately obvious.

for less tiles lower -q quality and raise the value of -c compression.

if you are using rescaling put -b 3, or the map will look bad.

the amount of tiles should not be a problem, i once had a 46mb smt file
that got compressed to around 4mb-8mb using 7z file compression,

dont set compression to high values, because it may remove some important tiles.

quality at around -70 to -85 lowers the size without losing much detail.

So, -q is to be given a negative value? And -c should be made nearer to 1.0?

Nevermind, that is clearly not the case. So, how does this work? At -c 0, -q 100, I was expecting no tiling to occur, but severe tiling results. Whereas with old Mapconv, a setting of -c 0 results in practically zero tiling. I think it's ignoring the -c parameter entirely. Which is really bad, since if you're trying to make a map with a very low amount of obvious tiling, and are not using a detailmap, then it's quite pixelated and ugly.

Moreover, the values of -r and -u, which are supposedly optional, are required, or the batch won't finish. And they require a value of "screens"- i.e., a 1025 heightmap == 16 "screens". Setting these values to 32 resulted in a runtime error, and a crash. Setting it any lower results in a halt. Not setting those values to anything results in a halt.

This is the current set of instructions I'm giving the application: This results in severe, obvious and very ugly tiling, as if -c was set to 1.0 - I think that part's getting ignored entirely

Hmm. I have a theory about what's wrong. I think that it's actually obeying the instructions in the -c parameter, but it's not sorting the matches properly, or is discarding the matches improperly, and isn't placing them in the SMT correctly- they're in the file, but not being assigned to their correct places X,Z. I'm going to test that theory here in a second.

Here are the results of your version of the software, which built a 43MB SMT:



Here are the results, with the old MapConv, with a setting -c of 0.5. This resulted in a 41MB SMT:



As you can clearly see, your version's tiling in a way that's very obvious, and very unattractive. I'm going to test your application with -c set to 1.0, and see what happens to both filesize and the resulting tiles.

This is the result of the following parameters:
Which resulted in a 13MB SMT. Huge filesize reduction- clearly, there must be fewer tiles being stored. However, it doesn't look any different.

-c is the multiplier for the tile comparison error threshold which defaults
80000.

if the tile pixels doesnt matches with the previous tile, it increases the error amount by the amount of pixels that are different, if there are more errors than the threshold it will return false, and it will get that tile from the image, else if the errors are lower it will return true,
and that tile wont be added.

so if the compression is 1.0, the threshold will be 80000*1.0=80000.
if the compression is 0.0 the threshold will be 80000*0.0=0.

it doesnt ignores compression,
and quality must be an integer from 0 to 100, no negatives,

so if the compression is 1.0, the threshold will be 80000*1.0=80000.
if the compression is 0.0 the threshold will be 80000*0.0=0.

Well, I showed you the parameters I used. As the screenshots show, setting -c to 0.01, or a threshold of 800, wasn't effective at reducing the number of tiles actually shown on the map- but the filesize got a lot larger, which strongly suggests that the tile image data was stored, just not applied to the resulting SMT.

I'll try a value of 0.001, a threshold of 80, and see if that works. If > 80 pixels out of 1024 differ from all previous tiles, then the tile should result FALSE, the tile should be saved, and displayed in that location. This will, no doubt, result in a giant filesize. But, I predict, the end results will be exactly the same. This isn't where the problem is. It's that the different tiles aren't being displayed at the required location, but instead the tile that was the closest match is being displayed, I think.