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.

[Mouse]

Who's arguing?

I'm not

[Mark Oliva]

Back to Heruca:

Once again, I am in no way trying to put your MapForge down. I've been following your work, mostly on the Dundjinni forum, for more than 10 years, and your contributions to the cartographic community are both tremendous and excellent. That's exactly why I'm raising the issues that I did. For the non-GIMP, non-Photoshop elements of the cartographic community, Dundjinni brought RPG cartography light years ahead in an age when CC2 Pro and FM7 still were stuck in vector cartography that usually produced maps that looked like something from a low grade imitation of an animated Disney film.

However, Dundjinni also is a program that burned itself out, and I would dislike very much seeing you launch a program that ends up doing the same thing. Dundjinni is a program that didn't manage to grow with the times. For those who still can get it to run (I can), it continues to make better battlemaps than anything I've seen (or made myself) with FM8 or CC3/CC3+.

However, when one tries to make a larger scale overland map or a city or village map with more than a few buildings on it, one gets into trouble. The reason for this is that Dundjinni has a single scale for all objects (symbols) and textures (fills). In comparison, CC3+ has four different scales available for each object or texture, and it automatically picks the best version of the object for the scale currently being displayed. FM8, like Dundjinni, offers its objects and textures in a single scale, but unlike Dundjinni, FM8 has different scales for overland, city and dungeon objects and textures. Both systems produce good results.

However, because Dundjinni has only a single (official) scale for all objects, and because Dundjinni can use only a limited amount of memory (like all 32-bit applications), one finds oneself in trouble in short order when making a map like the sample from our project group that you posted above (a map that was made with FM8 ). When one sticks with the official, single Dundjinni scale of 40 pixels = 1 scale foot, the building objects are unnecessarily huge. Some of these objects (symbols) have a size of more than 20 MB each. That size isn't necessary for such a map, but it's the only official size. In Dundjinni, duplicating the map shown above causes an incredible result. One cannot merely make a cup of coffee while waiting for Dundjinni to draw the map on the screen. One could in theory drive to relatives 50 miles away, drink a cup of coffee or two with them and then return home before Dundjinni is done drawing ... and that with a modern computer using SSD drives and 32 GB memory. However, that's only theoretical. In practice, Dundjinni will have crashed before one reaches the distant relatives.

That notwithstanding, one can successfully make such a map with Dundjinni, if one goes into a graphic program and makes new, scaled-down versions of the objects and textures being used. I've made such maps with Dundjinni by scaling down the objects and textures from 40 pixels = 1 foot to 10 pixels. However, that requires the creation of down-scaled versions of every single object and texture used in the map. Who wants to do that, when one can buy FM8 or CC3+ and avoid that?

That's the reason I brought up the scaling issue. I'd like very much to see you succeed with Map Forge, regardless of whether I would use it personally.

On the 32-/64-bit issue:

This really has nothing at all to do with learning to walk before you fly. Writing 64-bit code is no more difficult than writing 32-bit code. But many of your potential users are running 64-bit Windows, and a substantial number of them will have 8 GB memory or more. Many decent laptops leave the factory these days with 8 GB as standard. People are starting to want to use what they buy. If you read through postings here, you'll find that one of the things, among others, that are driving CC3+ and Dundjinni users over to The GIMP and Photoshop are the limited resource usage of Dundjinni and the frequent crashing and non-performance of CC3+ (If that means nothing to you, read ProFantasy's own forum).

From your last posting, I assume that Map Forge will be an application that runs on top of another program's machine, just as CC3+ is an application that runs atop Evolution Computing's FastCAD. If that's the case, and the machine you've selected is 32-bit only, you have no alternative. That's similar to the dilemma that ProFantasy faces with Campaign Cartographer. To produce a 64-bit version, Evolution has to come out with a 64-bit FastCAD machine that ProFantasy can use or ProFantasy has to drop FastCAD and program its own machine ... no minor chore.

In any case, if you're committing a lot of your time and/or money to Map Forge, I hope you'll seriously address the question of how many people might buy your product over what period of time. If it's a 32-bit edition, my guess is that most folks will look at it as an alternative new Dundjinni version, and that it will have decent startup sales among Dundjinni users who want an update. But will it be able to sustain sales after that initial bubble breaks, or will it burn itself out and lose its market like Dundjinni did once Fluid Enterprises decided to drop the program after the big Dundjinni bubble.

You've done a lot for us here in the cartographic community. I'd like to see you succeed. That's the only reason for these remarks.

[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.