Spring RTS Engine

Incase people don't look in the mapping forum, we need someone to take a look at why mapconv screws up the mipmaps when compiling maps.

http://spring.clan-sy.com/phpbb/viewtop ... 73#p244573

Aaron of l3td has made the source for his l3dt plug in (that can compile maps) available to look at so we just need someone with some C skills to take a gander at mapconv and see were the errors are.

Think how much better maps would be without those annoying lines!

aGorm

Do you have the source files (texture, height, etc)
of a map that shows these lines to test mapconv's
compilation with?

Pretty much any map will do it

But I'll zip some up for you if thats a help. (runs of to pack up some map files.)

aGorm

oh, so now 2 years later, someone wants to take a look.

Meh, thanks kloot, at least someone has finally deemed it a halfway decent idea.

In a typical fasssion, any map small enough for me to zip up refuses to have the problem (or atleast very badly)

I'll sort a test map out after chrstmas...

aGorm

could you fix the memory problem too, i cant make 32x32 maps, but i can still allocate and write 1070 megs with my own C program... so there is some sort of bug in mapconv...

32x32 takes just 768megs... i have over 2gigs mem, though, im not sure can windows even use rest of my memory after 2 gigs o_O

MapConv reserves 4 bytes for every texture-map
pixel, not 3 (so a 16384x16384 texture requires
1024MB). Other than that I don't see any bogus
memory allocations being done, how much it can
get at once depends on the RT implementation of
new and on OS policy for user-space apps.

Kloot wrote:MapConv reserves 4 bytes for every texture-map
pixel, not 3 (so a 16384x16384 texture requires
1024MB). Other than that I don't see any bogus
memory allocations being done, how much it can
get at once depends on the RT implementation of
new and on OS policy for user-space apps.

Can the memory allocation be split up a little bit so it can get close to 2GB?

Removing the texture size limit would be nice, but removing the lines is more important... any idea whats been causing it?

aGorm

Yes, but I'd rather not have to make my own
map to find out for certain

Lurker: not sure how beneficial that would be,
if a process cannot allocate one N-byte heap
block then it is not likely to get M (N/M)-byte
blocks either (unless its VM is already heavily
fragmented). Case in point, the largest request
that I had mapconv do that succeeded was for
~2.8GB, which I could not top with four separate
~701MB allocs.

OK, I promise ill post one here tomorrow. All my small maps don't have the problem very much, blasted things. So I'll do a new texture.

aGorm


:::EDIT:::

UF is down.... and I don't have 50 mb spare on my web space... I could gmail it to you? If you PM me your address.