3 ms·

Actually, programming homebrew for the NES and SNES, I was surprised by how similar my experience was to learning OpenGL. You can't plot individual pixels on ha

by Drakim 8y ago

Actually, programming homebrew for the NES and SNES, I was surprised by how similar my experience was to learning OpenGL. You can't plot individual pixels on hardware like that, you have to fill CHR memory (like textures) and create arrays of sprite data (like triangles) to upload to the hardware accelerated unit of the console. While it's totally true that you had to be very "close to the metal" in everything you do, I feel it's not that dissimilar from coding C and OpenGL today, in terms of the overall flow of your project.

BonsaiDen 8y ago
Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows. But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for. However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D [1] https://gitlab.com/BonsaiDen/vectroid.gb https://gitlab.com/BonsaiDen/vectroid.gb
beagle3 8y ago
NES and SNES were not your general "development system of the 80s"; I'm quite sure GP was referring to the Apple, Oric, Acorn, BBC, Dragon, MSX, Tandy CoCo, Spectrum, Amiga and even PCg/PCjr/XT of the time. Commodore's C64, PET and VIC20 were exceptional in how hard they made using graphics at the time from the included BASIC; But in general it was quite easy. The Atari VCS2600 had an even weirder video setup: It had one line of video memory (a 1D canvas!), and it was up to the program to replace the contents of that line while the screen raster was flying back to the next line. And a few sprites to sweeten the deal.
ashleyn 8y ago
Modern hardware still works much the same, writing bytes to hardware that handles graphics generation, albeit today's are vastly more complex and SIMD-oriented. The key difference is these consoles lacked a framebuffer; RAM at the time was very expensive.

by Drakim 8y ago

BonsaiDen 8y ago

Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows. But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for. However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D [1] https://gitlab.com/BonsaiDen/vectroid.gb https://gitlab.com/BonsaiDen/vectroid.gb

beagle3 8y ago

NES and SNES were not your general "development system of the 80s"; I'm quite sure GP was referring to the Apple, Oric, Acorn, BBC, Dragon, MSX, Tandy CoCo, Spectrum, Amiga and even PCg/PCjr/XT of the time. Commodore's C64, PET and VIC20 were exceptional in how hard they made using graphics at the time from the included BASIC; But in general it was quite easy. The Atari VCS2600 had an even weirder video setup: It had one line of video memory (a 1D canvas!), and it was up to the program to replace the contents of that line while the screen raster was flying back to the next line. And a few sprites to sweeten the deal.

ashleyn 8y ago

Modern hardware still works much the same, writing bytes to hardware that handles graphics generation, albeit today's are vastly more complex and SIMD-oriented. The key difference is these consoles lacked a framebuffer; RAM at the time was very expensive.