6 ms·

In the excellent Masters of Doom it is explained that Keen was the Mario-like game (i.e. sideways scrolling). They offered the tech to Nintendo as an option to

In the excellent Masters of Doom it is explained that Keen was the Mario-like game (i.e. sideways scrolling). They offered the tech to Nintendo as an option to port Mario to the PC. Nintendo declined, thus Keen was born. It was a vast leap for PC gaming and it opened an new era of PC gaming. However, here is what I never quite understood, what was so different about the NES and PC tech that Nintendo had figured out to do sideways scrolling years before the PC?

enneff 3y ago
They actually did a port of SMB3 and presented that to Nintendo. When Nintendo didn’t bite, they made new assets to make what became Keen. Here’s a video of the port: https://youtu.be/1YWD6Y9FUuw https://youtu.be/1YWD6Y9FUuw
- janvdberg 3y ago
  Wow amazing! I did not know this was available on YouTube. Thank you. It is kind of bonkers considering how well it works for a prototype that all-in-all (based on the comment by Lane Roathe) took just 48 hours to make!
  - marmakoide 3y ago
    I don't think it's 48h from scratch. Making the prototype for scrolling a tile map, a tile editor, etc might have taken more time. 48h sounds more like the time to capture sprites and slap them using already made tools/code.
- zactato 3y ago
  I recall playing this back in the day. It was super cool. My Dad pulled it from the DEC internal file sharing service and brought it home. I long believed that it was a figment of my imagination until I heard that ID had developed a demo for Nintendo that must have gotten leaked
MattBearman 3y ago
I’m not 100% on this but I believe the NES has a dedicated graphics chip for sprite manipulation, where as it all had to be done in software on the PC
- JohnBooty 3y ago
  Essentially, yeah. You give it a list of pointers to background tiles and a list of pointers to sprites and tell it where you want them drawn. It then does that for you at 60fps for free. The downside is that that's all it does. That's the whole graphics system. You can't like, paint an individual pixel. (you can, if you treat each tile as a mini framebuffer, which is how something like the NES port of Elite is possible, but this is expensive and you only have a very small amount of processing time and a limited number of tiles)
- RuggedPineapple 3y ago
  Exactly this. Most consoles of the era were set up fundamentally to work with tightly defined graphical regimes. For the NES as an example, has almost zero ability to work with pixels or bits. It fundamentally at a hardware level deals with tiles. Sprite tiles are 8 by 8, or doublewide 8x16 if you put in some effort. You can build larger sprites by combining sprite tiles, but be careful because the hardware that processes this can only handle 8 sprites per scanline. PC's have typically had a much more bitmapped graphical regime, where individual pixels are addressable and drawable, which better suits a general purpose computer but means you have to do some trickery if you want to get some of the polish that consoles had, and was typically slower since you didn't have dedicated hardware that spoke in those terms. on the flip side though setting up a windowing system on an NES with its hardware speaking in sprites and tiles would be a nightmare.
  - shdon 3y ago
    A nightmare, perhaps, but it has been done: https://arstechnica.com/gadgets/2022/09/nesos-somehow-fits-gui-desktop-word-processing-into-8-bit-nintendo/ https://arstechnica.com/gadgets/2022/09/nesos-somehow-fits-g...
