5 ms·

My problem with these "part 1 making a game" tutorials is that they usually never make it past part 3... This article only covers 1BPP byte graphics, and assume

My problem with these "part 1 making a game" tutorials is that they usually never make it past part 3... This article only covers 1BPP byte graphics, and assumes that all 65(c)02 machines use them which is absolutely not the case. Graphics for 8-bit machines are usually handled by a separate processor with its own format(s) anyway: VIC for C64, ANTIC for Atari 8-bit, PPU for the NES, etc. You could check out the Nerdy Nights tutorial for NES development which is fully fleshed out and has a tried and true record of getting people started: https://nerdy-nights.nes.science/ https://nerdy-nights.nes.science/ Apologies to the author if this seems harsh and disheartening, but, i've seen too many tutorials both never finish and give out incorrect information.

WoodenChair 5y ago
I agree, but you need to give this person the benefit of the doubt. They haven't yet "not finished" since this just came out yesterday. This "unfinished" issue is also a problem with regards to tutorials for writing emulators. It's amazing, given how popular writing NES emulators is, that there is not yet a great step-by-step written tutorial for writing one (there IS great documentation and some great video tutorials (see One Lone Coder for example)). This is why one of the big projects in my next book will be a detailed tutorial showing how a simple NES emulator is built.
- cepher 5y ago
  Do you know if any tutorial exists for SNES emulators? Haven’t been able to find one, and I’ve heard it’s a large step up in difficulty from a NES emulator.
  - WoodenChair 5y ago
    I don't know SNES. I went from writing a really basic NES emulator to working on a really basic IBM PC emulator. If you want to know more about SNES, I would look at old posts on the subreddit emudev: https://www.reddit.com/r/EmuDev/ https://www.reddit.com/r/EmuDev/
- nicetryguy 5y ago
  Perhaps i'm projecting my own frustrations trying to learn retro dev, which is unfortunate and maybe immature on my part, but i've been burned too many times to shut up. > Simple NES emulator The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Many 6502 instructions don't behave like you think they would with page boundaries, there are some hardware errors. The PPU / registers get all kinds of weird with their behavior too, such as $2003/$2004 (sprite addr / data) basically being broken on real hardware and Sprite DMA only falling on even cycles, etc. Each mapper is it's own unique snowflake as well, the MMC3 and VRC6 scanline interrupts work completely differently in hardware. There are many more examples of strangeness. I'd love to see someone tackle it and wish you luck.
  - WoodenChair 5y ago
    > The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Right, I agree. The PPU's intricacies are what make it difficult to write a good tutorial. When I wrote my own emulator as a personal learning project in C I did it myself except the background rendering of the PPU which I ported from a popular cycle-accurate Go project. In writing this book, what I've done is go and say "how can I write the absolutely minimum PPU so that the most basic NROM games will play (like Donkey Kong & Tennis)." My rewritten from scratch PPU is as simple as possible, only doing any rendering once per frame (the simplified PPU only does anything 60 times per second). I have it working well on very simple commercial and public domain games in C. Now my challenge is to get it ported and performant enough in pure Python, the language of the book.
    - nicetryguy 5y ago
      You're doing Gods work then my friend =) Is it possible to sync python up enough to get it to write frames accurately without a significant amount of lag? I'd certainly be interested in how to get it to do that.
- 21bits 5y ago
  Off topic, but I wanted to tell you that I'm enjoying going through 'Classic Computer Science Problems In Python.' I think you're a very good writer and I'm looking forward to more of your work.
  - WoodenChair 5y ago
    Thank you! Much appreciated.
