7 ms·

The glEnd of Zelda(): Automatic 3Dification of NES Games (2016)

359 points by fniephaus 9y ago

DanBC 9y ago
There are a few comments about the video here that you might be interested in: https://news.ycombinator.com/item?id=11411054 https://news.ycombinator.com/item?id=11411054
__s 9y ago
The video states the UI is out of reach.. but screen scroll glitch Being able to move the player's character around would also be useful for goal setting out of local maxima wrt AIs
Pulcinella 9y ago
Might want to add (2016) to the title.
- sctb 9y ago
  Thanks!
deleted 9y ago
[deleted]
djsumdog 9y ago
I hadn't seen this before. This is amazing, and well presented. I looked at some of his other videos like making programs that can also be ascii text. Insane! Why solve such insane problems? I feel like the constraints are the kinds of things you come up with at a party with people you work with at 2am while drunk.
- onli 9y ago
  You should look at some other things the author did. They fit in the same area of craziness, and are absolutely great. For example https://www.youtube.com/watch?v=QVn2PZGZxaI https://www.youtube.com/watch?v=QVn2PZGZxaI, Portmantout: A portmanteau of every English word, or the first one, https://www.youtube.com/watch?v=xOCurBYI_gY https://www.youtube.com/watch?v=xOCurBYI_gY, Computer program that learns to play classic NES games. I also liked the humor in What, if anything, is epsilon?, https://www.cs.cmu.edu/~tom7/papers/epsilon.pdf https://www.cs.cmu.edu/~tom7/papers/epsilon.pdf.
- superasn 9y ago
  Insane that he used an older version of GL just so that he could use that headline. That just took it to whole another level:)
  - planteen 9y ago
    I just got the joke after you said that - legend is to glEnd. Wow!
  - Iv 9y ago
    I suspect that he feels like me that glBegin and glVertex are very convenient to make low performance prototypes. When you initialize a gl context it is not always to feed it millions of polygons.
- petercooper 9y ago
  Why solve such insane problems? Because some people find it fun and it keeps the brain sharp. Conversely, I don't find hiking or playing cricket fun but millions do :-)
- Iv 9y ago
  They are related to automated game AI. He tells it is another of his interests.
smaili 9y ago
Amazing and well-detailed video - kudos to Tom! One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?
- white-flame 9y ago
  GPUs deal with rendering to framebuffers. Old school graphics chips didn't have the memory to hold an entire framebuffer (memory was expensive!), nor the speed to clear & repaint a full framebuffer at 60Hz, so they'd generate the pixel colors for each screen location on the fly in real-time as the raster scanned the CRT picture, from tile-based graphics definitions and a bunch of registers that controlled positions, scrolling, and other properties of a generally fixed set of graphics capabilities. Many game consoles gave their video chip its own internal memory, so the CPU would hit memory mapped I/O ports to set registers, like palette values or the position of sprites.* At each line (or character, or however it's timed), the video chip would read the current value of the palette & graphics bitmap data and stream it out the analog video generator pixel by pixel in sync. Multiple layers (SNES, etc) or sprites would all be read "live" per scanline, and the chip would decide, based on transparency & priority, which object's color would be visible for that final pixel output. Graphic screens were usually a grid with a byte per "tile" or "character", often an 8x8 pixel chunk, which offers a form of dictionary compression. The tile ID byte + tile gfx dictionary (gfx were usually 1-4 bits per pixel, for 256 8x8 pixel tiles) + palette info constitued the screen graphics formats, with a similar setup for independently movable sprites. Many effects could be achieved by having the CPU change registers mid-way down the screen. It can do color gradients by updating the palette every line, change tile or scroll definitions for different sections of the screen (like having a non-scrolling score/inventory section, then flipping to scrolling graphics for the other part of the screen). Many video chips signaled CPU interrupts at configurable scanlines, or allowed the CPU to set up display lists which had address/value/screen-location tuples that it would execute as it drew the screen. Because all of this was real-time generated, most games were 60fps. If there was too much going on in some frame then graphics were simply lost or ended up in the next frame with wild visual glitches because the timed gfx changes happened at the wrong time & place. Nowadays, GPUs paint a framebuffer, and display that framebuffer when it's done being drawn, yielding variable frame rate. Some non-action games did that back in the 80s as well, and it was often slow enough to see each step of the image being drawn. [* = most home computers held gfx and palette info in their "large" main memory, with the video chip having exposed configuration registers on the memory bus, instead of tunneling through I/O ports]
icelancer 9y ago
Tom also built Learnfun and Playfun, which was Lexicographic Ordering applied to... playing video games. http://www.cs.cmu.edu/~tom7/mario/ http://www.cs.cmu.edu/~tom7/mario/ Truly awesome stuff.
- seeekr 9y ago
  The Episode 2 video with learnfun/playfun is really good, too [0]. Tom7 is a fun guy. [0] https://www.youtube.com/watch?v=YGJHR9Ovszs https://www.youtube.com/watch?v=YGJHR9Ovszs
valleyer 9y ago
This makes me wish I had gone to grad school.
- thematth 9y ago
  Well, if you mean because you get to do fun stuff like this then yeah! This work is not really a product of higher education though. It's one of creativity, tenacity, good programming and more than that a deep knowledge of the NES architecture! Most people have the capability to do the last two regardless of education! The more I read about 8 bit computing the more amazed I am. Needing a very detailed knowledge of the underlying system was a given then, unlike today. What's massively impressive is that some hit games back then were developed by teens in their bedrooms (so no grad school!). Miles away from the game industry we see today!
- gwillen 9y ago
  Having hung out with Tom 7: Grad school didn't make him like this, he just has an absolutely insane level of drive to create cool things. I don't think he could stop if he tried. And like most things, the way you get good at "making cool and hilarious hacks / techno-art" is to do a lot of it. So start hacking! :-)
