Spring RTS Engine

So does that mean that one could have a very, very large map (just with a low rez ground texture?)

That is...was the 40x40 limit on mapconv's end or on the engine's end?

Because if it was on mapconv's end...I can totally see some ginormous water maps coming.

the 40 x 40 limit is mapconv issue
the limit is defined on tilehandler.h there is a variable called max_map_size = 40 and other that is maxtiles that is around 400000

but this feature is not done yet, i am still working on it.

and for very huge maps over 80 x 80 would take alot of time to make

and the fast scaling filters would make the heightmap look ugly, and the
good scaling filters would take alot of time to scale but would give good results

this converter also supports 16 bit raw images

ralphie wrote:Well I got agorm's odd colour/distortion, and scanlines. Not quite a miracle fix yet

That map looks awesome, LET ME KNOW WHEN YOU'RE DONE (or if you want to make S44 version :D)

Instead of rescaling, I'd rather have tiling.

i allways thought that rescaling would be a quite good improvement to it

yes tiling would be good too, it will be necessary for very huge maps since rescaling too much makes it look bad in game

tiling you mean making the map divided like instead of using a 8192 x 8192 texture using 4 4096 x 4096, or very small 256s or 512s images?

and the no odd maps limitation,is it a spring problem or mapconv problem?

edit:i think will add an option for choosing rescaling filters that will be fastest ,medium, and best

OK, so here's the deal. With PNG, I get no weird map tiles being in the wrong place. (although the minimal strangely DOES still show the issues... go figure).

It does however still do all the lines issues. So using texconv.exe not nvdxt.exe is still goona be the way to go.

aGorm

post a screenshot so i can see how it looks like

so texconv is an option, DevIL can also save dds files, nvdxt comes with
a set of libraries for dds manipulation, there is also the gimp plug-in for dds. surely this shouldnt be a problem to fix

i will later upload a new version with new features. and i will include one build that uses texconv for converting

edit:texconv is not working for me it prints failed to create d3d device
when using the command to convert the pngs, probably i have put the wrong commands, going to fix it

removed dither option for creating dds files, and i think i found the problem, when nvdxt is creating the compressed dxt1c textures it will set most of the very dark pixels to 0 alpha this means 100% transparent,

switching to dxt1a compression stops this.

i will upload a new version, with new experimental features for testing

it will also come with a better readme

edit: done rescaling, just need a few bugfixes, and now tiles seem to look better than before , for more information look at the readme

edit:the lines seem to be gone now, this one doesnt generates them:

http://www.unknown-files.net/spring/4013/mapconv06b/#

Hi, i'm trying the 0.6b version you posted on UF.

C:\Documents and Settings\jamie\Desktop\mapping\plateau2tmp>mapconv.exe
-i -l -x 440 -n -55 -m metal.png -a height.png -t map.png -f feature.png -z te
xcompress -o "Emain Macha v1.smf"
Loading texture
current x:8192
current y:8192
Creating height map
heightmapx:65
heightmapy:65
loading heightmap image...
current x:1025
current y:1025
Creating features
current x:64
current y:64
current x:1024
current y:1024
Grass Placement:

A subdirectory or file temp already exists.
Creating dds files
this part may be really slow
Library dxtn.dll found and loaded with success
Converting temp\*.png
Source image xsize: 1
Source image ysize: 1
ERROR, xsize too small, must be at least 512 pixels
Could Not Find C:\Documents and Settings\jamie\Desktop\mapping\plateau2t
mp\temp\Temp*.png
creating minimap
Version 8.30
Reading mini.png [Processing] Writing .\mini.dds
Invalid switch - "Temp*.png.raw".
Saving metal map
current x:1024
current y:1024
Writing 0 features

It doesn't seem to create the temp files. Do you have any idea how i'd rectify this?

Hijack!

SpikedHelmet wrote: That map looks awesome, LET ME KNOW WHEN YOU'RE DONE (or if you want to make S44 version :D)

Have finished it (some weeks ago actually), thread is here

I'm happy to make a '44 version. Do you want to send me a metal map again?

found the problem , -b -r -u , must be there , try adding -b 1 -r (the size of the map x in spring, 16 for that map) -u (the size of the map y in spring, 16 for that map).

it will print some rescaling information, but it actually wont rescale anything , or you can wait until i fix it( wont take too much time).

for the next, maps will have an increased size limit ,it can be incresed up
to 2500 or maybe more, mapconv will have less problems in feature placement.

Lines are gone in this version, however... I noticed this instead. Very odd pixelation. Any idea whats causing it? Be great if you can fix it.

aGorm

::EDIT:: Vew it 100% to see properly...

i can, but are you sure you put all the command line parameters correctly?

make sure you arent using rescaling(-b should be 1,-r the map x in spring(texture x/512),-u the map y in spring(texture x/512)).

this happens when using rescaling with filter 1, and on the old, what was the results?

this didnt hapened to any of my test maps.

I've got -q as 100 and -b is 1.

MapConv.exe -x 300 -n -80 -l -m metal.bmp -a height.bmp -t texture.png -o IslandDivide.smf -c 0 -q 100 -b 1 -r 10 -u 10

And the map shold be 10 x 10.

anything wrong with that.

aGorm

nothing seems to be wrong with the parameters, but try using -c 0.1, if it still happens, i will need the texture or the png and raw tile files so i can see what happens with the images when created

Good thing it's my very small test map then... I'lll send it over this evening after trying the c 0.1

aGorm

URL REMOVED... BANDWIDTH

There you go, test files. Happy bug hunting

aGorm

ok , this probably shouldnt take very long, seems to be a tiling issue, because on the other parts, the image is not pixelizated

It seems to happen on different mip levels, so when your closer those parts look fine, but as you zoom out the mips go pixelated...

aGorm

::EDIT:: How many peopel smegging downloaded that? Now I'm about to exced the 2gig limit on that account. Geeesss... thats just ludicrus. It's not like they were of intrest to anyone but user.