AI War:Current Post-8.000 Beta

Prerelease 8.025

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

Official 8.024

(Released October 18th, 2016)

• Fixed several bugs, some going back to the very beginning of the mechanic, where Exogalactic Strikeforces were not aggressive enough about spending their whole budget. Especially when the set of eligible ships is heavily restricted (e.g. the guardian-only or starship-only AIs).
  • Thanks to Mal for reporting.

• Fixed a null-reference bug in the code for drawing health bars of carriers.
  • Thanks to Kalzarius for the report and save that finally let us reproduce this.

• Added some protective code to avoid index-out-of-bounds errors on the Achievements window.
  • Thanks to Hedrik for reporting.

• Fixed various misuses of "It's" and other typos in the loca files.
  • Thanks to Aeson, Toll, Blue_Lotus, tadrinth, and pumpkin for reporting.

• Updated the Arcen Games logo used by the game to be the modern one that we've used for the last few years.

• Updated the main menu of the game to have a graphical button that opens a window that tells you about the AI War II kickstarter, and which then has the option to click a button and find out more about the project if you're willing/interested.
  • https://www.kickstarter.com/projects/arcengames/ai-war-ii/

Official 8.023

(Released February 22nd, 2015)

• Fixed an exception that happened when trying to load into a game in the last version.
  • Thanks to chafouin and RockyBst, for reporting.

Official 8.022

(Released February 22nd, 2015)

• Put in better error message handling for if a language loca file failed to open.
  • Thanks to GarathJJ for reporting.

• fixed a very nonsensical error that could potential happen on OSX computers during the initialization of achievement lists. Though really this seems to have been some sort of internal engine issue, so it's troubling.
  • Thanks to GarathJJ for reporting.

• Put in some code to prevent SetFarZoomIconInner from throwing null reference exceptions in the event that there is a race condition where it is trying to create a far zoom icon image before everything is properly loaded.
  • Thanks to GarathJJ for reporting.

• Put in a change that should hopefully stop the game from halting with a permanent "loading items from disk: x" count if an image fails to load for some reason.
  • Thanks to TheUbiquitous for reporting.

Official 8.021

(Released January 6th, 2015)

• Our recently-added ArcenAsyncFile was causing some crashes in cases of extreme numbers of threads being used over a short period of time.
  • It appears that the version of Mono included in Unity 3D does not handle thread disposal quite like normal .NET does -- and peculiarly, always reports the number of threads as 0 rather than whatever the real count is. So that was... problematic to say the least, when we wanted to instantiate a lot of threads and then destroy them. Instantiating them and then reusing them was what we had tried to begin with, but there were some unexpected hangups there as well.
  • What we're now using, which seems to work great, is the ThreadPool class, which is part of Mono/.NET that is specifically aimed at doing this sort of thread reuse in the first place. It seems to work exactly as advertised, fingers crossed. ;)
  • Thanks to pxld1, Kraiz, Vinco, and Spiderseam for reporting.

Official 8.020

(Released January 5th, 2015)

• The ability to submit leaderboard scores to steam has been completely removed. This was previously opt-in, but that was causing problems when enabled. And in general the global scores don't mean much given how many variants players can have in terms of how they configure the game.

• Since 2010 when we switched to the Unity 3D engine, we've been using their WWW class to load images from the disk asynchronously. However, in more recent versions of unity it's been a case where for a small number of people, if they had multiple network adapters on their machine, then the WWW loads from their own disk would load incredibly slowly. We didn't know until now what exactly caused that.
  • We've now created a new internal ArcenAsyncFile class that is our own implementation of the asynchronous disk calls (and will later be extended for network calls as well). This has been tested on windows, osx, and ubuntu, and it not only works, but seems to load noticeably faster than before. This should also bypass the issue that the WWW class had with getting oddly slow (if it doesn't, then something _seriously_ strange is going on, as they have almost no code in common).
  • Thanks to Vanreis for the latest report, and figuring out that this was related to the number of network adapters.

• The WWW class is no longer used for checking for game updates, but instead the new ArcenAsyncFile is now used.
  • This _should_ provide more fault tolerance when programs like AVAST want to kill the ability of the game to check for updates. Knock on wood!

Official 8.019

(Released October 9th, 2014)

• The windows version of the game also now uses the "tame" garbage collector expansion again. It doesn't really expand the GC nearly as much as one might want, but it does a good enough job and doesn't cause the internal allocated RAM to get needlessly high too fast.
  • Thanks to Zair for reporting a problem that may have been related to this.

