Castlevania II (Simon's Quest) - Multilingual enhancement

[Bisqwit]

I played through the game quickly using a few select cheats and emulator patches and produced this map. It shows every actor / sprite that was encountered during the playthrough, in the real game palette. Background graphics are not colored, sorry. Everything that is in dark purple colors is something that was never rendered as a sprite, either because the actor never assumed that pose, or there was no actor that could ever assume that pose.



Each line is a separate VROM page. Those tiles that are in same horizontal position on different lines have the same tile number.
It is not possible to swap smaller units of VROM data in this game (MMC1) than the entire 4 kB page (one horizontal line in this map). That is why a lot of graphics is duplicated on different pages.

There are a few sprites that never appeared during this play. Though some of them are due to my style of play (such as not discovering all cluebooks), but there are genuinely some unused graphics. For example, what's that on the right side of Carmilla?

EDIT: I also made similar pictures from a few other games. Here I just used a select TASes (a few of which desynced) instead of comprehensively looking for every possible animation.
http://bisqwit.iki.fi/kala/nes_vrom_sprites_mario2.png -- Super Mario Bros. 2 (USA)
http://bisqwit.iki.fi/kala/nes_vrom_sprites_mario3.png -- Super Mario Bros. 3
http://bisqwit.iki.fi/kala/nes_vrom_sprites_batman.png -- Batman
http://bisqwit.iki.fi/kala/nes_vrom_sprites_kirbyadv.png -- Kirby's Adventure
http://bisqwit.iki.fi/kala/nes_vrom_sprites_tmnt.png -- TMNT
http://bisqwit.iki.fi/kala/nes_vrom_sprites_mm3.png -- Mega Man 3
http://bisqwit.iki.fi/kala/nes_vrom_sprites_mm5.png -- Mega Man 5
March 30, 2013, 09:43:16 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

The "activation area" of many of the signposts in the towns is off-center. Standing on the right half of the sign doesn't trigger it, while standing far to its left still can.

I will try to resize the hitbox for the signposts. Shouldn't be too difficult. I wonder though why they left it like that.

In doing what I wrote, I just noticed that A) the hitbox is not of wrong size; rather, it is misplaced in some towns, and B) you said so, and I did not read you correctly the first time.

In Veros, the sign is placed properly. You can stand on either side of the sign and activate it properly. But in all other towns, it is off by one tile to the left. So, to fix this problem, I need to edit the maps after all. This is even easier. I reverse engineered the hitboxes for nothing Mmh. I will make them larger anyway.

I released version 2.5.3 containing the Simon blinking feature, and the fix for the townsigns.
The blinking feature is disabled by default! You will have to enable it in the patch machine. I will make it enabled by default if enough people agree it's a good idea.

[Fes]

Awesome! Thanks for fixing the signpost thing. That always drove me crazy. When I first played the game as a kid, I didn't know you could read the signs cause I wasn't standing in the right spot. I think this will definitely help anyone who plays the game for the first time.

Also loving the invulnerability strobe; it makes the game feel more polished.

[keropi]

blinking is a very nice addition IMHO  makes the game more polished

[Zynk]

http://bisqwit.iki.fi/kala/nes_vrom_sprites_mm3.png -- Mega Man 3

Heys, Bisqwit! I noticed Megaman has A LOT of sprites of himself in MM3! Does that mean that I can (theoretically) make individual sprites from those, like Megaman in Snakeman mode?

[Bisqwit]

Heys, Bisqwit! I noticed Megaman has A LOT of sprites of himself in MM3! Does that mean that I can (theoretically) make individual sprites from those, like Megaman in Snakeman mode?

