New MAPCONV

[zwzsg]

We don't need a new map format, just a new map editor. And I'd rather have bandaid on the current map maker prgm than keep on bleeding while waiting for another map editor that may not come.

[nitrus]

The main problem (as far as I can see) with the current format is that each map contains its own tileset which accounts for about 75%(guess) of its size . If we move that to a seperate file then multiple maps could use the same tileset (with maybe a smaller internal tileset for unique features).

Only problem with using tilesets is that maps sharing a particular tileset will look similar - obvious I suppose.

[Torrasque]

I've got a map ready, but when I use your mapconv to add tree, it crash...
i've got a 4096^2 texture map, 1024 metal map and 513 heightmap.

[[K.B.] Napalm Cobra]

Thats a retardedly detailed metal map. Twice the heightmap?!?! Try reducing it to 512.

[mongus]

what about that tileset TAMEC did compile on 2004? (tamec2004HPI or smtg)
cant that be the ... source for tiles? just and idea, i dont have idea really O_O .

Edit: "i dont have idea really O_O" that was what i was talking bout
Always thought that hpi was about tiles...

but a file containing a collection of tiles may be usefull here.... again... i may been stupid :D

[Gnomre]

Erm... The TAMEC HPI file is and always has been a collection of features, not tilesets... Fileuniverse has a nice huge tileset section now, though:

http://fileuniverse.com/?page=listing&ID=74

[nitrus]

I've got a map ready, but when I use your mapconv to add tree, it crash...
i've got a 4096^2 texture map, 1024 metal map and 513 heightmap.

Hmm - works for me.. must be something strange with the bitmaps you're feeding it. I noticed that trying to put tree too close to the edge of the map will crash Spring when the map loads.. dunno what's going on there!!
Make sure all your trees are away from the edge.

[hrmph]

It is the program. I'm having the same exact problem. Maps under 8192x8192 work fine when I add trees. For some reason on my 8192x8192 map I cannot add one tree without it producing the same error. Note: The mapconv program itself does not error it produces the map as it would normally, but when the map is loaded into spring the program hangs on the creating tree texture announcement. Also I tried any number of things regarding the bitmaps before coming to this conclusion.

[Ace07]

The main problem (as far as I can see) with the current format is that each map contains its own tileset which accounts for about 75%(guess) of its size . If we move that to a seperate file then multiple maps could use the same tileset (with maybe a smaller internal tileset for unique features).

Only problem with using tilesets is that maps sharing a particular tileset will look similar - obvious I suppose.

That would be the best idea. Having similar tilesets that all of the maps can use for different elevations and environments. It would make the maps much smaller.

[adeveloper.clan-sy]

Nitrus,

Thanks for doing a good job with modifying the Map Converter code and providing extra features. I am sure many map makers will be very happy.

The Map Converter is licensed under the GNU GPL ( refer to http://taspring.clan-sy.com/phpbb/viewtopic.php?t=1344 )

Nitrus, send in your code changes to SJ, if you have not already, so that it may be tested and included into the main distribution.

As a reminder, if you distribute the MapConverter binary (or any modified Map Converter binary) you will also have to provide a link to the source code and to the source which contains your modifications.

[mother]

Well they most definitely do.

I tried about 50 differnt permutations and came to the following:
a)one green pixel of value 200-215, on a field of black, in a 24bit bmp, created by The GIMP, crashes
b)same made from mspaint works
c)big complex metalmap saved as a png and loaded into mspaint and then saved as a 24-bit bmp, crashes.
d)Ive identified one difference between MSpuke BMP's and the BMPs coming out of The Gimp: the 'scale ratio'
*edit: ignore d), total brain-fart on my part*

OTOH the two bitmaps do differ (if anyone wants to try to figure out what is going on)




Any ideas people? Nitrous?

Yargg me wants me bloody trees!

[mother]

The 2 bmps:
From
MS and The Gimp

[nitrus]

It might be the CBitmap class having some problems with different formats. I use Paint Shop Pro for all my bitmaps and works ok.

I'll investigate..

err.. those two bitmaps are the same file.

update: I've just tried it with that bmp and works ok for me, sm2 built:
test:
Metal map: 256x256 - the file here: http://www.acsu.buffalo.edu/~asa5/tehgimp.bmp
height map: 257x257
colour map: 2048x2048

[mother]

Gah. Don't make fun of me just because Im stupid!

Heh, sorry about the wonderful linkage...

Turns out that I've been able to explain about 90% of the tree-crash problem.

Ready?

1)Spring doesn't like 1kx1k maps, or at least the simple ones I was trying to use for testing.
2)Spring will barf if you use uber-mapconv with a metal map containing trees which is at full texture resolution

Why that is I do not know, nor do I care. I successfully redid my metalmap at 512x512 (for a 4kx4k map), and it worked.

I had avoided sub-texture metalmaps because of the initial geovents-o-plenty problems.

So to all those still going INSANE over the trees: try a metalmap at 1/4 res.

Now that we know this it is a feature not a bug

[Buggi]

mother, just wait for my new map conversion utility.



Due out tonight.

-Buggi

[aGorm]

Looking sweet cool there.... good thing as im workin on a large 32 x 32 map and i need all the options i can get

aGorm

[Hannes]

Nice job man . I couldnt get uber mapconv to work but yours works fine. Im still map-newbie and just wanted to create a simple 2x2 map, but i have alot of cool ideas now that i have the right tools.

[jcnossen]

this thread is ancient