• Target framerates are again used, rather than letting framerates run unrestricted as they have in the last two versions.
  • However, the targets are set a lot more generously than before, so you can get nice high framerates even on lower performance settings.
  • What this helps, though, is runaway framerates in particular when you are tabbed out of the game. This mostly seemed to affect windows, and could cause memory-related crashes just due to being tabbed out of the game (Chris wound up having this happen once, too).
  • This fix is the best of both worlds, because it lets the framerate be high without being insane, and thus lets things be smooth without letting RAM churning kick in.
  • Also, whenever there are assets loading or you have not started a game yet, the game uses a target framerate of 240, which is extremely high. This should keep things loading quickly for doctorfrog, knock on wood. The problem framerates tended to be when the game was running at 900+ frames per second, which it would easily exceed when you tabbed out in the last couple of versions.
  • Thanks to Zair for the initial report.

Official 8.018

(Released October 8th, 2014)

• The new logic for stretching the garbage collector in the prior version works great in windows, but for whatever reason causes the spinning beachball of death on OSX. Most likely it is also a problem on linux.
  • Thus the old tamer logic is now applied again on OSX and Linux (and it seems to work fine there, anyway), and the new more aggressive logic is still used on windows (where the old tamer logic stopped working due to unity 3d upgrades at some point).
  • Thanks to Bud Backer, Sounds, and Tokyodan for reporting.

Official 8.017 Boost THIS!

(Released October 8th, 2014)

• Reduced the internal RAM used by iterating over lists of planets.

• Newer versions of the unity engine have apparently not been working properly with our "stretch the garbage collector" method, so we've implemented a revised one that actually does stretch the GC. The newer versions of unity are more efficient about not wasting GC space, which is great, but we wanted to create more of a buffer, so needed to work around that new optimization to do so.
  • What does this accomplish? Well, it leads to less-frequent garbage collections in general, which causes fewer related hitches during gameplay. Though those hitches are relatively lightweight on modern computers in general.

• Reduced the internal RAM and some minor CPU costs used by finding animators and far zoom icons and associating them with ships.

• Vsync is now off by default, as is the framerate limiter. This helps to smooth out slight jerkiness that could be caused by the latter in particular.

• Fixed an issue that could cause planet-wide munitions-boosting to have a much higher performance cost than necessary.
  • Note that the mere existence of these would cause performance issues throughout the whole solar system, no matter what was going on in the game. The more ships on the planet(s) in question, the more they would cause periodic lag (general jerks in the framerate every 2ish seconds or so).
  • This issue was actually "years old," but due to recent performance improvements in other areas, it finally became more noticeable.
  • Thanks to RockyBst for the report and save.

Official 8.016

(Released October 7th, 2014)

• Fixed an issue in the non-combined icon mode where the icons for ship modules were drawing.
  • Thanks to Fleet Unity for reporting.

• Fixed the remaining flicker of far zoom icons, which could happen when ships of one sort changed icon colors. So if something was changing icon colors periodically in particular, you'd notice icon flicker at that point.
  • The solution to that was actually making these into dictionaries in-memory, and the way that this is done actually leads to even MORE efficiency gains through more batching. So yay, even more performance. :)
  • Thanks to Bud Backer for reporting.

Official 8.015 Flicker Factor

(Released October 6th, 2014)

• Fixed an issue in recent versions where if you turned off icon grouping in far zoom, the display would not really work in far zoom.
  • Thanks to StarKeep for reporting.

• Ported over the "sorted batched" sprite logic that is used for shots and ships in The Last Federation. This is now used for far zoom icons and shots and similar in AI War, and prevents the bulk of that flickering that previously could be seen.
  • Thanks to Bud Backer, Kahuna, TechSY730, Fleet Unity, and The Hunter for reporting.

• Far Zoom Icon Combination Distance is now default of 0 (and will automatically reset itself to that for everyone), rather than a default of 12.
  • This causes the combination of far zoom icons to lower the number of draw calls to cease. This actually saves you some CPU, which is great, and it shows you literal icons for every ship rather than combining nearby ships into one kind of compound icon.
  • This also solves the remainder of the flicker problem that has been reported in recent builds. Why this aspect of the flicker is only showing up recently is not entirely clear, but it seems related to the overall higher framerates and thus the higher rate of recalculation of these groups.
  • Most importantly of all, these groups really are not important for performance reasons now, because the game is now doing the sprite batching that these were trying to work around the lack of previously. We still have the feature available in case someone does turn out to need it, but this is not expected.
  • Thanks to Bud Backer, Kahuna, TechSY730, Fleet Unity, and The Hunter for reporting.

Official 8.014 Now With Moar

(Released September 16th, 2014)

