“Toggle-plexing” Sprites on the Commodore 64 (2019) | Hacker News Reader

“Toggle-plexing” Sprites on the Commodore 64 (2019)

kodiak64.com

61 pointsingve22 comments

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.

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.

I'm not sure how you figure? Have you ever seen slo-mo of a CRT television set? The pixel would be lit by the beam instantly and fade back to black before the scan line is completed; the only reason we see a rectangular image on a CRT instead of a scanning dot is persistence of vision.

Wikipedia[0] confirms that the response time for a CRT was 0.01ms on the top end and could be less than 1 µs; typical LCD panels have response times between 1-8ms.

I could definitely perceive a 30-Hz flicker as such on an ordinary CRT television. You may be confusing that with the fact that thin 1-pixel lines of alternating colors tended to smear into blended colors on a CRT in games like Sonic the Hedgehog because the chroma channel of a composite signal was of lower resolution than the video hardware's output.

[0] https://en.wikipedia.org/wiki/Comparison_of_CRT,_LCD,_Plasma...

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.

No flickering is an overstatement, but yes, the signal is 256x240 lines and alternating frames draw on alternating vertical lines of the 480 "visible" scanlines of a CRT (+/- minus overscan). The "no flickering" has more to do with the mental illusion of persistence of vision and the quality of the glowing phosphor on the glass excited by the beam on a particular CRT.

Yes, any crt has flickering, but that is not relevant nor related to this approach. This approach ensures a sprite is drawn in the multiple places of a display every time the crt updates the display.

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.

Pac-Man was terrible mess.

Interestingly it was the best selling Atari 2600 game of all time. https://www.youtube.com/watch?v=HL2p2ANFlQ4

> 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

No.. it speaks of setting sprite 0 to a new position on the screen midway-through a field. So you can use sprite 0 for a plane at the top and scenery in the middle and for text at the bottom.

> which will flicker.

No flickering involved, except for the "afterburner" variant of this.

It starts out talking about multiplexing sprites by changing their position mid-screen, yes. Then it goes on to discuss also “toggle-plexing” sprites by using them for two different images and objects on the same raster line on alternating frames, with a diagrammatic example of a laser and an afterburner.

Commenter said:

> > is setting one sprite to two different positions on alternating frames to provide the illusion of two separate objects, which will flicker.

Which is not something described here.

Two things are described:

* Multiplexing sprites by changing their position mid-screen (no flicker).

* Animating sprites by toggling between sprite variants on alternate frames (and -not- changing their position). (Flicker only to the extent -desired-).

And I said:

> No flickering involved, except for the "afterburner" variant of this.

It was a common technique on the Atari VCS (2600), generally called interlacing. On the VCS it may be a bit more straight forward, as you have to write the entire kernel (the code for rendering a video frame) anyway, hence assigning alternating pointers for sprites in between frames doesn't result in much of an overhead or specialized code.

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.

https://csdb.dk/release/?id=48577

You can actually get 9 sprites on a raster line, but only in a very specific configuration.

This absolutely blew my nerd mind when I saw it.

The famous English saying.... "Death, Taxes and 8 sprites per raster" no longer holds true.

You can get 9 sprites on one raster line but only 7 sprites on the next raster line, so you essentially alternate a sprite. If you're only using alternating lines, you can already give the appearance of 16 sprites, so it doesn't seem to be a win, overall.

Not only could the ZX Spectrum in fact produce 16 colours, but two of them were even recognisable as red.

Are you making fun of the C64's embarrassing lack of a proper red (or any bright colour for that matter) ?

Fair point, but also quite bold for a ZX Spectrum fan to say something about graphics ;)

Of the three main 8-bit machines, the Amstrad CPC wins that round hands down : https://imgur.com/a/D7Ocd

True but irrelevant. The article compares the colour palettes of C64 and Spectrum.

15, I think. "Dark black" and "light black" were the same (absence of) colour.

The C64: 16 colours, all brown.

There was a chess program showcased in 64-er magazine, where the chess pieces (32 of them) were sprites. The technique was used by a lot of the demos at the time that were put in front of hacked games. I remember The tricky part being that your interrupt handler needed a constant amount of cycles otherwise you would get artifacts (flickering). You could also get sprites in the upper lower borders.

brings back memories.

Explains Fort Apocalypse.

Reply on news.ycombinator.com