Modified NEStopia for Castlevania graphics enhancement

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
SaucJedi
Posts: 46
Joined: Wed Jul 27, 2005 9:46 am
Location: Spain

Modified NEStopia for Castlevania graphics enhancement

Post by SaucJedi »

I have recently come across this at romhacking.net:

http://www.romhacking.net/forum/index.php?topic=24125

I downloaded the source code of the modified NEStopia emulator and checked the ppu code, but don't understand how all of this is triggered in order to replace graphics...

I remember a Sinclair ZX Spectrum which, in a similar vein, allowed for replacing graphics in games, it was not easy (as it would be with this modified NEStopia), but could be done for more than one game.

http://www.emulatronia.com/emusdaqui/sp ... rewulf.htm

Wonder if the techniques used in Castlevania could be used to enhance more games.

Has anybody looked into this?
Run, you fools!
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Modified NEStopia for Castlevania graphics enhancement

Post by lidnariq »

See this thread for an emulator specifically designed to do this kind of tile substitution instead of grafting it onto Nestopia...
(The author of that emulator, mkwong98, pops up in the end of the thread you mention. Sour, also appearing in that thread, wrote the only other implementation.)
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Modified NEStopia for Castlevania graphics enhancement

Post by Sour »

The current version of Mesen only has partial support for HDNes' packs - but like I said in the romhacking.net thread, I've been working on improving it and with the latest changes it works for all games (that code is not on GitHub yet) and has no real limitation on the maximum scale factor (though it needs to be an integer value obviously).
For CHR ROM, the tiles are matched based on palette & tile ID (i.e the offset in CHR ROM).
For CHR RAM, the tiles are matched based on all their data (16 bytes) + the palette.

I'm also working on automatically dumping the game's tiles (w/ their proper palette) to PNG files as you play through a game.
It's working pretty nicely with CHR ROM games at the moment, and some CHR RAM games as well (e.g Castlevania). Other CHR RAM games are a bit of a pain when it comes to dumping the graphics in a decent arrangement in the PNGs, though. Final Fantasy 3 for example almost continuously animates a water tile in CHR RAM (even when no water is visible on the screen), which causes the bank's "hash" to constantly change, making it harder to correctly group together tiles that were in CHR RAM at the same time.

At the moment, I can play a game to get some PNG files containing the tiles automatically, and then just replace the graphics in the PNG files to change them in the game as well - it's pretty straightforward. I'm still not quite done and it will probably be a few more weeks before I can release anything with the new changes, though.
User avatar
SaucJedi
Posts: 46
Joined: Wed Jul 27, 2005 9:46 am
Location: Spain

Re: Modified NEStopia for Castlevania graphics enhancement

Post by SaucJedi »

Such features would be great to have. After playing with this Castlevania enhancement I find very interesting to be able to modify the appearance of a game without affecting the inner workings.

This came just when I was wondering if it could be possible to revamp an emulator to simulate two PPUs and try to emulate in software the master/slave behaviour to have two background planes...
Run, you fools!
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Modified NEStopia for Castlevania graphics enhancement

Post by tepples »

I can see two practical problems with running two 2C02 PPUs in a master/slave configuration. The biggest is that the missing dot on every other frame when rendering is enabled would cause the PPUs to drift out of sync over time, 30 pixels for each second in which one PPU's rendering is enabled and the other's not. Another is that you'd need two separate sets of CHR RAM and nametable memory, one for each PPU, unless you can design some sort of multiplexer circuit.

If you have solutions for these, I'd be interested to see a new topic about them.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Modified NEStopia for Castlevania graphics enhancement

Post by Sumez »

I don't see the logic in even emulating two PPUs for a feature that's only intended for the emulator anyway, though.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Modified NEStopia for Castlevania graphics enhancement

Post by Sour »

SaucJedi wrote:simulate two PPUs and try to emulate in software the master/slave behaviour to have two background planes...
Part of the new features I'm working on is the ability to specify a "background" based on conditions (e.g presence on a specific tile at a specific position on the screen, or even the value of a specific address in RAM, etc.)

It lets you, for example, add a background to the battle screen in FF3 instead of just black:
Final Fantasy III (J) [!]_002.png
Final Fantasy III (J) [!]_002.png (7.32 KiB) Viewed 4869 times
I guess it could also be possible to use it as a very primitive form of parallax scrolling in some scenarios, too.
e.g, in this case, the gray rocky background is normally just black and since the background doesn't scroll along with the rest of the stage, it looks like it could be the ground, far below.
Final Fantasy III (J) [!]_003.png
Final Fantasy III (J) [!]_003.png (8.89 KiB) Viewed 4869 times
Obviously this isn't perfect (you can see some of the rocks through the treasure chest, for example) - but if you were to replace the treasure chest's tiles with a "HD" tile, you could make those portions of the tile non-transparent, which could be used to fix it.
User avatar
SaucJedi
Posts: 46
Joined: Wed Jul 27, 2005 9:46 am
Location: Spain

Re: Modified NEStopia for Castlevania graphics enhancement

Post by SaucJedi »

Sumez wrote:I don't see the logic in even emulating two PPUs for a feature that's only intended for the emulator anyway, though.
The same logic behind SNES MSU: experimentation.
Run, you fools!
Post Reply