I am not sure what exactly you are asking.
In Megaman3, there are two 64-tile pages reserved for Megaman alone. While the top page always stays the same when Megaman is visible (it's swapped out only when e.g. bringing up the status screen), the bottom page is different for each subweapon that Megaman can use. Even in the bottom page, only the bottom 16 tiles are different for each subweapon.  This matches the behavior of Megaman1 and 2, where the same was implemented with VRAM rewrites: 16 tiles were rewritten whenever a subweapon was switched.
So in Megaman3, when Megaman has the SN weapon, pages 0 and 1 are selected.
When he has the GE weapon, pages 0 and 2 are selected. HA or RJ? 0 and 3. RC? 0 and 4. SP and SH? 0 and 6. And so on.
EDIT: Actually there's a third page which has Megaman's graphics. It has the tiles for his hand, jumping, and climb-shooting. While the tiles are always the same, the rest of the page differs depending on the enemies in the stage. For example, page 12 is the page that appears in Topman's stage. So when Megaman is in Topman's stage and has SH weapon equipped, the pages from which Megaman's graphics are fetched at that moment are 0, 6 and 12.
Megaman4 is essentially the same, but went back to the VRAM route.

In Megaman5, fewer pages of Megaman's tiles are mapped simultaneously. Instead, the pages are switched whenever Megaman does some action. This allows more tiles for other actors, and also for Megaman's weapons. This however meant that a Megaman clone enemy could no longer be trivially written into the game, because the clone would need to share Megaman's graphics, even though Megaman himself has a complete monopoly over them. In my opinion, this was the cleverest and most optimal of the solutions in this NES series. (The clone could however have a copy of Megaman's graphics. They did not do it.)

In Megaman6, they went back to VRAM again.


The reason why scrolling was slow in Megaman1 and 2 was that a lot of PPU writes had to happen during the scrolling. New VRAM tiles would have to be written for the following screen, and two entire screens of nametables&attributes would be rewritten. The game would use horizontal mirroring and always maintain a buffer of at 0.5 screens in either direction. Rewriting those screens would happen during the vertical scrolling. And it was slow. In Megaman3, they swap between horizontal mirroring and vertical mirroring, depending on scrolling, essentially always using just a single screen. They would not use a buffer. They would always write stuff right next to the current screen only as needed. This reduced the number of PPU writes by half, and then using VROM instead of VRAM meant that you no longer need to write into VRAM either. Scrolling could be really fast.
In Megaman4, they used VRAM again, but they retained the nametable technique, which meant that although scrolling could not be exactly as fast as in Megaman3, it could still be a lot faster than in Megaman1 and 2. This alternated between Megaman5 and Megaman6, as well.
April 04, 2013, 04:30:36 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Back to the topic of Castlevania II, I am still working on that palette fade problem.


(Click to enlarge. GIF size is 1.1 megabytes, which is why I only inlined a snapshot here.)

Here are a couple of different fading algorithms. I am trying to find an algorithm that could possibly be done in real time and not require 32 kilobytes of storage.
From top left:

1. Angular interpolation. It simply uses the NES color index and interpolates that using angular mathematics. An exception is added where one of the colors is without chroma component.
Pros: Requires no additional storage space, and it could be done really fast.
Cons: It only looks nice when fading between similar colors. It has problems with fading through very different colors (such as from blue to red on the ground), or from a gray color to a colored one such as from white to purple.

2. Precalculated interpolation using 16 steps. This is theoretically optimal.
Pros: It looks as good as it can get, and thanks to consisting of only table lookups, there is no question of whether this can be done in real time.
Cons: It requires 64*32*16 bytes, i.e. 32 kilobytes of ROM storage just for the tables. Even though my ROM budget may allow it, it is painful in principle to dedicate such a huge percentual amount of ROM for such a miniscule feature.

3. Precalculated interpolation with temporal dithering. This attempts to solve the problem where the NES palette simply does not have the right color, by blinking through two different colors where the mixture of those two matches the intended color.
Pros: It produces a smoother fade than algorithm 2, especially when rendered on a CRT. It may not look so nice in the web browser, because of issues in rendering high-framerate GIFs.
Cons: It requires twice as much ROM space as algorithm 2; 64 kilobytes in this case.

