PDA

View Full Version : Tokens, best technical size?



Blacky
August 26th, 2013, 19:42
Question for moon:

With 3.0.0, is there a specific token size better than another?

For example, is the power of 2's size (16px, 32px, 64px, 128px, etc.) still better handled by FG (if it was the case, maybe it's urban legend)?

For example, apart from zoom capability and weight and such, would 64px token be better than 59px token?

Trenloe
August 26th, 2013, 20:39
I think the base 2 sizes were a preference from a lot of users - I don't think it is based in anything that works better with FG. Base 2 sizing hits a slight problem with the 64 -> 128 -> 256 progression with d20 based games whose huge size is 3 times that of a medium creature - the size should be 192. Not a major issue, just needs to be taken into account.

To muddy the water a bit - in 3.0 the CoreRPG portrait_token_mask.png file is 46x46 - so this is the size that PC tokens are created if the portrait is dragged onto the token icon in the character sheet. From this, to keep all tokens in the same size shouldn't we be looking at tokens being multiples of 46? If the GM then uses 46 pixels per map square and uses monster tokens that are 46x46 for medium, 92x92 for large, etc. there won't be any need to resize any of the tokens. Or, if the map is not 46 pixels per square then the "lock token size" can be used to make the 46x46 reference token size of the square and all other tokens fall into line - both PC and NPCs.

I've never really seen a problem with lock token size creating a difference in size from my PC and NPC tokens. But, I use 50x50 for NPC tokens, so this is very close to the 46x46 used for PC tokens.

unerwünscht
August 26th, 2013, 23:22
To muddy the water a bit - in 3.0 the CoreRPG portrait_token_mask.png file is 46x46 - so this is the size that PC tokens are created if the portrait is dragged onto the token icon in the character sheet. From this, to keep all tokens in the same size shouldn't we be looking at tokens being multiples of 46? If the GM then uses 46 pixels per map square and uses monster tokens that are 46x46 for medium, 92x92 for large, etc. there won't be any need to resize any of the tokens. Or, if the map is not 46 pixels per square then the "lock token size" can be used to make the 46x46 reference token size of the square and all other tokens fall into line - both PC and NPCs.

FINALLY! Someone else gets it, I have been pointing this out for close to 3 years now to a deaf audience here.

And I also use 50x50 as the base (medium) size for NPCs, Creatures, and Custom made top town tokens for for PCs. It comes out to 46x46 once you add in a bevel on the base.

Trenloe
August 26th, 2013, 23:35
And I also use 50x50 as the base (medium) size for NPCs, Creatures, and Custom made top town tokens for for PCs. It comes out to 46x46 once you add in a bevel on the base.
Ah yes, I had forgot about the bevel - that would make it 50x50 pixels for the final PC token. That explains why my 50 pixels per square and medium sized NPCs works perfectly with the PC tokens.

In rulesets prior to 3.0 this PC token size more often than not differed from 50x50 pixels - and some themes changed it from what was defined in the ruleset (e.g. the 3.5e Wood theme).

With 3.0 rulesets being based off the CoreRPG ruleset, which uses 50x50 pixels for the PC token, we will hopefully see a more constant PC token size, allowing GMs to resize their other tokens appropriately. As long as people who write theme extensions don't mess with it!

unerwünscht
August 27th, 2013, 00:36
With 3.0 rulesets being based off the CoreRPG ruleset, which uses 50x50 pixels for the PC token, we will hopefully see a more constant PC token size, allowing GMs to resize their other tokens appropriately. As long as people who write theme extensions don't mess with it!

Not to toot my own horn here, but I honestly think I have made more themes for FG than anyone else has, and I promise that I won't change the default token sizes in my themes ever again. ... and historically have only changed them to make them 50x50. ;)

phantomwhale
August 27th, 2013, 07:49
Any idea what size the new Fantasy Grounds "provided" tokens / pogs are ?

Always happy to follow a Smitework recommended standard - alas, Savage Worlds (as inherited) used a 64 pixel base, so I've been working off 32 / 64 / 128 for my tokens. By finally adding a PC token box to the character sheets in the latest version, at least users can override all the tokens as they choose, so matching the "portrait default" becomes less essential.

Griogre
August 27th, 2013, 18:49
Unfortunately, Raymond's FG "pogs" are not scaled or more correctly all animals, monsters and characters are scaled to the "pog" so they are all 128 pixels square - cat, dragon or halfling. The non-pog versions are all either 128 pixel squares or 256 pixel squares. Typically, top down tokens are much larger than portrait style though.

