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


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


15

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

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


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


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


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

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