[[DescribeTopicHere Describe]] HowVideoGameSpecsWork [[DescribeTopicHere here]], but in ''layman's terms'', please (like the ''Guinness World Records'', we're just here to head off [[InternetBackdraft hunting bets]], not prep you for IT 101.) This isn't TheOtherWiki.

Ah, video game specs. The fanboys like to use them as the ultimate indisputable weapon in their {{Flame War}}s. But they don't really know what they mean, for they barely look past one aspect of them.

Take the old bit size (8-bit, 16-bit, 32-bit, 64-bit, etc.). Most of us know that bit size isn't a real measurement of a system's power, but few of us even know why. It's actually ''word'' size; the measurement of how large a chunk of information can be handled by the processor at once.[[note]]This can mean the size of the registers, the innermost memory inside the CPU. Or it can refer to the width of the CPU's "data bus", the wires that transfer data between the CPU and main memory. A 64-bit data bus, for example, means that there are 64 data wires running from the CPU to the main memory board, each of which can carry one bit at a time, so the CPU can "read" or "write" that much data in a single system-clock tick.[[/note]] In theory, larger word size should mean faster processing, but it's not that simple--especially since computer manufacturers have figured out that people are using "word size" as a quick-and-dirty proxy for "fastness" (or worse, "realistic graphics"[[note]]a misconception that was made popular due to an offhand remark in the WesternAnimation/{{Reboot}} episode "Enzo the Smart", as well as several other video hardware manufacturers of the time. While it's true that the number of bits dictate how many colors can be displayed on screen at a given time and the maximum resolution of the screen, the only hardware affected by this is the ''GPU'' and even then, the amount of memory the GPU has or is capable of addressing also plays a role in determining these capabilities[[/note]]), and started playing arcane tricks designed to boost word size at the possible expense of actual improvements in the rest of the architecture (this marketing scheme began very early on, in fact; the NeoGeo was advertised as a "24-bit" system, and the UsefulNotes/{{Nintendo 64}}, while indeed capable of 64-bit calculations, ran with a 32-bit capacity most of the time for a lot of good reasons). Some people have gone so far as to call the [[UsefulNotes/SegaDreamcast Dreamcast]], UsefulNotes/PlayStation2, and [[UsefulNotes/NintendoGameCube GameCube]] generation "128-bit" thanks to this misinformation to this very day--out of these, only the PS2 was capable of 128-bit ''anything'' natively, and even then, it's not for general-purpose processing--and on top of that, its main processor is a 64-bit MIPS R5900 [[note]]Both the CPU and Vector Units have 128-bit Single-Instruction, Multiple Data (SIMD) instructions. However, these don't work on a single 128-bit value, but either 4 32-bit values, 8 16-bit values, or 16 8-bit values.[[/note]] although Sony deliberately mismarketed it as being twice as much that due to the "more bits equals better graphics" belief still lingering, and to compete with the equally misnumbered UsefulNotes/SegaDreamcast[[note]]Which actually had a 32 bit CPU, with a 128 bit vector unit, which Sega got marketing mileage out of by using this fact to advertise the whole system as being 128 bit[[/note]]. Even Nintendo got on the bandwagon, the tech demo for the [=GameCube=] was called ''[[http://en.wikipedia.org/wiki/Super_Mario_128 Super Mario 128]]'', implying that the console has a 128-bit word size CPU[[note]]It's actually a 32-bit [=PowerPC=]-based CPU with a double-precision 64-bit FPU which many took to mean that the CPU was 128-bit since 2x64=128, although the real reason the demo is named as such is because it spawns [[ExactlyWhatItSaysOnTheTin 128 individual 3D Marios on screen]])[[/note]]. Occasionally, the bit misconception still pops up today, such as some mistaking the {{Xbox 360}} as having a 360-Bit CPU (it actually uses 64-Bit hardware).

Which is not to say that the leap in bits was entirely pointless: An 8 bit word can only hold a value of up to 255, while a 16 bit word can hold a value of up to 65,536 (which acts as a {{cap}} on anything the programmer wants to do: want a map with more than 256x256 squares? You're going to need to go to 16 bits for that, and in the NES, for example, that's gonna require more space than the CPU has easy access to). There is a point of diminishing returns, though: a 32 bit word holds a value of up to 4,294,967,296 (4 billion), which is more than enough for most purposes (and most 32 bit CPU instruction sets support 64 bit variables), so the jump to 64 bit words was usually driven more by bus limitations and memory growing larger than 4 gigabytes than by programmer needs.

However, what is done with the processor can have a significant difference in performance. An instructor in a class on mainframe programming gave an example. To clear a line of eighty 8-bit characters to blanks, such as for printing, the common practice was to put a space in the first character, then move the entire field from character 1 to character 2 for a length of 1 less than the size of the field. This moves character 1 to character 2, then to 3, and so on for 80 characters. What he pointed out was that even though arithmetic using floating point is much slower than operations of moving characters, it would have been faster to put, say, 4 blanks in a floating point register and store that 20 times than moving one character 80 times.[[note]]Now, it might be thought that because single-precision floating point numbers are 32-bit; on a 32-bit system, copying via either a move of 1 unit of information 80 times somewhere else will take the same time as 4 units stored 20 times, except that the store is 20 actions; the move a to a+1 single byte action is 80 actions, since the machine moves data 32 bits at a time even if only 8 bits are moved.[[/note]]

Or take processor speed. The SuperNintendo's 65816 CPU had a UsefulNotes/ClockSpeed of 3.58 megahertz. The UsefulNotes/SegaGenesis's 68000 CPU had a clock speed of 7.67, just over twice the Super NES. So that meant that Super NES games should only run half as fast, right? Sega did have this advertising campaign of "blast processing", and some early Super NES games did have slowdown. Well when Capcom ported ''VideoGame/StreetFighterII Turbo'' to the Super NES, it had a secret mode that was even faster than the arcade speed, but no slowdown. The mode turned out to be more gimmick than playable, but it showed that the clock speed was only part of how the processor worked, and proper use of the system was what made the game run so fast (this was also shown when the game was ported to the Genesis, and also had no slowdown in that mode).

In fact, nowadays most hardware engineers have given up on bumping clock speeds and gone on to improve bus speeds, which has less to do with how fast the computer "thinks" than with how fast it "talks". Taking the same example of fourth-generation consoles, the 65816 could "talk" at full speed, while the 68000 could "talk" only once every four cycles, resulting in an actual speed of 1.92 [=MHz=] for the Genesis. But the 68000 could push 16 bits every bus cycle, twice that of a 65816, making them not too different in overall bus speed (3.58 MB/s vs. 3.84 MB/s).

So if you really want to know what specs actually mean for video game systems (which covers computers, set-tops, and handhelds), just take a look at the following pages.

See VideoGameSystems to see how these specs work for them.
!!!Nitty and gritty:
* UsefulNotes/AnalogVsDigital
* UsefulNotes/BinaryBitsAndBytes
** UsefulNotes/PowersOfTwoMinusOne
** UsefulNotes/BinaryLogic
** UsefulNotes/BinaryPrefix
* UsefulNotes/ClockSpeed

* UsefulNotes/CentralProcessingUnit
** UsefulNotes/FlynnsTaxonomy
** UsefulNotes/MultiCoreProcessor
* UsefulNotes/DisplayTechnology
* UsefulNotes/GraphicsProcessingUnit
** UsefulNotes/GraphicsRendering
** UsefulNotes/VideoRAM
* UsefulNotes/RandomAccessMemory
** MemoryHierarchy
* UsefulNotes/ReadOnlyMemory
* UsefulNotes/MassStorage
** UsefulNotes/MagneticDisk
** UsefulNotes/OpticalDisc
*** UsefulNotes/CompactDisc
*** UsefulNotes/{{DVD}}
*** UsefulNotes/BluRay
** UsefulNotes/{{Cartridge}}
*** UsefulNotes/FlashMemory (including Solid State Drives)

* GameEngine
** MiddleWare
** PhysicsEngine
* OperatingSystem
** UsefulNotes/DOSBox
*** UsefulNotes/{{DOS4GW}}
** UsefulNotes/MacOS
** UsefulNotes/MicrosoftWindows
** UsefulNotes/{{UNIX}}
** UsefulNotes/ApplicationProgrammingInterface
*** UsefulNotes/CursesAPI
* ProceduralGeneration
* UsefulNotes/ProgrammingLanguage
** UsefulNotes/{{Python}}
** ScriptingLanguage
*** UsefulNotes/{{Lua}}
* UsefulNotes/RandomNumberGenerator
* UsefulNotes/SoftwarePorting

!!!Related topics
* UsefulNotes/BitmapsSpritesAndTextures
** PixelVsTexel
** TextureCompression
* UsefulNotes/DigitalDistribution
* UsefulNotes/GamingAudio
** {{MIDI}}
** UsefulNotes/{{MOD}}
** {{MP3}}
** UsefulNotes/WavAudio
* PolygonalGraphics
* RetroGaming
* VideoGameCulture
* VideogameInterfaceElements
** GeneralGamingGamepads