The letter token pogs supplied with FG come in two sizes: Small which are 32 pixel squares; Medium which are 70 pixel squares.

phantomwhale
August 28th, 2013, 01:58
I guess one of the interesting points here then is that the two "default" sizes being implicitly promoted by the core FG offering are 50x50 (generated token from portrait) or 128x128 / Base2 sizing (supplied token packs) - which are not easily happy bedfellows.

And, to muddy the waters, Savage Worlds ruleset supports 32x32, 64x64, 96x96 and 128x128 generated tokens from portraits, and comes with the letter tokens built in, which I had assumed were 32x32 and 64x64 - but am interested to read the larger ones are actually 70x70 !

In all cases, this disparity is side-stepped by not using portrait generated tokens, and as long as all your tokens comes from the same source, things should be good in token to token comparison. Although I believe there is a slight issue with scaling maps for modules, which often benefit from being tweaked a little to ensure a nice grid can be added, esp. with maps that are quite grid-focused, like dungeons.

None of the above is saying whats right and wrong, just summing up what I understand the state of the landscape to be.

Blacky
August 28th, 2013, 02:11
My real question for the FG devs was more: is there a technical advantage to using certain sizes of tokens (specific to Fantasy Grounds, apart from the obvious costs&benefices).

Trenloe
August 28th, 2013, 04:22
My real question for the FG devs was more: is there a technical advantage to using certain sizes of tokens (specific to Fantasy Grounds, apart from the obvious costs&benefices).
I think we've covered that above, haven't we?

Or, what other technical advantages were you thinking of?

Nickademus
August 28th, 2013, 05:29
Yes, there is always technically a technical advantage to using a base 2 size image. But this is for video cards not FG. And, technology has long since surpassed this even being a concern for 2D software like Fantasy Grounds. You would see only the smallest spec of improvement using diagnostic tools were you to conform your tokens to base 2 sizes.

Phystus
August 29th, 2013, 23:08
True dat.

The bigger issue as far as performance is file size, which is only partially related to pixel size. Reducing color depth can often do wonders without much change in appearance.

And just for another data point, I use 30 pixels for man-size creatures.

~P

Griogre
August 30th, 2013, 00:18
*Grin* and I use 32 pixels for medium sized creatures. :) To further elaborate on Phystus' point though, one of the best things you can do to reduce the file size of images is go from 32 bit color to 8 bit color per pixel. On almost all monitors the change is not visible and file sizes of the 8 bit images are about quarter the size of the 32 bit ones. Almost all modern art programs default to 32 bit color which is needed for printing but not for monitors.

Edit: 32 bit colors is usually called "millions and millions of colors" while 8 bit color is "256 colors".

Nickademus
August 30th, 2013, 02:58
reduce the file size of images is go from 32 bit color to 8 bit color per pixel

Oh no, you are NOT taking away my periwinkle!

Blacky
August 30th, 2013, 09:38
To further elaborate on Phystus' point though, one of the best things you can do to reduce the file size of images is go from 32 bit color to 8 bit color per pixel.
That's besides my original question, and besides the 3.0.0 test version, but while on 32px tokens going from rgb to indexed (24/32bits to 8bits colors) shouldn't be visible, one should keep usually the alpha transparency. A bad transparency is very visible.

unerwünscht
August 30th, 2013, 10:16
That's besides my original question.

If I follow the thread correctly the original question is "Why is there not a standard size?"
The simple answer is "Because the gaming community has never been able to agree on anything."
What we basically need is for Smite Works to step in and say "This is the way things will be for OFFICIAL content".
Then the community has a set size to work from, but not one set in stone. The vast majority of community content will begin to comply with the official content, and what doesn't will just go away.

The topdown tokens are great, but the 'official' ones have no variation in scale, and the artist changed his ToS so many times since the start of that project that it was, in my opinion, a bad investment. The community is not allowed to modify or redistribute his artwork (not even within the FG platform) even tho that was the point of the project to begin with.

Devin Night also makes some very awesome topdown tokens, and last I checked his do have varying scales. However, his are so larger by default that they are difficult to use with anything else.

So there you have it. My opinion. It is worth what it cost you. ;)

Blacky
August 30th, 2013, 10:49
If I follow the thread correctly the original question is "Why is there not a standard size?"
Absolutely not.

