4 ms·

I haven't read _Racing the Beam_, but the impression I get is that while the 2600 looks crazy, it actually wouldn't be that difficult or insane to write a graph

I haven't read _Racing the Beam_, but the impression I get is that while the 2600 looks crazy, it actually wouldn't be that difficult or insane to write a graphics kernel to generate the screen layout you need. It's just a matter of keeping track of what line you're on and feeding in the correct data. It seems tedious, but that's what computers are for. Once the graphics kernel is written, it just a matter of playing with the data that's fed into it. The real challenge, it seems, it simply that there are so few cycles left over to implement the actual game logic.

Someone 4y ago
> The real challenge, it seems, it simply that there are so few cycles left over to implement the actual game logic. I haven’t programmed the 2600, but I expect that, in about every program for the 2600, running out of time for your game logic is unavoidable, and will make you go back to your universal, (relatively) easy to use kernel and tweak it to make it just a little bit faster for your particular use case. Given that that kernel will be written in tight assembly, I expect that more or less amounts to a rewrite. You’ll use your knowledge f the kernel to write a new one.
- psychphysic 4y ago
  Even on the NES and I'm sure more modern consoles and maybe any game. You often round robin game logic. Here's a fun example Castlevania on the NES by timing your movement precisely you can make it skip certain blocks being loaded. Making it leave a stair case or even a door. Works because alternate even and odd frames responsible for loading different y coords for level data in blocks. https://m.youtube.com/watch?v=Dw7NkOzp8tE https://m.youtube.com/watch?v=Dw7NkOzp8tE It might seem like there's no point now..but even in a 120fps game do you need absolutely everything to update at 120hz?
  - djmips 4y ago
    Believe it or not we still amortize work and have game architecture where the sim updates at a much lower frequency than the game presentation.
- toast0 4y ago
  You don't really have that many spare cycles per line (unless you have double height pixels), and since there's not many registers either, you really can't get much done with the spare cycles, either. You really do need to get almost all your game loop to fit into vblank, and spend most of the screen on time driving the graphics. NES and other systems with fancier graphics systems kind of inverted the script; on those you run the game loop during screen on, and mostly transfer data to the graphics unit during vblank.
kgwxd 4y ago
Many new games are made with an arm processor built in the cart[0]. I'm not super familiar with how it works but they do some really fancy graphics kernels. Still limited by how the graphic/color registers work and not many cycles to change them all at the right time. [0] https://forums.atariage.com/topic/330778-part-1-cdfj-overview/ https://forums.atariage.com/topic/330778-part-1-cdfj-overvie...
- djmips 4y ago
  Despite the arm processor in the cart it barely helps with the kernel and game code in most games. Typically they are older not so powerful Cortex M0 and it is largely tied up emulating the cartridge hardware. It can give modest gains when doing the kernel but most of the fancy graphic kernels are designed as they always have been - with a lot of deep human thought.
jandrese 4y ago
The other real challenge is that you have to build your entire game using just 128 bytes of memory. Not kilobytes, bytes. You don't have the luxury of having a single scanline of the screen at memory at once. There is no caching of anything. You have just enough memory for a handful of current state variables and that's it. Luckily your program is running out of ROM so you don't have to load it before you execute, but even with that it's an incredibly tight fit.
ant6n 4y ago
Here’s a detailed video by retro game mechanics that shows how the logo graphics of the infamous E.T. game is rendered: https://youtu.be/sJFnWZH5FXc https://youtu.be/sJFnWZH5FXc It seems incredible, very difficult. And remember, back then cartridges only had 8KB of memory. This means even more hacks are required, if your game needs more than a few levels. Theres a recurring hn post how Pitfall encoded levels in a single byte (bitfield), then used some sort of sequence generator to allow going back and forth among the 255 levels.
djmips 4y ago
Easier said than done. Implementing the game logic during the vertical blank is actually more straightforward.

Someone 4y ago

> The real challenge, it seems, it simply that there are so few cycles left over to implement the actual game logic. I haven’t programmed the 2600, but I expect that, in about every program for the 2600, running out of time for your game logic is unavoidable, and will make you go back to your universal, (relatively) easy to use kernel and tweak it to make it just a little bit faster for your particular use case. Given that that kernel will be written in tight assembly, I expect that more or less amounts to a rewrite. You’ll use your knowledge f the kernel to write a new one.

psychphysic 4y ago
Even on the NES and I'm sure more modern consoles and maybe any game. You often round robin game logic. Here's a fun example Castlevania on the NES by timing your movement precisely you can make it skip certain blocks being loaded. Making it leave a stair case or even a door. Works because alternate even and odd frames responsible for loading different y coords for level data in blocks. https://m.youtube.com/watch?v=Dw7NkOzp8tE https://m.youtube.com/watch?v=Dw7NkOzp8tE It might seem like there's no point now..but even in a 120fps game do you need absolutely everything to update at 120hz?
- djmips 4y ago
  Believe it or not we still amortize work and have game architecture where the sim updates at a much lower frequency than the game presentation.
toast0 4y ago
You don't really have that many spare cycles per line (unless you have double height pixels), and since there's not many registers either, you really can't get much done with the spare cycles, either. You really do need to get almost all your game loop to fit into vblank, and spend most of the screen on time driving the graphics. NES and other systems with fancier graphics systems kind of inverted the script; on those you run the game loop during screen on, and mostly transfer data to the graphics unit during vblank.

kgwxd 4y ago

Many new games are made with an arm processor built in the cart[0]. I'm not super familiar with how it works but they do some really fancy graphics kernels. Still limited by how the graphic/color registers work and not many cycles to change them all at the right time. [0] https://forums.atariage.com/topic/330778-part-1-cdfj-overview/ https://forums.atariage.com/topic/330778-part-1-cdfj-overvie...

djmips 4y ago
Despite the arm processor in the cart it barely helps with the kernel and game code in most games. Typically they are older not so powerful Cortex M0 and it is largely tied up emulating the cartridge hardware. It can give modest gains when doing the kernel but most of the fancy graphic kernels are designed as they always have been - with a lot of deep human thought.

jandrese 4y ago

The other real challenge is that you have to build your entire game using just 128 bytes of memory. Not kilobytes, bytes. You don't have the luxury of having a single scanline of the screen at memory at once. There is no caching of anything. You have just enough memory for a handful of current state variables and that's it. Luckily your program is running out of ROM so you don't have to load it before you execute, but even with that it's an incredibly tight fit.

ant6n 4y ago

Here’s a detailed video by retro game mechanics that shows how the logo graphics of the infamous E.T. game is rendered: https://youtu.be/sJFnWZH5FXc https://youtu.be/sJFnWZH5FXc It seems incredible, very difficult. And remember, back then cartridges only had 8KB of memory. This means even more hacks are required, if your game needs more than a few levels. Theres a recurring hn post how Pitfall encoded levels in a single byte (bitfield), then used some sort of sequence generator to allow going back and forth among the 255 levels.

djmips 4y ago

Easier said than done. Implementing the game logic during the vertical blank is actually more straightforward.