[HN Gopher] "Toggle-plexing" Sprites on the Commodore 64 ___________________________________________________________________ "Toggle-plexing" Sprites on the Commodore 64 Author : ingve Score : 27 points Date : 2020-05-10 07:39 UTC (15 hours ago) (HTM) web link (kodiak64.com) (TXT) w3m dump (kodiak64.com) | tom_ wrote: | Not only could the ZX Spectrum in fact produce 16 colours, but | two of them were even recognisable as red. | tenebrisalietum wrote: | What the article is speaking of is setting one sprite to two | different positions on alternating frames to provide the illusion | of two separate objects, which will flicker. | | I never saw C64 games do that much, but Atari games did. | Adventure being a good example - it effectively only has 2 | "sprites" but flickers when more than 2 are in the frame. An | infamous example would be the Pac-man ghosts, flickering 1 ghost | across 4 frames and looking overall terrible (this is on top of | all the other problems Atari Pac-man had). | | At least a few NES games made extensive use of this. The bullets | in Contra flicker for this reason I believe. I think 1990 Batman | and Return of the Joker also did this for the full screen to | provide an illusion of two mixing backgrounds. | ako wrote: | It was used quite a bit, as far as I can remember, and there | was no flickering: the switching is synchronized with the crt | drawing the screen. | bitwize wrote: | _Super Mario Bros. 2_ did this, "toggle-plexing" entire | objects if enough of them appeared on one scanline to exceed | the NES's 8-sprite-per-scanline limit. The game also slowed | down considerably when this happened. | zeta0134 wrote: | It's worth calling out here that for games that maintain a | steady 30 Hz flicker (very common on NES, and even carried over | to SNES in a few titles) played on an original CRT, the effect | really works quite well, in part due to the slow response time | of the hardware, and also in part due to persistence of vision. | On most real CRT monitors, a properly rendered 30 Hz flicker | (ie, when the game isn't delaying frames due to lag) closely | approximates a 50% alpha blend against the background. This was | often confounded on NES due to the 8-sprites-per-scanline | limit, so your memory of Super Dodgeball's "flickery nightmare" | is accurate. | | A modern flat LCD panel has a _much_ faster response time for | the individual pixels, making the effect seem harsher even when | the software works correctly. Complicating matters, many | emulators of older game systems struggle to push out exactly 60 | Hz (sometimes on purpose, to correctly simulate the original | hardware 's non-60 Hz timings) which can introduce additional | artifacts and make the result look messy. | spiritplumber wrote: | Explains Fort Apocalypse. | tinus_hn wrote: | Note that the VIC chip prepares the sprites at the beginning of | the scanline so you can't horizontally multiplex them. | | The 3 bytes of bitmap data are loaded into a small buffer that is | used up as the sprite is displayed and the buffer isn't reloaded | until the next scanline. | | Even though it's difficult to control, the cpu can manipulate the | VIC during the scanline which is how you can turn off the side | borders. But you can't horizontally multiplex the sprites, that's | a limitation of the VIC chip. ___________________________________________________________________ (page generated 2020-05-10 23:00 UTC)