The thread's question was for the FG developers and is: “is there FG specific things relative to token size and performance, in the 3.x branch?”

Moon Wizard
September 1st, 2013, 02:57
There are very few technical considerations for graphics in the FG code. Any individual graphics greater than 2048x2048 will be scaled to that size, unless they are image/map files. Also, large graphics are broken into 512x512 chunks for processing. Other than that, the other considerations include: transfer time, resolution, and relative sizing for miniatures on maps.

As a separate but related question, should SW even attempt to set a standard given the vast disparity between token sets? I actually spoke with Doug briefly about this topic at Gencon. I'd like to eventually offer the option to specify which size you want to download tokens your purchase/receive from the FG update server, so that your tokens are all relatively sized. I'm torn about what size is correct, since it's all up to the people playing and what level of detail they want. Also, I have been thinking of ways to perhaps automatically perform token scaling when tokens from the combat tracker are added to a map with a grid. (i.e. we have a token size, a grid size and a ruleset specified creature size; so use them.)

Regards,
JPG

Callum
September 1st, 2013, 09:13
I have been thinking of ways to perhaps automatically perform token scaling when tokens from the combat tracker are added to a map with a grid. (i.e. we have a token size, a grid size and a ruleset specified creature size; so use them.
This idea is really good. It won't work all the time, of course, but where those pieces of information are all available, it would be great to auto-resize the tokens by default.

Blacky
September 1st, 2013, 09:29
There are very few technical considerations for graphics in the FG code. Any individual graphics greater than 2048x2048 will be scaled to that size, unless they are image/map files. Also, large graphics are broken into 512x512 chunks for processing. Other than that, the other considerations include: transfer time, resolution, and relative sizing for miniatures on maps.
Again, thanks a lot.

Several urban legends killed at once.

Moon Wizard
September 1st, 2013, 20:23
Callum,

My thoughts right now.
* If default scaling and grid set and token dropped from CT, then set map-to-token global scale.
* If scaling set and grid set and token dropped from CT, then set individual token scale.

My main concern for this is user interface, and trying to do the "right thing" automatically in a non-confusing way.
* How do I "notify" the user that the scaling has been set? Is notification necessary?
* What happens if the scaling is set when the GM doesn't want it scaled? Is this issue worth the trade-off?
* Should there be a default scale for images? Seems unlikely, since every map often has a different pixel to distance ratio; and it varies from campaign to campaign.

Cheers,
JPG

Blacky
September 1st, 2013, 20:46
Also, I have been thinking of ways to perhaps automatically perform token scaling when tokens from the combat tracker are added to a map with a grid. (i.e. we have a token size, a grid size and a ruleset specified creature size; so use them.)
It's possible to define a grid size? In meter or feet I mean. Or an npc unit size for that matter…

I've missed that.

Andraax
September 1st, 2013, 20:56
It's possible to define a grid size? In meter or feet I mean. Or an npc unit size for that matter…

I've missed that.

Depends on the ruleset. You can create an extension to change it.

Blacky
September 1st, 2013, 21:03
Ok. Which means one size for all maps in a campaign.

Trenloe
September 1st, 2013, 21:24
Ok. Which means one size for all maps in a campaign.
A ruleset generally has a game size/distance for the grid that is put on a map. e.g. 5 feet per square. There is no fixed number of pixels per square for the whole FG campaign - the grid needs to be manually added to each map.

Blacky
September 1st, 2013, 21:43
Yes, I was asking for the real life distance of each grid case.

unerwünscht
September 2nd, 2013, 00:35
My main concern for this is user interface, and trying to do the "right thing" automatically in a non-confusing way.
* How do I "notify" the user that the scaling has been set? Is notification necessary?
* What happens if the scaling is set when the GM doesn't want it scaled? Is this issue worth the trade-off?
* Should there be a default scale for images? Seems unlikely, since every map often has a different pixel to distance ratio; and it varies from campaign to campaign.


Yes for the love of all that is good we would need a notification if the program changed the size of something automatically. I would panic if my tokens stopped displaying the way they are supposed to, and didn't get a notification.

Is it worth the trade off? The issue becomes even more complicated once you figure in hex maps, I would assume.

Should there be a default scale for images? as long as it can be changed within the program when needed, I think a default size would be awesome. It would be just the incentive needed for the community to start moving towards a universal token size.