JohnBooty 3y ago
EGA essentially gives you a big framebuffer. You can draw whatever arbitrary thing you want in EGA's graphics mode: lines, circles, individual pixels, whatever. That's what it's built for. But you don't get scrolling for free. You've got to manually copy memory around and as the linked article points out, if you brute-force it you only get around 5fps because of the ISA bus' limited bandwidth. The NES (and other 8/16bit) game systems are not built to let you draw arbitrary crap. They are built to render tiles. You define a grid of background tiles and provide a scroll offset. Sprites work similarly but they can move independently. You get all this for free at 60fps. The downside is that you can't render arbitrary stuff very easily. You have to jump through some serious hoops to e.g. paint an individual pixel somewhere. It's not so much that Nintendo "figured it out" before IBM. IBM built a general-purpose computer and created a series of general-purpose graphics systems geared towards static graphics, giving you fine-grained control over every single pixel. If you look at an EGA card it's a beast; lots of silicon on there. Nintendo on the other hand created a much simpler single-purpose graphics system geared toward sliding tiles around.
anthk 3y ago
The NES and the GB were tiles based I think. They worked games on "sprite", basis with layers, so 'accelerating' 2D had a lot of sense.
HelloNurse 3y ago
The methods in the article emulate hardware-managed tiles (https://www.nesdev.org/wiki/PPU https://www.nesdev.org/wiki/PPU seems a good starting point for the NES) in software, using a frame buffer of independent pixels: the challenge is adapting a sideways scrolling game engine to look good in a completely different system's memory space and bandwidth limitations, not "figuring out how to do sideways scrolling" per se.

enneff 3y ago

They actually did a port of SMB3 and presented that to Nintendo. When Nintendo didn’t bite, they made new assets to make what became Keen. Here’s a video of the port: https://youtu.be/1YWD6Y9FUuw https://youtu.be/1YWD6Y9FUuw

janvdberg 3y ago
Wow amazing! I did not know this was available on YouTube. Thank you. It is kind of bonkers considering how well it works for a prototype that all-in-all (based on the comment by Lane Roathe) took just 48 hours to make!
- marmakoide 3y ago
  I don't think it's 48h from scratch. Making the prototype for scrolling a tile map, a tile editor, etc might have taken more time. 48h sounds more like the time to capture sprites and slap them using already made tools/code.
zactato 3y ago
I recall playing this back in the day. It was super cool. My Dad pulled it from the DEC internal file sharing service and brought it home. I long believed that it was a figment of my imagination until I heard that ID had developed a demo for Nintendo that must have gotten leaked

MattBearman 3y ago

I’m not 100% on this but I believe the NES has a dedicated graphics chip for sprite manipulation, where as it all had to be done in software on the PC

JohnBooty 3y ago
Essentially, yeah. You give it a list of pointers to background tiles and a list of pointers to sprites and tell it where you want them drawn. It then does that for you at 60fps for free. The downside is that that's all it does. That's the whole graphics system. You can't like, paint an individual pixel. (you can, if you treat each tile as a mini framebuffer, which is how something like the NES port of Elite is possible, but this is expensive and you only have a very small amount of processing time and a limited number of tiles)
RuggedPineapple 3y ago
Exactly this. Most consoles of the era were set up fundamentally to work with tightly defined graphical regimes. For the NES as an example, has almost zero ability to work with pixels or bits. It fundamentally at a hardware level deals with tiles. Sprite tiles are 8 by 8, or doublewide 8x16 if you put in some effort. You can build larger sprites by combining sprite tiles, but be careful because the hardware that processes this can only handle 8 sprites per scanline. PC's have typically had a much more bitmapped graphical regime, where individual pixels are addressable and drawable, which better suits a general purpose computer but means you have to do some trickery if you want to get some of the polish that consoles had, and was typically slower since you didn't have dedicated hardware that spoke in those terms. on the flip side though setting up a windowing system on an NES with its hardware speaking in sprites and tiles would be a nightmare.
- shdon 3y ago
  A nightmare, perhaps, but it has been done: https://arstechnica.com/gadgets/2022/09/nesos-somehow-fits-gui-desktop-word-processing-into-8-bit-nintendo/ https://arstechnica.com/gadgets/2022/09/nesos-somehow-fits-g...

JohnBooty 3y ago

EGA essentially gives you a big framebuffer. You can draw whatever arbitrary thing you want in EGA's graphics mode: lines, circles, individual pixels, whatever. That's what it's built for. But you don't get scrolling for free. You've got to manually copy memory around and as the linked article points out, if you brute-force it you only get around 5fps because of the ISA bus' limited bandwidth. The NES (and other 8/16bit) game systems are not built to let you draw arbitrary crap. They are built to render tiles. You define a grid of background tiles and provide a scroll offset. Sprites work similarly but they can move independently. You get all this for free at 60fps. The downside is that you can't render arbitrary stuff very easily. You have to jump through some serious hoops to e.g. paint an individual pixel somewhere. It's not so much that Nintendo "figured it out" before IBM. IBM built a general-purpose computer and created a series of general-purpose graphics systems geared towards static graphics, giving you fine-grained control over every single pixel. If you look at an EGA card it's a beast; lots of silicon on there. Nintendo on the other hand created a much simpler single-purpose graphics system geared toward sliding tiles around.

anthk 3y ago

The NES and the GB were tiles based I think. They worked games on "sprite", basis with layers, so 'accelerating' 2D had a lot of sense.

HelloNurse 3y ago

The methods in the article emulate hardware-managed tiles (https://www.nesdev.org/wiki/PPU https://www.nesdev.org/wiki/PPU seems a good starting point for the NES) in software, using a frame buffer of independent pixels: the challenge is adapting a sideways scrolling game engine to look good in a completely different system's memory space and bandwidth limitations, not "figuring out how to do sideways scrolling" per se.