Atomic I/O letters column #136Originally published 2012, in Atomic: Maximum Power Computing
Reprinted here December 20, 2012 Last modified 17-Jan-2013.
As a person with a friend that is very much into the "Indie" side of gaming, I've managed to see some very interesting things from time to time. Most recently, this same friend of mine has brought one of the more recent, more interesting titles on Steam to my attention, a game by the name of "Evochron Mercenary". Overall, it's a decent "Space Sim" game. The same old formula is there: trade commodities for money, save money for bigger ships, trade MORE commodities, Save MORE money, get Giant-Ship-O-Death™, kill people for money, etc.
The most interesting aspect of it is the sheer scale of the play-field. There are multiple star systems to explore, and they all FEEL like entire star systems. Asteroid clusters shift about, ships move in and out of systems, planets can be landed on with transitioning from space to planet surface, travel distances are frustratingly large, and it has all of it without even a loading screen to be found.
So, I see this game and I can't help but think that this marvel of gaming just HAS to be absolutely enormous to install! What with all the planets and systems, the shiny graphics on display, it must be well into the multiples of gigabytes!
So, I purchase it off Steam, start up the install, and it tells me that this game requires a whopping chunk of my HD: 257 Mb.
My mind has been blown before, but this takes the cake. How is it possible for something this large to take up less than half the install space for Half-Life ONE?
Elite. Eight galaxies, 2048 planets. And even this Amiga version was less than half a megabyte.
Welcome to the world of "procedural generation"!
What's happening here is, the game code generates a long string of pseudo-random numbers, and uses those numbers to determine star locations and characteristics, planet locations and characteristics, et cetera. To simplify, wherever you go, the game looks at the portion of its long and deterministically repeatable number string that corresponds to where you are, and uses those numbers to create the nearby environment for you.
Procedural generation has a very long history with space-sim games. The grand-daddy of all 3D space-sims is Elite, first released in 1984, when 128 kilobytes was a lot of memory.
(In 1984, it was also exciting and futuristic to get home-computer games on floppy disk, instead of the incredibly slow-loading cassette tapes that many people with less money were still using.)
Elite had 3D graphics (wireframe on most computers, filled on later versions of the game for higher-powered machines like the Amiga and Atari ST), and eight galaxies, each containing 256 planets. Each planet had its own appearance and colourfully-described inhabitants, and local prices for various commodities.
Elite came on cassette and floppy disk for various platforms. The biggest versions took up a few hundred kilobytes; the original versions were down around the 20-kilobyte mark.
(You can still get Elite disk images for use with emulators, or with actual old computers, today.)
Procedural generation survives today in many games. Space-sims like the Evochron games, Minecraft, Dwarf Fortress, umpteen "roguelikes" and their real-time descendents like Diablo, and the list goes on.
Many games today have a mutated version of the idea - terrain or dungeons that were procedurally generated as part of the development process, then refined by humans, and stored conventionally as the large amount of data you expected to see in the Evochron installer. (This explains why you can find the occasional levitating shrub or see-through boulder in Bethesda games from Oblivion to Skyrim, and why the roads do strange things in some parts of Fuel's vast map. It's possible that a human level designer directly caused the geometry to be wrong in these spots, but it's more likely that some algorithm plunked the features down incorrectly, and the humans meant to fix such problems missed a few.
Even Elite had human curation of its algorithmically-generated universe, to keep rude words out of the planet names!
I've always wondered, why does the sound loop when software, usually a game, crashes?
It doesn't always happen, but it often does - the picture freezes, and whatever audio was playing is now about a half-second loop. I sort of feel like the image should loop too.
Behold the circular, or ring, buffer.
Buffers are pieces of memory that hold data of some sort between the time when some software has created it (or read it from somewhere else), and the time when it's meant to be delivered to the screen, speakers, printer or what-have-you.
A simple buffer, a basic video buffer for instance, has data written into it, and then when that's finished the data can be read back out. Things get more complex if reading and writing are both happening at the same time to the same buffer; the video card displaying the contents of a buffer as they change is what causes "tearing" of the image on the screen. Tearing goes away when vertical sync is on, because then the buffer's back to the simpler mode of operation.
A circular buffer is a simple linear fixed-sized buffer, but with the end connected to the beginning, hence the name. The data source writes data to addresses zero through whatever-the-end-address-is, then continues writing at zero again. The data receiver reads from the buffer the same way, round and round. But if the data source stops for whatever reason - a crash, network congestion, whatever - and the data receiver keeps on reading, the receiver will now go round and round the unchanging buffer, reading the same data over and over, forever. Hence, looping sound.
Circular buffers can be used for video, too; they're well suited to use with streaming data of various kinds. So you can indeed get a Max Headroom scratch mix of both video and audio if the source of a video-and-audio stream stops streaming, but the receiver decides to keep on trucking, rather than just saying "buffering...". Game video doesn't use circular buffers, though, so if the writing side fails but the read-and-display side keeps going, you usually just get a still image to go with your looping sound.
I just came across a slightly odd interaction - or at least it seemed odd to me. Maybe it's normal?
Basically, a PC wouldn't boot up, or come out of hybrid sleep, when a specific powered USB hub was attached. Upon investigation, it appeared that the USB hub was providing enough power back to the motherboard that the motherboard power light was still lit, even when the PC was completely disconnected from the mains. I replicated this problem on a second PC, which had similar symptoms (both running Asus motherboards, but different models).
If I unpower the USB hub by pulling the wall wart, everything works fine (even the hub and the devices plugged into it). Should USB hubs really be providing power out of their type B (upstream) connectors, or is this a design fault? If a fault, is it common? This was a cheap-ish (about £15), no-name hub, but with a fairly comprehensive wall of positive reviews on Amazon, and it works fine unpowered.
There are meant to be two sources of five-volt power in a modern PC.
The first one is the main +5V rail from the power supply, which may be split into separate rails each feeding its own collection of power plugs for drives and so on, or which may be just one rail for every red wire coming out of the PSU. This 5V rail is not meant to be energised when the PSU is off, but still plugged in. (And it obviously won't be energised if the PSU isn't plugged in, or if the PSU has a hardware power switch that's turned off.)
The second 5V source is the "5VSB", five-volt standby, rail. This has a much lower current rating than the main 5V rail or rails, and it is supposed to be energised when the computer is off but the PSU is still plugged in (to a wall socket that's turned on, of course).
The basic purpose of the 5VSB power is to energise the teeny bit of motherboard that monitors whether the two pins of the power-switch connector on the mobo have been connected together, by a case's power button, or by your car key, if you're fiddling with a naked motherboard on the kitchen table.
5VSB also energises various other components, including USB, keyboard and mouse ports. Otherwise, you couldn't wake a computer from sleep mode with keyboard input, and Wake-On-LAN would also be impossible.
All of these ports - PS/2 keyboard and mouse, the ancient AT keyboard connector, and USB - have a five-volt power rail. So it's easy to run them all from 5VSB; you can just directly connect all of these power rails to 5VSB on the mobo.
So what the computer you're looking at has, is a USB 5V rail that's connected to the 5VSB rail, with no circuitry to prevent the one powering the other. The hub you've got completes the picture. Powered USB hubs are meant to be able to run in unpowered-hub mode from a computer, or from their own plugpack, but I'm pretty sure the spec says they're not meant to pass five volts back upstream when both a computer and the plugpack are connected. But this one clearly does, as I think do a lot of other cheap hubs.
So 5V comes into the computer via the hub, and lights the standby LED on the mobo.
(Different motherboards have different built-in annunciator gizmoes. A single LED to indicate 5VSB is energised is common, and there may be an LED indicating "full" power as well.)
I'm not sure whether the ATX specifications forbids this, but the USB and ATX specs are widely disobeyed. (The current ATX spec mandates splitting the 12V rail into at least two independent ones, but not every PSU does that. The USB spec forbids, among other things, extension cables.)
As a practical matter, this ignoring of the spec - and more severe versions; on some mobos the CPU fan will keep spinning if the computer's off but there's a cheap powered USB hub connected! - isn't very important, and probably isn't dangerous either. A malfunctioning USB hub or peripheral that shorts its 5V supply to ground could in theory pop a fuse on a motherboard that was connected directly to it, but this is unlikely.
If the mobo's got a load of stuff that'll run from incoming USB power if possible then it could be a bad situation, like starting the engine of a manual-transmission car while it's in gear and forcing the little starter motor to move the whole car. This could overload the hub's power supply, and failure of that power supply or some other glitch could damage the motherboard's USB controller, especially if there's a little spark when you plug in the hub or its plugpack. But, again, I don't think it's a major risk.
In your case, somehow this back-fed power from the USB hub is preventing the computer's PSU from going into full-on mode. If I had to guess, I'd say it was doing this because the powered hub is somewhere south of the mandated 5.0 volts, especially after resistance losses from mobo traces, cables and connectors, and the extra load of whatever motherboard bits the USB hub is accidentally powering. If this manages to hold the 5VSB rail far enough below five volts, the PSU could think there's something wrong with itself and refuse to go into full-power mode. Or the USB voltage itself could be below spec, but connected to and also hauling down the voltage on the "Power Good" pin on the motherboard power connector, which is meant to be fed 5V by the power supply when it's satisfied that it's starting up properly. This'd make the motherboard think there's something wrong, and again you get no turn-on.
(Just to make everything even more confusing, a possible failure mode for both motherboards and PSUs is loss of calibration of their voltage sensors - so everything can be A-OK and all 5V rails can be 5.00 volts precisely, but because a sensor thinks that's 4.2 volts or 6.5 or something, the computer doesn't work.)
A way more expensive brand-name powered hub might cure this problem, but there's no guarantee a branded peripheral will actually stick to the spec any better than a $3 eBay special. You could also probably solve the problem by cutting the (probably red) +5V wire in the cable going from the computer to the hub, which would of course make the hub not work at all when its plugpack isn't connected. Or, more ingeniously, you could tap a non-standby-5V wire from the PSU and power the hub from that, instead of from its plugpack.
Or, of course, you could just unplug the hub when you want to do the things it's stopping you from doing.
This is all a bit of a long walk for that to be my final advice, but I spent this much time thinking about it, so I feel I must make you suffer as well.