Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 50

Thread: New battlemap-creation software on the way

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Publisher Mark Oliva's Avatar
    Join Date
    Jul 2009
    Location
    Altershausen, Northern Bavaria
    Posts
    1,505

    Default

    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.
    Mark Oliva
    The Vintyri (TM) Project

  2. #2
    Administrator Redrobes's Avatar
    Join Date
    Dec 2007
    Location
    England
    Posts
    7,201
    Blog Entries
    8

    Default

    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.
    Last edited by Redrobes; 02-17-2017 at 06:45 AM.

  3. #3
    Publisher Mark Oliva's Avatar
    Join Date
    Jul 2009
    Location
    Altershausen, Northern Bavaria
    Posts
    1,505

    Default

    Quote Originally Posted by Redrobes View Post
    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.

    Quote Originally Posted by heruca View Post
    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!
    Mark Oliva
    The Vintyri (TM) Project

  4. #4
    Software Dev/Rep heruca's Avatar
    Join Date
    Nov 2006
    Location
    Buenos Aires, Argentina
    Posts
    172

    Default

    I do remember Dundjinni taking what seemed like hours to export the final map. 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.
    Looking for battlemap creation software that can be used to create gorgeous print-resolution output on Windows or Mac OS?
    Give MapForge a try.

  5. #5
    Software Dev/Rep heruca's Avatar
    Join Date
    Nov 2006
    Location
    Buenos Aires, Argentina
    Posts
    172

    Default

    To clarify, what I exported was just a floodfill tile texture that was randomized to make each tile different. MapForge doesn't really have layers yet, aside from a grid overlay (which adds about a second to the export time, if you export with a grid). This is being tested on an early prototype. Performance may be slower in the final shipping app (which WILL have layers), or it may be even faster once optimizations are added.
    Looking for battlemap creation software that can be used to create gorgeous print-resolution output on Windows or Mac OS?
    Give MapForge a try.

  6. #6
    Software Dev/Rep heruca's Avatar
    Join Date
    Nov 2006
    Location
    Buenos Aires, Argentina
    Posts
    172

    Default

    I think you counted the zeroes right, because my BMP export was 300MB. I think most of the time saving to BMP format is spent writing the huge file to disk. The PNG export was just 4.9 MB. JPG was around 3 MB, but it took so much longer it's not worth the savings. Probably faster for a user to open the exported PNG in MS Paint (or whatever) and "save as" a JPG.
    Looking for battlemap creation software that can be used to create gorgeous print-resolution output on Windows or Mac OS?
    Give MapForge a try.

  7. #7
    Software Dev/Rep heruca's Avatar
    Join Date
    Nov 2006
    Location
    Buenos Aires, Argentina
    Posts
    172

    Default

    Thanks. Not sure that anyone's really arguing, though, just clarifying misunderstandings.
    Looking for battlemap creation software that can be used to create gorgeous print-resolution output on Windows or Mac OS?
    Give MapForge a try.

  8. #8
    Administrator Redrobes's Avatar
    Join Date
    Dec 2007
    Location
    England
    Posts
    7,201
    Blog Entries
    8

    Default

    Agreed, when designing systems the devil is in the details. Its important that the details are well understood by everybody in the same way. Small differences in understanding always lead to big implementation problems. Its not that in this case were designing it but it is important to understand the design details that Heruca is outlining.

    300Mb sounds right to me. 10,000 x 10,000 x 3 (RGB) is 300 million bytes. Its odd that it takes longer to compress to JPG than PNG. Its almost extraordinary that it is longer to save an uncompressed BMP file than a PNG. In the process you have compute and I/O. Since the PNG is only 5Mb then it implies that the system on which it was being tested had great CPU performance to compress it but terrible HDD performance to store it. If you had used a slower CPU machine with an SSD I would have expected it to be very different. Also, it implies that the system did not have 300Mb of cache RAM spare to offload the file before it was saved. Most systems / OS's 'save' the file to a system buffer which then chugs it out to the HDD in the background and gives control back to the app. Its possible tho that the app tried to check the file by reopening it (or doing some kind of stat on it) which would force the OS to stall that check until the save had fully completed. I know on my app the PNG is the slowest, JPG is better and BMP is fastest. I do overlap the render and save at the same time for bitmaps (BMP files) but I cant do that for the other two tho. So maybe that skews the timings a bit. Even so I would think that you may need to check those times on various bits of hardware before really relying on them. Its a very unusual result to say the least. JPG is normally quite quick to compress and quick by being small to save so normally wins. Some CPUs have special instructions that can be leveraged to help save JPGs but a JPG library may need to ask for them at run time. If they didn't exist then it could be slower. Lots of reasons the speed could change between hardware.

    I agree that CC3 is doing special stuff regarding its layers. It obviously has to in order to do 135 layers. So its not comparable to measure it against GIMP. The texture fill thing is an obvious trade off between memory usage and versatility. As an bitmap / raster / image editor (you pick) Gimp is clearly going to be able to have anything going on at any point in one image layer since it has allocated enough memory for the whole sheet. I know a lot of mappers here at the guild are artists that make great maps rather than CAD like in their approach which is why we get a lot of photoshop / Gimp users. Artists will make use of the layers at all points and so Gimp runs rings around CC3 in that respect. So you win some you lose some by taking the trade off. Incidentally its a trade off that I took with my app and as such you still needed an image editor to use it properly. In my mind CC3 and Gimp (a vector - hybrid and a raster app) operate in two separate spaces. But I know I would be fighting a lonely battle if I kept up with that argument - but I believe it nonetheless. Some apps like Xara bridge it well but no app does both sides as well as the best dedicated ones. To pick a camp one side or the other is to miss the point so to be entrenched into one side and waving the flag proudly is a poor decision.

    So yeah, how to make a mapping app that handles the best of vector and raster at the same time ? If you go for one or the other then there are other apps out there already which do it well I think because its easier to persuade people of the benefits of each individually and so the graft of development has already happened. But I am in the camp that if targeting maps specifically as opposed to maps of pure art then there could be a better option. That option is still not implemented. Its a hard task. Part of the task must be to persuade / show or realign peoples mentality about how to go about mapping to the way your app is going to do it - which is something I found extremely challenging. So my very best of luck to you with your endeavor.
    Last edited by Redrobes; 02-17-2017 at 02:10 PM.

  9. #9
    Software Dev/Rep heruca's Avatar
    Join Date
    Nov 2006
    Location
    Buenos Aires, Argentina
    Posts
    172

    Default

    I have an SSD on my computer, but it is nearly full and is probably having a hard time because of that. That might explain why the BMP took so long to write to disk.

    What is your app called, Redrobes? Good to see you here again, by the way.
    Looking for battlemap creation software that can be used to create gorgeous print-resolution output on Windows or Mac OS?
    Give MapForge a try.

  10. #10
    Community Leader jfrazierjr's Avatar
    Join Date
    Oct 2007
    Location
    Apex, NC USA
    Posts
    3,057

    Default

    Quote Originally Posted by heruca View Post
    I have an SSD on my computer, but it is nearly full and is probably having a hard time because of that. That might explain why the BMP took so long to write to disk.

    What is your app called, Redrobes? Good to see you here again, by the way.
    ViewingDale. There is an older Youtube video if you want to check it out. The way it deals with zoom is really really cool. If I did not have a VTT, I might consider it simply because of that feature.
    My Finished Maps
    Works in Progress(or abandoned tests)
    My Tutorials:
    Explanation of Layer Masks in GIMP
    How to create ISO Mountains in GIMP/PS using the Smudge tool
    ----------------------------------------------------------
    Unless otherwise stated by me in the post, all work is licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Page 3 of 5 FirstFirst 12345 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •