PDA

View Full Version : Map creation best practices



BubaDragon
July 11th, 2017, 22:48
Disclaimer: I am sure this has been addressed before, however I seem to loose things in the "noise" of this board (I'm old give me a break).

This is what I know so far:

Keep maps under 2048 X 2048 pixels
Design to a 50 X 50 pixel grid
Save maps a .JPG
Keep quality between 30% - 50%
Keep size between to 500KB - 1MB, and closer to the 500KB
The image size directly affects performance, 32bit applications can only address 2GB of memory


Did I miss anything?

I'd like to gather everything about map image best practices in one place, of course if this is already done please point me to the post!

BubaDragon
July 11th, 2017, 22:48
I was also wondering about the grid size.
- It occurs to me that a 5' grid at 50 X 50 pixels gives 10 pixels per foot, or 1.2" per pixel while a 5' grid at 60 X 60 pixels gives a much more OCD pleasing 12 pixels / foot, or 1" / pixel. Any reason not to use 60 pixels per 5' square?

Zacchaeus
July 11th, 2017, 22:57
Hi Buba welcome to FG. Your list is certainly the recommended dimensions and sizes. Grid size is not particularly set in stone. You might for example not want to spilt up a big map so might want to have a 25px grid or even smaller. And there's no reason why you can't have a bigger grid if you want one.

Trenloe
July 11th, 2017, 23:03
Welcome to the forums BubaDragon

That's about it. But, some clarifications/reasons:
- Image size of 2048x2048 is a recommendation to keep memory use to an acceptable level.
- some people use different grid pixel sizes. A lot will depend on how big the map is, and also if a user has specifically sized a bunch of their tokens for a specific grid size (and they're not using auto token sizing). 50x05 is basically a good trade-off with an acceptable amount of detail per grid square without having to have large resolution maps. There's no technical/performance implication purely based on grid size.
- Yep, JPG's give smaller file size.
Bullet point 4 and 5 basically go hand-in-hand, if your map is small-ish (pixel wise) you can go with a higher JPEG quality, as long as the file size is kept 0.5-1MB. The file size recommendation is to keep sharing time to the players low.
- And a clarification on the last point. Yes, opening large images (pixel size) uses up memory. Yes, FG is a 32-bit application. the 2GB limit is on 32-bit operating systems, on 64-bit operating systems the limit for FG is around 3.5GB due to the FG executable being compiled with the Large Address Aware flag.

BubaDragon
July 12th, 2017, 00:13
Thanks for the replies, I just wanted to clarify another point. I have seen several people mentioning their export PPI. I may be wrong here, but an image that is 2002 X 2002 is the same size in memory, if it's saved at 72 PPI or 288 DPI. It's the job of the rendering program to display the image the correct size as described by the resolution.
Where I think we 'might' get some good size savings is if you create the map using the black & white color space. Hey, if it was good enough for us in high school (THAC0 anyone)....

BubaDragon
July 12th, 2017, 00:15
Welcome to the forums BubaDragon

This Dragon is honored by your greeting, illustrious one.

Trenloe
July 12th, 2017, 00:19
PPI has nothing to do with how FG displays/processes the image. It just displays it as is, based off pixel dimensions. Where PPI usually comes in is with the original map makers, who will frequently use it to describe how many pixels on one side of a 5' square there are. So, 50 PPI might (if the map make did 1 square to the inch) mean 50x50 pixel 5' squares. But different cartographers can package their maps differently, so don't rely on PPI being pixels per 5' square.

Using a purely black and white colour space will save file size - thus sharing to players quickly, but it won't reduce the amount of memory FG uses to display the map.

BubaDragon
July 12th, 2017, 00:48
Using a purely black and white colour space will save file size - thus sharing to players quickly, but it won't reduce the amount of memory FG uses to display the map.

Now that is an interesting piece of information!

Thank you!