ZunTzu

Am I right in thinking that ZT allocates a separate chunk of RAM for front and back counter masks, even when front and back masks are exactly the same?

And if so, is this not needlessly wasteful of resources?

Regards, Bill.

Bill Barrett wrote:Am I right in thinking that ZT allocates a separate chunk of RAM for front and back counter masks, even when front and back masks are exactly the same?

And if so, is this not needlessly wasteful of resources?

Regards, Bill.

There is probably exactly one person who has the ability to answer this question for sure.

Le sigh...

I've been busy/distracted with some other issues, and things have moved more slowly with a new version of ZunTzu than I would like. I'll try to keep this question in mind when I (finally) get to my initial code review and design scoping of the code base.

I had it in my mind the other night that it should be possible to introduce a single mask that could be applied to every (or specified) counters, to cut down on needless waste. It fits into your question with some poignancy.

I was also considering whether the "auto chopping" feature of ZT with sections on a countersheet might benefit from internal "breaks" being introduced.

Assets like these could benefit from the above two features being introduced, I would think:

https://boardgamegeek.com/image/1249155 ... nd-edition
https://boardgamegeek.com/image/1513689 ... nd-edition

-- joshua

I've been busy/distracted with some other issues, and things have moved more slowly with a new version of ZunTzu than I would like. I'll try to keep this question in mind when I (finally) get to my initial code review and design scoping of the code base.

Real life is such a waste of time

I had it in my mind the other night that it should be possible to introduce a single mask that could be applied to every (or specified) counters, to cut down on needless waste.

Yes I long ago thought that that would be much more efficient, but not knowing the ins and outs of the graphics engine I wasn't sure if it would have an impact on performance. However, would it not perhaps be better to simply dispense with mask files and "allow" ZT to recognize and use alpha channels?

It seems to me that Jerome wanted to keep things as simple as possible for neophyte gamebox builders, and that he made certain assumptions (that most people would use scans for example) that are now getting in the way of those of us with more experience

I was also considering whether the "auto chopping" feature of ZT with sections on a countersheet might benefit from internal "breaks" being introduced.

Assets like these could benefit from the above two features being introduced, I would think:

https://boardgamegeek.com/image/1249155 ... nd-edition
https://boardgamegeek.com/image/1513689 ... nd-edition

No I don't think that's necessary. If you open up my GMT No Retreat! module and examine the game-box.xml file you'll see that the counter sheet is a straight 8x11 row/column layout - the counters are declared as being larger than they actually are, and the mask file simply "stamps them out" at the correct size. I won't be using this method in the future (too many wasted pixels that could be used for increased resolution), but it does at least work for now.

Regards, Bill.

Hello Bill!
Your intuition is correct: your transparency mask is transformed internally into an alpha channel merged into each image. So it is accurate to say that it takes double memory space if you use it for both the front and the back of the counters.
Why does ZunTzu use a separate file for transparency? Because I felt that it would be simpler for novice users, and also because it makes working with JPEG possible. JPEG is usually the best format for scanned images, but it lacks support for an alpha channel.

Yay! An actual post from the main man

So that invites the obvious question: how difficult/time consuming would it be to implement an alternative, more RAM efficient method? And I for one, only use the PNG format for counters these days...

Regards, Bill.

It could be done by keeping the colors and the transparency as two separate textures in video memory, and then by combining them during rendering.
It is an interesting idea.

Yes, well it's not such a big deal when (for example) there are only a few non-square/rectangular markers, but if for merely aesthetic reasons one wants to give all the counters a "clipped" appearance (see screenshot below) then the memory impact of the current method quickly becomes prohibitive...

I had it in my mind the other night that it should be possible to introduce a single mask that could be applied to every (or specified) counters, to cut down on needless waste. It fits into your question with some poignancy...




____________
watson