3.1 is the first version with a proper installer; the installer can’t
possibly know where to find versions of VASSAL prior to 3.1.0-beta1.
Therefore, there is no way to install it so that your previous version
won’t be available.
Loaded beta2 and it works while prior Vassal 3.0 also still works.
Older module that used to load with an older, pre-3.0 Vassal release now loads OK with the beta2
My current module that used to load OK with 3.0 (actually 3.017) now doesn’t load with beta2.
It does use module extensions (I don’t know if this is the same thing as “autoextensions”). So maybe this was expected?
It occurs when I zoom out twice.
The extensions for the saved game are:
3 rows x 2 columns.
The non-loading occurs on:
row 1, column 2 and row 3, column 2. (Get continual load progress displays in those blocks.)
Haven’t yet had time to do any more testing.
In general, the new block loading mechanism seems slower, though that may be just a perception because you get to watch it refresh block by block, whereas in the old scheme, you’d just get a refresh when the load (zoom) was done. (However, I much prefer it loads robustly even if it isn’t as aesthetically pleasing.)
This is complex, but you should be able to produce the effect with the module listed in the prior post, downloading both
and putting the MapExtensions.zip contents in a PanzerCommandII_ext subdirectory.
Then, load the saved file posted here.
Now the complex explanation:
I first noticed the effect in an update to the module on which I was working with at home. Unfortunately, the link above is to the posted version, which is a version behind. Nonetheless, I downloaded the posted version back to my PC, and then used the save file posted here and got the same result.
Because the posted Module is an older version and the .sav file is working with a later version, the .save file will get error messages for several images that are in the newer version that aren’t in the posted version. Nonetheless, I just went ahead, temporarily ignoring the messages. After hitting the Zoom out button twice, the rotating “loading” icons should appear.
I don’t have this solved yet, but I’m getting close: The problem only
occurs when you have a both a board and a flipped version of the same
board which suddenly become visible at the same time. This doesn’t
happen with the board layout in your saved game until you zoom out
twice due to the size and positions of the boards and the size of the
window containing the map.
Hence, there’s some problem with ScaleOpBitmapImpl.TileOp or
OrthoRotateOpBitmapImpl.TileOp, or both.
Making a new game in Beta2 using the same map configuration produces no problems. However, when I created a new game in VASSAL 3017 generating the same map configuration, and then loaded the game in Beta2, the original problem re-appeared.
Some compatibility problem between the Beta2 and the current version …
You can use the new posted game module that has no errors to simplify the problem. Also, you don’t need a saved game to reproduce the problem.
This is a coincidence, what you’re seeing here has nothing to do with
the problem, which I finally found (after nine hours of trying): Some
tiles end up in the request queue ahead of other operations on which
they depend. There’s no way for the dependencies to cut in line, so
we get in a state where no more tiles can be loaded.
I thought that my design made it impossible for operations to get into
the queue out of dependency order, so now I need to figure out how this
The solution required some actual computer science, for once: An ImageOp
and its dependencies form a rooted directed acyclic graph (DAG). Doing a
topological sort on a DAG representing dependencies will give you an
order in which you can schedule the jobs so that no job is scheduled
before one of its prerequisites. I implemented this, and I believe that
it works now.*
*There’s a small problem with GamePieceOpImpl, though, which this exposed:
You can apply it synchronously, but you can’t apply it asynchronously.
GamePieceOpImpl creates its image from the draw() method of a GamePiece,
and GamePiece.draw() has no way at all of reporting on its dependencies,
Thus, GamePieceOpImpl can’t report accurately on its dependencies, either.
If you call GamePieceOpImpl.getImage() acynchronously (i.e., with an
ImageOpObserver as a callback) and some ImageOp which GamePiece.draw()
calls isn’t already completed or in the queue ahead of the GamePieceOpImpl,
then the GamePieceOpImpl will end up in the queue ahead of one of its
hidden dependencies, which will lead to deadlock. This is not a problem
right now, since GamePieceOpImpl is only called synchronously, but it
indicates that GamePieceOpImpl (and basically all of the internals of
FreeRotator, where that code came from originally) eventually needs to be
kicked to the curb. Fortunately, it doesn’t have that long to wait, as
FreeRotator will have to change anyway when we switch to JOGL for
It looks like it was struggling, but it eventually loaded all the maps. It also successfully loaded the older module noted in the 1st post that triggered this topic. So it seems to have fixed both problems.
The individual panes are loaded in a staged manner, some faster than others. Because of the progress icons, if one pane loads slower than another, you sometimes think it’s not going to continue to load. (It appears to be bogging down.) This occurs on both a zoom level and overview displays.
This may be a perceptual problem. On 3.0.17, nothing is displayed until the whole map gets loaded, and so naturally there is a noticeable delay, but then the entire map flashes into view. (In both cases, however, after the initial load, the paging between zoom levels and overview is much faster. That seems to be the same.)
So is the total initial delay of 3.0.17 greater than that of the new pane-by-pane system? I’ll have to measure it. It might be a couple of days before I’m able to get back to test it. I wouldn’t worry about it until I get some results.
It appears that all refresh display functions were faster with svn4029, even the initial load.
The initial impression appears to have been a perceptual problem – the difference between the entire map flashing into view and watching it display tile by tile. Too bad you can’t inhibit the window refresh display – include inhibiting the progress icons – until all tiles are loaded. Then the appearance would be the same as the prior version even though it’s using tiling internally.
Anyway, speed does not seem to be an issue at this point.