New battlemap-creation software on the way

[Redrobes]

Lack of physical RAM is a problem whatever bit program your using I agree. But what I was saying is that if you had say 16Gb of physical RAM and you want to run a 32bit app which then limits the apps process to being able to access 2 or 3Gb or so (depending on the setup) then you have 13Gb of physical RAM you cant access unless you use a 64 bit app. But you can run a 32 bit app which creates many processes (instead of many threads) whereby each process can run up 3Gb of allocation. So its possible to have a 32 bit app use all 16Gb of physical RAM. Most web browsers open a new tab in a new process because a) it isolates the page from other pages which is for security and b) you can have pages running up large memory footprints and have many of those pages. So what I was saying is that being a 32 bit app is not a hard limit to accessing large amounts of RAM. But a lack of memory sticks in the machine is always going to be a problem for large multi layered maps no matter how you slice it. But if you can only compile / write 32 bit apps (see herucas post #12) then its not a dead end situation for the ability to deliver large mapping capabilies.

The XCF thing I agree with you. It didnt appear from post #14 as though that was what you were saying. But with that clarification - I agree.

[Mark Oliva]

Lack of physical RAM is a problem whatever bit program your using I agree. But what I was saying is that if you had say 16Gb of physical RAM and you want to run a 32bit app which then limits the apps process to being able to access 2 or 3Gb or so (depending on the setup) then you have 13Gb of physical RAM you cant access unless you use a 64 bit app. <SNIP>

I understood, and I agree.

The XCF thing I agree with you. It didnt appear from post #14 as though that was what you were saying. But with that clarification - I agree.

As I said, I wasn't very clear. I think describing The GIMP as a bitmap program with layers will leave a wrong impression with some people who don't have a lot of technical knowledge, leading them to think that The GIMP produces bitmap graphics that one can open in programs like MS Paint with file extensions like BMP, JPG and PNG. This, of course, isn't what The GIMP does, It produces a raster graphic file that consists of one or more layers, each of which is a bitmap. To make this into a flat bitmap that's the kind of file many understand a bitmap to be, the content of the native XCF file graphic has to be flattened and exported as a BMP, JPG, PNG or whatever. I thought this difference should be mentioned.

I ran some tests with MapForge, exporting a 10Kx10K pixel image in 24-bit color (uncompressed size: 300000000 bytes) and it took between 8 and 31 seconds to complete the export to PNG format. Exporting to JPG and BMP format took much longer, but was still very fast in comparison to DJ.

If I counted the zeroes right, 300000000 bytes = 300 MB.

That's a pretty good performance statistic.

Not a plus-or-minus point, but a curiosity. You mention the PNG conversion being faster than the BMP and JPG conversions. As I understand it, all three were exports from Map Forge. A question then: Assuming (perhaps incorrectly) that the conversion was a direct conversion from memory to new file, did you compare the JPG and BMP export times to the times that would result in converting an exported PNG file from Map Forge into BMP and JPG files with an external program?

Whatever the case, I'll be watching this with interest. Even if the end result is nothing more than what amounts to a new and improved version of 32-bit Dundjinni, it's still more than we have now. I'm on your side. I hope you succeed!

Good luck!