AI War:Current Post-8.000 Beta

Prerelease 8.008

(This isn't done yet, we're still working on it.)

• The game now uses vsync in order to cap the framerate and avoid out of memory errors. If you are running below your screen refresh rate, which is super common, this still shouldn't affect your actual game speed adversely.
  • For some players, it seems that with the framerate being able to just run too fast and thus cause a lot of transient memory, this would cause the game to lock up.

• A major shift to how the game pools sprite objects internally has been made; now there is one global pool regardless of sprite size, rather than a separate pool per sprite size. This adds a small bit of overhead to some draw calls (and none at all to many), while at the same time saving a fair bit of internal RAM.
  • This reduces the starting memory of the game by about 50MB, the low-load memory by about 37MB, and the high-load memory by about 19MB. Why exactly there is this much tapering-off is unclear, but it certainly is much more economical in general.

Official 8.007

(Released September 9th, 2014)

• Undid the change to make the game use DrawMeshNow so much in the prior version, as this may have been causing freezes and hitching for some players. And it didn't seem to be helping players overly much.
  • Thanks to Daggus for reporting.

• Updated the game code to reuse materials for same-texture draws, rather than using quite so many materials as it was before.

Official 8.006

(Released September 8th, 2014)

• The game only uses DrawMeshNow again, since it seems to have better performance than DrawMesh in the specific context of AI War. This may be the root of the graphics performance woes that some folks are seeing.
  • Thanks to blackied and Bud Backer for reporting.

Official 8.005

(Released September 7th, 2014)

• Completely rewrote the frame-scheduling/limiting code and the way that frame draws are calculated in order to solve some severe performance issues that the game has been having since the upgrade to the new unity engine.
  • The issue that was happening was really kind of a confluence of events of different architectures clashing with one another. It wasn't bad code on anybody's part per se, but it was older engine code of ours clashing with newer unity engine code. Now our code has been updated with their revised engine in mind, and the result is seemingly the fastest AI War yet, although we'll see what other people report.
  • Thanks to Bud Backer and blackied for reporting.

Prerelease 8.004

(Released August 29th, 2014)

• Fixed an issue that causes a crash while (auto)saving when the game is run with the steam overlay enabled (and, probably, the report-high-scores option on).
  • Thanks to map66, spot888, and ArnaudB for reporting.

Official 8.003

(Released August 25th, 2014)

• Fixed a bug in the previous version that was preventing shots and explosions from drawing at all in far-zoom.
  • Thanks to Toll, Dragondraikk, and others for reporting.

• The nebula intensity and max loading threads sliders are now wider, and also show their values. This lets you adjust them with better precision, and actually see what their current value is.
  • Note that for the max disk threads slider the only values it allows are:
    • 140, 160, 180, 200, 220, 240, 260, 280, 300, 320, 340, 360, 380, 400, 440, 480, 520, 560, 600, 650, 700, 750, 800, 850, 900, 950, 1000, 1050, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 2000, 2200, 2400, 2600, 2800, 3000, 3500, 4000, 4500, 5000
  • Thanks to Kahuna and Vyndicu for inspiring these changes.

