I was wondering if anyone has ever made a patch for a NES emulator so that if a certain game is run with it, instead of using the game's own graphics it uses custom-design higher-quality graphics for it (larger resolution, more colors, alpha channel). I think that could be a cool idea.
Anyone up to the challenge? It would be cool to see some existing TAS with high-quality graphics. :P
Anyone up to the challenge? It would be cool to see some existing TAS with high-quality graphics. :P
Hmm... so how much would really need to be changed in order to make the emulator's native resolution something like 640x480?
...Ahh, I think it's moot; you could never expect a TAS for an existing emulator to stay in sync in the "enhanced" version, could you?
A video console has certain standards imposed by the technology and the hardware. For example, the SNES can hold only 64 KB of graphics data in its main video memory. The registers used to access this memory have only certain bits reserved for addresses, so you couldn't access extra memory blocks even if there would be more. The main CPU and the support chips run at certain clock frequencies, so there would be no time to process/transfer more data. Not to mention that the custom hardware wouldn't understand things like alpha support etc.
You could create a new virtual console, but it wouldn't be the same any more. The games (or parts of them) would have to be rewritten, too.
...Ahh, I think it's moot; you could never expect a TAS for an existing emulator to stay in sync in the "enhanced" version, could you?
Why not? Why couldn't the emulator emulate the game *exactly* in the same way as with the original graphics, but simply replacing the game's graphics with enhanced ones. Everything else would be identical down to the smallest clock cycles.
creaothceann wrote:
A video console has certain standards imposed by the technology and the hardware. For example, the SNES can hold only 64 KB of graphics data in its main video memory. The registers used to access this memory have only certain bits reserved for addresses, so you couldn't access extra memory blocks even if there would be more. The main CPU and the support chips run at certain clock frequencies, so there would be no time to process/transfer more data. Not to mention that the custom hardware wouldn't understand things like alpha support etc.
I don't think you understood my proposal. The emulator would not touch the game itself in any way, and would still emulate the game exactly in the same way as always. The only difference is that when the game tells the "hardware" (which is emulated by the emulator) to draw a certain tile or sprite, the emulator instead draws the enhanced version of that tile/sprite graphic on screen. This will not affect the game itself in any way, only how it looks to the user.
Bob A wrote:
i think it would be easier to port the game.
Actually, I don't think that's true. If you port a game you basically have to write *everything* from scratch. Changing the game graphics in an emulator only requires you to do the graphics and the little piece of code which replaces then on the fly when drawing them on screen, and that's it.
Besides, the whole point was that existing TASes could be run with the enhanced emulator.
Why not? Why couldn't the emulator emulate the game *exactly* in the same way as with the original graphics, but simply replacing the game's graphics with enhanced ones. Everything else would be identical down to the smallest clock cycles.
If course it could be done; it's not that complicated, in theory. It's really just a question of how many things would become broken and how badly. I'd be surprised if debugging the rest of the program didn't take five times longer than making the change to the video code.
Edit: I think I'm just repeating what I said last time. Let me put it this way: video.h is included in movie.c. I don't even know why, but there's probably a reason that neither of us actually understand.
The emulator would not touch the game itself in any way, and would still emulate the game exactly in the same way as always. The only difference is that when the game tells the "hardware" (which is emulated by the emulator) to draw a certain tile or sprite, the emulator instead draws the enhanced version of that tile/sprite graphic on screen. This will not affect the game itself in any way, only how it looks to the user.
OK, but how do you detect what tile has been loaded? There will be problems if the game generates graphics data on-the-fly (e.g. Mario Paint), or uncompresses/decodes them into main memory and then transfers it to video memory.
OK, but how do you detect what tile has been loaded?
You study the game binary and find the routine which loads tiles or sprites, and patch the emulator so that when that routine is being emulated, it takes the original graphic address used by the routine and maps it to the equivalent enhanced graphic instead.
(Of course an alternative "brute force" method is to take the original tile/sprite graphic itself, compare it to a list of graphics stored in the emulator, and then use the enhanced version for that graphic.)
It's not like this kind of thing hasn't been done before. I think Bisqwit once patched fceu to show a solid beam in megaman instead of a blinking one.
This has been discussed before on the ZSNES board as well. It's possible, but not very feasible. Very game specific. Will probably never happen to more than one or two games someone might do out of spite to show everyone it can be done.
Disch wrote:
This idea has been brought up on several boards that I've gone to in the past. I even went so far as to dummy up a joke "XTREME" version of a NES emu I was working on to sort of poke fun at the idea.
I really don't like this idea at all. It could definately be done. It's not even that it would be hard (in fact, unless I'm mistaken, older versions of some emus did something similar by using "graphics packs" for some games which uses compression schemes which had not yet been cracked). It's just that this fundamentally goes against what emulation is: the recreation of the behavior of a system through software.
Not to mention it would clash and look poorly on older systems (like NES). NES's megaman's graphics and animation style compliment each other. And SNES Megaman X's graphics and animation style compliment each other. Ripping one away from the other and mixing them up would look really crappy and awkward. Imagine MMX graphics with MM's 3 frame walking animation -- it would look stupid.
Also -- on older systems this could comprimise emulation accuracy. NES games rely on some raster effects that involve pixel placement (sprite 0 hit). Failure to emulate the normal rastering process means PPU flags will not be raised (or will be raised at the wrong time).
Joined: 3/11/2004
Posts: 1058
Location: Reykjavík, Ísland
creaothceann wrote:
Disch wrote:
Not to mention it would clash and look poorly on older systems (like NES). NES's megaman's graphics and animation style compliment each other. And SNES Megaman X's graphics and animation style compliment each other. Ripping one away from the other and mixing them up would look really crappy and awkward. Imagine MMX graphics with MM's 3 frame walking animation -- it would look stupid.
I think this is all that needs to be said. So why am I posting it again?
Let's restart the discussion.
Take something like the high-res texture addons for n64 games. Could something similar to that be done with older consoles?
Let's restart the discussion.
Take something like the high-res texture addons for n64 games. Could something similar to that be done with older consoles?
It's possible, but it would involve something very different. With N64, the graphics card is actually capable of processing those high-res textures so long as it can be made to fit in memory (and with emulation, you can just increase the emulated video RAM size).
Whereas the NES video card is not capable of processing more than 25 colors per line, or handling resolutions higher than 256 x 240 pixels, so something rather more complex would have to be implemented, which would involve running pattern matching algorithms on each line as it's rendered, and replacing the patterns with the high-res versions. This would be slow, inaccurate, and rather difficult to implement.
How fleeting are all human passions compared with the massive continuity of ducks.
I had this same exact idea I presented on here a while back. Mine was to have packs for the emulator which were specific to the games. They could contain graphics, sound, and when and what to replace.
which would involve running pattern matching algorithms on each line as it's rendered
Says who? The NES has a tile memory and a sprite memory. It only requires that when the game loads a graphic to either memory, the emulator internally uses a higher-version of that graphic when that tile/sprite is drawn on screen.
There are two options for replacing the tile/sprite graphics: Either examine its contents and search it in the emulator's stored database of graphic mappings (this is a quite fast operation), or examine where from the game code the graphics are being loaded and from this address make the deduction (an even faster operation).
In theory an emulator could even be enhanced with an "editing" capability for replacing graphics. At any given moment press some designated key which makes the emulator go to the editing mode. This mode pauses the game and then you can point to any tile or sprite with the mouse (the emulator could help finding them by drawing borders around them) and then tell the emulator what to replace it with (eg. from a list of existing higher-quality graphics read from a directory or whatever). When this is done, the emulator would then, depending on the replacement mode described above, either put the original tile graphic in its database, or resolve where that tile graphic was loaded from and put that address in its database, along with the higher-quality graphic.
This could actually go even further. The editing mode could support copying a tile/sprite graphic (or a group of them) to the clipboard, allowing you to edit it with your favorite image editor, and then it could support importing graphics from the clipboard as the replacement graphics.
