Difference between revisions of "AI War:Current Post-8.000 Beta"

From Arcen Wiki
Jump to navigation Jump to search
Line 60: Line 60:
 
* 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).
 
* 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.
 
** 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-8.000_Beta

Revision as of 14:34, 5 September 2014

Prerelease 8.005

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

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