Dundjinni Maps

[Griogre]

The grid size is adjustable in pixels not just 50x50 you can set it to any interger value. I use 32x32 for medium monsters myself but many use 50x50 and sometimes larger for top down tokens. The letter tokens that come with FG are 30x30 pixels.

You are correct in that FG's grid just overlays the image. If the image has a grid on it already you are usually better of not using FG's Grid because it can be hard (though not impossible Xorns video does say how) to get the two grids to line up.

You are correct that DPI is meaningless - only the pixels matter.

[TR0LL]

For best performance and small files sized, export your images at a DPI twice what your grid size is(if you use grid 50px dpi 100/ 32px dpi 64 etc.), I use a grid size of 50 so I create photoshop images (resolution not image size) and export dunjinni maps at 100dpi. I have a 2500x2500 image that exports at .jpg and is 1.2MB is size, works very well. Some people might scoff at the low dpi for for our purpose with FG, and the fact that we shrink the image a little to fit the grid you don't lose any effect. here is an example Images at 100dpi, on a grid of 50 pixels.


Note: these are tiles(tokens) not a single image, but the resolutions and sized are the same 50px 100dpi.

[Longrath]

For best performance and small files sized, export your images at a DPI twice what your grid size is(if you use grid 50px dpi 100/ 32px dpi 64 etc.), I use a grid size of 50 so I create photoshop images (resolution not image size) and export dunjinni maps at 100dpi. I have a 2500x2500 image that exports at .jpg and is 1.2MB is size, works very well. Some people might scoff at the low dpi for for our purpose with FG, and the fact that we shrink the image a little to fit the grid you don't lose any effect. here is an example Images at 100dpi, on a grid of 50 pixels.


Note: these are tiles(tokens) not a single image, but the resolutions and sized are the same 50px 100dpi.

I didn't follow your resolution calculation.

Actually, screen resolution is still 72dpi isn't it? so if I want a possible zoom factor of 2, I need to make my image at 144 dpi. ... Ack, I'm back to trying to figure out inches on my screen and end up at, dpi (the inches) part doesn't matter.

It occurs to me that this will all hinge on map size, and the amount you wish to zoom.

If 2500 x 2500 images at 1.2Mb gives good performance in a game situation, I think I should work back from there to see how much area of gameworld I can display.

[Longrath]

Your image subtitle says 50px, 100 dpi.
Your squares are the equivalent of 1/2" grid paper. 1" = 10'.
I'm in archtecture, so 1/10" = 1'-0"... nearest standard scale is 1/8"=1'-0". That's close to 1:100.
if someone hand sketched my a map on 1cm grid paper, I would ask for a scale of 1:100.
5ft is 1.5m or 1500mm.

....

I pulled my mathematical cortex.

[TR0LL]

Oh this is going to be a little drawn out but I will explain my process.



I am using a scanned in WotC D&D Tile.(which I own) This works for any image. Dunjinni, GIMP, PSP, whatever. (I use Photoshop CS4)

Steps:

1. crop the image to the minimum needed size.
2. count how many square on both sides (top/bottom and left/right)
3. Decide what scale you want to use in FG (I use Grid scale 50 Note: this is in pixels)
4. Multiply the number of squares by 50 (both sides- this image is 8 horizontal, and 10 vertical) so for this image we are looking at 50*8=400 x 50*10=500 so our image needs to be 400x500
5. Open your resize image dialog for whatever image editing software you use, PS-CS4 is Ctrl+alt+I
6. Enter the RESOLUTION FIRST as it will scale your image dimensions. As we already decided on 50px squares. we want the Resolution to be 100 (grid size * 2) as seen in Figure B of the image above
7. Enter the Width and Height (Horizontal and Vertical respectively) Figure A
8. Click OK
9. Save file (native editor file first incase you need to make changed CS4 is PSD)
10. Save As file (new copy) a .jpg it will ask for quality values set them to the highest. the images are small enough that there is no need to sacrifice visual quality.

As you see in Figure C the saved .jpg is very small! 246KB for an image that is 8x10 squares (at 50px squares) and the image has awesome clarity and looks great in FG.

These steps can be reproduced for any image size, just go through the steps.

Also keep in mind for simple images you a lower resolution.
example I have a simple black image that I use as a blank map for placing modular tiles on that is 2500 x 2500 (width x height) I have it set to a resolution of 10 with the LOWEST quality possible for .jpg saves and the file is only 54.5KB

Hope this helps.



Edit:

as per your calculations kinda, when dealing with tabletop gaming/rpgs 1 square usually 5' so in this scale 1/2" = 5' (the scale doesn't need to be 1' = 5" because we are not printing these. if we were to use them on a table, we would print at resolution 200 with a grid of 100. which would give us 1' = 5" - the doubled resolution is needed for visual clarity on a printed medium - cardstock, paper etc. )

[Foen]

BTW, PNG saves a 2500x2500 solid black image at 27.5KB. It isn't so good at photo images though, becuase it uses loss-less compression.

Foen

[TR0LL]

BTW, PNG saves a 2500x2500 solid black image at 27.5KB. It isn't so good at photo images though, becuase it uses loss-less compression.

Foen

I dont want to step on toes or cause bad feeling but wanted to point out a little more.

PNG should not be used for images with multiple colors. (unless you NEED transparency)

I took this same image (PSD format) and re-saved it as a PNG, both interlaced and non and the file size was doubled. (near 500KB/400KB respectively.)



PNG is a loss-less compression format (read: like no compression for image fidelity- it can be recovered), .jpg is highly compressed (can not be recovered to original fidelity) - but when dealing with small images the quality loss is negligible.

[Foen]

No problem, I think we're saying the same thing though: don't use PNG for images with colour variations. PNG *does* compress, as it doesn't store images as individual pixels (that would be BMP format) but rather as an encoding. The encoding is loss-less however, which means that you can recompose the original bitmap without any loss of fidelity.

JPG is generally much more compressed, and uses mathematical approximations of the original image. JPG files are typically smaller as a result, but the image isn't 100% perfectly represented. In some circumstances, JPG doesn't yield such small files: this is most typically when the image is simple, like areas of solid colour. In that case PNG or GIF can be a good choice.

The choice of encoding isn't absolute, but depends on your need. English is a pretty good language for encoding the simplest images ("a black, 2500x2500 pixel image" takes a lot less space than 54KB or even 27.5KB, and is fully loss-less) but lousy for describing a photo. Well, my english certainly wouldn't do a very good job

Finally, it is worth saying that the program used to create an image can also have an impact. I have attached the black 2500x2500 image to this post, it was created with Paint.NET and is only 27.5K.

Foen

[TR0LL]

yes, we are on the same page, just using different words to say it

I also like my method of figuring out what size to re-size images. number of squares * grid size is much easier to me, than figuring out the length of 10 squares on the image then dividing by the grid size you want. I've also found that the latter method is not 100% as the base resolution is not divisible by the grid you are scaling it to (more often than not) The key with my method is to change the resolution to grid * 2, if you don't, it will not work out right.

[Foen]

Isn't language a nuisance?

Historical Footnote:

At one point there was the widely held belief that the compression used for FG maps wasn't important, because the engine sent a bitmap representation from the host to the players and so the transfer would always be huge if the map area was large. The SmiteWorks guys dispelled the myth, and confirmed that image compression is retained for image transfer.