A few performance questions

[Deuterazamus]

Hey everyone,

for the sake of one of my players who has a very weak pc I'd like to ask you guys a few questions in order to find a balance between game performance and quality in my maps.

First of all some background: we use 1.3b87 on a home wifi, each player has his onw pc and our ping to the router and outside (actually unneded) is satisfactorily low.
I have built a campaign file of around 80Mb composed of 9 maps (util maps incuded), almost all with VBL and we use lmarkus' MT1.3b87.02 Pathfinder framework. All players start maptool with 1GB except one that only has 512MB on board and therefore he starts it with that much memory allocated.

My problem is that on that pc some maps become very slow with response times of 30+ seconds. I've tried to reset FoW (to no avail), checked network performance (and is fine, as mentioned earlier), simplified my VBL and generally tried all solutions pointed in the forums. Fact is that the pc in question fills the java memory in a split second and then starts swapping like there is no tomorrow.
Some of my first maps that were done in photoshop and then imported in maptools were the most troublesome (beginner's mistakes - they exploded in memory once loaded!) so for the later maps I moved to full maptool manipulation gladly accepting a marginal quality loss while gaining a lot of performance. And the results were much appreciated.

However my players are now entering a larger dungeon level that I've been implementing on a map sized approx 160x120 squares with many object/items/floor/wall shadows etc and I fear that the weak pc will not hold the impact...

Finally the questions:
1. Floors: is it better to use texture filled drawing tools or replicate many times the same texture resource used as an object/background?
2. Does it make any difference if I grab an image from my resource library and use it repeatly or if I drag and drop multiple times the same image from the file system? Will Maptool notice that the image has already been dragged on the map and reuse it correctly?
3. I've created the map setting a ~4MB Jpeg ~8500x7000px as background, then draw on it and once finished I plan to replace that image with a the default black. Do you agree that memory occupation will be lower compared to the current 590-700MB?

If needed I can share the campaign file via dropbox...

Kudos to everyone that will care to share his thoughts!

Cheers!

[Elorebaen]

Lately, I have been experiencing a similar type of problem that I haven't been able to identify. I have been using Maptool for 5 years. I am not ultra-experienced on the tech, but I think I understand how to create acceptable Maptool files.

I am wondering if it has something to do with Java or some such. Either way, the performance hit is definitely something fairly new.

[Deuterazamus]

What I can't really understand is how Maptool allocates memory...
I mean, if I run the campaign file on a pc (with plenty of memory for the jvm) it goes up to 790-800 MB. If I remove an unused map it drops dramatically.
I even managed to reduce occupation down to 200-300MB but I'd really like to better understand how images and maps are cached.

[masterclif]

Finally the questions:
1. Floors: is it better to use texture filled drawing tools or replicate many times the same texture resource used as an object/background?
2. Does it make any difference if I grab an image from my resource library and use it repeatly or if I drag and drop multiple times the same image from the file system? Will Maptool notice that the image has already been dragged on the map and reuse it correctly?
3. I've created the map setting a ~4MB Jpeg ~8500x7000px as background, then draw on it and once finished I plan to replace that image with a the default black. Do you agree that memory occupation will be lower compared to the current 590-700MB?

First off. If you want to make it easy on the guy, use a separate campaign file for each map. Lighting is a huge cpu draw, and so is fog of war. Always remember that this uses java heavily. So the version of java you use will affect the program.

Now, these are what I use because I've had players with horrible computers and dial up.
1. I paste the image into the background as many times as needed. Just make sure to set the size to native and stretch it if necessary. Also, try not to use high res images. It's a background. It doesn't need to be 10 mb.
2. Maptools will reuse it correctly. Though what I do is select it, hit ctrl+c and then ctrl+v as many times as needed(copy and paste paste paste).
3. Lower in comparison to not having a huge picture as background? Or lower verses something else. I don't really get what you are trying to do. But using the draw tools will use up less memory than the picture, if that is what you mean.

I am wondering if it has something to do with Java or some such. Either way, the performance hit is definitely something fairly new.

You will want to make your own topic.

[CoveredInFish]

Using the drawing tools could make horrible huge maps when you use insanely large textures. But usually you choose well-sized, tileable textures a with those drawings are much smaller than a background-image would be.

MapTool is smart in reusing images and should identify copies despite of the way you drop them on the map (it builds a hash-id from the image-content and caches it, so identical images get identical id - IIRC)

Reusing images (aka objects or stamps) is much more efficient than having lots of individual images or a single huge image. Images have a small overhead (to remember stuff like resizing, rotation, position, ...) but the image content has to be stored only once.

hth

[Deuterazamus]

Thank you both, your insight is very helpful, but let me clarify a few points...

I know that lightning and fow are major performance devourers cpu-wise however I've profiled the guy's computer via VisualVM (yes, it was a dark and stormy night...) and cpu is not overstressed as I whould expect. What really bogged down performance was IO hits once memory filled up. This kind of analisys encouraged me to try to lower overall memory usage of the campaign file.
1. In fact for the background I use a 200x200 28Kb image used alternatively as copy-pasted tile(for larger and more regular areas) and as filling for finishing touches, so to say.
2. When I need a texture I do just as masterclif does, but let's say that I have to add a table in the middle of a room. Insead of going through all my maps and resource library looking for a particular object I've already used I usually pop up a file explorer window, search for "table", find the image and drag&drop it on Maptool. If CoveredInFish is right and image are cached by hashcode then my behaviour should be fine.
3. I'm sorry, I should have explained better... it's not an excuse but I'm not english mothertongue so it's a little bit harder for me to be perfeclty clear. The huge image is there temporarily to help me lay down the map over it. I've attached 2 low quality screenshots, one of the backgound image and the other of the finished map. I should really have said: "when I'll remove the huge image will Maptool free up the allocated space, right?"

Here are the images:

Before

A room.jpg (52.23 KiB) Viewed 1207 times

After

A mapped room.jpg (44.29 KiB) Viewed 1207 times

[Sol Invictus]

I've heard several warnings about using clients with different memory settings from each other and from the server. May that is the problem. Maybe you need all of your MT instances set to what the weak link is set to?

[Azhrei]

[...] Fact is that the pc in question fills the java memory in a split second and then starts swapping like there is no tomorrow.

I think you found your problem.

That PC has little memory and needs to swap to maintain the image, and the drive is probably some butt-slow 4200rpm drive with 15ms average access time!!!

Have the user drop their video card bit depth down to 16-bit color (I think WinXP calls it "Medium color"). That should help significantly as all of the MT images that are kept in Java's heap memory at the same bit-depth as the screen will also be much smaller.

And 16-bit color is usually fine for MT maps. But it can't be changed on a per-application basis, so when the MT game is over he will need to change it back if he cares. I've found that most users don't really care.

[jfrazierjr]

The larger the map area, the more efficiency you will gain by using tiles that repeat. For example, you could build a "forest" with 100 individual trees copied 10 times each OR you could use 10 individual trees copied 100 times each. Both will put 1000 trees on your map. However, the former approach will eat up far more memory since it's 100 objects instead of 10.

There is a bit of overhead with each copy of the same object, but that overhead is x/y coordinates, scale, and rotation but it references the same object in memory once. So, let's just say that each of the "10" trees is 1MB and then multiply by .05 MB to store the extra information(times 1000 since there will still be 1000 total trees). So that's 10 MB just for the image portion and 50 MB for the extra information which equals 60 MB.

Now, go the other way and have 100 trees, so you start with 100 MB and then add in 50 MB in extra information for 150 MB. You have now just doubled your memory footprint by using more unique trees to generate the same amount of total trees.

NOTE: The above numbers are purely for illustration purposes and should not be taken as accurate representations of resource size within MapTool. The point being, the more you duplicate the same object/stamp, instead of using a new one (and by duplicate, I mean from the same physical resource on your file system, NOT via copy/paste duplication), the lower your overall memory size will be.


Another important thing to find out is exactly what is the target player's memory configuration on his machine and what is he providing to java? If he has 4 GB of RAM and is only providing java 256, then yea.. that's an issue. If he has 1 GB of RAM...well there is not much you can do about that until he gets more RAM(or a different computer). Also, as noted, all players should have their max RAM usable when they start java set to the same as the host server, so you as the GM should begin a fact finding mission to determine what they have available and begin making maps that cater to the requirements the players will enforce(and that might mean smaller maps or less graphically intense ones)

[Lee]

@Azhrei/jfj I haven't used the logger for image i/o in favor of the others, would it be relevant to the discussion here?

[Azhrei]

@Azhrei/jfj I haven't used the logger for image i/o in favor of the others, would it be relevant to the discussion here?

I don't understand the question. The logger isn't used for image IO, it's used for logging messages...?! I'm guessing there must be a word or two missing from the question.

[Lee]

I meant would the information in the log file be helpful to the OP for his question? Yeah, I know I could go do the process of replacing my logging file in .maptool to see for myself, but I'm just so lazy about doing things like that

[Deuterazamus]

I meant would the information in the log file be helpful to the OP for his question? Yeah, I know I could go do the process of replacing my logging file in .maptool to see for myself, but I'm just so lazy about doing things like that

This was enough of a hint for me to look in the misc folder and find the log configurations I'll give a it shot with full log next time I play or next time I'll get some spare time to make some further investigation...

The point being, the more you duplicate the same object/stamp, instead of using a new one (and by duplicate, I mean from the same physical resource on your file system, NOT via copy/paste duplication), the lower your overall memory size will be.

While I understand your example (I read it before in a couple other threads) I'm not sure I understand correctly what you meant here. I copy/paste the same stamp/object from inside Maptool, am I doing somthing wrong? Just sometimes, see the "table" example in my previous post, I take an image I've already used in the same campaign from the file system and drop it on a layer. Is this "bad practice"?

Lastly, the 16-bit color depth change might be a quick and easy way for my player to spare some precious memory, thanks!

[CoveredInFish]

Dropping from file system or copy-pasting from inside MT or dropping from the resource library is all okay - as long as the image is exactly the same (content-wise). All this leads you to reusing a single image.

Joe just says this: if you drop redTree and greenTree you need memory for two times image-data and two times overhead while using 2x greenTree just need mem for image-data once (but 2x overhead).