39,327
edits
m (categories and general cleanup) |
m (Mass update links) |
||
Line 12:
* '''16 bits''' can hold a value as high as 65,535. The [[Super Nintendo Entertainment System]] and [[Sega Genesis]] were 16-bit, as were PCs in the mid 1980s, and a few Japanese gaming computers.
* '''32 bits''' can hold a value as high as 4,294,967,295. The [[Sega Saturn]] and [[Dreamcast]], Sony [[Play Station]], Microsoft [[X Box]] and the Nintendo [[Game Cube]] and [[Wii]] are all 32-bit. So are desktop PCs from 1987 to 2007.
* '''64 bits''' can hold a value as high as 18.4 quintillion (or 1.84×10<sup>19</sup>). The [[
* '''128 bits''' can hold a value as high as 340.2 undecillion (or 3.4×10<sup>38</sup>). Computers usually do not have 128-bit general-purpose registers, but the [[
Note that in addition to the above, most recent processors have additional "vector" processors for dealing with multiple calculations in parallel; these have so far been up to 256 bits wide. Also floating point calculations are often done at different sizes.
Line 38:
*** It might backfire on modern processors as while multiplication takes a few cycles but the shifts would introduce data hazards and cause stall cycles. Hopefully the processor will implement out-of-order execution.
* Errors. Many function calls use -1 as an error code. If this value is not checked for, and then gets stored into an unsigned variable, it becomes the highest number the variable can hold (due to how "two's complement" signing works.)
* [[Divide
** As of [[Divide
* For alignment purposes. For most purposes, data in memory has to be aligned to its size. For example, a one-byte (8-bit) value can be stored at any address, but a four-byte value must be stored on some platforms at an address that is a multiple of four. When game programmers used to map out memory used by the game, they would keep in mind this alignment requirement. Say a given block of memory is used to store player inventory, and each item in the inventory is a single byte. It makes sense to give the player a power of two items, since any value stored after it will have the same alignment as the start of the block.
* Reading in data for something it's not meant for. A very frequent source of [[Good Bad Bugs]] in olden times was when data was loaded as something that it actually wasn't. For example, suppose something goes iffy in the code, and the game starts reading map data as if it were attack data. But map data is something very different from attack data. Perhaps the game uses the value FFFF (65535 in hexadecimal) to indicate the end of the map. This is a common value to use for this purpose (called a "terminal value" in programming jargon) because it's the ''last'' value two bytes can store, so it's easy to remember. (One FF by itself might be used for, say, the end of a room, or the end of a script that runs on that map.) If the code starts reading in a map as attack data, however, these values may end up anywhere. If FFFF were read in as the damage of an attack, for example, the attack would deal 65535 damage (possibly capped to 9999, of course).
|