I’m now running Vassal 3.0.17. I tried loading an older module that had worked without problems using an older Vassal version. It now gets:
The application has run out of memory
Java heap space
To decrease memory usage, try reducing the number of colors in your display
Windows XP, Service Pack 2, 1 GB memory
Thus spake “Hagar”:
This will almost certainly not happen with the current beta for VASSAL 3.1.0:
vassalengine.org/forums/viewtopic.php?t=724
In the event that it does, please let me know, and what module you’re
using.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Is there a way to install the Beta without having it replace my current production version – i.e. have both versions available?
Thus spake “Hagar”:
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.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Good news:
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
Bad news:
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.)
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.)
Thus spake “Hagar”:
What module?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
vassalengine.org/community/i … ule_id=537
I’ll have to give you the scenario file in the next post. For a test, you can simply start a new game, and choose a 3 rows by 2 column set of maps. Try saving and then reloading.
If you can’t reproduce the problem, I’ll post the scenario file later. (I won’t be able to retrieve it until late this evening.)
This is complex, but you should be able to produce the effect with the module listed in the prior post, downloading both
PCIIMod.zip
MapExtensions.zip
and putting the MapExtensions.zip contents in a PanzerCommandII_ext subdirectory.
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.
Let me know if you can’t reproduce it easily.
Thus spake “Hagar”:
So you know: I will look at this, but it might be some time, possibly
a week or two, before I get to it. I’m quite backlogged at the moment
due to being away from home so much recently.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Hagar”:
I’d like to look at this problem now, but I can’t find the MapExtensions.zip
file. From where should I get it?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Hagar”:
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.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
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.
Rather, you don’t need someone else’s saved game. You need a game saved under VASSAL 3.0.17.
Thus spake “Hagar”:
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
is happening.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake Joel Uckelman:
I believe I’ve fixed this problem now. Try the svn4029.1 builds, here:
nomic.net/~uckelman/tmp/vassal/
Somewhat esoteric discussion of the problem:
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
rendering.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
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.
Thus spake “Hagar”:
What do you mean by “struggling”, exactly? (In comparison with 3.0.17,
especially.)
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
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.
Thus spake “Hagar”:
I can tell you what you should find: The time from nothing to displaying
a map is slower with tiling at 100% than without, while tiling is much, much
faster at all other zoom levels.
If that’s not what you find, I’d very much like to know.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
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.