ncx 9y ago
What is the knowledge (low-level/math/computer-graphics/etc/etc/...) required to create something like this. I am a student in 1st year currently. And I am very much interested in Emulation as well as crazy stuff like this. Can anyone please explain in a bit of detail what all knowledge is required to build such a thing.
- tomyws 9y ago
  Familiarity with hardware would be a good starting point - the author explained how he can made use the three tables used by the PPU to pick out objects and textures. There is a lot of information about the NES online which would be useful references. Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource. To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!
- ccvannorman 9y ago
  Google, stack overflow, and this guy's video are likely all you need to make a significant leap forwards.
- jerf 9y ago
  With just a bit of Google-foo and some persistence, you can have working emulators of the 8-bit systems by the end of the summer if you put your mind to it. While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.) It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :) And the power differential between the Gameboy and a modern computer is so vast you can even use Javascript in a browser if you like. Use whatever language you like. C/C++ is still not necessarily a bad choice or anything, but don't fall into the trap of thinking you need their performance in this case. You've got gobs of power, you can afford any current language you like or would like to learn.
mrfusion 9y ago
Side note: I don't remember the graphics of Nintendo looking so terrible. Was it just that on a low resolution crt screen they looked good somehow?
- timlyo 9y ago
  Crt had colour bleed that blended the sprites differently and made things look better.
- 0xcde4c3db 9y ago
  Yes, that's a factor. Zelda also isn't the prettiest NES game by a long shot; you might be remembering later titles with slicker artwork like Kirby's Adventure, Crystalis, Little Samson, etc..

359 points by fniephaus 9y ago

There are a few comments about the video here that you might be interested in: https://news.ycombinator.com/item?id=11411054 https://news.ycombinator.com/item?id=11411054

__s 9y ago

The video states the UI is out of reach.. but screen scroll glitch Being able to move the player's character around would also be useful for goal setting out of local maxima wrt AIs

Pulcinella 9y ago

Might want to add (2016) to the title.

sctb 9y ago
Thanks!

deleted 9y ago

[deleted]

djsumdog 9y ago

I hadn't seen this before. This is amazing, and well presented. I looked at some of his other videos like making programs that can also be ascii text. Insane! Why solve such insane problems? I feel like the constraints are the kinds of things you come up with at a party with people you work with at 2am while drunk.

onli 9y ago
You should look at some other things the author did. They fit in the same area of craziness, and are absolutely great. For example https://www.youtube.com/watch?v=QVn2PZGZxaI https://www.youtube.com/watch?v=QVn2PZGZxaI, Portmantout: A portmanteau of every English word, or the first one, https://www.youtube.com/watch?v=xOCurBYI_gY https://www.youtube.com/watch?v=xOCurBYI_gY, Computer program that learns to play classic NES games. I also liked the humor in What, if anything, is epsilon?, https://www.cs.cmu.edu/~tom7/papers/epsilon.pdf https://www.cs.cmu.edu/~tom7/papers/epsilon.pdf.
superasn 9y ago
Insane that he used an older version of GL just so that he could use that headline. That just took it to whole another level:)
- planteen 9y ago
  I just got the joke after you said that - legend is to glEnd. Wow!
- Iv 9y ago
  I suspect that he feels like me that glBegin and glVertex are very convenient to make low performance prototypes. When you initialize a gl context it is not always to feed it millions of polygons.
petercooper 9y ago
Why solve such insane problems? Because some people find it fun and it keeps the brain sharp. Conversely, I don't find hiking or playing cricket fun but millions do :-)
Iv 9y ago
They are related to automated game AI. He tells it is another of his interests.

smaili 9y ago

Amazing and well-detailed video - kudos to Tom! One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?

