If Genesis is limited to 80 sprites / 20 sprites - does that mean you can use up to 80 sprites without any troubles since VDP will always handle them? How about other HW then? Is Genesis VDP design the most comfortable way?
taken from Wikipedia:
The Sprite Engine is a hardware implementation of Scanline rendering. For each scanline the appropriate scanlines of the sprites are first copied (the number of texels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the # of sprites on a line), and costly caches (the size of which limit the horizontal width) and as the pixels are sent to the screen, these caches are combined with each other and a special sprite: The background. It is larger than the screen and tiled, were the tile map is cached, but the tile set is not. For every pixel every sprite unit signals it presence onto its line on a bus, so every other unit can notice a collision with it. Some sprite engines can automatically reload their "sprite units" from a display list.
so we know that Genesis is limited to 20 sprites / scanline
is this because of the number of caches in its hardware or what basically is behind this limitation?
how do the lates 2d hw designs work? for example take a look at Cave 3rd generation hw as mention on www.system16.com - it uses a 133 MHz Hitachi CPU combined with some custom chips like Altera Cyclone EP1C12F324C8 FPGA
is the Cave hardware still using sprite hw list or does the programmer have to program the sprites in a different way???
I think the Genesis approach is the best except from that scanline limitation since you do not have to deal with the situation if the system can handle all the sprites you want to display, you simply have 80 free slots / 20 for scanlines and it is up to you to fill them all, but how about other hardware like that Cave board, the programmer could easily get stuck into framerate drops if it doesnt use predefined number of sprites???
taken from Wikipedia:
The Sprite Engine is a hardware implementation of Scanline rendering. For each scanline the appropriate scanlines of the sprites are first copied (the number of texels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the # of sprites on a line), and costly caches (the size of which limit the horizontal width) and as the pixels are sent to the screen, these caches are combined with each other and a special sprite: The background. It is larger than the screen and tiled, were the tile map is cached, but the tile set is not. For every pixel every sprite unit signals it presence onto its line on a bus, so every other unit can notice a collision with it. Some sprite engines can automatically reload their "sprite units" from a display list.
so we know that Genesis is limited to 20 sprites / scanline
is this because of the number of caches in its hardware or what basically is behind this limitation?
how do the lates 2d hw designs work? for example take a look at Cave 3rd generation hw as mention on www.system16.com - it uses a 133 MHz Hitachi CPU combined with some custom chips like Altera Cyclone EP1C12F324C8 FPGA
is the Cave hardware still using sprite hw list or does the programmer have to program the sprites in a different way???
I think the Genesis approach is the best except from that scanline limitation since you do not have to deal with the situation if the system can handle all the sprites you want to display, you simply have 80 free slots / 20 for scanlines and it is up to you to fill them all, but how about other hardware like that Cave board, the programmer could easily get stuck into framerate drops if it doesnt use predefined number of sprites???
