I’m designing the expansion module for Space Empires Close Encounters.
Using 3.2.0 of Vassal I am employing a lot of the new features such as asthmatic expressions and literal strings for shortcut keys.
With the new expressions I am able to employ the “Production Sheets” found in the board game. These basically work like spreadsheets. I’m using counters to represent each cell.
I noticed as I was setting this up that it seems to be taking an enormous amount of memory. I know JAVA isn’t the most memory friendly, but do you think I will run into an issue where the module might become un-runable, at least on some machines?
With the Production Sheets as they are now, there are 7 screens, each doing different things, like the one below for each player (so 28 total). There’s still more work to be done and cell counters to be added but running it as it is now JAVA takes up about 530MB of memory and VASSAL another 60MB on my Win 7 machine.
I’m getting worried it may increase even more and could use some reassuring/pointers before I put a many more hours into finishing the module. I don’t want to do a ton of work only to have the thing crash on machines with ~1-2 GB RAM.
Thoughts? Thanks in advance
EDIT: I’m using 3.2.0-svn8213 here
Thus spake chrono280:
I’m designing the expansion module for Space Empires Close Encounters.
Using 3.2.0 of Vassal I am employing a lot of the new features such as
asthmatic expressions and literal strings for shortcut keys.
With the new expressions I am able to employ the “Production Sheets”
found in the board game. These basically work like spreadsheets. I’m
using counters to represent each cell.
I noticed as I was setting this up that it seems to be taking an
enormous amount of memory. I know JAVA isn’t the most memory friendly,
but do you think I will run into an issue where the module might become
un-runable, at least on some machines?
With the Production Sheets as they are now, there are 7 screens, each
doing different things, like the one below for each player (so 28
total). There’s still more work to be done and cell counters to be
added but running it as it is now JAVA takes up about 530MB of memory
and VASSAL another 60MB on my Win 7 machine.
To what do you have your max heap set for the module?
–
J.
It’s set to 512MB in my file → prefs. I have never messed with this option, but I’ve read about it concerning ‘out of memory’ errors.
I’ve never received any errors, I’m worried about that and performance though. Thanks again
Thus spake chrono280:
It’s set to 512MB in my file → prefs. I have never messed with this
option, but I’ve read about it concerning ‘out of memory’ errors.
I’ve never received any errors, I’m worried about that and performance
though. Thanks again
Have you found that tiles which you’ve seen before are not displaying
immediately? If that’s happening, then maybe your module design is
squeezing the tile cache a bit. If that’s not happening, then I doubt
that you have anything to worry about.
–
J.
The main map takes about 7 seconds to so to load in (the background and the at start stacks). That didn’t used to happen. Not game breaking but I can try shrinking the map some. Although I will need to keep the size the same to keep my at start stacks in the right place.
On the production sheets sometimes it takes half a second, but it is livable.
Also I noticed moving a unit on the map now is a bit more delayed that it was before. It used to only happen when large amounts of units were being moved at once. It takes roughly 2-3 seconds for the unit to stop being “translucent” and appear in the new hex with move trail and chat-log annouce of movement. Do you think it is Report that is causing this or something else?
Thanks
Would it also help if I removed unused image files from the VMOD archive file?
Thus spake chrono280:
The main map takes about 7 seconds to so to load in (the background and
the at start stacks). That didn’t used to happen. Not game breaking
but I can try shrinking the map some. Although I will need to keep the
size the same to keep my at start stacks in the right place.
On the production sheets sometimes it takes half a second, but it is
livable.
Also I noticed moving a unit on the map now is a bit more delayed that
it was before. It used to only happen when large amounts of units were
being moved at once. It takes roughly 2-3 seconds for the unit to stop
being “translucent” and appear in the new hex with move trail and
chat-log annouce of movement. Do you think it is Report that is causing
this or something else?
I have no way of telling conclusively without looking at the module.
Can you post it somewhere?
–
J.
Thus spake chrono280:
Would it also help if I removed unused image files from the VMOD archive
file?
No, that has no affect whatsoever.
–
J.
I checked the two modules for which you privately sent me links. I used the default max heap of 512MB. In all cases, no matter which scenarios I loaded, the size of the image cache ranged from 75% to 88% of allocated memory, which is what I expected. You’re not having a problem with too little memory.
I can’t replicate the problem you’re having with movement, but my guess is that it’s the painting of the movement trail that’s slow.
Great thanks for looking into it for me, you’ve put me at ease about it