Sprite Replacement for Emulators

Post by **racketboy** » Wed Dec 05, 2007 4:34 pm

Somebody posted this comment in the "Sonic 2 HD" post:
"I imagine there will eventually be an emulator that will allow the sprite replacement needed to implement this. There already is for the N64 (i.e. that allows the low-res textures to be updated with higher res replacements)."

Is this feasible?

Post by **Burnsro** » Wed Dec 05, 2007 4:40 pm

I remember that in emulators, like a Super Nintendo one, it is possible to turn the different "layers" on or off. By turning them off parts of the background will disappear for example. So maybe the layers could instead be replaced by new HD ones? That's how I would envision this being implemented although I have no knowledge of any technical aspects of how these emulation programs really work.

Post by **samratty** » Wed Dec 05, 2007 5:27 pm

Interesting idea. I'm not sure how feasible it would be unless they are scaled perfectly, otherwise I guess it could fuck with the collision detection and just ruin the feel. Replacing sprites with HD sprites for a game like Sonic 2 would be a massive undertaking also.
I'm not expert tho.

Post by **Pullmyfinger** » Wed Dec 05, 2007 6:54 pm

not on an emulator, remember there is a limit to the colors a SNES and a Genesis can display at a time and they also output a certain resolution only.

Post by **racketboy** » Wed Dec 05, 2007 7:15 pm

Pullmyfinger wrote:not on an emulator, remember there is a limit to the colors a SNES and a Genesis can display at a time and they also output a certain resolution only.

Ah... didn't think of that.
But the textures in the N64 emulator isn't an issue since the textures don't actually change the number of colors or resolution....

Post by **Yackom** » Wed Dec 05, 2007 9:04 pm

racketboy wrote:
Pullmyfinger wrote:not on an emulator, remember there is a limit to the colors a SNES and a Genesis can display at a time and they also output a certain resolution only.
Ah... didn't think of that.
But the textures in the N64 emulator isn't an issue since the textures don't actually change the number of colors or resolution....

Not true.. it is possible but it would take an extensive amount of work, basically would have to reverse engineer the rendering code of the game, and would be on a per game basis. Remember the emulator isn't the system so the rendering system of an emulator often happens at a slightly higher level of abstraction, allowing for the sprite filtering and even upscaling and so on.

I once considered doing this for Super Metriod but rendering it in the Quake3 engine, then realized it would probably be a years long project

Post by **lordofduct** » Wed Dec 05, 2007 9:20 pm

The big issue I see is that the game would have to be rendered at a higher resolution... the play area would thusly be extended. A lot of older games are programmed with respect to the resolution of the play area (sorta like when you code a HTML web page in respect to resolution as opposed to percentage of screen size). The game wouldn't just need to have the sprites and background tiles replaced, but would also need to be scaled to accommodate the rise in playing field area!

note, play Sonic The Hedgehog 2 NOT in full screen so it's a small little image on screen (about 320X240), it looks pretty damn good like that!?

Other issues arise as well too in the handling of the code, such as RAM size and bandwidth of the processors of the machine you are emulating. Just because your PC supports it, doesn't mean the processor you are emulating supports it. For instance the 68000 in the Genesis only supports tile upto the size of 64X64 (I think this is about it) no matter how hard you push the processor that is its max. And emulating is basically copying that same exact processor. There is just so many blocks to put info in... extending those parameters is emulating a different processor.

a lot of assembly and machine code is dependent on the parameters or limits of the processor itself... a line of code in hex represents memory row, and column... that line of code maxes out at 16-bit, of which only part of it represent memory register positions to choose from... of which there is a limit, kinda like how older versions of DOS or Windows 95 only support HDDs up to 32 gigs, or older Pentium 2 processors support under 512MB of RAM.

...
Then again I don't code emulators... there are probably all kinds of loop holes to use and trick the thing into doing this kinda stuff. Most consoles didn't max out all the capabilities of a processor due to cost ratios (like the main board of the Dreamcast could actually support more RAM then the Dreamcast had, ala the Arcade DC boards).

You could also render them that way, create some filter on the video output to swap all textures with new ones, extend palette ranges and scale the game. Very reasonable and plausible...

Post by **Yackom** » Thu Dec 06, 2007 1:10 am

lordofduct wrote:....create some filter on the video output to swap all textures with new ones, extend palette ranges and scale the game. Very reasonable and plausible...

Yeah that's what I was trying to get at

edit:

The point here is that we don't try to make an HD version of a game within the framework of the original machine, but extend its output capability with modern hardware by analyzing what the original is trying to put on screen.