4. The NES colors are stored in a sorted array according to their green RGB component. The closest match is looked up from that table using just the green component using binary search. Then a few nearby elements (5) in the table are tested using their whole RGB value, and the closest one is used.
Pros: It requires 3*64 bytes for NES palette colors and 128 bytes for the green-sorted array, 256 bytes total. Acceptable. It may be simple enough to do it in real time, or at least in 2 frames per fade-iteration.
Cons: It does not look very nice.

5. The NES colors are put in seven categories depending on which RGB channels have the maximum value. Each of those categories is sorted by luma. The closest match is looked up from the right table using binary search according to the luma value alone (using the television industry standard formula where Y = R*0.299 + G*0.587 + B*0.114).
Pros: It requires 7*64*2 bytes of space, which translates into 896 bytes. Acceptable. It is likely doable in real time. It should be a bit faster than method 4.
Cons: It looks kind of odd.

6. This method attempts to do exactly the same as algorithm 2, except without precalculation. To make it a bit more doable in real time, color resolution is sacrificed: Each RGB component is saved in just 4 bits (12 bits RGB). The colors are looked up using a linear search, or a kd-tree.
Pros: It is kind of there. It requires 128 bytes of storage for palette data, 56 bytes for candidate color table, a few other small tables, and 432 bytes more if a Kd-tree is used. The total is way within acceptable limits.
Cons: Some flashing occurs, and I am not sure why. Also, using a linear search, it still requires 7700 cycles minimum, 9500 cycles maximum, to calculate one palette value. This means it is still way too slow. I am trying to see what a Kd-tree could do to it... It should go somewhere around 900 cycles per palette entry, which means that one fading iteration for 23 colors should be possible to calculate in about two frames. It may still be too costly.

EDIT: I have managed to reduce the data size enough.  Algorithm 2 is now doable.

[Turambar]

(Click to enlarge. GIF size is 1.1 megabytes, which is why I only inlined a snapshot here.)

I actually like the first one the best.
You are trying to get it to change in real time without pausing the game, right?
I have a cool idea about how to deal with the zombies in town if you do this transition stuff without pausing the game.
How about when you're in town at night and it starts to become daytime the zombies in town became paler or blacker or redder (depending on which one looks better) and then on the final transition frame it destroys them as if you've whipped them (sets them on fire), as if it was the sunlight that set them on fire and the sun indeed vanquished the horrible night.
And when it becomes nighttime the townspeople could just fade to black and disappear and the zombies would start spawning.

[Bisqwit]

I have released the retranslation version 2.6.0. Get it at: http://bisqwit.iki.fi/cv2fin/#now

This adds support for the palette fader option. If something is a holy cow to Simon's Quest fans, it is the "the morning sun has vanquished the horrible night" messages, and this patch does away with them completely. As such, the feature is disabled by default. You will have to enable it in the patch vending machine to get it. The day and night do still change normally, but it is no longer accompanied with an obtrusive dialog box. The palette just fades smoothly to a new set of colors and the music changes, without interrupting the game.
As a bonus incentive, this patch also fixes the game's original bug where the townsigns would become unresponsive when day/night changes. The bugfix depends on the palette fading patch.
Video demonstration: http://www.youtube.com/watch?v=oCfnehhRBsk

I did not implement Turambar's suggestion on the zombies turning into fire or something like that when the morning comes, but the townfolks do fade to black, and it looks quite cool. (Ladies are exempt. Could not be helped, because they share palette with Simon.)

The Simon blinking feature is still an optional and default-disabled one. I wish to hear more feedback about it before changing its status.

As always, if you encounter new weird bugs with the game, please don't hesitate to report them here.

[Turambar]

I love seeing this with my own eyes. It's so awesome. This is easily romhack of the year and it's only April.
I don't think it would be blasphemy to change the woman in red to be the rustier brown shade of the other townsfolk so that she fades the same as the others.
I would love to see the zombies get owned by the sunlight though.
The destroy monster sound effect, the fire, the multiple zombies dying all at once. That would be quite amusing and awesome to see.
It would be as awesome as in Half-Life 2 when you can pick up an enemy's grenade with the gravity gun and throw back in his face and watch him ragdoll away.
Let's all use peer-pressure on Bisqwit until he puts it in. Or money! That would probably work.
If that feature gets put in then the romhack is done and can't possibly get any better.

