A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

New answers tagged

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


2

Intel very likely did this with surplus batches of ROM-equipped microcontrollers - eg if you look closely at the pinout of the 8031 vs 8051/8751, an 8051 wired up like an 8031 WILL behave as an 8031 no matter what is in the ROM/EPROM.


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


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


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


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


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


16

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


0

I am grateful for the different answers, and I will probably try one of them, but for the sake of completeness, the people who sell the chips got back to me, and told me that the STERH 007 programmer, can be used with this chip, and sure enough it is listed as one of the supported chips. The downside is the cost - 250 USD for the basic model, plus the cost ...


Top 50 recent answers are included