• The "sort ship textures" option has been removed from the settings window, because it literally had no performance benefit anymore (and yet still would make ships look a little odd in close zoom when they passed one another).

• Put in a protection against a (possibly rare or new or both) division-by-zero bug in the health bar rendering code.
  • Thanks to FluidDynamite for reporting.

• A major new addition to the render pipeline has been created, and is now in use not only here but also in Spectral Empire and The Last Federation. This new systems does highly-efficient sprite batching, which makes the framerates absolutely skyrocket when there is a lot of stuff on the screen at once (big battles, ahem. Previously on machines that would chug if there were thousands of shots onscreen at once (for instance), those now render incredibly efficiently.
  • The amount of performance load this removes is frankly staggering. In one performance regression test savegame, there were 25,317 enemy ships invading a system. This was leading to 5,875 draw calls at times, which is just astronomical. With the batching, that 5,875 translates to merely 162, and everything is still drawn visually the same as it was before. With the batching on, during this battle the game was running in realtime speed with 50fps framerate (a drop from the target of 60fps, but not a heavy one for that scale of battle).

Official 8.013

(Released September 11th, 2014)

• Fixed an issue from 8.008 and onwards where if you were centering on some ships that were moving, they would appear to be blurry and jump around.
  • Thanks to Fleet Unity for reporting.

Official 8.012

(Released September 10th, 2014)

• Reverted the do-while logic that was introduced in 8.009, which was causing ship movement to be extremely jerky even on high framerates. All the other improvements since then have been retained, as they were actual improvements, but that one wasn't working out.
  • Thanks to FluidDynamite, Recombinant, and Fleet Unity for reporting.

Official 8.011

(Released September 10th, 2014)

• Converted a dictionary lookup to an array lookup for the far zoom icon renders. This possibly saves a tad of RAM, and almost certainly saves some CPU time.

• No longer compressing the far zoom icons, as that was making them ever so slightly blurry, most particularly on some machines more than others.
  • Thanks to Fleet Unity for reporting.

• The last few versions have forced vsync on, but this is now a settings option that is merely on by default (so you can turn it off if it doesn't seem to be working well).

• The game also again now uses the Application.TargetFramerate setting, which it used to use, but hasn't lately. We're not super convinced that this works as advertised on windows, but perhaps this was making a difference on linux.
  • Thanks to DrNoid for inspiring this change.

Official 8.010

(Released September 10th, 2014)

• In recent versions, the game had been updated to only redraw itself when the simulation actually changed. Aka, if ships hadn't moved, then don't clear the screen and draw them again -- that wastes CPU power and potentially makes your entire framerate slower since it's trying to keep something approximating precise timing, and wasting cycles on something that literally has no visual effect is detrimental to that.
  • Well, one unintended side effect of this was that when you make certain interface changes -- zooming in and out, panning the screen, selecting units, drawing the selection box, etc -- it would not realize that it needed to go ahead and do a redraw when those things changed. So that made those things feel very choppy and simspeed-bound. Eep!
  • Now the game looks at all those specific cases and says "consider the display in need of a redraw if one of these things has happened, even if the simulation has not yet had another step."
  • If you find some case that was missed where there is still lag on some input piece when you're on the slower simulation speeds, then please do let us know. We marked all the ones that we found, which should be all the major ones, at least.
  • Thanks to Zair for reporting.

Official 8.009

(Released September 10th, 2014)

• Put in some prevention code to prevent the screen from completely stopping rendering if for some reason it thinks the last frame just isn't rendering.

• Adjusted the recently-rewritten game timing code to now use Time.deltaTime instead of a stopwatch.
  • A stopwatch is still used to detect runaway slow frames -- that's a big part of why it was used before -- but now the central timing is not based off of the stopwatch. The freezes in the non-menu graphics that people were seeing since the new timing was introduced was likely resulting from this.

• Put in yet another fix to a potential cause of the recent sometimes-main-graphics-freeze-but-menus-still-work issue. Basically there was a while loop that perhaps was coming back as false the first time on some occasions, and now it is a do-while loop to make sure that can never ever happen and it always renders at least one frame in these cases.

Official 8.008

(Released September 9th, 2014)

• 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 20MB.

• Made several key simplifications to require less matrix math on the CPU attached to each draw call.

• The game is now compressing textures in memory much better, which leads to a much smaller game RAM usage. It also leads to faster rendering and lowered video-ram usage. The downside is that the image loading process is a bit slower, because it has to go through a one-time image compression process each time it loads an image. The tradeoff is really substantial in terms of RAM savings and GPU performance, however.

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: AI War:Current Post-7.000 Beta