pvg 5y ago
Apple ][s have pretty much dumb framebuffer graphics and plenty of games were written for those. Fairly sure the ZX Spectrum didn't have much in the way of dedicated graphics hardware either.
- nicetryguy 5y ago
  True. 2600 sprites work like this too. "Specky" has a Z80 anyway. I can't imagine realistically targeting something like this or being nostalgic for that XOR'd sprite look. Most later machines had more / varied graphical capabilities, even the new Commander X16 which uses a 'c02 has it's own graphics processor and several formats.
  - duskwuff 5y ago
    The 2600 was a whole wacky world of its own. The system didn't actually have any native support for sprites or bitmapped graphics! The graphics chip was designed to implement games similar to Pong, and only natively supported drawing a few blocks of color; games which wanted to display more complex graphics (which is to say, almost all of them) had to abuse this hardware by modifying its registers on a per-scanline (or even an intra-scanline) basis.
    - nicetryguy 5y ago
      Right, all you could do with the "player" objects was point them at a different byte every scanline, write the X value into the register, and it would paint the "1's" as "pixels" in that byte on that particular scanline with that X value. It was up to the programmer to multiplex them on a per scanline basis. No framebuffer whatsoever. Fun stuff!
    - bitwize 5y ago
      The Atari 2600 supported sprites: two "players", two "missiles", and one "ball", that could be moved freely over the low resolution playfield. However, their bitmaps were only one pixel high; you had to change them on each scanline in order to get taller images. Rectangular bitmap sprites may have debuted in consumer hardware with the TI-99/4 in 1979; the term "sprite" comes from the technical documentation for that computer.

WoodenChair 5y ago

I agree, but you need to give this person the benefit of the doubt. They haven't yet "not finished" since this just came out yesterday. This "unfinished" issue is also a problem with regards to tutorials for writing emulators. It's amazing, given how popular writing NES emulators is, that there is not yet a great step-by-step written tutorial for writing one (there IS great documentation and some great video tutorials (see One Lone Coder for example)). This is why one of the big projects in my next book will be a detailed tutorial showing how a simple NES emulator is built.

cepher 5y ago
Do you know if any tutorial exists for SNES emulators? Haven’t been able to find one, and I’ve heard it’s a large step up in difficulty from a NES emulator.
- WoodenChair 5y ago
  I don't know SNES. I went from writing a really basic NES emulator to working on a really basic IBM PC emulator. If you want to know more about SNES, I would look at old posts on the subreddit emudev: https://www.reddit.com/r/EmuDev/ https://www.reddit.com/r/EmuDev/
nicetryguy 5y ago
Perhaps i'm projecting my own frustrations trying to learn retro dev, which is unfortunate and maybe immature on my part, but i've been burned too many times to shut up. > Simple NES emulator The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Many 6502 instructions don't behave like you think they would with page boundaries, there are some hardware errors. The PPU / registers get all kinds of weird with their behavior too, such as $2003/$2004 (sprite addr / data) basically being broken on real hardware and Sprite DMA only falling on even cycles, etc. Each mapper is it's own unique snowflake as well, the MMC3 and VRC6 scanline interrupts work completely differently in hardware. There are many more examples of strangeness. I'd love to see someone tackle it and wish you luck.
- WoodenChair 5y ago
  > The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Right, I agree. The PPU's intricacies are what make it difficult to write a good tutorial. When I wrote my own emulator as a personal learning project in C I did it myself except the background rendering of the PPU which I ported from a popular cycle-accurate Go project. In writing this book, what I've done is go and say "how can I write the absolutely minimum PPU so that the most basic NROM games will play (like Donkey Kong & Tennis)." My rewritten from scratch PPU is as simple as possible, only doing any rendering once per frame (the simplified PPU only does anything 60 times per second). I have it working well on very simple commercial and public domain games in C. Now my challenge is to get it ported and performant enough in pure Python, the language of the book.
  - nicetryguy 5y ago
    You're doing Gods work then my friend =) Is it possible to sync python up enough to get it to write frames accurately without a significant amount of lag? I'd certainly be interested in how to get it to do that.
21bits 5y ago
Off topic, but I wanted to tell you that I'm enjoying going through 'Classic Computer Science Problems In Python.' I think you're a very good writer and I'm looking forward to more of your work.
- WoodenChair 5y ago
  Thank you! Much appreciated.

pvg 5y ago

Apple ][s have pretty much dumb framebuffer graphics and plenty of games were written for those. Fairly sure the ZX Spectrum didn't have much in the way of dedicated graphics hardware either.

nicetryguy 5y ago
True. 2600 sprites work like this too. "Specky" has a Z80 anyway. I can't imagine realistically targeting something like this or being nostalgic for that XOR'd sprite look. Most later machines had more / varied graphical capabilities, even the new Commander X16 which uses a 'c02 has it's own graphics processor and several formats.
- duskwuff 5y ago
  The 2600 was a whole wacky world of its own. The system didn't actually have any native support for sprites or bitmapped graphics! The graphics chip was designed to implement games similar to Pong, and only natively supported drawing a few blocks of color; games which wanted to display more complex graphics (which is to say, almost all of them) had to abuse this hardware by modifying its registers on a per-scanline (or even an intra-scanline) basis.
  - nicetryguy 5y ago
    Right, all you could do with the "player" objects was point them at a different byte every scanline, write the X value into the register, and it would paint the "1's" as "pixels" in that byte on that particular scanline with that X value. It was up to the programmer to multiplex them on a per scanline basis. No framebuffer whatsoever. Fun stuff!
  - bitwize 5y ago
    The Atari 2600 supported sprites: two "players", two "missiles", and one "ball", that could be moved freely over the low resolution playfield. However, their bitmaps were only one pixel high; you had to change them on each scanline in order to get taller images. Rectangular bitmap sprites may have debuted in consumer hardware with the TI-99/4 in 1979; the term "sprite" comes from the technical documentation for that computer.