Page 3 of 4
Posted: 06 Jun 2005, 13:24
by NOiZE
i made a 2048x2048 texture map
a 257x257 heightmap
a 257x257 metalmap
when i try to compile the map i get the following..

Posted: 06 Jun 2005, 18:19
by CnlPepper
I've just released the source files to my Africa Coast map if people want a set of source images to test/learn this program with. As these are known to work it may be of some help to those fiddling with the program.
The download link is in a post near the bottom of this thread
http://taspring.clan-sy.com/phpbb/viewtopic.php?p=16758
CnlPepper - Helpful?
Posted: 06 Jun 2005, 19:26
by Buggi
NOiZE wrote:i made a 2048x2048 texture map
a 257x257 heightmap
a 257x257 metalmap
when i try to compile the map i get the following..
First, you're setting yourself up for failure, read my posts on spaces in your directories.
Can you zip those files and get them to me somehow?
-Buggi
Posted: 06 Jun 2005, 22:56
by aGorm
Mine gets stuck here... 15 strips... out of 16... bloody weird.
The old mapconv accepted a metal map that was the same size as the terrain, and you said yourself that teh prog would resize things to the right dimentions...
Not that its even got to that bit yet... its still trying to split my bmp.
aGorm
Please make it work...

Need the best and this... apart from the bug... is the best.
Posted: 06 Jun 2005, 23:04
by Buggi
Okay, if your metal map isn't the same size as your height map, your geo's will not be where they need to be. I look at every pixel in that file and if it's green, (green > 240) I place a geo at that x*8 and y*8 location. So you can see why that wouldn't be good.
Can you send me those files? PM me with a URL or something for the zip. I'll have to debug line-by-line to figure this one out.
You certainly like your grass... ^_^
-Buggi
Posted: 06 Jun 2005, 23:19
by aGorm
Fine. Ok. Kill Me Now. I re-sized the MetalMap to 1025 insted of 1024 and this time it worked because I was actully awake. I say it worked... Its actully still running but its got past the last stage... So hopefully it will!
Update When its done...
EDIT:: It all worked fine, expect m,y new map withing a week...
aGorm
Posted: 06 Jun 2005, 23:56
by Buggi
@_@;;;
*smiles and nods*
-Buggi
Posted: 07 Jun 2005, 01:33
by mufdvr222
Weeeee,, it worked, but I get these artifacts.
any ideas.
Posted: 07 Jun 2005, 02:36
by Buggi
Which version of SharpMap are you using?
That was a problem that cropped up when I completly re-wrote tile parsing and is fixed in the latest version.
-Buggi
Posted: 07 Jun 2005, 03:55
by Dragon45
Any word on the status of a reworking of the map format itself?
Posted: 07 Jun 2005, 04:55
by interrupt
Reworking the map format is a beast - first everyone needs to decide on a format, then a map making program needs to be made for it, and then finally spring has to support it. Getting all those pieces together is going to take some time.
Posted: 07 Jun 2005, 07:11
by Dragon45
The order is different- the SYs will do what they damn well please, then we'll all come around to agreeing with it, then Buggi will make a new program for it

...
Posted: 07 Jun 2005, 23:55
by hrmph
Great concept, program works fine and looks perfect. EDIT: AH Now I see, this makes perfect sense because I'm on a 1.3ghz with 512 of ram. Note: Just thinking to myself it would be ubercool if, in the future version where metal patch stamps will be possible, the user can produce his own stamps (IE: a texture with a specific heightmap, like core prime industrial's middle areas) Although you have probably already been thinking about something like this.
Posted: 08 Jun 2005, 02:04
by Buggi
I do a massive amount of error checking that the console based system doesn't do. I also use memory in a vastly different manner.
While the old version relied heavily on ram amount, my converter really benefits from processor speed.
a 20x10 map took 11 minutes to convert on my main system (3.2 Ghz). The same map, same settings, took 15 minutes on a 2.4 Ghz machine.
It's crunching a LOT of numbers. It basically analyzes every pixel.
What I'd like to do, is set the texture bmp, then allow the person to set the size of the map they want, and it would programatically stretch the bmp (or the strips) to that size and then process the tiles, or process the tiles then stretch them (the latter would be insane code though).
-Buggi
Posted: 08 Jun 2005, 11:13
by TARevenger
hey buggi
I have a 32767x32767 image 3gig (64x64 map size

) and i'm getting a "split texture failed" error message.
anyway to fix it up?
and for those who want 64x64 map textures download this little app
http://www.trulyphotomagic.com/shortcut ... info&cat=3 the app resizes and cleans the image up to look much nicer
the trial version puts a watermark on the image if thats a problem
it's probably a lost cause as I can't even open the 3gig image file

Posted: 08 Jun 2005, 15:38
by aGorm
32767x32767 images are above even photoshops limit (im pretty sure anyway...)
Its taken me 3 evenings to get my 32x32 map together... so i hate to think how the hell youll touch up a 64x64...
I suspect that it failed becasue theres no way it can read such a bmp... even if it should theroeticly be able to!
aGorm
Posted: 08 Jun 2005, 15:47
by Redfish
Yeah the gimp can handle bigger images but don't expect to do anything except swap if you don't have 4 GB of ram. Also doing these map sizes is not efficient in editing programs. However the use of command lines cannot be used here. So maybe we need a tiling editor that can edit parts of a huge map without having huge mem demands. And then combine the maps into 1 huge map.
Posted: 08 Jun 2005, 17:03
by TARevenger
32767x32767 doesn't work as when you divide by 8 you get 4095.875 which the map compiler doesn't like
so I dropped it down to 63x63 (32256x32256) which worked but now I'm getting the "index was outside the bounds of array" message
well at least the compiler split the 3gig file into a managable 64 editble files to view the watermarks left by photozoom.
very handy app to enlarge the surface textures if your paint progam can't.
no point using it in free trail mode

Posted: 08 Jun 2005, 18:24
by Buggi
okay... um..
For one, the "unit" of messure for a TA map. 1x1 or 30x30, is that value times 512.
1x1 would be a 512x512 image. 32x32 maps are 16384x16384. The texture has to be divisable by 512 otherwise it won't even work in spring.
Also, the current MAX_SIZE setting in the GUI program is the same for the original converter. And that is 40x40.
I don't even have files to test anything over 58 because photoshop can't create/load images greater than 30K pixels
If anyone wants to zip one up (incl metal and height maps) so I can test, then I could work with it. Just make sure your images are 24bpp!!!
Also, it would be pointless to make maps of that size as Spring couldn't even load them. I'll have to check into the code for that.
-Buggi
Posted: 09 Jun 2005, 12:12
by sp2danny72
I tried a program called xRes a long time ago.
Back then it was waaaay better than photoshop
in handling large files. It was from macromedia
if i remember correctly. Maby its still around?