Test builds for 3.3.0

Hello
The Area of Effect / Map Shading bug does not appear anymore in Vietnam. Thank you.
Kr
Claudio

I’ve now gone over RegionGrid and Region for HiDPI support. They didn’t require any changes.

3.3.0-svn9352 adjusts the editor for SetupStack for HiDPI support.

Looks fixed in 3.3.0-svn9352.

So… remaining problems. I see two issues reported by marktb1961 which are still outstanding:

https://forum.vassalengine.org/t/test-builds-for-3-3-0/10056/100 – moving a deck in C&C Napoleonics

https://forum.vassalengine.org/t/test-builds-for-3-3-0/10056/102 – resizing a window during a replay

Are these still reproducible with 3.3.00svn9352? I haven’t been able to reproduce either of these myself (though I do see the problem for the first one happen when I replay the log).

I just tried this in 3.3.0-svn9352 and it still happens. I can see it happen in scenario B003 - Vimiero.vsav. You’d think it was a faulty scenario, but it works fine in 3.2.17.

A nuisance that has existed on the Mac client for a while, also in 3.2.17 as well as 3.3.0-svn9352, is that most of the time when you load a scenario the panels at the top are at 100$ of the window size, and the map board is not shown. There is no divider/splitter bar handle to show the map either. You need to open/close a panel using a toolbar button to show the divider/splitter handle, and then you can drag up to show the map board. Would be nice if you could fix that.

Thus spake bdgza:

viewtopic.php?p=58916#p58916[1] – moving a deck in C&C Napoleonics

I just tried this in 3.3.0-svn9352 and it still happens. I can see it
happen in scenario B003 - Vimiero.vsav. You’d think it was a faulty
scenario, but it works fine in 3.2.17.

In around 40 tries, I have yet to see it occur. (I’m using Linux.) Is this
something which happens on Macs only?

I’ve uploaded 3.3.0-svn9294, which is a build from just before I started
the HiDPI changes. Can you reproduce the problem with that? (NB: That
build may claim it is svn9352, but just ignore that.)


J.

Thus spake bdgza:

A nuisance that has existed on the Mac client for a while, also in
3.2.17 as well as 3.3.0-svn9352, is that most of the time when you load
a scenario the panels at the top are at 100$ of the window size, and the
map board is not shown. There is no divider bar handle to show the map
either. You need to open/close a panel using a toolbar button to show
the divider handle, and then you can drag up to show the map board.
Would be nice if you could fix that.

It would be nice if I could fix that. It seems like it should be easy!
I’ve said that very thing each time I’ve tried since 2006, which totals
to seven or eight attempts. The number of times I’ve explained to
confused users that they need to drag the divider up to see the map
likely runs into the thousands by now.

I may take another crack at it, but don’t hold your breath.


J.

If you have a Retina display, please try VASSAL-3.3.0-svn9352-retina_test-macosx.dmg. This test build removes some code which was a workaround for a bug in which Java failed to paint the “compatible” image type to the screen on Retina displays. I suspect this bug was fixed sometime after Java 6. The thing to check with this build is that maps paint correctly. If so, then Java 13 no longer has the bug and I can remove the workaround code.

I tried in 3.3.0-svn9294. It also sometimes fails in this one. Not at first, but loading the scenario for the 2nd, 3rd, 4th, 5th… time. Relaunching the module resets.

I tried 3.3.0-svn9352-retina on Mac Retina display. Everything looks normal in the 2 mods I tried, so I assume that means it works ok.

About the Retina, is there any way to provide Retina/HiDPI assets in the vmod for VASSAL to use?

Thus spake bdgza:

I tried 3.3.0-svn9352-retina on Mac Retina display. Everything looks
normal in the 2 mods I tried, so I assume that means it works ok.

Yes, if it looked normal then the problem’s been fixed and the workaround
code is no longer necessary. Thanks for checking.

About the Retina, is there any way to provide Retina/HiDPI assets in the
vmod for VASSAL to use?

Yes, but no changes are required for it. Images are now requested from
the image cache at the actual pixel dimensions at which they’ll be
painted to the screen on HiDPI screens.


J.

But can you add @2x assets, double resolution versions, for VASSAL to use when in HiDPI mode? Otherwise it’ll be a sharp UI with blurry module images.

Thus spake bdgza:

“uckelman” wrote:

About the Retina, is there any way to provide Retina/HiDPI assets in
the
vmod for VASSAL to use?

Yes, but no changes are required for it. Images are now requested from
the image cache at the actual pixel dimensions at which they’ll be
painted to the screen on HiDPI screens.

But can you add @2x assets, double resolution versions, for VASSAL to
use when in HiDPI mode? Otherwise it’ll be a sharp UI with blurry module
images.

There’s no support for that, and I’ve got no plans to add it to 3.3. I
can’t see many modules making use of it between now and V4, and I’d
rather not delay V4 further.

Also, I don’t see what you mean about blurry images. The point of the
HiDPI changes was to prevent blurring, by rendering images at their
actual size on HiDPI devices rather than requesting them at their UI size
and then upscaling that by the device scale factor for rendering.


J.

Even with the use of dedicated upscalers or tweaked settings with fancy AI image processing algorithms doing a regular upscaling of a bitmap image is never going to be as crisp as an actual higher resolution bitmap image. This is why you use vector/SVG images or at least provide bitmaps at various densities to prevent bad (up)scaling. I was just wondering if you added support for providing higher resolution images, since if you did I would’ve wanted to take advantage of it.

Thus spake bdgza:

Even with the use of dedicated upscalers or tweaked settings with fancy
AI image processing algorithms doing a regular upscaling of a bitmap
image is never going to be as crisp as an actual higher resolution
bitmap image. This is why you use vector/SVG images or at least provide
bitmaps at various densities to prevent bad (up)scaling.

Yep, I’m aware of all that. Still, 3.3.0 should have crisper images on
HiDPI displays than 3.2.17 did if the images start out large enough to
support it.

I was just
wondering if you added support for providing higher resolution images,
since if you did I would’ve wanted to take advantage of it.

V4 will have that support for multiresolution images. I’m just not
interested in putting all that additional work in to V3 at this point.


J.

I understand. Fine by me. Just wanted to ask to make sure.

I reread this just now and realized that I don’t understand what you’re seeing. The splitter problem I’m familiar with but don’t know how to reproduce reliably is that the splitter starts dragged all the way to the bottom of the Player window. What you’re saying is that there is no splitter at all displayed? I don’t understand how that’s even possible. What are you clicking on the toolbar to make the splitter show up?

I spent a few hours poking at the ComponentSplitter. Try 3.3.0-svn9354-splitter_test. Does that behave better?

I changed is the preferred size of the component in the top half of the Player window, and also reduced the initial number of rows in the chat pane. That gives the map significantly more vertical space when I start games.