• Also, to answer a great question about the "max loading threads" feature from the prior version:
  • Question: "I don't quite understand what this things does. Does it affect performance? If yes.. how? What would happens If I set it to minimum and what if I'd set it to maximum?"
  • Answer: It affects disk loading only. So in other words, think of it like this:
  • 1. If the number of max disk threads is 10, and you need to load 4000 items, then it will start loading 10, and then as soon as 1 finishes then it puts another in the list, and then another when the next one finishes, and so forth.
  • 1.a. Assuming that the loading time and processing time are about even, then this is really just as efficient as any other method. However, that is NOT the case, because once something is loaded off disk it needs at least a few ms to convert its format from PNG into a GPU-specific compressed texture format that is prepped for being able to be sent along the bus immediately at any time to the GPU.
  • 1.b. Even assuming that you only had a single-core processor with no hyperthreading or anythinig, case 1 is still somewhat less efficient because your CPU is still able to split things between threads, and your disk IO (which is the biggest bottleneck for any sort of loading operation) is not being fully utilized during the time when there is texture compressing, etc, going on.
  • 2. In the case that we've been using for a while, we used 140 threads at max. So in the case where you need to load 4000 items, the likelihood of your disk IO ever being underutilized is basically zero. The ratio of CPU-processing time to the number of threads to the amount of disk IO at all available on modern hard drives -- even SSDs -- is such that unless you had the fastest SSD possible paired with a 15 year old CPU somehow, then you'd likely not be wasting any disk I/O. Even with theoretical future hardware, as long as CPUs remain equal to or faster than HDD loading speeds when it comes to these sorts of operations, it's perfectly fine. And that's highly likely.
  • 3. However, in the case of the Unity bug, it can randomly tack on an extra 3-10 seconds of CPU "processing" where it does NOTHING. It just sits there, not even spinning cycles or using CPU capacity. What is it doing? I have no idea. It only affects certain systems, and never has affected one of mine. It did affect one of Keith's systems a year or so ago, but does not any longer. Anyway, in this case, Unity is basically "helpfully" simulating your having the worst CPU in the world, paired with whatever your hard drive is. 3-10 seconds to process that texture!? My 800mhz 2001 laptop could have managed better than that.
  • 3.a. In this case, the amount of concurrency matters a lot. If you have 4000 threads to load, and you set a maximum of 4000 threads loading at once, then basically it throws everything at the disk I/O at once. The operating system is going to go "whoa, buddy, you guys are going to have to get in line because you just asked me for a mess-ton of stuff at once." So your disk I/O will be pegged at full capacity, which is what we want. But the OS manages which things get loaded first, and that's fine with us because order doesn't matter. Meanwhile, on the CPU side, while each of these 4000 threads "spaces out pointlessly" for 3-10 seconds, they are all pretty much doing it simultaneously for the most part, or at least close to that, rather than doing it a few at a time. This makes it so that those stupid space-outs happen more on top of one another rather than one after another, in other words.
  • Anyhow, that's how it helps with that particular issue. How will this affect performance during the rest of the game? Basically it won't. It only affects things like loading graphics and music, and it only has any effect at all when there are more than 140 of them that need to load at once. That almost never happens during the game itself, and if it did happen then that would be a case where you'd get a moment of lag anyway, and if you fall into case #3 above, then it would actually HELP your performance. But in the case of a few images popping in every so often, those are in 2s and 3s, or even a few dozen at once, not 4000 at once, heh.
  • In terms of negative side effects, there really are none... except that on certain OSes, the number of disk calls are directly tied to the number of threads in a program in general, and the max thread count is set to something like 256. So in those cases, if you exceed 256 threads, you get a crash. Hence my not cranking this up automatically for everyone.

Official 8.002 Lock And Load

(Released August 25th, 2014)

• Fixed a bug where at certain middle-high levels of zoom a wormhole would be drawn twice, with the second being in a spurious and variable visual location.
  • Thanks to Toll for reporting.

• A new Preload All Images settings option has been added to the graphics tab.
  • Defaults Off. With this option enabled, all of the textures for the game are loaded immediately at startup. This causes the game to load slower at first, but then prevents any need for images to load later on during gameplay.
  • Thanks to Aklyon and doctorfrog for inspiring this change.

• A new Max Loading Threads settings option has been added to the graphics tab.
  • Default 200. Setting this to progressively higher values will make more images/etc try to load from disk simultaneously. On some operating systems (like OSX), there are hard limits on how many threads can be running at a time. In those cases the limit is often 256, so going above 220 is probably not a great idea. For other operating systems, you may be able to crank this up and have better concurrent loading speeds.
  • Previously the default was 140, but 200 should be safe for all OSes.
  • Thanks to Aklyon and doctorfrog for inspiring this change.

• When you first load the game, it now always loads all the images for the bonus ship far zoom images. This way you don't run into load times on images in the middle of generating new map seeds in the lobby.
  • Thanks to Aklyon and doctorfrog for inspiring this change.

Official 8.001 Oiling The Engine

(Released August 20th, 2014)

• Since the upgrade to the new engine version, the game has been running with 2x antialiasing on. This may have been what caused compatibility issues with some (very very - 2001 era) old graphics cards and drivers.
  • Thanks to greywolf and mirkobern for helping us discover this change.

• Since the upgrade to the new engine version, the game has not been capturing fullscreen mode the same way on OSX. Fixed.
  • Thanks to jerith for reporting.

• A couple of our shader definitions were slightly different in AI War compared to our later games. Nothing major, but very slightly less efficient. This may have been a factor in some compatibilities with certain outdated linux drivers (fingers crossed).
  • Thanks to mirkobern for helping us discover this change.

Pre-8.0 Release Notes

• Found here: http://www.arcengames.com/mediawiki/index.php?title=AI_War_-_Current_Post-7.000_Beta