Spring RTS Engine

.....
Creating tiles 91041/245248 93%
Creating tiles 91069/245760 93%
Creating tiles 91096/246272 93%

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

AHHHHHHHHHHHHHH!!!!!!!!!!!!



-Buggi

I've tried three times, on two machines, and it always bombs at 93%...

Argh!

-Buggi

I've tried different compressions and everything...

I've put about 60 hours into this map, I'd hate for some mysterious "thing" to stop me now...

-Buggi

I'm going to just keep appending onto this thread... thinking outloud

Anyway it seems to always quit when...

y*xsize/4+x = 246272

*continues digging*

*more*
Okay I found some more information. I did a generic try/catch around the block, but I don't know what TYPE of exception is thrown so I have to just catch all.

However, I did print out the current x and y values after the exception.
x=64 and y=481
Now what how those values are being used, I don't know. Nor can I guess why this situation throws an exception. I see no out-of-bounds arrayness happening.

-Buggi

Check out the code from the cvs and run it in debug mode should make it easier to find.

I was thinking about doing that... but my poor system.. *patpats*

One thing that BEGS an answer is why doesn't the map texture consist of just a JPG file. There'd be no need to "tile" anything.

I took my AsiaPacific texture file which is 473 megs and saved it as a JPG and it saved to 9 megs.

I take my EternalStruggle bmp file which reins in at 786 megs and the size of the JPG? 11 megs.

11 megs!!! Versus 786 megs. I get out of memory errors when trying to convert the BMP file and I get this odd crash when trying to convert using the JPG file.

Why not just use the JPG file as the texture map and apply the height to it without the need for tileing stuff?

*sobs*

-Buggi

Even if the maps are stored as a jpg picture they still would need to be decompressed into memory.

Even if the maps are stored as a jpg picture they still would need to be decompressed into memory.

Not if they were worked with directly in the compressed format without decompressing. It would be lots of work to implement, certainly.

I'm looking for some solution that helps fix this. So far I haven't gotten to create my map once because of this, this seriously hinders mapmaking.

-Buggi

Upon debugging... I'm thinking memory overflow...

In the begining we stored stuff in memory as jpegs and decompressed them to textures when needed but it was a lot slower than the current system. (although it was technically more cool :) )

Sounds like you runs out of memory if alloc fails.

Jpeg is not a loseless format. The littles jpeg compressions errors (small squares, ripples, etc) will lead to ugly looking heigh map, with 'square stairs' everywhere (just look rigth now about the prb already existing with the heigh map resizing prbs, and aliased borders. It will be even worse if jpeg is used)
Jpeg could only be used for the texture map. For the heigh map, you need to find a lossless picture format.

Dude, I used jpg for the texture map, the height map is tiny compared to the texture map.

If you are running Windows XP you can try to:

Enable the /3GB switch to the Boot.ini file ( try looking at http://www.microsoft.com/whdc/system/pl ... AEmem.mspx for more info) Be warned! If you make a mistake with your bootloader entry then your system may not boot! If you have not done this before, make sure you do some research.

and

Relink MapConv using the /LARGEADDRESSAWARE switch in the Linker (see http://msdn.microsoft.com/library/defau ... ension.asp )

You'll also need to add more physical RAM to your system, to improve performance.