Fixing Mapconv's line issue.

[aGorm]

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

[Kloot]

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

[aGorm]

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

[Forboding Angel]

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.

[aGorm]

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

[TradeMark]

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

[Kloot]

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.

[lurker]

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?

[aGorm]

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

aGorm

[Kloot]

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.

[aGorm]

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.