That’s a great idea—I implemented it, and it works perfectly on Linux,
but the files still aren’t deleted on Windows. Apparently you can’t
directly unmap memory-mapped files in the Windows JVM, which prevents them
from being deleted until the MappedByteBuffer is garbage collected. That
might never happen when the JVM is shutting down, and File.deleteOnExit()
doesn’t really work on Windows. Windows rules!
Re-posting this for McBeth because I screwed up and moved it to the wrong section. My Moderator L-plates are on sorry!:
mcbeth said,
It appears that maybe the e-mail → forum bridge isn’t working as my replies have shown up in the mailing list but not in the forum. Anyway
I’m not sure the right place for this, but I saw Tim above, so I’m hoping he sees this. I believe this works (it works in spaced directories on my wifes Mac, which is as good a test as I can think of right now). I’m not posting elsewhere, as I don’t know GMT’s policy (although I drew the icon myself to be similar to what is on the packaging)
And, since you (Tim/Joel) probably don’t have random Mac boxes running around, I’ve also put up a zip so you can see what I did (trivial stuff entirely, I’m in awe of how much work you guys have done)
The map tiling is really awesome. It’s really nice to get rid of that dead air at startup time. My thoughts on final touches:
We definitely need some kind of feedback when the tiles are loading. A “busy” cursor works but doesn’t feel quite right when all of the tiles except one have been fetched. I’d be happy just to see the word “loading…” in the center of a tile that’s still being loaded.
Will it be possible to fall back to the original behavior based on a preference setting? It was useful to be able to do this for the image scaling changes a while back. It would give certain people a way to continue running while we ironed out any unanticipated problems that only affect certain systems.
There will be certain errors conditions that prevent the use of these memory-mapped files, chiefly permissions and no-space-left errors. Will we be able to fall back to the old behavior?
I worry about leaving all those temp files behind. It’s pretty unfriendly to leave 1G of temp files behind under any circumstances. If Windows won’t clean up those memory-mapped files, we have to find a way to. One idea would be to clean up all the temp files on startup, but you have to be able to distinguish between files that never got cleaned up and ones in use by another process. Let me suggest something like the following:
Create a ‘scratch’ directory inside the VASSAL root directory. Each VASSAL instances generates a globally-unique id (Java provides a UUID class) and creates a sub-directory for itself with that name. At startup, it touches a lockfile in its directory and removes the lockfile with a shutdown hook. It still attempts to clean up the temporary files, which may not always work, but the lockfile, being empty and globally unique, should never fail to be removed on shutdown. On startup, VASSAL can look for directories in the ‘scratch’ directory that don’t contain a lockfile and delete them, since any such directory must belong to a terminated session that did not clean up after itself. This almost takes longer to describe than it would to implement.
Overall, this is going to be a key improvement that will really improve the experience across the board. Excellent work!
For reasons I haven’t been able to suss out, when you set the Main-Class
in the manifest and start VASSAL with the -jar option, performance tanks
on that run. If you start VASSAL from the same JAR, but instead specify
it using the -cp option and give the main class explicitly, performance
is as normal. I can’t think of any reason why there should be a difference.
Where’s the latest build Joel? I want to use it with my current games for testing purposes, it may be an idea to update the link in your original post so that we know where to go to dget the latest version.
Eventually I’ll move this over to our webspace at Sourceforge,
but until I get to it—the priority for that is pretty low for
me—you’ll find my builds there.
I’m seeing some strange behavior with rotated pieces. for example I’ve got a piece with both Rotate and Layer traits; When I rotate the piece from the default, I can’t then cycle through the layers.
The proposed solution in svn2742 didn’t work. It’s amazing how hard Windows makes it to do simple things like deleting a file. I think I have a solution which does work, here in svn2750:
I found what I think is a good way to handle this: We can catch exceptions
thrown by creation of a memory-mapped file, and just cache the image in
RAM in that case.
I believe I’ve solved this problem now. The current build catches the
exception when a memory-mapped file can’t be created and instead keeps
the image in RAM (like it would have been in anything in the 3.0 series
or earlier).
I’m encountering a problem with your UtLB module, namely that the
ArtilleryR and ArtilleryP prototypes have something which isn’t an
image specified as Image 1 in the Disabled/Captured Layer
(systemscandata.txt is the file). Why is that there? How’d it get
there?
I’m wondering if you’re looking at the wrong module; There are actually two available for Under the Lily Banners, one of them only contains the “Rocroi” scenario and it’s not the one I created.
Huh. I see that now. I’m glad I tried the other one, though, as it exposed
a bug that I wouldn’t have found otherwise. (It hadn’t occurred to me that
the the DataArchive would ever be asked to load as an image a file which
is not an image.)