Spring RTS Engine

I prefer PCLinuxOS myself...

But I don't want to have to switch to that just to make a map. I'm not particularly Linux savy anyway.

All my progs I need for mapping are windows... so it would make sense if Mapcov was to.

aGorm

What is it with you pclinux people? :)

What do you mean "switch"? Its called dual boot, my friend. Or vmware server. Or just forget it and be a windows noob (sometimes theres no choice).

It is called dualboot... how else would I be running Windows and Linux??

Hell my laptop is now triple booting... came with scummy vista so it now has XP and Linux to.

The day adobe make all their stuff have a linux build I'll be able to switch over. (Well that and a few other programs like games...)

aGorm

::EDIT:: Oh and PCLinuxOS just is very easy to manage, for linux noobs with little time like me.

Hey this might be a long shot but I had a similar problem to this using carrara.

I imported a height map I make in a separate program (such as gimp) and kept getting a grid-like pattern in my final texture. I was very frustrated for a while and then realized what the problem was. Turns out that if I render that height map at a resolution higher than that of the heightmap image, I am telling the 3D program to take a small image and expand it before rendering it into a heightmap. This pixelizes it! The heightmap rendering only lets me choose square sizes (such as 256x256, 1024x1024) but so long as whatever size I choose is smaller than the heightmap image I imported (both width and height), I am fine. Resizing can be done later to get a rectangle.

If you are not importing a heightmap into a 3D rendering program, this may still be relevant to you. Look to the pixelization. That may be your clue.

That is good advice, but mapconv takes a raw texture image and does not resize it. It's a bug, no more, no less.

Pxtl wrote:Does it bother anyone else that maps for a free, open-source program can only be properly made in a retail program?

I realize I'm 20 some odd days late on this one... but realistically, that's not really aaron's fault. He didn't bribe anyone to make mapconv shitty. What are we supposed to do? Refuse to allow anyone to make development tools for spring that they don't release for free? That kind of violates our role as a provider of a free to develop for software suite.

I'd be ecstatic if aaron did choose to release a spring map dev kit for free, but it's really no more his fault than it is any of ours that we haven't produced any comparable mapping tools to his work within our community.

Ummm, I don't think anyone was blaming Aaron, in fact I think its amazingly cool he added it to his program, I think we were more pointing out that It's stupid that some one should suggest that his program makes it fine that our own doesn't work properly. The fact that his is cool is no excuse for ours being crap

aGorm

to much tl;dr swift?

aGorm wrote:The fact that his is cool is no excuse for ours being crap

+1

I have a theory for why mapconv sometimes produces these lines on the mip-maps.

It looks like mapconv uses a separate program (nvdxt.exe) in order to create the final texture tiles, including the mipmaps. However, instead of passing each 32x32 tile individually, mapconv appears to create a 1024x1024 "collage" of tiles. Presumably this was done for performance reasons, since calling nvdxt.exe for each individual 32x32 tile would be kinda ridiculous...

The experienced texture artists can probably already tell where this is going :)

What happens is that you end up with a 1024x1024 collage of tiles in which adjacent tiles are sometimes different colors. In other words, you might have a bright green grass tile right next to an orange desert tile. Since nvdxt.exe doesn't know these are separate tiles, it computes the mipmaps normally - adjacent pixels are averaged together when downsizing the tiles.

So you end up with lines at the seams of the tiles, because the edge of one tiles is averaged with the edge of an adjacent tile when creating the mipmaps.

I think the problem could be fixed relatively easily.

The issue is with nvdxt specifically, as Linux builds
of MC go through the same tile-collating process
(but use texcompress to create the dds textures)
yet do not produce the lines.

Wouldn't it be possible to use texcompress[_nogui] on Windows too?
(Or is it slower maybe / other disadvantages?)

Yeah it is, I sent aGorm a win32 (cross-compiled) build of MC
with the hardcoded nvdxt dependency removed that behaves
like the Linux one (so it accepts "-z texcompress.exe" as a CL
argument, etc). Unfortunately the version of libIL it's linked to
(from mingwlibs10) causes artefacts in the temporary bmp's
mapconv writes to disk:

good
bad

No idea why yet, but it's pretty borked.

Does that mean you wont be able to fix it?? Desparatey want it... All dev's should drop everything and fix this problem. No eat's till you do.

aGorm