New to Digital Cartography? Software General Information

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

I like having maps that I can always use, whichever system or VTT I might be with at the time. So I'd be very reluctant to develop a large library of maps that tied me to that VTT - or mapping prog if it comes to that.

That said, I'd be happier to create more using a VTT if I had the same tools, effects and speed of creation that I can get using a pure map prog, so long as the end result was as atmospheric to play.

What I do now is to create the base map with all the fixed elements. The movables I add in the VTT. And I make sure that I have a load of compatible textures, objects etc available should I need to do something spontaneous.

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

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

[guyanonymous]

Ok...I'm lost - VT?VTT?MT?DF?VD?

VD is ViewingDale I'm guessing...the others?

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

Ok...I'm lost - VT?VTT?MT?DF?VD?

VD is ViewingDale I'm guessing...the others?

VT = Virtual Tabletop
VTT = Virtual TableTop
MT = MapTool
DF = DungeonForge

and you're right
VD = ViewingDale

[Redrobes]

LOL - yeah you have me there...

VD = ViewingDale (At least outside of a hospital and in the guild...)
MT = MapTool
DF = DungeonForge

VT and VTT are used interchangably by different people but its all Virtual Tabletop or TableTop depending on your preference. I never liked either term but its the ones that have stuck and become popular.