New to Digital Cartography? Software General Information

[icosahedron]

Thanks for the recommendation - and it is nice to see that you are so keen on it.

But, as I promised Redrobes, I have already tried it. I found it incredibly slow and I can understand why you found personal tutorials helpful.

The tutorials weren't about its speed, on my machine the pan and zoom is so fast I sometimes overrun and have to back up! It was just getting my head around some of the initial learning curve since the program works like no other I've experienced. Having said that, it was a fairly shallow learning curve, and I'm sure when Redrobes has time he'll include some of these things in a helpfile update - I might even send him a draft to peruse if I get time first.

Well, I'm not sure I understand the bit about the DF grid being a cage. You can rescale any object on the map at any time.

Oops, I'd forgotten this bit. It's been a while since I used DF. I sorta stopped using it - I had a couple of big projects I wanted to do, and I was waiting for the zoom to be fixed...

it can go much more detailed than nearly all the images available on the net) and obviously it is up to you what scale the grid represents.

True, I mainly used the 20x20 scale, that's what I had in mind when I mentioned detail. DF can handle detailed images.

I didn't really see VD being a tile mapper but more of an image placer (I might be wrong on this though). If that's the case, then the grid has a different function in the two progs.

What's in a name? VD has a snap to grid and path feature which enables you to lay down repetitive 'tiles' quickly, but you can turn the grid off and place images wherever you want.

I'm not intending to be negative about VD generally - it just didn't work well on my system though it clearly does on lots of others, including yours.

Likewise me with DF, I found it to be a very useful program for producing small maps on the fly and if the updates had happened, I might never have looked for a replacement. In fact, I did use it only last week to send a quick sketch-plan to someone.

Will probably have another look at MapTools soon. BRPG's own mapping ability has improved over time, and I assume MapTools will have done too, though I don't expect VTTs to compete with mapping progs for basic mapping.

I haven't seen Maptools. I stumbled across VD by accident and Redrobes personally sold me on it via email correspondence - his 'before sales service' was excellent, including his advice on upgrading my computer to run VD.

What I like most about it is its ability to act like a 2D virtual universe experience - there are no separate maps in separate files, you just pan and zoom to go anywhere on a planet, and you can jump to any planet. It's a 'universe in a box'. Of course, you have to create the universe first...

Redrobes produced this video sequence, not sure if the link is still live:

http://www.viewing.ltd.uk/Temp/CG/VD_Demo5/Universe.avi

[RPMiller]

There is a map that dorpond did that I think was a couple miles square so yea, no size limits, or if there are they aren't really significant.

There are several tile sets that are currently in use that you can see at the RPTools forums. Users are making pretty large maps inside MT natively.

Oh, and there is a great map of the Temple of Elemental Evil floating around somewhere if you want to see MT handle a really large map.

[trevor]

I also noticed that you'd taken away the maximum cell size limit that I seem to remember from before (50x50 I think it was) <snip> but it seemed to me that the maps would still be done outside of MT primarily.

Must have been a while since your last MT update

<ramblings of a VT developer follows, feel free to disregard>

