RPTools.net

Even though you are the programmer I disagree with that statement.

No matter the zoom level that are a certain number of pixels that equate to a grid and that grid represents a real world measurement whether it is 5', 2 meters, 2 cubits or a furlong.

So there is a correlation even if you haven't exposed it.



I'm not sure that I am following you here. Are you saying that if I bring in a graphic while at a 200 px/grid zoom level and then back off to a 40 px/grid level that the 200 px object will be scaled down to 40 px?

Is it assuming that images brought in as stamps are always 1 grid unit in size?



That was kinda the point of my post.

If MapTool does not have a "native size" than no one will be able to make bitmapped objects that will be at the correct scale. Every object that is brought in will have to be scaled at the time it is placed on the map.

If a 40 pixel item is brought in and fills a square at the 1:1 zoom but at 2x zoom it only fills a corner of the grid that is a problem for the GM.

Essentially there needs to be an established size that people can prescale to so that they can expect an imported object to be displayed at the appropriate size independent of zoom level. When a GM brings in a table they will want it to be table-sized on the map without having to piddle with it.

There is the potential of using the DPI setting within an image for MapTool to make intelligent scaling decisions about images brought in. If a PNG is brought in with a DPI setting of 200 then MapTool equates that to mean 200 px/grid and scales it appropriately to match pixels/grid of the current zoom level.

I think you might have misunderstood my statement.

If you put a 100x100 image onto a 500x500 image, it will take 1/5 of the area, regardless of zoom. that's what I mean by native size.

We'll have to figure out a way to make dropping stamps very simple, resize and rotate very intuitive and trivial.

I think it's something that we'll just have to hammer out as we go. Implement it in a first pass, let you guys play with it, and tweak it as we need.

Could we have some sort of XML placed in the comments section of the image file that would define the size. And if that section is blank, just have to resize it as normal.

It would mean a little extra initial work for people making things specifically for MapTool, but could save a lot of time in the long run.

Sounds like a feature for the Advanced TokenTool

That would be cool, have it define, by default, how many cells x and y it consumes, and perhaps a default z-order (rendering order).

I think that is an understatement. I feel like I'm in the Abott & Costello who's on first skit.



Now you're talking about a different issue.

I'm not talking about putting images on images as in stamps on stamps. I'm talking about dropping objects into a map, which may or may not be a single bitmapped image. Like quickmaps for example.

The GM has a created a quick map with the grass texture and has a grid shown. The view is at 1:1 and there are exactly - no more, no less - 40 display pixels per grid. The PCs are accompanying a wagon train when some attack occurs. The GM places the tokens for the PCs, horses and attackers. Then he picks a PNG file of a wagon. This PNG file is 200 pixels by 400 pixels. He puts it on the display. He makes no adjustment what-so-ever to the graphic.

How many display pixels will the wagon occupy?

How many grids will it cover?

The answers better be 200 x 400 pixels and 5 x 10 grids. (Really freaking big wagon.)

Now if MapTool, when loading the image, got the DPI property from the image and saw that it was 200 DPI and then interpreted that to mean 200 Pixels Per Grid, then MapTools would load it and scale it to 40 x 80 pixels (1 x 2 grids) for the 1:1 view and all would be right with the world.



Which is why there must must be a defined native resolution (pixels per grid or whatever) so that people can create/use graphics knowing that they won't have to resize every single one they bring in.

Using the DPI property of images to determine how big an image was meant to be removes this issue for the majority of graphics that people may want to use. It also makes it trivial to correct within the graphics themselves without requiring custom tools or other tricks.

Being able to resize and/or rotate images as you bring them in is a good thing.

Having to do it for every image you bring in is a bad thing.

MapTool does keep track of a semblance of px per feet, but we don't prescribe any such thing. I think this is a little different from other map sharing programs which require you to resize your image files to a specific size before using them.

It has a concept of cells per feet (or feet per cell) so that distance measurement has meaning.

It then has a concept of px per cell. So it can do the math for you to determine px per feet. And that's what it's doing when you drag a token or the measurement tool.

Instead of prescribing to the cartographer the px per feet, we let you decide what works best. If you don't tell us different, we use 40 px per cell and 5 foot per cell or 8 px per foot.

But we want you to tell us different when it makes sense to you! I use many maps at 16px per cell and 5 feet per cell which is 3.2px per foot.

If I drop a stamp that is 200x400, I'd expect to be able to scale and rotate it while dropping so that it was 1x2 or 2x4 or however many cells it was supposed to be. I certainly wouldn't want it to always be 62.5 x 125 feet.

And, IMO, the best way for me to tell you that is for you to interpret an image as have a number of pixels per cell equal to the DPI setting of the image itself. In the absence of such a setting, default to 40 px/cell and prompt the user with a dialog to confirm or change as needed.



Which is perfectly fine. And if I give MapTool a graphic of a candlestick that was created at 20 pixels per foot then with your 16 px/cell map at a 1:1 view the candlestick would be a 1 pixel dot but at 8x zoom all the detail would be there. But only as long as MapTool had some point of reference to use when interpreting that graphic. PNGs, BMPs, JPEGs all have DPI settings and many of the images for fantasy mapping purposes use that DPI setting as dots per 5' which is the same as saying dots per grid.

Note I am not saying at all that you should enforce a resolution. I am saying you should use the resolution information that already exists. Furthermore there is no reason not to establish a default resolution so that people can create graphic objects and know exactly how they will appear in MapTool without the user having to mess with them. In reality you have already done this but you guys just seem so very reluctant to just say it.

Establishing defaults while having the ability to adapt to the user is a good thing. It is not a limitation or a restriction.



I repeat:

Being able to resize and/or rotate images as you bring them in is a good thing.

Having to do it for every image you bring in is a bad thing.

All I'm saying is:

• Define a default behavior - 40 pixels per cell and 5' per cell or whatever. Not important what it is as long as it is clearly defined.
• Optionally let the user change that if desired - eg 64 px/cell and 2 meters/cell. This could be an overall preference or a per map/encounter preference.
• Use the information that is already present in the many, many existing graphic files to adjust their size when importing them into MapTool.
• Let the user resize/rotate during import or afterwords.

No special XML hidden in image comments or other special handling needed. Simple and straightforward.

Ok, already there.

Ok, already there, and it's per map

That's a great idea.

Ok, already planned (we're still talking about stamps and not tokens).

The XML or other special handling will probably also be done, but it's always been intended to be "in addition" to our most basic handling which will hopefully always do "what you expect".

That's just the kinda guys we are.

One reason we like to say that we don't already have a default resolution is because we have already given it to you as a per map settable preference.

That being said I love the idea of using any "DPI" information in the header of the graphics file to determine the default size of a stamp.

I think absent any such information we still may not pick 40px/cell but rather the current setting of the map you're trying to stamp, and yes, we'll have a dialog or other tools to adjust it as you drop it. We should be able to make them stay out of your way if you don't need them. Thus, in yet another way I will avoid talking about MapTool's default "resolution"

Well then it sounds like everything is going to be perfect.



Definitely only talking about stamps. Tokens need different handling.



Which is why MapTools is the the great tool it is.



It finally clicked just what the heck you were talking about. The pixels/cell set when the user adjusts the grid to match the map. Which btw could also start using the maps DPI setting to auto-conform the grid.

Definitely defaulting to the current maps setting for stamps is the way to go.

Tracker added