Here's an idea that I haven't seen posted anywhere on any other emulation board. I would love to see someone either incorporate it into emulators or/and spread the ideas to other boards.
We already have the algorythms to enhance full screen graphics, like Scale 2x, Eagle, HQ2x or 3x and similar that have been used over time.
Why not apply these algorhythms to the sprites and backgrounds BEFORE they are composited into a full frame?
The advantage would be that things like the edges or any transparent bits would be much smoother - a higher res sprite on a higher res background. You would lose some of the "stairstepping" which shows up when you go to HQ3x or higher.
For that matter, why not provide hooks in the code which allow replacing the graphics outright with higher resolution 'packs' fairly easily? Whether manually enhanced or even completely redrawn? The N64 emulators already do something like this - allowing upgrading the textures with user supplied packs. Why not do the same with not only genesis sprites but tilesets to the background? Jack your copy of Revenge of Shinobi up to 1920x1080p just for the hell of it with high res drawn images!
The two ideas are really pretty complimentary - they might as well be coded at the same time. It would be like the Street Fighter 2 Turbo HD Remix which people are going gaga over more recently.
For that matter though it's not graphics, why not do something like MetalMAME for genesis or even SMS emulators? :) Provide hooks so that the triggered music tracks and sound effects could be replaced by mp3 files or higher res WAV files to upgrade the sound in similar fashion. All while running original code, and giving a chance for fans who cant really code (like me) but who love older games to work on graphics/sound update packs for all their favorite classics and give back to the community.
Feel free to crosspost this idea to any other emulator board - i'd love to see this incorporated on everything from Atari 2600 to enhanced MAME or modern emus as well.
IDEA for enhanced graphics (better than Scale2x, HQ2x, etc
Moderator: BigEvilCorporation
-
DogOnTheNet
- Newbie
- Posts: 2
- Joined: Mon Jun 07, 2010 6:28 am
Huge is completely right.
Such a concept had actually been considered for the Sonic the Hedgehog 2 HD project, but it was decided that hacking an emulator do to what you've described simply won't get the desired results, nor the flexibility required... if you want Revenge of Shinobi in HD, you're probably better off gathering up a huge interested community into making its own HD remake project.
Replacing music is also somewhat impractical (Though, perhaps simpler then the graphics), even an MP3 playback tool for Sonic the Hedgehog 2 was made that piggybacked off Gens... I can't say I ever got it to work, however, and even then, it's game dependent.
Basically, with the way the Mega Drive works, it's not happening, not easily anyway.
Edit: Also, anyone, please feel free to correct me on any points that I may have gotten wrong... I'm not exactly as advanced as all you techheads, heh.
Such a concept had actually been considered for the Sonic the Hedgehog 2 HD project, but it was decided that hacking an emulator do to what you've described simply won't get the desired results, nor the flexibility required... if you want Revenge of Shinobi in HD, you're probably better off gathering up a huge interested community into making its own HD remake project.
Replacing music is also somewhat impractical (Though, perhaps simpler then the graphics), even an MP3 playback tool for Sonic the Hedgehog 2 was made that piggybacked off Gens... I can't say I ever got it to work, however, and even then, it's game dependent.
Basically, with the way the Mega Drive works, it's not happening, not easily anyway.
Edit: Also, anyone, please feel free to correct me on any points that I may have gotten wrong... I'm not exactly as advanced as all you techheads, heh.
Sounds like a pretty gross hack. It would be more elegant to port Sonic 2 to Sega CD... if it's possible (some levels change tiles midway through, also, bosses, title cards, etc). But, I think they already ported many Sonic games to Sega CD.even an MP3 playback tool for Sonic the Hedgehog 2 was made that piggybacked off Gens
Why not set up hooks for high-res tiles instead?
From what I understand, bg & sprite images are are stored in the game ROM as groups of 8x8 tiles, that are copied to VDP RAM as necessary, and then rendered to screen.
Now, how difficult would it be to:
1 - extract the tile data, in their respective groups into their own separate image files? i.e. the tiles for level 1 might be stored in one part of the ROM, tiles for level 2 might be stored in another part of the ROM, tiles for the player's sprites might be stored in yet another part of the ROM and so on. Would it be possible to export them, as is, to level_01.tga, level_02.tga and player.tga?
2 - for the purpose of this er... experiment, scale the images up to 8x their original size, so instead of 8x8 4bpp tiles, you're looking at 64x64 32bpp tiles.
3 - create some kind of an .ini file, containing a list of which tga file corresponds to which group of tiles in the ROM. Preferably listed by ROM address. i.e. $xxxxxxxx="level_01.tga".
4 - (The most difficult part) Create/Write an external renderer that constantly watches what the VDP in the emulator is doing, such as loading, unloading and/or rendering a group of tiles; and try to follow it using the tga & ini files. So when the VDP gets an instruction to copy a series of tiles from location $xxxxxxxx, the external renderer looks up the ini file, and loads the content of "level_01.tga". When the VDP gets instructed to show 8x8 tiles 1, 2, 3, and 4, the external renderer shows the first four 64x64 "tiles" it loaded into memory.
5 - (Not as difficult as part 4) Disable the original video output (the images created by the emulated VDP), and show the new HD image created by the external renderer instead.
Then again... this would create problems with palette swapping unless the change in color values could be recalculated into some kind of a hue/saturation shift.
Line scrolling might be another problem. Then again, this can probably be avoided if the aforementioned renderer supports some basic scripting.
Just an idea.
From what I understand, bg & sprite images are are stored in the game ROM as groups of 8x8 tiles, that are copied to VDP RAM as necessary, and then rendered to screen.
Now, how difficult would it be to:
1 - extract the tile data, in their respective groups into their own separate image files? i.e. the tiles for level 1 might be stored in one part of the ROM, tiles for level 2 might be stored in another part of the ROM, tiles for the player's sprites might be stored in yet another part of the ROM and so on. Would it be possible to export them, as is, to level_01.tga, level_02.tga and player.tga?
2 - for the purpose of this er... experiment, scale the images up to 8x their original size, so instead of 8x8 4bpp tiles, you're looking at 64x64 32bpp tiles.
3 - create some kind of an .ini file, containing a list of which tga file corresponds to which group of tiles in the ROM. Preferably listed by ROM address. i.e. $xxxxxxxx="level_01.tga".
4 - (The most difficult part) Create/Write an external renderer that constantly watches what the VDP in the emulator is doing, such as loading, unloading and/or rendering a group of tiles; and try to follow it using the tga & ini files. So when the VDP gets an instruction to copy a series of tiles from location $xxxxxxxx, the external renderer looks up the ini file, and loads the content of "level_01.tga". When the VDP gets instructed to show 8x8 tiles 1, 2, 3, and 4, the external renderer shows the first four 64x64 "tiles" it loaded into memory.
5 - (Not as difficult as part 4) Disable the original video output (the images created by the emulated VDP), and show the new HD image created by the external renderer instead.
Then again... this would create problems with palette swapping unless the change in color values could be recalculated into some kind of a hue/saturation shift.
Line scrolling might be another problem. Then again, this can probably be avoided if the aforementioned renderer supports some basic scripting.
Just an idea.
Tiles are often stored compressed in ROM and decompressed by 68k while being loaded to VRAM. There is also line scrolling and vertical column scrolling to worry about, also animated tiles in some cases. Even if tiles are stored plain and just copied to vram the emulator would have hard time tracking where they came from as there are so many ways to code ROM->VRAM copy routine (well except when they are copied using DMA).
You could identify tiles by a crc of their raw data perhaps, and perhaps it would be possible to set up something that monitors vram tile updates every cycle, and switch tiles into the new versions whenever they are updated.
I don't even want to guess the computational requirements of such a method, however.
Beyond the possibility of such an upgrade, though, I'm more worried about how such an "upscale" filter would look with huge sprites made up of 8x8 tiles, or huge sprite+background combinations (like the bosses in Ranger X, or the final Death Egg boss in Sonic & Knuckles). Filtering the block graphics one by one may result in an end result that just looks terrible (the 8x8 map grid could be seen, since there would be no interpolation between the multiple 8x8 tiles).
Of course this isn't much to worry about if the emulator pulls hand-crafted hires tiles, similar to what all those horrible N64 emulators do. But that would have two problems: One, simple-colored tiles with no real graphics would be un-editable, unless the tile lookup code isn't just crc based but something more advanced. Two, who the hell would go and upgrade every single tile one by one in a game, apart from the OCD kids in the Sonic community?
I don't even want to guess the computational requirements of such a method, however.
Beyond the possibility of such an upgrade, though, I'm more worried about how such an "upscale" filter would look with huge sprites made up of 8x8 tiles, or huge sprite+background combinations (like the bosses in Ranger X, or the final Death Egg boss in Sonic & Knuckles). Filtering the block graphics one by one may result in an end result that just looks terrible (the 8x8 map grid could be seen, since there would be no interpolation between the multiple 8x8 tiles).
Of course this isn't much to worry about if the emulator pulls hand-crafted hires tiles, similar to what all those horrible N64 emulators do. But that would have two problems: One, simple-colored tiles with no real graphics would be un-editable, unless the tile lookup code isn't just crc based but something more advanced. Two, who the hell would go and upgrade every single tile one by one in a game, apart from the OCD kids in the Sonic community?