One consideration of making maps in a VT (like MT) vs outside is the limits of map size. Creating a full size image for the background can cost a lot of memory, especially at high dpi. Which also means more data that has to be transmitted to each player (particularly in VTs that don't send the compressed version of the map, such as BRPG iirc, please correct me if this is no longer the case).

Whereas if your scene has a lot of duplicate images you can create the same scene directly in the VT with very little memory by using the same image for each instance, regardless of rotation and scale (this is what MT does). So you could conceivably have a forest of trees, with maybe 3-4 derivatives, that goes on forever (well, within reason), and takes no more memory than those 3-4 images.

One advantage of making the map outside of a VT is the ability to use the resulting map across (nearly) any VT. That is, a jpg is a jpg is a jpg. Whereas if you make a map in a VT using that VT's tools, it will only work in that VT.

One advantage of making maps inside any VT is the "rich" features you can build into the map. Such as the ability to move chairs and open doors (or burn stuff down, as the pyros in the house are wont to do ), or have vehicle combat that spans several 10s of miles (or more!).

Over the years I've seen both style executed extremely well. For example, I recently opened a user's campaign to help debug some speed issues, and was in awe as I zoomed out and looked at the extent of their cave system. It was huge, and immaculate. And all built directly in MT using drawing tools with textures, and stamps. On the other extreme there are users that build amazing jpg map with tools like dundjinni and photoshop, that look like I could reach ouch and touch them.

Different GMs are comfortable with different styles, I think both methods are valid and that it's valuable to support both (and everywhere in between ).

[Redrobes]

I agree with all that said there. I started writing my app as a campaign world mapper first and added the VTT bit second. If all you ever do is battle map fights then its not useful to have zoom - well some are like ranged weapons or flying battles etc but most hand to hand stuff can be done at a fixed battle scale.

What I wanted was a system where you could have many many DMs all mapping bits of a world and bring it all together - a lot like the CWBP, which is why I try to support it as much as I am able. I would like to go into a city and pick any house and go in and get the map - a proper map that makes sense instead of a random one.

Trevor is right in saying that you lose something having the map in a custom format. If all the mappers and VTTs used a common format then it would not be the case and I think we would agree that having it in that format would then be better. Its the lack of interchangeability thats the problem. Since PNGs are being used almost exclusively now for the image format then that is something that can be agreed is the good format for a tokens nowadays. Its actually extremely difficult to come up with a common format however. We could all use XML and extend it in the ways required by each app but I don't think even then that it would be capable to doing what we want. I keep my layout icon files as text so you can read them and maybe write a script to convert if required but I doubt anyone would.

Having the map in a custom format that allows for reuse of the images does save a lot of memory tho. I have asked before and was told that DF does this and like MT, I do it too. I was told that DF wraps all its used images into the map file. I keep mine separate and I don't know what MT does. If you looking at a map with a lot of reuse then it gets very small indeed. I have some music score which is so tiny its unbelievable. Its actually smaller than the vector file PDF of the same music and about the same res too and then of course a second page of score would be proportionally less again given the extra reuse. Also in the same vein, the RAM used while looking at the map is a lot smaller too since the map 'image' is held as a series of variable resolution parts and we don't burn RAM with layers holding a lot of blank areas. Pro's and Con's always - its just that some people don't see that there are some cons with their one big piece of software.

[Redrobes]

Dormouse, I have no idea why your system is running that so slowly. For the top line to print that it would suggest that the app is asking if your card driver supports OpenGL and its saying it does. Then it goes off and asks if it supports a list of required features and its not complained that any are missing. So as far as its concerned it has linked to the ATI card driver and has handed off all drawing to it. So for it to go so slow implies that the ATI driver is not running OpenGL correctly.

If you go to the desktop, right click, for the Display Properties, Settings, Advanced, Troubleshoot. There is a slider to control hardware acceleration. Yank it all the way to the left for None. Ok that and try the demo again. I tried it and got this...

Your graphics card is not capable of accelerating this OpenGL
    application. The program will still run, though very slow
    depending on how fast your CPU is. If you are expecting that
    your card should have accellerated OpenGL then check that
    the driver is installed properly. Certain older cards may
    claim to accelerate some OpenGL but this program is requiring
    features not supported by it. Look at www.viewingdale.com
    to see if there are any special notes about this card

OpenGL is successfully running this application using the Windows
    software renderer.

Frames rendered: 864

Frames per second: 28.8

Your system is of moderate speed and will run ViewingDale though
    you will notice some slow down on complex scenes.

You would benefit greatly from adding a graphics card that accelerated
    OpenGL when running ViewingDale.

So this is using the software renderer which on my machine is about 15x slower than hardware rendering, but even then, its not 4fps. I am wondering if you did this that it would actually speed it up in your case !

Dont forget to slide the troubleshooting bar back to the right !

I would suggest updating the driver but thats up to you and its a good idea to take a system restore point before doing it (http://www.microsoft.com/windowsxp/u...emrestore.mspx) . I am sure that you would find other apps like Blender, Sketchup and so on would run a lot better if your OpenGL was functional.

[dormouse]

Dormouse, I have no idea why your system is running that so slowly.

SOLVED! (I think)

I would suggest updating the driver

I did that. Difference nil or minimal.

I always thought that the issue was likely to be a conflict with something else running on my machine. I'd not noticed any other application running slower than it should so I have no idea if anything other than VD was or might have been affected. Your Test App was really helpful in testing as I suspended/unloaded various processes etc.

Turned out (I think) that the culprit was CircleDock. Unfortunately, it's something I have open and use all of the time. I shall report the issue, but unfortunately again the developer seems to have been taken over by real life a few months ago. Anyway, I have reinstalled VD and will have a look; I'm willing to spend some time without CircleDock, every now and then at least

[dormouse]

Having the map in a custom format that allows for reuse of the images does save a lot of memory tho. I have asked before and was told that DF does this and like MT, I do it too. I was told that DF wraps all its used images into the map file. I keep mine separate and I don't know what MT does.

I see that. For a VTT, it's much more efficient to keep images separate because they might be used in different maps. For a pure mapmaker, the advantage of wrapping everything in the map is that it becomes totally portable between users (not that I noticed many users of DF exchanging maps

[dormouse]

Must have been a while since your last MT update

Well, seems like little more than yesterday to me

One consideration of making maps in a VT (like MT) vs outside is the limits of map size. Creating a full size image for the background can cost a lot of memory, especially at high dpi. Which also means more data that has to be transmitted to each player (particularly in VTs that don't send the compressed version of the map, such as BRPG iirc, please correct me if this is no longer the case).

I don't really know if this is still the case in BRPG. Doesn't really affect us since we are all in the same room. If we were operating over the net though, I'd make sure that we all had all the maps on our computers before we started. And we might well use something like Dropbox as the easiest way of doing it. It's the recommended way of doing it in BRPG, and I don't see any advantages of actually doing the sending within the VTT unless you absolutely have to. There's enough going on without that.

Using this system, it works well to have a lot already on the base map and all that needs to be sent is the ID of the images being used.

Whereas if your scene has a lot of duplicate images you can create the same scene directly in the VT with very little memory by using the same image for each instance, regardless of rotation and scale (this is what MT does). So you could conceivably have a forest of trees, with maybe 3-4 derivatives, that goes on forever (well, within reason), and takes no more memory than those 3-4 images.

Fine for the forest; amounts of duplication in many of my maps is limited, mostly textures for floors etc.

I recently opened a user's campaign to help debug some speed issues, and was in awe as I zoomed out and looked at the extent of their cave system. It was huge, and immaculate. And all built directly in MT using drawing tools with textures, and stamps. On the other extreme there are users that build amazing jpg map with tools like dundjinni and photoshop, that look like I could reach ouch and touch them.

I do see the advantages of both, but I find the latter works best for atmosphere. Which we like best. Not needed for fast moving hack and slash though or stuff that is mostly in the mind. The choice is a world away from the days of moving dice and salt cellars between cereal packets, books and magazines LOL

[dormouse]

One advantage of making the map outside of a VT is the ability to use the resulting map across (nearly) any VT. That is, a jpg is a jpg is a jpg. Whereas if you make a map in a VT using that VT's tools, it will only work in that VT.

Is this really the case for MapTool?

Seems to me it will 'save' as a PNG, even if it is only an export screenshot. Haven't started working out the resolution effects of that; presumably it is dependent on zoom etc.

I can see that this is still in development. Export 'whole' map will be good when it comes, so would export/save defined area. I assume 'save', is achieved by 'save campaign'; does this allow other MapTool users to acquire the images in maps/campaigns shared with them? Only major issue is the lack of control of drawn areas once they are drawn; not a problem for a VTT usage, but is a problem if used as a mapper.

Seems to me (so far) that there's not a huge number of useful functions (as a mapper) that MapTool is short of. No fractals (but not really needed on battlemap/VTT scales); no randomisation; no shadow control for walls/objects (really suited to being done in a VTT); no/limited number of wall modifiers; no scaling control for textures used for walls/fills (one plus of a tiling system is that the tile textures are autoscaled to the grid).

Special door objects (or rather a set of controls for objects used as doors) would be good; could be designed with rotate options. Ditto for windows (all windows would share settings for light). Ability to define buildings/caverns would be good (ie no internal light, only comes in through open doors and windows if there is light outside).

An option to gradually blend one texture into another would also be nice. Not that I know of any other mapping prog doing that.

Have to say it is looking pretty impressive. Especially when I have always thought of DJ as being clunky because of Java

[trevor]

Is this really the case for MapTool?

Perhaps it's because of my familiarity with how MT works vs how I _want_ it to work

The drawing tools are long overdue for a rewrite. There are also a ton of map making tricks that have been on hold for a long time now (a couple you have mentioned already).

Also, as you mentioned, the export only exports the current viewport, not the entire map.

So, from my perspective, if the end result is a jpg or png, there are other programs out there that are much better suited for that task.

But the MT users constantly suprise me with what they come up with, so I may not be the right person to ask