[Bisqwit]

I don't think it would be blasphemy to change the woman in red to be the rustier brown shade of the other townsfolk so that she fades the same as the others.

She would have to be changed permanently, which I don't like as an idea. It is not possible to change it just for the fades, because the colors in her sprites are in a different order (black, red, white -- as opposed to the other palette which is brown, white, black).
Well... You could reorder palette 2, and change the sprites of the monk and the boy to use the reordered palette. This would work. Then you could change the lady (and the sitter, if he/she was outdoors) temporarily to palette 2 for the fading. Hmh. I'll leave it as an idea for now.

[Turambar]

It occurred to me that if Simon and the woman in red shared the same palette and laurels cause you to flash that maybe the woman in red flashed too because I figured the shared palette would just rapidly change, but that's not the case. How is it that just Simon flashes and not the woman? I wish I could make the woman flash, if you know what I mean.

[Pikachumanson]

o.O

[Bisqwit]

It occurred to me that if Simon and the woman in red shared the same palette and laurels cause you to flash that maybe the woman in red flashed too because I figured the shared palette would just rapidly change, but that's not the case. How is it that just Simon flashes and not the woman? I wish I could make the woman flash, if you know what I mean.

The game cycles Simon's sprite through the four different palettes.
I.e. it uses Simon's palette, then it uses hearts and fire palette, then it uses actor 1's palette, then it uses actor 2's palette, and back to Simon's palette again. It is not that Simon's palette, as in the list of colors, is rewritten.
The strangers in the graveyards, the bodypart bags, the chain of the morning star, and the golden knife all flash using this same manner. The palette index for the object is rotated, rather than the palette data itself.

So, there's now a 2.6.1. It includes palettefade related updates discussed earlier.

[Vanya]

Things are looking more and more awesome with each update! Cheers!

On the Subject of the zombies in the morning. While it would be cool to see all the zombies combust in the morning, it really wouldn't fit in with zombie lore. However, what would be nearly as cool is if you could give them the "diving back into the ground" animation similar to the animation used by the zombies in CV3 use to emerge from the ground.

[hossbags2]

Is it possible to make Simon Belmont's palette look like the way he does in original Castlevania. Sometimes he blends in to much with the scenery in the background like where you very first start the game at. Also, can you make the health bar look any better?

[Bregalad]

Is it possible to make Simon Belmont's palette look like the way he does in original Castlevania. Sometimes he blends in to much with the scenery in the background like where you very first start the game at. Also, can you make the health bar look any better?

I released a hack that does exactly that in January.

[MathUser2929]

I like the CV II Simon Belmont. Since it depicts him with this pallette in artwork I don't think it should be retconned out. Also, digging in and out of the ground would be cool and all, but wouldn't work unless they were on the ground. If they were on stone platforms they'd be digging and rising into the stones. Stones that probably don't have room for the zombies to fit in.

I hope you didn't change the pallette of those villagers. I liked the pallette. Hate to see them switched to a more bland pallette.

[Turambar]

You are the man, Bisqwit!
You should have seen the epic conga line I made trying to fry as many zombies at once as possible.

[Bisqwit]

I also wish to point out that zombies are not the only enemies encountered in towns.

It would be possible to change Simon's palette without it affecting the palette for the half and full hearts, by using the same trick that I did for the townsfolk in 2.6.1. But I see no reason to do such a change. Similarly for the HP bar.

Bregalad, if you want to do it, just redraw the half-heart sprite in VROM pages 1,3,5,7,9,10 and 12: Swap colors 2 and 3 in each pixel, and change the sprite descriptors for heart2 and heart3 to use palette 1. The data is in bank 0:

Code Select Expand

$B368 SpriteData_Pose8C_Heart2   .byte $01, $E8,$57,$00,$FC
$B36D SpriteData_Pose8D_Heart3   .byte $02, $F0,$57,$00,$F8, $F0,$57,$40,$00You will have to add +1 to the third byte on both rows and the seventh byte on the second row. This will fix the problem for your patch. (If you need ROM file offsets for the above memory offsets, they are $3378 and $337D respectively.)

