New battlemap-creation software on the way

[Mark Oliva]

It'll run on 64-bit, but I suspect the executable is 32-bit.

Don't misunderstand me please. You've been one of the really great assets to the cartographic community for a long, long time, and I really respect your work. However, 64-bit operating systems have been the standard for some time too. I have three 32-bit cartographic programs - Dundjinni, FM8 and CC3+. I'm dissatisfied with all three because of the squeeze at the 4 GB memory border. Even if it's far better than anything I already have, and if you're producing Master Forge it will might be, I still can't picture myself developing much interest in yet another 32-bit cartographic program. For me it's not a still birth but rather an obsolete birth.

[heruca]

Fair enough. I'm limited by the development environment, so it isn't really my call.

[Mouse]

Don't be discouraged heruca. No one ever learned to fly before they could walk, and its the same with software development I'm sure.

I use CC3 mainly, and apart from the speed issue you tend to get when you have a map with 135 sheets (those are layers in PS-speak), and 350 sheet effects (layer effects), then things are going to be just a tad on the slow side - even with a 64-bit app I have yet to see a bitmap app that can handle that many layers in one doc, and throw out renders (exports) at 10,000 pi square - but CC3 seems to do it ok, even though its only a 32-bit app

[Mark Oliva]

I have yet to see a bitmap app that can handle that many layers in one doc

??? Bitmaps have no layers. They're flat.

[Mouse]

GIMP is a bitmap app, not a vector programme. It has layers

Speaking from experience - although GIMP has features I can't reproduce in CC3, like the ability to variably blend one fill into another using a brush, it can only do so with a maximum of 7 layers at a time on my machine, whereas working on the very same machine in CC3 I can have at least 135 layers (CC3 sheets) in one file and still be working on it with all 350 sheet effects turned on. That is why I don't believe 32-bit software is necessarily inferior to 64-bit software.

There is simply no way that I could have created Merelan City in GIMP on my machine. GIMP might be a 64-bit app, but its just isn't efficient enough with the system memory and processing power to be able to do much more than a very small corner of the CC3 map I created.

The same is also true of all the other 64-bit graphics apps I have - CorelDraw 11, Corel Photopaint 11, Krita... and so on.

[Mark Oliva]

GIMP is a bitmap app, not a vector programme. It has layers

I'm not interested in arguing with you about this, but the above may confuse some others. For their benefit:

The GIMP produces raster images, not vector images, and those raster images certainly are in layers. However, the native format .XCF files with layers that The GIMP produces are not bitmaps. The GIMP certainly can export the content of its .XCF raster images as bitmaps, if one wants a bitmap in the end. And in fantasy RPG cartography, that's usually what one wants.

[Redrobes]

The GIMP produces raster images, not vector images, and those raster images certainly are in layers. However, the native format .XCF files with layers that The GIMP produces are not bitmaps. The GIMP certainly can export the content of its .XCF raster images as bitmaps, if one wants a bitmap in the end. And in fantasy RPG cartography, that's usually what one wants.

You confusing bitmap the generic term for arrays of pixels with bitmap the file format as in a windows.bmp file. Windows chose to make the file format named 'bitmap' to refer to the arrays of pixels when at the time of Windows 16bit there were not many image file formats about. So Gimp is definitely a bitmap editor.

For Hernan, You probably know this and I am not sure what language or OS your intending to write this new app in but I believe that if it is for Windows (given the target of 32bit) then it may be that MS make the C/C++ compiler free for 64 bit if you take the version without the maximum amount of optimization. Its been a while since I made Windows apps but I think it was called Express or Community edition. The GUI for the free visual studio compiler at the time when I looked at it was not free. I am not sure what the state of that is now. Also for Windows there is the MinGW system where you can compile it using gcc to create 64 bit apps on windows. I thought that if you were writing in Java then the JVM would be 64 bit anyway - but I am no Java coder.

Final thoughts are that even if you write a 32 bit app which has limited memory to 1, 3, or 4 Gb of memory depending on the machine set up, its still possibile to write it multi process where each process has that limit and you can transfer data between processes. Also, its not a fundamental limit of the bits / RAM that determines how many layers you can handle and if an app is written so that it targets the idea that many layers is going to be used then better handling of the memory could prevent the issue. Gimp is super lazy about how it manages the images that it holds.

Also, for Mouse, if you have layers that are greyscale (shadows, masks etc) then do set the Image / Mode to Greyscale instead of the default RGB which should quarter the amount of RAM Gimp will allocate for it. But 10K x 10K x greyscale x 135 = 13.5Gb of RAM uncompressed and if they were RGB then that would be 54Gb of RAM required. Not many image editors are going to handle that and CC3 is not going to either if those are genuinely bitmap layers your referring to.

[Mark Oliva]

You confusing bitmap the generic term for arrays of pixels with bitmap the file format as in a windows.bmp file. Windows chose to make the file format named 'bitmap' to refer to the arrays of pixels when at the time of Windows 16bit there were not many image file formats about. So Gimp is definitely a bitmap editor.

I probably wasn't clear enough. The GIMP (in native .XCF format) generates layers of bitmaps. The XCF file contains not one bitmap but several. For distribution, most people want "a bitmap," which requires a flattening of the image and then exporting into a bitmap file format, such as BMP, PNG, JPG, etc.

I agree with most of the rest of what you have to say on the topic. I can't shed any new light on current free vs. not-free issues. I retired in 2009. My son took over my Microsoft compilers. I have no idea what's current now.

Multi-processing certainly does accelerate things, but I can't agree that it makes up for the lack of RAM at the 4 GB level when one is doing heavy duty graphics.

Gimp is super lazy about how it manages the images that it holds.

Ainnit the truth, as my Dutch grandfather used to say.

[Mouse]

...Also, for Mouse, if you have layers that are greyscale (shadows, masks etc) then do set the Image / Mode to Greyscale instead of the default RGB which should quarter the amount of RAM Gimp will allocate for it. But 10K x 10K x greyscale x 135 = 13.5Gb of RAM uncompressed and if they were RGB then that would be 54Gb of RAM required. Not many image editors are going to handle that and CC3 is not going to either if those are genuinely bitmap layers your referring to.

That's a useful tip about using greyscale in GIMP. Thanks Red

In answer to your last point - CC3+ uses bitmap textures to fill polygons, and most of the symbols/icons are tiny bitmap images, but none of them are stored in the CC3 file. They are all referenced by the software and 'called' (I hope that's the right term) from elsewhere to be displayed on the screen and used to calculate the final output render/export bitmap. Its just easier to refer to them as layers when discussing them with non-CC3 mappers

EDIT: Heruca - When I made my earlier comments about 32-bit being perfectly ok, I was trying to encourage your entrepreneurial spirit, not start an argument with anyone! LOL! Best of luck with your project

[Mouse]

Who's arguing?

I'm not