Dundjinni Maps

[DarkWarder]

I've created maps in Dundjinni, but I'm curious as to the best way to export when using FGII.

What has worked best for you?

Thanks

[nezzir]

I've created maps in Dundjinni, but I'm curious as to the best way to export when using FGII.

What has worked best for you?

Thanks

Try exporting to both .png and .jpg and look at the size. It's the size that matters most, load times can be excessive if there are a lot of clients connected.

Other things of note, I don't put a grid on my maps. That way you can use FGII to do your grid to take advantage of token snap. Sometimes I will put a 'key square' on my map to remind me of the proper grid size, then just draw over it and it populates the rest of the map.

[DarkWarder]

Is there a way to send a zipped package to all players before the game to speed up load times with large maps.

I didn't like the jpg I exported but the bmp was over 30Mb!

[Foen]

Take a look at Astinus' post, he pre-loaded maps and tokens and then played FG on a dial-up connection with zero load times.

https://www.fantasygrounds.com/forums/showthread.php?t=7585

Some changes have been made to FG since this was done, so I'm not sure if the same mechanism will work. Please post back here to let us know how it goes.

Cheers

Foen

[Sigurd]

Is there a way to send a zipped package to all players before the game to speed up load times with large maps.

I didn't like the jpg I exported but the bmp was over 30Mb!


There has to be a happy medium. Try pngs. Try Cutting up big maps. Most of my maps are 16 bit pngs with 128 or 256 colours. If you get them close to the size you'll use them in the application it makes everything easier.


Sigurd

[Foen]

It might also be worth trying Xorne's approach: have a small scale map for handling general party movement, and large scale maps for each key encounter area.

That way you don't have to download massive files, but you maintain the high quality images for zooming in on the action.

[arnon]

I import to PNG and then scale them down a bit. I try not to have a map more than 1000x1000 and usually make them even smaller.

Also, as Nezzir, i too remove the grid... though i haven't through of putting a sample square (I usually remember the width of certain areas in the map, and place the FG grid accordingly).

[Griogre]

Make sure you de-rez your maps, you'll save a ton of file size. IE go down to 256 colors from 24 bit color. Also if you are going to use 50 pixel squares for medium reduce the map so the squares are 35 or 40 pixels. With FG you can zoom in a make the "squares" larger so making the squares on the map a little undersized works fine.

I usually use pngs myself, but jpegs work fine also if you don't zoom them more than a bit.

[EugeneZ]

I usually export as PNG and then re-save in 8-bit. For many maps, there is not a noticable loss of quality but an enormous reduction is size. For some maps, particularily diverse maps with many colors and shades, it look horrible. Then I use JPEG, but don't use DJ to export. Use a good JPEG compression program, I use Paint.NET.

[Longrath]

I'm going to dig this post up, because I'm rooting for instructions on making maps.

I'm still looking for an understanding of how FG2 uses images for maps.
I'm a complete noob to FG2.
I've watched the map resizing video.

I'm I understanding correctly that FG2 simply has it's own 50px by 50px grid that it uses to control token placement, and that's really just overlaying a background image?

If that's the case do I want to do the following?

ex. I run 1680x1050 monitor resolution. in FG2 I may want a map 600x950 (50mm grid) open on the FG2 desktop. That will be map 12 squares wide by 19 squares high. At 5ft per square my map shows 60ft x 995ft of game world ground.

Is there any reason to try and use the 72dpi magic number from web design?
If I do that, how does it play with FG2.
Since this is all virtual, am I right that the "inch" of dpi is really irrelevant.

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

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/Useful01.jpg
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.

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/Useful01.jpg
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.

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/Sample.jpg

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:

crop the image to the minimum needed size.
count how many square on both sides (top/bottom and left/right)
Decide what scale you want to use in FG (I use Grid scale 50 Note: this is in pixels)
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
Open your resize image dialog for whatever image editing software you use, PS-CS4 is Ctrl+alt+I
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
Enter the Width and Height (Horizontal and Vertical respectively) Figure A
Click OK
Save file (native editor file first incase you need to make changed CS4 is PSD)
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.)

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/Sample2.jpg

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? :D

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.

[blake67]

I use 72 x 72 as my standard grid size across all maps and tokens.

Using a single grid size for everything makes it easy to organize and standardize. There were two considerations I gave before choosing 72 x 72.

First, that seems to me to be sufficient size that at native resolution, you can get a great deal of detail. Your "zoomed in" maps look great, and the tokens have lots of detail.

Second, 72 x 72 can be scaled down very easily by whatever algorithm that FG uses to downscale images. The reason it works so well is because 72 x 72 can be cleanly divided by a large number of integers, which results in a smoothness in the image when scaled:

72 / 2 = 36
72 / 3 = 24
72 / 4 = 18
72 / 6 = 12
72 / 8 = 9

[Longrath]

Base 2, right?
Why everything computer is 480, 640, 1024.... numbers like that.

[Czarisyn]

because of the bit

[Longrath]

Sorry. Shouldn't have said "why".

It sounded like an ESL question.

Thank You for verifying though.

[DNH]

I am a bit late wading in on this thread but if you are using tiles, you could do a lot worse than PyMapper from the dungeon_tiles Yahoo group. You can create your map in there from all the official tilesets (useful for recreating WotC-published maps from Dungeon magazine, Dungeon Delve, RPGA etc) and export it as a .jpg for use in FG2. Be sure to resize your map background once you're done mind, or you will end up with many KBs of blank space. I haven't done much more than experiment with this, but it looks like a decent area battlemap should not weigh in much more than 100KB or so.

[almeidafreak]

I export them to .bpm (export to map graphic, raw .bmp with 100 as size), then use "save for web" at photoshop and then I use advanced jpeg compressor. That way I get ~300kb files with almost no resolution loss and, therefore, great graphics!