Other: Castlevania 30th anniversary

[Maxbeta]

Does anybody know if there is a raw build of this Nestopia emulator that you could compile for example as a retroarch core?

In any case, are there any other NES emulators that allow for this kind of color patching?

This is way too awesome!

[kya]

Does anybody know if there is a raw build of this Nestopia emulator that you could compile for example as a retroarch core?

You may try to build this one for your favorite platform. The sources are included in src.zip in the root folder of the archive (and there is a libretro folder there). I personally was able to build this version for Ubuntu, a good friend of mine built it for Mac, and xttx fellow on this forum has succesfully built it for Xbox. As you can see, it's quite portable.

In any case, are there any other NES emulators that allow for this kind of color patching?

HDNES supports tile packs, albeit in a format that differs from the one used in this hack, and only for CHR ROM games (Castlevania is CHR RAM).
Mesen is another one. The author of Mesen is now working to add a support for CHR RAM games in his emulator, and to provide us with tile dumping tools.

[Maxbeta]

....

Hello kya and thank you for your input and helping me locate the source.

I wouldn't know the first thing about compiling programs and would really like to get this working on my Wii U now that the retroarch version keeps getting better and better. I really look forward to even creating some graphic packs for Ninja Gaiden I, II and III so we can have a properly enhanced trilogy.

Question: Is there a limit to how many new colors you could use on a game with this build?

I want to post the source over at the Retroarch forums to see if someone could compile a core, mainly for the Wii U so I can get the ball rolling, but I would definitely like to credit the main author of this build. Would that be you?

Thank you once again.

[kya]

I really look forward to even creating some graphic packs for Ninja Gaiden I, II and III so we can have a properly enhanced trilogy.

You mean taking out the tiles from the SNES trilogy and putting them into NES games?
Unfortunately it is not possible right now. The problem is not with the hacked Nestopia, but with the tile dumping tool.
To construct a skin.png you need not only the replacement tiles, but also the original NES tiles dumped in a special format.
I modified slightly the FCEUX emulator, and used it for dumping. It worked well for Castlevania, but I've just checked - it does not work for Ninja Gaiden.

So we all have to wait while Sour (the author of Mesen emulator) will make a proper tile dumping tool.

Question: Is there a limit to how many new colors you could use on a game with this build?

32768 colors (5 bits red, green and blue) in any arrangement for any tile.

I want to post the source over at the Retroarch forums to see if someone could compile a core, mainly for the Wii U so I can get the ball rolling, but I would definitely like to credit the main author of this build. Would that be you?

The correct credit would be "Nestopia was written by Martin Freij, and ported to Linux by R. Belmont.
The new cross-platform port is maintained by Ryan Danbrook."
My job was adding the tile replacement code to that port and constructing the skin.png for Castlevania.
The tiles were taken from Castlevania mobile (2003 and 2004 versions), Castlevania Bloodlines (title screen), Vampire Killer for MSX.
The rest of the tiles I've recolored/redrawn manually.

[mkwong98]

I remember seeing a fan art of Ninja Gaiden in the NesDev forum:

[Maxbeta]

....

I never liked the trilogy for SNES even if SNES is my all-time favorite console. I think Tecmo did a very rushed job and didn't take full advantage of the huge SNES color palette. IMHO other Ninja Gaiden ports like the Master System and Turbo Gfx-16 displayed much better color palettes than the SNES trilogy. So if anything I would be borrowing from those two ports and manually drawing in a few sprites. Its a bummer that the tiles don't currently display on your modified FCEUX, but again I'll wait for Mesen. Thanks for the tip and all the hard work you've put into this. I've been wanting to fiddle around with something like this for years! Another game I would love to tackle is NES Double Dragon.

I remember seeing a fan art of Ninja Gaiden in the NesDev forum:

Now that is just SICK!

[FeRcHuLeS]

Woow this is a great mod!!! btw how do you edit the tiles I mean the program recommended to do this I was trying with Paint Shop Pro 7 and don't know how to save it, the silhouette of the old tiles are mixed with the new ones.

[kya]

how do you edit the tiles I mean the program recommended to do this I was trying with Paint Shop Pro 7 and don't know how to save it, the silhouette of the old tiles are mixed with the new ones

Basically, any program which could edit a 24-bit PNG should do. I know that both GIMP and Photoshop work. I've downloaded Paint Shop Pro 7.04, tried some basic editing with it, and found it working too.
Could you be more specific - what exactly you do that goes wrong? I suspect some problems with partial transparency (excuse me, if I write obvious things here). 24-bit PNGs can have semitransparent pixels, but the hack requires the pixels to be either totally transparent or totally opaque.

[FeRcHuLeS]