white-flame 9y ago
GPUs deal with rendering to framebuffers. Old school graphics chips didn't have the memory to hold an entire framebuffer (memory was expensive!), nor the speed to clear & repaint a full framebuffer at 60Hz, so they'd generate the pixel colors for each screen location on the fly in real-time as the raster scanned the CRT picture, from tile-based graphics definitions and a bunch of registers that controlled positions, scrolling, and other properties of a generally fixed set of graphics capabilities. Many game consoles gave their video chip its own internal memory, so the CPU would hit memory mapped I/O ports to set registers, like palette values or the position of sprites.* At each line (or character, or however it's timed), the video chip would read the current value of the palette & graphics bitmap data and stream it out the analog video generator pixel by pixel in sync. Multiple layers (SNES, etc) or sprites would all be read "live" per scanline, and the chip would decide, based on transparency & priority, which object's color would be visible for that final pixel output. Graphic screens were usually a grid with a byte per "tile" or "character", often an 8x8 pixel chunk, which offers a form of dictionary compression. The tile ID byte + tile gfx dictionary (gfx were usually 1-4 bits per pixel, for 256 8x8 pixel tiles) + palette info constitued the screen graphics formats, with a similar setup for independently movable sprites. Many effects could be achieved by having the CPU change registers mid-way down the screen. It can do color gradients by updating the palette every line, change tile or scroll definitions for different sections of the screen (like having a non-scrolling score/inventory section, then flipping to scrolling graphics for the other part of the screen). Many video chips signaled CPU interrupts at configurable scanlines, or allowed the CPU to set up display lists which had address/value/screen-location tuples that it would execute as it drew the screen. Because all of this was real-time generated, most games were 60fps. If there was too much going on in some frame then graphics were simply lost or ended up in the next frame with wild visual glitches because the timed gfx changes happened at the wrong time & place. Nowadays, GPUs paint a framebuffer, and display that framebuffer when it's done being drawn, yielding variable frame rate. Some non-action games did that back in the 80s as well, and it was often slow enough to see each step of the image being drawn. [* = most home computers held gfx and palette info in their "large" main memory, with the video chip having exposed configuration registers on the memory bus, instead of tunneling through I/O ports]

icelancer 9y ago

Tom also built Learnfun and Playfun, which was Lexicographic Ordering applied to... playing video games. http://www.cs.cmu.edu/~tom7/mario/ http://www.cs.cmu.edu/~tom7/mario/ Truly awesome stuff.

seeekr 9y ago
The Episode 2 video with learnfun/playfun is really good, too [0]. Tom7 is a fun guy. [0] https://www.youtube.com/watch?v=YGJHR9Ovszs https://www.youtube.com/watch?v=YGJHR9Ovszs

valleyer 9y ago

This makes me wish I had gone to grad school.

thematth 9y ago
Well, if you mean because you get to do fun stuff like this then yeah! This work is not really a product of higher education though. It's one of creativity, tenacity, good programming and more than that a deep knowledge of the NES architecture! Most people have the capability to do the last two regardless of education! The more I read about 8 bit computing the more amazed I am. Needing a very detailed knowledge of the underlying system was a given then, unlike today. What's massively impressive is that some hit games back then were developed by teens in their bedrooms (so no grad school!). Miles away from the game industry we see today!
gwillen 9y ago
Having hung out with Tom 7: Grad school didn't make him like this, he just has an absolutely insane level of drive to create cool things. I don't think he could stop if he tried. And like most things, the way you get good at "making cool and hilarious hacks / techno-art" is to do a lot of it. So start hacking! :-)

ncx 9y ago

What is the knowledge (low-level/math/computer-graphics/etc/etc/...) required to create something like this. I am a student in 1st year currently. And I am very much interested in Emulation as well as crazy stuff like this. Can anyone please explain in a bit of detail what all knowledge is required to build such a thing.

tomyws 9y ago
Familiarity with hardware would be a good starting point - the author explained how he can made use the three tables used by the PPU to pick out objects and textures. There is a lot of information about the NES online which would be useful references. Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource. To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!
ccvannorman 9y ago
Google, stack overflow, and this guy's video are likely all you need to make a significant leap forwards.
jerf 9y ago
With just a bit of Google-foo and some persistence, you can have working emulators of the 8-bit systems by the end of the summer if you put your mind to it. While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.) It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :) And the power differential between the Gameboy and a modern computer is so vast you can even use Javascript in a browser if you like. Use whatever language you like. C/C++ is still not necessarily a bad choice or anything, but don't fall into the trap of thinking you need their performance in this case. You've got gobs of power, you can afford any current language you like or would like to learn.

mrfusion 9y ago

Side note: I don't remember the graphics of Nintendo looking so terrible. Was it just that on a low resolution crt screen they looked good somehow?

timlyo 9y ago
Crt had colour bleed that blended the sprites differently and made things look better.
0xcde4c3db 9y ago
Yes, that's a factor. Zelda also isn't the prettiest NES game by a long shot; you might be remembering later titles with slicker artwork like Kirby's Adventure, Crystalis, Little Samson, etc..