Hot answers tagged

30

It's rather simple. Neither the multiple sprite mode, nor any secret trick is used. The TIA doesn't have any directly-accessible register for storing a sprite position ahead of time. Sprites are drawn when they are enabled on the actual line (Y coordinate) and whenever RESPx is triggered (X coordinate). To display the 6 aliens, RESPx gets triggered 6 ...


27

The Picture Processing Unit (PPU) in the NES can only draw 64 sprites per frame and 8 sprites per horizontal line (scanline). If the game tries to draw more than that, some of them will be invisible. It could ruin the game if enemies became invisible because there were too many of them, so the developers programmed the games to change the order of sprites ...


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 ...


19

The NES did not use an extra bit for sprite positions. A sprite's X-position was the position of its left edge, which means that sprites cannot be placed partially off the left side of the screen: However, the NES did actually provide the feature you're suggesting, in a way: bits 1 and 2 of the PPUMASK register can be used to keep the leftmost 8 pixels of ...


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. ...


16

Yes, there is a limitation. Due to incomplete address decoding, the VIC sees the bitmap font ROM between $1000 and $1FFF and $9000-$9FFF. Here is the end of the font ROM (the C64/chargen file in VICE) 0FC0: 00 00 00 FF │ FF FF FF FF │ FF FF FF FF │ FF 00 00 00 0FD0: FE FC F9 93 │ 87 8F 9F FF │ FF FF FF FF │ 0F 0F 0F 0F 0FE0: F0 F0 F0 F0 │ FF FF FF FF │ E7 ...


16

It definitely was possible, as demonstrated by Parasol Stars, which "only uses a single sprite to create the score panel at the top of the screen!" That article has a more detailed discussion of exactly that title but it sounds to be as simple as racing the beam, adjusting the sprite position continually to push it backwards beyond the location currently ...


15

Here are some extraction from an article: Missing Cycles by Pasi 'Albert' Ojala. In short, VIC needs to fetch the sprite data from memory. For each sprite it needs to fetch 3 bytes (one line of sprite shape) for each scanline. If there are sprites on the screen, the VIC needs even more cycles to fetch all of the graphics data. Scan lines are time ...


11

You need an assembler to do this trick. This is an interrupt timing trick with some behind-the-scenes coding. The frame allows sprites to sneak towards the edge without the device stopping them. They are connected to scan lines displayed by the device. Of course, for top and bottom, it is easier to make this happen as you only need to interrupt once and only ...


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 ...


8

There are a fixed amount of memory cycles for the PPU to read the sprite data on each scanline; once those are exhausted, no more sprite data will be fetched. As NobodyNada said, programmers would rotate the order in the list to make sure that the user would see all the sprites. The technique was also used on other systems that didn't work the same way, ...


8

Actually, the most probable limit was the amount of the on-chip RAM to hold sprites. To my knowledge, sprite circuitry, including sprite on-chip RAM (or just flip-flops) were responsible for the majority of silicon space in VIC-II chip. In all the architectures @rwallace listed none were able to buffer even the single line before actually outputting it to ...


7

On most of those early systems, the scan line data for the sprites was fetched from main memory during the horizontal blanking interval prior to each display scan line, which is a fixed amount of time in NTSC or PAL video timing. So the number (and width) of sprites was limited by memory bandwidth (which was limited by memory data bus width and DRAM cycle ...


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 ...


6

After looking at the posted videos, I think that OAM layout may be the cause of the Zelda right-to-left glitch, but not the Metroid top-to-bottom glitch. In Zelda if you frame step you can see at least one frame where the left half of Link is on the right hand side of the screen and his right half is on the left. The OAM accepts only 8 bits to specify ...


6

It's usually not as centralised as you describe. If a system supports a background and, say, four sprites then there'll be one part of the video chip that generates the background. That's always running. Then there'll be four distinct shift registers, each responsible for a single sprite. They're also always running. The five outputs go simultaneously to a ...


6

Expanding on my comment above: For a while I pursued efficient drawing of filled polygon graphics on 8-bit systems through differencing. My intention was that I would exit the 3d calculations with what amounts to a span buffer: for each line an ordered list of only the x positions at which a change of colour occurs, and the colour that is changed to. The ...


5

I asked in Limiting factor on sprite sizes what the limiting resource is, and there were some good explanations about how memory bandwidth and the size of on-chip memory to store sprite data are both issues. And these issues stay the same. In fact, your concept suffers even more from limited bandwidth. Storing character data (like on the C64) in a buffer ...


5

Most sprite systems allow for sprites to overlap, generally with either the first or last sprite having priority over the others. If software allocates sprite resources in the required order of priority, this will avoid the need to have hardware manage priority in any other way. While a display system that requires sprites to be listed in left-to-right ...


5

So that's machines spanning six years of time, multiple iterations of Moore's law, one or two orders of magnitude of available transistor count, but the sprite limits are strangely constant, which is surprising if transistor count is the limiting resource. Or maybe 8 sprites per scan line is something that chip designers considered sufficient for all games ...


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 ...


4

Memory bandwidth was usually the limiting factor. The video generation hardware has to fetch data for the background image and all sprites from memory. On most 8/16 bit systems this was done "on-the-fly", as the screen image was being generated. As such memory speed placed an absolute limit on the amount of data that could be fetched in the time available, ...


4

256 is the maximum number of pixels per row, but most games used fewer. Using fewer pixels allowed for partially off-screen sprites with only 8 bits of position information. Most hardware of that era allowed some flexibility with screen resolutions. While the timing for the display (PAL or NTSC) was fairly well nailed down, the programmer could choose to ...


3

the stuff you are describing has nothing to do with x resolution selection. In the 8 bit era CPUs didn't have mul , div instructions so computing *,/ was really expensive. That is why the x resolution is usually power of 2. That allows to compute pixel address from x,y coordinates using just basic ALU operations. For example on 256 pixels per line and 1 ...


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 ...


2

But for some reason, you could only work with 28 sprites instead of the maximum of 32. So, what was the reason behind this? One reason may have been space. Of the 16 KiB RAM, build-in TI-BASIC uses 2 KiB for screen handling (including 80 bytes line buffer) (*1), leaving a bit less than 12 KiB for programm and data. For Extended BASIC it is essential to be ...


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 ...


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