4 ms·

Ack. That doesn't look very good. And it runs unplayably slow and glitchy / flashy. "Your first assumption might be that geod has hard-coded specific algorithm

Ack. That doesn't look very good. And it runs unplayably slow and glitchy / flashy. "Your first assumption might be that geod has hard-coded specific algorithms for each supported game, training the emulator in how to detect specific objects and create good-looking 3D models for them." I don't know why anyone would assume that, given how poorly it works. My current assumption would be that game-specific algorithms would be the only way to make this work given how ambiguous NES graphics are. I suppose a top-tier neural network expert could make a game-agnostic algorithm... but it would probably handle a frame per minute on a multi-thousand-dollar machine. I wish someone would come up with better filters for emulating CRT glow so the game would look like a series of photos of the game being played on a top-of-the-line CRT (PVM / BVM). But that would probably be way too slow, too. Actually I have an idea of how to do it... If I could get an array of pixels per frame into Unity or some other game engine and make each pixel a light... or even just make each pixel a partially transparent shaded sphere bitmap and multiply them together where they over lap... it would probably run too slow but I once made something like that and looked pretty good and ran plenty fast albeit at a sub-NES resolution.

logicrook 11y ago
>I don't know why anyone would assume that, given how poorly it works. You're tough. Every type of computer generated visuals have some cases that won't work well, given that there are so many semantic choices: anti-aliasing, dithering, textures, forms, compete for the information of each pixel. Each pixel can encode any subset of these features. We rely on the human brain to parse it and decode it meaningfully, and even then, it doesn't always work. If you've tried yourself at pixel art, you'll understand quickly (you can also look at the research on upscaling algorithms). So the result is very far from an actual product, but it's really impressive.
- daodedickinson 11y ago
  Alright, I put it far too rudely, but I do find this aesthetically displeasing compared to raw pixels and Contra looked completely unplayable, and it shows massive slowdown and audio distortion, so I don't get the point.
  - vlunkr 11y ago
    The article states that it's in beta still, so I assume the audio at least will get cleaned up.
qnaal 11y ago
>I wish someone would come up with better filters for emulating CRT glow I'm a fan of Blargg's NTSC filter[a], included in snes9x-gtk. [a]http://slack.net/~ant/libs/ntsc.html http://slack.net/~ant/libs/ntsc.html
- jmiserez 11y ago
  I highly recommend reading Kyle Pittman's article on CRT emulation: http://gamasutra.com/blogs/KylePittman/20150420/241442/CRT_Simulation_in_Super_Win_the_Game.php http://gamasutra.com/blogs/KylePittman/20150420/241442/CRT_S...
pcwalton 11y ago
You're way too pessimistic about doing image recognition on NES tiles. NES games don't update the tileset very often during gameplay. They can't--the NES has no framebuffer and a very underpowered CPU, so the VBLANK time is a mad dash to push all per-frame data to the GPU (PPU in NES-speak) by the time the video signal is going to begin. Most games barely slide under this window. Lots of games didn't even try to do dynamic tileset updates and stored tileset data in ROM. Because of this, you can do a lot of graphics processing up front and cache it on a per-tile basis. The hit rates on that cache are going to be massive.
- khedoros 11y ago
  Agreed. The hardware itself does palette and tile lookups for each pixel, then shoves the data out the wire. Building an emulator that way is more literally how the hardware works, but it's slow. It's easier (and usually just as accurate) to cache the tiles for the current palette settings and blit them to the playfield as needed. There's no reason that the same wouldn't be true for 3D representations of those same sprites. Updating the sprites in CRAM is fairly rare (and impossible in any game that uses CROM).

logicrook 11y ago

>I don't know why anyone would assume that, given how poorly it works. You're tough. Every type of computer generated visuals have some cases that won't work well, given that there are so many semantic choices: anti-aliasing, dithering, textures, forms, compete for the information of each pixel. Each pixel can encode any subset of these features. We rely on the human brain to parse it and decode it meaningfully, and even then, it doesn't always work. If you've tried yourself at pixel art, you'll understand quickly (you can also look at the research on upscaling algorithms). So the result is very far from an actual product, but it's really impressive.

daodedickinson 11y ago
Alright, I put it far too rudely, but I do find this aesthetically displeasing compared to raw pixels and Contra looked completely unplayable, and it shows massive slowdown and audio distortion, so I don't get the point.
- vlunkr 11y ago
  The article states that it's in beta still, so I assume the audio at least will get cleaned up.

qnaal 11y ago

>I wish someone would come up with better filters for emulating CRT glow I'm a fan of Blargg's NTSC filter[a], included in snes9x-gtk. [a]http://slack.net/~ant/libs/ntsc.html http://slack.net/~ant/libs/ntsc.html

jmiserez 11y ago
I highly recommend reading Kyle Pittman's article on CRT emulation: http://gamasutra.com/blogs/KylePittman/20150420/241442/CRT_Simulation_in_Super_Win_the_Game.php http://gamasutra.com/blogs/KylePittman/20150420/241442/CRT_S...

pcwalton 11y ago

You're way too pessimistic about doing image recognition on NES tiles. NES games don't update the tileset very often during gameplay. They can't--the NES has no framebuffer and a very underpowered CPU, so the VBLANK time is a mad dash to push all per-frame data to the GPU (PPU in NES-speak) by the time the video signal is going to begin. Most games barely slide under this window. Lots of games didn't even try to do dynamic tileset updates and stored tileset data in ROM. Because of this, you can do a lot of graphics processing up front and cache it on a per-tile basis. The hit rates on that cache are going to be massive.

khedoros 11y ago
Agreed. The hardware itself does palette and tile lookups for each pixel, then shoves the data out the wire. Building an emulator that way is more literally how the hardware works, but it's slow. It's easier (and usually just as accurate) to cache the tiles for the current palette settings and blit them to the playfield as needed. There's no reason that the same wouldn't be true for 3D representations of those same sprites. Updating the sprites in CRAM is fairly rare (and impossible in any game that uses CROM).