Graphics in general

Technical Support & Bugs
1

I’ve been sticking with 3.0.17 until the bugs have gotten worked out in 3.1 but I decided to take the plunge and migrate my game over to 3.1. I’ve also recently rebuilt a new system:

Intel Dual Core
2 gigs Ram
nVidia 8600GT w/ 512 megs
Win XP SP3

I noted there has been some discussion on the graphics engine but I wasn’t paying that much attention to it. What I have experienced on this end is that the rendering in 3.1 is so incredibly sluggish as to make my game practically unusable. It’s very, very slow. There’s times when I’ll be moving a counter from one end of the map to another and sometimes I have to wait for the counter to catch up with the mouse pointer for a considerable amount of time. If I change zooms, it may take as long as 15 to 20 seconds before it re-renders the map.

I’m running the heap at 512 / 1024
I have high quality scaling turned off
I’m running my system colors at 16 bit as 32 bit was making it even worse.
It doesn’t seem to matter if I have memory mapped images turned on or off - results are about the same.

I went back to 3.0.17 to see if my new system may be causing the problems and the graphics run as smooth as silk in the older version.

I noticed there was some mention of the new version working better with smaller maps but after a year of development on my game, I’m really quite reluctant to go back and redo over a thousand graphics to accommodate. I will if it’s absolutely necessary but …

Are these known issues that are being worked on? If you need anymore info or some experimentation, let me know. I’ll be glad to assist. I’m preparing the game for a public release but I don’t think I can release it like this.

Thanx

2

Doc,

Thanks for the report. Most people find that 3.1 is much more responsive than 3.0, so we need examples like yours to plug up the remaining drags on performance.

After the obvious latest-Java-version check, start by figuring out what actions slow you down the most. It is slow simply clicking around a map with no counters? Scrolling? Notice that v3.1 divides the map into tiles and only loads them when you scroll to a new area of the map. Is it the initial loading that’s slow or is it still slow after the tiles have loaded?

rk

Post generated using Mail2Forum (mail2forum.com)

3

Is you module available for download somewhere? We will need to have a close look at it so see what is going wrong.

Thanks,
Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

4

Just a guess, but looking at the images of the mod I would say the graphics
being used in it are the 32 bit variety - the detail is astounding, but its
probably half the problem also! :slight_smile:

Can you verify your graphics are all 8 bit and same palette / file type - no
mix and matching files (png/jpg/gif/bmp etc…)

drnostromo.com/hacx/TBK-06.jpg

Post generated using Mail2Forum (mail2forum.com)

5

That’s an old screen shot (grin). It looks even better now.

I know all the graphics are PNG and the last time I went through them I did my best to make sure they were PNG-8 …although a few PNG-24’s might have gotten in there but I doubt it. Also tried to make them all 128 but several ended up saving as 256 anyway. I was having trouble with transparencies using 128.

Problem might have something to do with the amount of counters used as well. The main map is 5430 x 4260 and it’s basically blank of terrain features if you start a new game. The terrain is built in a semi-random fashion using terrain disc. All the terrain you see in that screenshot are separate terrain discs that are laid on the map prior to game play. Combine that with several decks of cards, buttons, chits and various other things, there’s a lot on the map.

Here’s a screenshot I just pulled out of the game. This shows the main kingdom map in the process of a world being built for game play. Notice the lower left area (Mariah Lowlands) is done and I’m in the middle of placing tiles in the Midlands. This is where the engine slows down to a crawl. Saving the game, shutting down Vassal, re-starting it and reloading the saved game will speed it up for about a dozen more tile placements but then it slows back down again.

drnostromo.com/uo/To_Be_KingMap.png

I’ll package up the mod a little later and give you guys a link to it …probably in PM. I don’t want public copies floating around yet.

6

Joel will be the person to investigate, he is pretty busy at the moment. The large number of counters could well be the problem. I would be interested in a look to see how it runs on my machine (Vista, Quad Core, 4Gb).

How many counters would you estimate are on the map at this stage?

Please include a saved game with the map already populated.

Thanks,
Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

7