[Fes]

There are no words for how awesome this is. Not only does the crossfade look great, but it doesn't even PAUSE THE GAME. Mind blown. The zombies dying in fire is hilarious, too. If the game were actually like this when it was released, I think it would be regarded quite differently than it is today.

[Vanya]

Also, digging in and out of the ground would be cool and all, but wouldn't work unless they were on the ground. If they were on stone platforms they'd be digging and rising into the stones. Stones that probably don't have room for the zombies to fit in.

The zombies in SotN didn't have any problem digging into the castle's stone floors. Also, with an animation like the one used in CV3 the zombie graphics don't have to fit in the floor anyway. Either way, I think the fade out in the original game is good enough. I just see it as a gaming idiosyncrasy.

I also wish to point out that zombies are not the only enemies encountered in towns.

The other enemies that appear in towns are crows (and maybe bats?), right? They can just fly away.
(Also, they aren't affected by daylight in a supernatural way, either.)


Now, more importantly, I have a small dialogue edit to suggest.
The Priests say this:
"Rest here
for a while.
In the name
of Father,
Son and
Holy Spirit,
amen."

I think he should say this:
"Rest here
for a while.
In the name
of the
Father, the
Son, and the
Holy Spirit,
amen."

This would be closer to the proper usage of the bible quote that a Priest of the period would use:
http://en.wikipedia.org/wiki/Trinitarian_formula
The main point being that each component of the trinity is conceptually a singular and unique entity in all of creation.

EDIT:

When I exit from saving, Simon jumps when I return to the game.
Also, shouldn't the actors and Simon not be displayed when they are in front of the dialogue box? Because sometimes they're in the way.

My observations while playing:

*In towns at night it would be a nice touch to make the open doors close so they don't look like you can enter them. perhaps bank swapping could be used to accomplish this.

*This might alter game play, but I really think it would be better if you gained experience from destroying enemies instead of from collecting hearts. Since you kill enemies a lot more often you'd need to either reduce the amount of exp enemies give, increase the exp needed to level up, or both.

*For initiating dialogue, maybe put in a check to see if the up button is being pressed so that dialogue doesn't interrupt my searching for breakable blocks with my holy water or my general dicking around with sub-weapons.

*In the status dialogue use a whip icon instead of writing out the word like how you did on the save screen. It's more consistent and looks better than abbreviating words. "@ Leather" > "Leath.Whip".

*Activating the clues menu with the left and right arrows seems a little counter intuitive. Consider using the B button instead. I imagine this might trigger a whip attack upon exit like the issue with the save menu. Also, consider change the clue activation button from start to B as well. This is even more counter intuitive. Same for the save screen, and everywhere else really. B button should be confirm, and A should be cancel as a rule of thumb.

*This is definitely a game play change, and nothing more than a pet peeve of mine, but... The bone chucking skeletons... Don't like 'em. First off, the bones burst into flames like the holy water should be doing. Remove this. Let them go through solid blocks like in CV1. This would make them more dangerous when they are above you. Also, remove the shield. The bone chucking skeletons in other games never use shields. Furthermore, the Skeleton Soldiers should have more HP than the bone chucking skeletons since they are less dangerous and have armor.

*Another optional enhancement might be to give town interiors a different tile set so it looks different from the outside.

*To fix the issue with skipping the clue book dialogues the simplest thing would be to change the behavior of the text scroll. Right now pressing B cancels out of the dialogue box. Most games have this functionality, but with an extra layer of protection. The way I think it should work is that pressing the B button should instantly fill out all the text and and not cancel the dialogue ever. This would prevent accidentally skipping any text when you just want it to appear quicker. Cancelling the dialogue should be a function of the A button.

*Consider changing the dialogue for the gypsy people that appear and give you stuff after they give it to you. This chick in Carmilla Cemetery keeps giving me Silver Knives when I talk to her, but I only have one.