I've noticed is that a lot of the example games have a very obvious flicker when drawing a frame. Is that a limit of the engine?
That's a great question!
The Chip8 virtual machine runs at an arbitrary speed. On the original COSMAC VIP, different instructions took a different amount of time to execute, and execution was generally quite slow. On modern interpreters, including Octo, this is generally abstracted to simply executing some number of instructions per frame. Octo allows you to adjust this speed by using the "Speed" top menu. (30 or less could be considered loosely "realistic" if you want your program to run acceptably on an HP-48 calculator, and the VIP is a little closer to 15.)
While we don't know how fast instructions will execute, we do have one precise timing reference: the "delay" register. If nonzero, the delay register counts down 60 times a second. Thus, if we use delay as a reference, we can make a fast-running interpreter burn off excess time, and allow our games to run at the same apparent speed. There's an example of this delay loop in the Chip8 programming techniques guide, as well as in many examples.
Like the delay register, the Chip8 display is updated 60 times a second- no matter where the program is in execution, or how much progress it has made in updating the display for the main loop. If objects are drawn in time on some frames and too late on other frames, they flicker.
So what do we do about it? Here are a few approaches:
- Increase emulation speed. Faster updates will often outright hide flicker. Some example programs suggest an appropriate speed to be run at; if the interpreter is too slow for a program, games will get sluggish and flicker more.
- Use a delay loop in combination with more speed.
- Minimize how much of the display you're redrawing on each frame. Using "clear" and redrawing everything each time is usually not a good approach for an action game. Use the xor-drawing feature of sprites to erase just the parts of the display you want to change before redrawing them.
- Minimize how long objects are erased for before being redrawn. The longer the gap between erasing and redrawing a sprite, the larger the chance it will look flickery. With specially-prepared sprites, it may be possible to "xor" the next frame of animation on top of the old one without erasing, giving buttery-smooth animation on even slow interpreters.