I don’t know the actual count but the game has over 1000 components and, except for those components used in the Lezon’s Palace map and the Catacombs map (which are small), everything is accessible from the Kingdom map either in the form of counters, terrain tiles, stacks of player tokens, 14 decks of cards with about 900 cards, chits, buttons, etc.

Previous versions had much of this stuff accessible in menus, tabbed windows, etc., but in playtesting, we found the the interface to be extremely clunky and annoying with constantly searching for things and windows covering up other windows, etc. It was a real pain. That’s not the fault of the vassal interface …it’s just the way the game is …you’re constantly looking for things. So, I solved the problem by just placing everything on the map. In playtesting, that was an extreme improvement and since there was no graphics issue with 3.0.17 for me or my partner, I never considered the number of counters being an issue. That was on an older computer, too (2.4 GHZ, older Gforce with 256 megs, 1 gig ram) and it ran just fine.

Anyway, here’s the TBK mod package. I’ll send the individuals in this conversation the zip password in PM.

drnostromo.com/uo/TBKTest.zip

Included:

TBK.mod - DOH!

PartialBuild.sav - This is the map you saw the screen shot of above in case you want to test it by placing some terrain tokens.

Built.sav - This is a completely built world.

4_World.html - This is the part of the rule book which goes into detail on building a new world. Don’t know if that will help.

In a nutshell - You would use the Create World menu option to bring up the Terrain tiles and world creation tools.

You can open the other two maps by using the button on the lower left corner of the Kingdom map or use the following hot keys:

ATL-K - Kingdom map
ALT-L - Lezon’s Palace
ALT-C - The Catacboms

You’ll note there doesn’t seem to be any problem with the palace or catacombs as they are much smaller with fewer counters.

How much do you think things would improve if I drop the overall size of everything associated with the Kingdom map by roughly 25%? The reason they’re as big as they are now is because Vassal didn’t have the option of zooming up beyond full size in previous versions. Now that it can, I can shrink stuff. It will put my release date behind at least another month but I’m willing to live with that if it will make a significant difference.

I’ll be around a lot the next few days and I have a Ventrilo server if it will help to voice communicate.

Thanx for the help.

8

Hi Fritz,

I have done some initial investigation.

I was able to run the module with the full built scenario with adequate performance once I bumped the Java Heap size up over 1Gb.

Are you aware that whatever means you use to increase the Java Heap size in 3.0 does not apply to 3.1? In 3.1, each module can have the Heap size set individually in the Preferences for the module. The default is 512Mb max. Make sure this is set to 1000 or 1300 (the maximum) and try again.

As I kept zooming and scrolling about, eventually, I maxxed out the Java Heap (1300Mb) and performance dropped off considerably. Part of the reason it works well on 3.0.17 is that there are only 3 zoom levels available, while in the 3.1 version, there are 6 available. This seems to be a bug in the 3.1 implemntation of the new Zoomer, it should copy the existing zoom levels, not make up new ones. I tried setting 3 specific zoom levels in the 3.1 version and this helped keep memory under control.

At this point, I will pass this on on to Joel/Michael with these questions:

  • The 3.1 Zoomer is adding additional levels that do not exist in the 3.0 version
  • This is a very large module and the 3.1 graphics was supposed to improve memory usage on large modules, yet 3.0 performance is significantly better, with signigicantly lower memory usage (580Mb on 3.0 as opposed to 1Gb+ on 3.1, even after reducing the number of zoom levels)

The memory consumed by images is in proportion to the square of their size, so reducing the size of everything by 25% will result in .75x.75 = 56.25% i.e. nearly half the memory usage. I would STRONGLY recommend that you do this, regardless of what Joel comes up with.

Cheers,
Brent.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

9

Yep. That’s exactly the percentage in size reduction I came up with.

Since the map can now be zoomed in over the actual size, I think that would be my best course of action. I’ll start doing that as soon as I finished rebuilding the website.

Well, a gamers life is never dull, is it?

10

Thus spake “Tim McCaron”:

Reducing the bit depth will have zero effect on drawing performance.
All images are stored in memory as 4-byte ARBG. The images here will
require the same amount of space as a monochrome image of the same
dimensions.

I’ll have a look at this problem, but it’s going to be some days before
I can get to it. (I’m home again now, but digging myself out is not a
small job. I’ve been at home a total of three weeks since the beginning
of April.)

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

