Hot answers tagged

24

Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at. So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start ...


21

In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations. If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per ...


17

Hardware of this sort has to be able to cope with the worst-case scenario in any given dot-clock cycle. So it has to look at the top layer pixel, determine whether that is transparent, and if so go down to the next layer and repeat. Only when it finds an opaque pixel (which may be the background) can it determine the colour to drive the video output with. ...


8

TL;DR Did historical sprite systems provide unrestricted positioning and overlap It wasn't unlimited and unrestricted, but limited by chip resources or memory bandwidth - or in case of inbetween systems by both. because the designers believed this was very valuable in reducing game development cost? No. Keep in mind, they often crippled machines ...


7

To start with, the citation is a bit misleading. The logic didn't handle 128 sprites and 256 tiles at a time, but its ROM could hold as many different ones. The arcade board does not feature a free programmable sprite engine. There is a fixed sets (128) of direct addressable graphics in 8 KiB of ROM used (128 x 32 x 16). A set of shift registers, feed by ...


5

if the programmer can guarantee that sprites will never overlap each other, and that they will be presented in numerically increasing order on each scan line. A hardware designer's response would be "programmers can't actually guarantee that." And they'd be right. The hardware would have to be designed to do something sensible if those rules were broken. ...


4

Supposing you have a fixed pixel output clock then the bottlenecks are: shifters, since you need to be sure you may need to sample any sprite at the current location; and either: bandwidth to fill those shifters, if you're a TMS descendant (which includes all 2d Sega consoles) and are fetching sprite contents from regular video RAM; or storage for what ...


3

The increased transistor count was used for more colors. The Amiga wants to show off its blitter. PAL has 64 µs period of which 52 µs are used to display something. The rest of the time is used in the computer for different stuff. While the NES allows VRAM writes only in this period, shared memory architectures like C64 and Amiga use this to read the sprite ...


3

The other posts about hardware and gate costs better answer your question, but I'll add this as a counterpoint: A situation where a game programmer decided not to take advantage of hardware collision detection (in this case, for the Atari 8-bit port of Super Pac-Man): On the 400/800 I noticed that people knee-jerked toward using the player-missile ...


1

The Atari 7800 kept almost all information about sprites, including positions, in general-purpose RAM, re-fetching it every scan line. Any time the RAM spent serving up sprite data was time stolen from the CPU, so the amount of data one could display was very dependent upon how much CPU time one wanted to have left. The hardware didn't make decisions about ...


1

One thing that strikes me about all these sprite systems is that they are unrestricted in what can overlap what; you can have all eight sprites overlapping each other, with parts of background showing through, so that each pixel can come from one of nine different sources, and the hardware guarantees to handle this perfectly. The majority of earlier games ...


1

In addition to the above explanations re: sprites actually only having 8 bits of position resolution, the first column blanking option etc, the NES - and others following its same general design - actually had another, simpler, more physical tactic to address the problem: Overscan. The pixel generator clock, derived from the NTSC colourburst crystal by some ...


Only top voted, non community-wiki answers of a minimum length are eligible