This is what is happening look at the zombie I edited from Simon's Quest https://drive.google.com/open?id=0BzLzYSdAsr2hVXdvcElIMUk5aTA .I'm not familiar with image editing so if you are using PSP 7.04 how do I must save? and how about copy-paste tiles from a bmp (256 colors) to png (24bit) how do I must save?? I've got a message of something about "just an alpha channel will be saved".

[kya]

This is what is happening look at the zombie I edited from Simon's Quest

Seems it's exactly what I thought. You have almost transparent pixels in your skin.png, but the hack renders them opaque.
You should make them totally transparent. Use Eraser tool, set its size to 1, hardness to 100 and delete those almost transparent pixels left from the old sprite.

I've got a message of something about "just an alpha channel will be saved"

Looks like you have multiple alpha channels in your edited skin (e.g. R, G, and B each have their own transparency). PNG24 does not support that. The editor warns you that it will merge these three channels into one. This is ok. As I told you above, the hack does not need this information. It does not support even one alpha channel, just a binary value - the pixel is either totally opaque, or totally transparent.
After you erase all unnecessary pixels, use Dropper tool to make sure they have zero opacity. The pixels should have
R: --
G: --
B: --
O: 0
shown in the right pane

[ferk]

Also (and correct me if Im wrong) I think the sprite needs to have exactly the same shape/silhouette for this hack to display it as intended, doesnt it?

Probably it makes more sense to wait for nicer HDNES support in Mese.
Though that doesnt take any merit away from this rom hack, it's an amazing work.

And its great you have spotted things that can be improved in the HDNES format, it would be awesome if there existed a standard and an easy way to edit the spritemap for artists.

[FeRcHuLeS]

Seems it's exactly what I thought. You have almost transparent pixels in your skin.png, but the hack renders them opaque.
You should make them totally transparent. Use Eraser tool, set its size to 1, hardness to 100 and delete those almost transparent pixels left from the old sprite.

Looks like you have multiple alpha channels in your edited skin (e.g. R, G, and B each have their own transparency). PNG24 does not support that. The editor warns you that it will merge these three channels into one. This is ok. As I told you above, the hack does not need this information. It does not support even one alpha channel, just a binary value - the pixel is either totally opaque, or totally transparent.
After you erase all unnecessary pixels, use Dropper tool to make sure they have zero opacity. The pixels should have
R: --
G: --
B: --
O: 0
shown in the right pane

I've tried everything you recommended a nothing worked for me, there is maybe something in the configuration I touched that it's making this to happen on the other hand I'm going to give a try to GIMP asap and tell you of the results.

[kya]

Also (and correct me if Im wrong) I think the sprite needs to have exactly the same shape/silhouette for this hack to display it as intended, doesnt it?

The exact rule is that if an original sprite has at least one non-transparent pixel in some horizontal row (of 8 pixels), the replacement sprite should also have at least one non-transparent pixel in that row (any pixel of 8, not specifically in the original pixel position).
Basically (but not exactly!) this means both sprites should have the same height, but not necessarilly the same silhouette.

If the above rule is broken, the hack displays the original sprite row (in original NES colors).

But from the screenshot posted by FeRcHuLeS we may see, it's not the case. Because the original sprite silhouette is white, not black/magenta.
That is why I beleive he has got not completely transparent pixels there, and the hack renders them opaque.

Probably it makes more sense to wait for nicer HDNES support in Mesen.

That's what I keep telling everyone in this thread, since I learned Sour is improving the support for tile packs in his emulator.
He has full control of his emulator and can do much more than this simple hack could.

To FeRcHuLeS: if you still wish to experiment with this hack, you can PM me your current skin.png, I'll look into it to see what's wrong.

[mkwong98]

From my experience there are some features which will help greatly when working on graphics pack besides dumping tile+palette data:
1. Batch add tile+palette data. In SMB, I played the game and got all the tile+palette data for basic small and big Mario. Without the ability to add my own data, I have to play the game again as fire Mario, basic Luigi, fire Luigi and star Mario etc in order to have them included in the dump.
2. Specify color palette to be used with the pack. If you try my Kung Fu pack with Mesen, then you will see the tiles in the title screen do not matches. This is because there are tile which I did not replace with a HD version and the default color palette of HDNes is different from the default one of Mesen. So a feature added to version 2 of HDNes format is to include a palette file to the pack. This will make the pack looks consistent across emulators.
3. Another feature added to version 2 is the ability to specify the brightness of the HD replacement to be used. Many games have fade in and fade out effects when the scene changes. Repeating the HD replacement for each brightness value will greatly increase the pack size and time cost to produce it. If we can reuse the same HD replacement but specify a different brightness value, it will remove such repetition.

