[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)