11

Thus spake “Brent Easton”:

That’s the theory I intend to investigate first. I know of several
places where we do some rather inefficient things (linear, instead
of log n) when searching for pieces, but these would only matter much
if you had a huge number of pieces.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

12

Thus spake “Dr_Nostromo”:

I wouldn’t start doing that until we determine what the cause of the
problem is. It might turn out that reducing the size of your images
is entirely unnecessary.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

13

Sounds good.

I’ve started working on an alternate version and I’ve already done a lot of reduction work on it. …just in case.

I’ll put is aside for now and get back to working on the web site.

I’ve sent you the zip password for the mod in PM in case you need it for testing.

Thanx

14

Thus spake “Michael Kiefte”:

So far as I know, 24-bit images are always stored as 32-bit images anyway
in order to ensure that each channel occupies the same bit positions in
each word. You wouldn’t have an alpha channel this way, but you’d still
use the same amount of memory.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

15

UPDATE:

 I've managed to reduce the main Kindgom map and all the terrain tiles that are used on it (as well as a few other things) by 25%. I began building a world with the new dimensions and my heap set at min-1024, max-1536.

It was smoother and I could get about twice as much done before it started to slow down significantly but it still got pretty bad after awhile. I had to save and restart 3 times before I could finish building the main map.

Something new, I noticed. At one point, when it was getting somewhat laggy, I popped open the Map Overview window to jump to another part of the map and the game practically came to a complete halt. As soon as I closed the overview window, it returned back to the level it was at before I opened the overview. The change was quite dramatic. …like I was opening a second map of the Kingdom.

16

Thus spake “Dr_Nostromo”:

I’ve spent most of the evening examining in a profiler exactly where
CPU time is spent when dragging a single token from one place to another.
Here’s what I’ve found:

  1. A negligible amount of time (6%) is spent painting the map. Like I
    suspected, it’s your tokens which are consuming almost all of the time.

  2. We were calling DragSource.isDragImageSupported(), which is a
    ridiculously slow method, basically every time the mouse moved during a
    drag. Fortunately, DragSource.isDragImageSupported() shouldn’t change what
    it returns over the life of an application (so far as I can see), so we
    can just call it once and cache the result.

  3. ScaleOpBitmapImpl.equals() uses ScaleOpBitmapImpl’s RenderingHints as
    part of its test. Unfortunately, RenderingHints.equals() is ridiculously
    slow—except in the case of identity. Fortunately, we’re not using
    different RenderingHints right now, so changing all ScaleOpBitmapImpls
    to use the same RenderingHints object dramatically speeds up
    ScaleOpBitmapImpl.equals().

  4. There’s a bug in Labeler which nobody noticed before which causes the
    imaged being drawn to be completely regenerated each time it’s used. Your
    module makes heavy use of Labelers. The changes I made in 2 and 3 were
    only noticeable in the profiler. When I fixed this, I didn’t need the
    profiler to tell me that what I’d done had worked.

All of this is in svn3981:

nomic.net/~uckelman/tmp/vassal/

Try it and let me know how this works for you.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

17

Wow!

I just took the time to completely build the Kingdom map at various zoom levels and encountered no lag at all throughout the process. What a tremendous difference. Awesome job, Joel!

I’m assuming these fixes will be in beta 3. Do you have a general ETA on when beta 3 will be released?

18

Thus spake “Dr_Nostromo”:

Thanks.

I’m waiting for the usual suspects to try this build. Maybe we’ll have
beta3 tonight or tomorrow, so long as no one discovers any major problems
which didn’t already exist in beta2.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

19

Thus spake “Dr_Nostromo”:

So I imagine that you can go back to your full-size graphics now instead
of 75%? Does this clear up all of the performance problems for you?

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

20

It certainly seems to have cleared up the performance issues. I haven’t played a long session game yet but I believe that if you’re going to get lag, it would be during the world building process and that didn’t happen.

I’m going to stick with the reduced graphics as they can be seen easily enough and Sudden Death and I have been making a lot of changes to the mod so switching back would be more trouble than it’s worth.

One of the things were working on is automating the world creation system. That will obviously increase the overall performance of the mod.