[SourMesen]

I've been working on this some more.

So far I've finished adding support for everything that HDNes currently supports (I believe):
-CHR RAM games
-Large sprites
-Custom palettes (palette.dat file)
-Brightness parameter on tiles

On top of this, I've added my own extensions to the format (and gave it version number 100 to avoid any potential numbering conflicts with HDNes). It keeps the same overall format, but adds some things:

1) Conditions: You can use conditions to conditionally replace tiles with different HD tiles based on surrounding tiles, or the presence of a specific tile at a specific point on the screen, etc.

2) Backgrounds: You can define a background image that will be used instead of the NES' background color. This makes it possible, for example, to give a background to the fight sequences in Final Fantasy games, instead of a black background:


3) IPS/BPS patches: It's now possible to ship IPS/BPS patches along with the HD pack itself so that you can, for example, create a HD pack for an existing romhack (or create a romhack specifically for the HD pack)

4) A flag to disable the sprite limit

Examples:

Code Select Expand


#Defining a condition that checks if we're on the battle screen, in the crystal tower, in FF3:
<condition>towerBattle,tileAtPosition,0,8,D250B460A8C2952270F4D0EA62508665,0F302112

#Using that condition to setup a background image (e.g what was shown in the screenshot above):
[towerBattle]<background>TowerBattleBackground.png,1

#Defining an IPS patch to use with the HD pack:
<patch>ff.ips,c4443fc24625e3c2bb859525eb44b6b3a80e7c35

#Disabling the sprite limit:
<options>disableSpriteLimit


I think that's about it for additions to the HD pack format.

On top of this, I also added a tile dumping tool to Mesen that dumps a game's graphics as you play through the game. The PNG files created display the tiles in the same order that they were placed in CHR ROM/RAM, which usually makes sense.  There are a few options to try and get the best results possible based on the game (it's by no means perfect, but it's a decent starting point to making an HD pack)
Technically speaking, after playing through the entire game with the dumping tool turned on, the "only" thing left to do is to redraw the PNG files with better graphics (which is probably the most time consuming part of the process).
The tool allows you to select what scale/filter you want to dump the tiles with - so you can dump the tiles as they appear with the xBRZ filter, for example, and use that as a starting point to redraw them properly in HD.

The tool doesn't actually let you manually modify the contents of a HD pack, though - this still needs to be done manually by editing the text file (at least for now)

There's still a little bit of work to get done (and most likely bugs to fix), but I'm slowly getting there.

[mkwong98]

Excellent news! Can't wait to test it out.

[bogaabogaa]

Me too can't wait to do some work.

[AxlRocks]

That looks and sounds great! Do conditions have an option (or can such a thing be added) for reading from user specified RAM addresses to change tiles, rather than just checking certain tiles on-screen?

I can only assume background replacement works (well) only with static screens and can't support scrolling in anyway, right? Still really useful regardless.

Can't wait to use this with some Megaman stuff I've been working on.

[SourMesen]

Do conditions have an option (or can such a thing be added) for reading from user specified RAM addresses to change tiles, rather than just checking certain tiles on-screen?

At the moment, no - this is because the thread that handles the HD conversion runs independently of the emulation. So you might get a 1-2 frame delay between the value in RAM vs what it actually was when the pixel was originally output. Having access to the value at the exact same time as the pixel is output would be pretty hard (esp. when considering performance). If a 1-2 frame delay seems acceptable, though, that would be easy to add.

I can only assume background replacement works (well) only with static screens and can't support scrolling in anyway, right?

Yea, pretty much. It would technically be possible to implement soft scrolling via a ton of conditions, but as is, that would require a lot of effort and a ton of PNG background files.

If anyone wants to play around with the new feature, there's a build with it here: https://www.mesen.ca/MesenHdPackTest.zip
But keep in mind some bugs may still exist, and I still might have to change the HD pack file format based on needs/feedback, so don't spent 10 hours making a HD pack based on this :)
I'd be nice to have some feedback about it, though!

Edit: Until it's properly documented, the best way to know the file format is probably to take a look at the code: https://github.com/SourMesen/Mesen/blob/master/Core/HdPackLoader.cpp

[mkwong98]

Can it dump tile data yet? I can't find the option for doing that.
SourMesen, thank you for the reply. It only appears when the game is running.


July 22, 2017, 06:51:02 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
I found 2 graphics glitch. I attached two screen shots, one from Mesen and one from HDNes for reference:
1. The "Help!" speech bubble in the screen shot. Not sure what's happening
2. When 2 sprites over lap, the sprites priority uses the original tile pixels instead of the HD pixels as shown in the bottom left of the screen shot.