#191 - Minor optimization to start location importing.  Have the PCX create a subimage directly when getting civ-colored start locations.

Not a measureable difference on my laptop.  Also realizing that the timings are more variable here than on my desktop or Core 2 Extreme laptop, probably because the clocks can vary so much as new computers spin up or down.
a9723a8a8777 — Quintillus 8 months ago
Add a five culture level test (versus the six that are standard).

Also update .hgignore b/c there's way too much that isn't committed, mostly config files.  Still could use improvement.
7a16dbb980ad — Quintillus 8 months ago
Add a test for Sengoku, which only has one spaceship part.
97fda6a689b4 — Quintillus 8 months ago

Just bumping the version and adding a line to the make script so it goes back to its original directory.
d8e26c39dceb — Quintillus 8 months ago
Update the editormake.bat script to include the launcher, and a new Editor_Launcher.bat file that will launch the launcher.
62c491845baa — Andrew@Alpha15 8 months ago
Give a warning when you try to open a file if memory is likely to be insufficient, and graphics are enabled.

Also make the startup widget only appear if the graphics are enabled.  The on-open-file warning will still fire if you enable graphics after starting the program.
9a9114b137b4 — Andrew@Alpha15 8 months ago
Add an Insufficient Memory startup widget, complete with red font and instructions.
2264b8d92872 — Andrew@Alpha15 8 months ago
Start refactoring StartupWidgets into constituent parts.

Somewhat limited because if you use the "Import previous settings" widget, it then updates the text of the "Most recently used file" widget, and it's not designed to have that cross-widget communication without them all being in one big method.
4c52e0c8f170 — Andrew@Alpha15 8 months ago
Optimize threaded PCX imports so they don't create a BufferedImage of the whole PCX if one isn't needed, just BufferedImage instances of the constituent parts.

This doesn't seem to have a significant impact on time of import; it seems processing the PCX and setting the pixels takes much longer than asking BufferedImage for a subimage, even though the direct sub-image-from-PCX method in PCXFilter performs fewer calls to ask the BufferedImage to set some pixels, would you kindly?  (one, versus one per row, a not-negligible difference in count)

It does reduce end-of-GraphicsImport memory-in-use-before-garbage-collection by about 25%, from roughly 240 MB to roughly 180 MB.  Unfortunately, this doesn't appear to have any real impact on memory requirements, since after the method exits and garbage is collected, it drops back to about 130 MB, of which 110 MB (decimal) is the BufferedImages for the graphics, which cannot practically be reduced in size, short of finding a way to compress textures in memory (which recent versions of DirectX allow, but initial searching in Java has not yielded anything insightful, and whether it's worth the CPU overhead is doubtful).

Still, a bit of technical progress, and even if the benefit is not small compared to the whole, it should be somewhat more efficient.
a9047313983e — Andrew@Alpha15 8 months ago
Set thread titles for debugger/profiler identification.

Also de-duplicate resource graphic importation.  This should make things marginally quicker, and also reduces the memory needed to import the graphics by about 1.19 MiB due to not retaining objects unnecessarily.

The VisualVM profiler is certainly clunky, but with a breakpoint at the right spot, a heap dump, and the right configuration (Preset: GC Roots, sort by Retaining descending), it eventually yielded an actionable insight.
1060d15f735d — Andrew@Alpha15 8 months ago
Disable the tabs if we realize that we have run out of memory.

Testing reveals that 186 MB is the minimum required to open Rise of Rome with maps, testing to the closest 2 MB increment that works the first three attempts.
5685f36b1bc7 — Andrew@Alpha15 8 months ago
Semi-successfully alert the user if we run out of memory, via a new UncaughtExceptionHandler.

One of the challenges is that all the threads are trying to gobble up memory at once, so even showing an alert is almost guaranteed to fail; the only time I have seen it succeed, it had the outline and title but the body of the alert was missing.  Hence, the title is also updated to indicate the error state, and that seems to work at least fairly reliably.

Testing with -Xmx128M and opening Rise of Rome reliably allows reproduction (with graphics enabled).
f46fae2fcff6 — Andrew@Alpha15 8 months ago
Teach the PCX threads how to subdivide into constituent parts.

So far, despite nulling out the original after it's done, the impact on memory usage is within the margin of error (+/- 1%).  With it setting off all the threads and ripping through them at the same time, this is not particularly surprising.

However, it is having a very positive effect on the readability of GraphicsImport.java.  It's one of those areas with a lot of residual legacy code quality, and this is moving it in the right direction by a  significant amount.
b4a8042aabef — Andrew@Alpha15 8 months ago
Refactor to reduce the boilerplate around finding file names.

Reducing memory use is probably going to have to involve not multithreading as much.  Along with that, teaching PCX Import Threads to parse things out as soon as they import could help, as that would allow the non-processed version to be discarded more quickly.
4d825bdf3ab5 — Andrew@Alpha15 8 months ago
Add/re-add memory usage metrics around the graphics import.

Goal: Reduce the peak usage, currently 324 MB for Rise of Rome.
Allow barbarians to own cities, either directly or as a civilization.

Also add a safety level for the map, which both this and the 512-city-limit will use.

And have the renderer fall back to culture group 0 if culture group -1 is used.
Add 512 city limit check when adding new cities.
Enforce the 256 building type limit as long as safety levels are enabled.