Posting this thread to accommodate discussion about the multilingual enhancement project of Simon's Quest that I released in late 2012.These two come from the same hack & source tree, so it is natural to discuss them together.

Project goals:-- In translation, to be as faithful as possible to the original Japanese design and content of the game-- To provide as clear, natural and understandable dialog as possible within faithfulness to the original game-- To improve the game with extra features and bugfixes that enhance the playing experience without compromising the game's design

Key features of my translation:-- Professional quality. No silly graveyard ducks. Loyal to original Japanese text, with minor improvements.-- Serif font as evidently intended by original development team-- Increased dialog box size / density allows for better text-- Multitarget---- NTSC and PAL can both be patched---- Mapper support: MMC1, VRC6, MMC3, MMC4, MMC5 and UNROM. Game is changed accordingly. MMC4 recommended, but other options are provided for hardware testing on various donor PCBs. Support for changing to use VRAM instead of VROM.-- Individual patch features can be changed---- The in-game map---- Dialog extensions---- Password extensions---- Ending and intro screen extensions---- Saving/loading of game state---- Much more

Known feature-specific bugs (as of version 2.9.8.19):-- In some situations, zombies can appear in towns before the townspeople have done disappearing [If palette fader enabled] (image)-- If you die while the day/night transition is in progress, the new music starts playing while Simon is dead [If palette fader enabled]

Known language-specific bugs (as of version 2.9.8.19):-- [Japanese]The prologue is in English (both versions).-- [Japanese]The ending is in English.-- [Japanese]The password screen is in English.

Original game bugs that have been fixed:-- The underline on password screen was in wrong position in PAL version. (image)-- Missing graphics pieces on the title screen. (image)-- Wrong hitboxes for signposts in some towns.-- Status screen cursor stopping over lines that contain no items, causing a lost cursor phenomenon.-- Not being able to spawn water or dagger if there's some other weapon in object slot #3 on screen, such as garlic.

Known bugs from the original game still remaining:-- When holding a morning star or a chain whip, in one of the animation poses Simon's hand is flashing along with the whip. (image)-- Simon can fall through floors by using a weapon at the right time when falling from two-brick ledge. (image)-- Simon can jump up three-brick tall obstacles by using a weapon at the right time. [Not present in FDS version] (image)-- When returning to the gameover screen from the password screen, the palette for the heart icon is wrong. (image)-- The ferryman does not stop at the opposite shore. (image)-- Open doors in towns do not close at nights, though you cannot enter them. (image)-- Orbs in mansions reappear even if you have collected them once.-- Cluebooks reappear even if you have collected them once.-- Gift-giving NPCs happily give you the same item twice, even if it is a non-consumable item.-- Town signposts become disabled when day/night changes. [Fixed if you enable palette-fader]-- If you fall from a great height and then jump to the screen's edge, so that the scene changes before the screen has fully scrolled vertically, you may end up inside a wall or under the floor. (image)-- If you do not have any items in some category, the cursor on the status screen can disappear and be tricky to locate.-- When entering the castle ruins, the screen scrolls down even before you have broke the bricks at the right side of the screen. Architecture of this scene suggests that this is not intentional. It was meant to use the "only scroll down when Simon hits the bottom of the screen" trick that is also found in those houses that have secret vendors.

This enhancement patch is multilingual. It is completely provided in the following languages: Finnish, English, French, Japanese, Tagalog/Filipino.-- If you want to contribute a new language, contact me!

I just finished the game using this patch at the instant, and it's very well done.

HOWEVER there is quite a few glitches. The password screen is glitchy, and some texboxes leaves attribute clashes after they are closed. This is especially noticeable when talking to your "friends" when they "refuse" to exchange their crystals -- or rather, in this version, gemstones --- with yours.

I used the patch which is on RHDN.

The map is a cool feature it's sad that it's somewhat glitchy, but it looks cool anyways and is a great addition to the game.

Also, it's hard to know how hard it would have been to beat the game with the "clues" as they are in, because once you know how to beat the game, you can't forget. I just vaguely remember the first time I played it I was raging and had no idea where to go to continue. I guess I was stuck at the part where you have to show the heart to the ferryman, since there is no clue to this.I was hoping to meet this stupid girl at midnight... man I was being tricked.

Thanks for the testing Bregalad!- Confirmed the problem with "your password is" screen in English version. Fixed in version 1.2.6!- Can you elaborate on the glitches of the map? Which version did you use, including the chipset? The patch on RHDN was updated at a point. You can see the version on the title screen. The VRC6 version should be completely artifactless for what I know. Which emulator did you use?- Can you provide examples of the attribute clashes? I have never seen such a glitch in this. Now there was a problem with the crystal trader's dialog, namely a line was one character too long, but it did not overflow into background scene, and it was now fixed in version 1.2.6.- Now about the "clues"... Well, I went through all the clues in the game and have verified that every secret is at least somehow hinted in the original game's dialog, and I carried that fact into the translation too. The ferryman one may be the most difficult one, but it is hinted to in two NPC dialog pieces and two distinct clues. You must piece it together. Compared to e.g. the whirlwind which is stated straight in one of the clues, or the deal with the lakes which is similarly explained in one of the clues.

I used the very first patch that was uploaded here. If it was updated since, all what I said might have been fixed. The mapper is still MMC1 like the original. I use Nestopia.The music is glitchy, and the graphics too, sometimes the screen flickers and shows apparent garbage for a frame when scrolling.

Since then NES doesn't have enough tiles to show on the screen at once I guess you had to do some advanced trick to switch CHR-ROM banks midframe, and this could be where the glitches are from.However, if there is a single split point, it could be done without glitches quite easily with a single sprite zero hit. Also has the advantage to work on both NTSC and PAL without code changes, and the DMC-DMA would not mess the timing.

The map screen is split in five pieces, with four CHR-ROM banks being used for the screen, plus a few sprites in the adjacent bank to complement some colors.- First piece: Title. Scrolling is fixed. CHR mappings $34000, $36000.- Second piece: Scrolling enabled. CHR mappings unchanged.- Third piece: CHR mappings $36000, $34000. (Done by simply writing to $2000)- Fourth piece: CHR mappings $35000, $37000.- Fifth piece: CHR mappings $37000, $35000. (Done by simply writing to $2000) $37000 also includes the map screen font.

I have not been able to get sprite zero hit testing working for some reason, so I just use cycle-precise loops, that are timed separately for all the different chipset&variant options.Any flickering & garbage issues are caused by situations where NMI occurs during mapper reprogramming. While VRC6 can be reprogrammed in a nearly atomic manner, MMC1 and MMC3 cannot. Both require a separate write for command and data. It is not a problem in most of the game, because when an NMI is entered during NMI, some part of the code is just skipped. In the map however, if the rendering is skipped during NMI re-entry, it will cause other kinds of visual problems. Every frame must be rendered. So far I do not know a workaround to this problem.

DMC is disabled at the beginning of each NMI in order to minimize how much it messes up with the timing loops. Small pieces of DMC samples still leak through, and this is fine. This effect reminds me of the pause screen in Super Mario Bros. 2 (USA). Aside from disabling DMC, there should not be any glitch to the music. Was this the only thing you were referring to?

There is also a slight error in the sprites on the map screen which are updated at one frame delay compared to the screen scrolling. This is minor enough that unless it becomes incredibly convenient to fix, I will let it be.

That's a lot of splits, but now that I think the map is full screen, and even more than that since it can be scrolled, it can't be avoided.I'd do it all with mapper switch (instead of mixing up mapper switches and writes to $2000) just for consistency though. Just a matter of personal opinion.

I don't think it's OK to keep the music as it's now. It really sounds strange and buggy. You should either properly disable DMC, or leave it completely enabled.

It is not easy but possible to have a timing loop that works even when DMC is enabled. For that you need to determine whether DMC is enabled by reading $4015, and kill some extra cycles if it's disabled, to compensate for this fact. However to get it right you'd probably need a lot of trial and error - just to say this is perfectly possible without a mapper IRQ.

I understand how the glitches works - of course you can't forget to "render" the map or it'll be glitchy. The only solution is to make sure that it never lags, that is the calculations are always finished before the frame.Of course you can only do the calculations during the "fifth piece", which makes it very challenging. You should probably just optimize the assembly code that does the logic, etc... to take minimal time. You could do it in the other pieces if the calculation time is constant, but then it will be incompatible with the DMC compensation.

It's weird you didn't get sprite zero working, especially if sprites work. You should make sure a non-transparent sprite pixel collide with a non-transparent BG pixel, and not on the right-most pixel of the screen.

Anyways, this map is great and is a cool addition to the game. It's just a shame it looks so buggy right now.

It is not easy but possible to have a timing loop that works even when DMC is enabled. For that you need to determine whether DMC is enabled by reading $4015, and kill some extra cycles if it's disabled, to compensate for this fact. However to get it right you'd probably need a lot of trial and error - just to say this is perfectly possible without a mapper IRQ.

My delay code in fact checks a RAM variable set by the music engine to indicate the presence of an active DMC sample. The problem was it was not fine-grained enough. The actual amount how much the DMC slows down the code depends on e.g. sample length and pitch, which cannot be easily accounted for.

I should however check the possibility of using MMC3 scanline counter on MMC3... Which would require me to hook the IRQ though.

Quote

The only solution is to make sure that it never lags, that is the calculations are always finished before the frame.Of course you can only do the calculations during the "fifth piece", which makes it very challenging. You should probably just optimize the assembly code that does the logic, etc... to take minimal time. You could do it in the other pieces if the calculation time is constant, but then it will be incompatible with the DMC compensation.

Yeah, the input handler should be optimizable a bit, and the part that offsets the sprites horizontally.I don't know how long a timeslice the music engine requires.

You're right, Simon's Quest only have 2 DMC samples but both aren't at the same rate... you could either hack them so they're at the same rate but the music would sound different, or have a way to know which sample is playing and have 2 different compensations for that... which would not be easy I admit.It is fine-grained enough if you check for $4015 regularly, like every scan line or so. Of course it takes 100% of the CPU time.

No, that's not where I saw it. When I machine translated your webpage I thought it might have been talking about that but wasn't sure.

Anyway, I don't know if you are gonna add scrolling to the map screen but that would be a nice addition. Another good addition would be either to have a moving cursor, or be able to use the dpad to move the position and see where everything is at. Say moving left highlights the location to the left such as a town or forrest. Then it'd show the name and you'd know how to get there. You could move all over the map to see where something is and you wouldnt have to walk somewhere to know where a location is.

Anyway, I don't know if you are gonna add scrolling to the map screen but that would be a nice addition. Another good addition would be either to have a moving cursor, or be able to use the dpad to move the position and see where everything is at. Say moving left highlights the location to the left such as a town or forrest. Then it'd show the name and you'd know how to get there. You could move all over the map to see where something is and you wouldnt have to walk somewhere to know where a location is.

Huh? It already has a cursor that you can move around, and you can scroll the view even without moving the cursor. You just don't quite see that in the still screenshots.

Bregalad, do you have idea how large a slowdown I should be expecting from the DMC? Even better if there is an accurate calculation. As in, from 10000 cycles by average 200 cycles are eaten by DMC.

If you have the available colors you should really turn those dots red or some other prominent color. The color you are using don't stand out at all. If you have the available tiles add a box around where the cursor is right then too. Also red.

If you have the available colors you should really turn those dots red or some other prominent color. The color you are using don't stand out at all. If you have the available tiles add a box around where the cursor is right then too. Also red.

I experimented with different colors from the available selection when I designed this, and came to the conclusion that it is good if the little dots don't stand that much. There is very little information value to them after all. But for the cursor, the problem is real.I don't have any spare colors, so I am just using whatever happens to be the most striking palette and going with it. I agree the cursor could be larger. There are really no spare tiles, but the algorithm can be worked to generate graphics on any number of tiles, so technically it could be done. I will have to research the cursors in different games and see what might work best on this background.

; Sound_PCMsampleActive may be: ; #$00 = no PCM sound ; #$5D = something 0E 7F F3 17 WaveLength=71 or 65, Count=$7F, Addr=$FCC0, Len=369 (ends at $FE31) ; #$5E = something 0F 00 F0 0B WaveLength=53 or 49, Count=$00, Addr=$FC00, Len=177 (ends at $FCB1) ; #$5F = something 0F 00 F9 0A WaveLength=53 or 49, Count=$00, Addr=$FE40, Len=161 (ends at $FEE1)If the sample # is $5D, the DMA will steal 4 cycles every 8*71 cycles (1 per 142). Right?Otherwise, it will steal 4 cycles every 8*53 cycles (1 per 106).This means that in order to delay 142 cycles, I actually need to delay 141 cycles (when sample $5D is playing). This is what I am trying now, but the results are not what I hoped they would be. The timings are off. Can someone point out what I may be missing?

The source code of the delay routine is at: http://pastebin.com/BPp259KNEDIT: Cycle counting failure. Found the bugs. It starts looking quite nice...

Something that struck me when playing. The signs in town read "Left" to here and "Right" to there. It would make more since if these read "West" and "East". Especially since the new map also follows these directions.

Something that struck me when playing. The signs in town read "Left" to here and "Right" to there. It would make more since if these read "West" and "East". Especially since the new map also follows these directions.

The thing is, West and East are not the same as Left and Right. In some towns (on the south of the map), west is on the left. In others (on the north of the map), it is on the right.When you look at a sign, you want to know immediately which direction to head to, without having to also consult a compass or a GPS.

December 20, 2012, 12:27:05 am - (Auto Merged - Double Posts are not allowed before 7 days.)It appears that the primary cause of the lag is the music engine. The last split point is so low on the screen, that the music code that is processed after it cannot entirely finish before new NMI occurs. Even if I replace all the input & scrolling handling with a mere "rts", fceux still registers lag at a pace that matches the music.EDIT: Well, that, or the sprite update code :-) Anyone have ideas how to make this faster?

As someone with multiple major products involving the CV2 engine, I could make use of these adjustments. I remember finding and debugging a glitch that made the game display the incorrect colors at times, but I lost my notes on it in a flash drive failure before I enacted on it, and started avoiding the glitch by avoiding certain palette patterns (which is apparently something the designers of the game did when making CV2).

The game slows a lot while scrolling and a bunch of sprites are on screen, but this could be like any normal NES game's problem. But also likely, I'm adding a crap load of code that slows down the game.

As someone with multiple major products involving the CV2 engine, I could make use of these adjustments. I remember finding and debugging a glitch that made the game display the incorrect colors at times, but I lost my notes on it in a flash drive failure before I enacted on it, and started avoiding the glitch by avoiding certain palette patterns (which is apparently something the designers of the game did when making CV2).

The game slows a lot while scrolling and a bunch of sprites are on screen, but this could be like any normal NES game's problem. But also likely, I'm adding a crap load of code that slows down the game.

Ah. Sounds like you utilized the PPU transfer queue mechanism built into the game. Yes, there is a certain protocol in that array. I am skipping all of that and basically reimplementing the wheel, using my own PPU transfer routines etc. in the map viewer.

So you reverse engineered the level data. I tried that, but gave up soon. You don't happen to have the music data format also reverse engineered? I have it disassembled, but it has way too many "ifs" that control how the data is interpreted...

I think you got the calculations quite right, but for NTSC I get the preriods 72 and 54 from here : http://wiki.nesdev.com/w/index.php/APU_DMC. I don't know why you substracted them with 1. (not saying it's incorrect).For PAL it will be 66 and 50 respectively.I don't know if you got this working, but if you did it's really great. Keep in mind most emus will be inaccurate and will not simulate the DMC stealing cycles to the CPU. Only Nestopia and Nintendulator might emulate this correctly. I'm even pretty sure they only emulate NTSC correctly and have off-timings for PAL. I can always test whatever with my powerpak, as I have both a NTSC and PAL console, if this can be handy.

Of those 3 samples, one is probably the "dog barking" noise that Simon makes when he's hurt, so only 2 of them, kick and snare, are used for music.

awesome work Bisqwit , this goes way beyond a simple translation hack... once the remaining bugs get sorted it will be the ultimate CV2 version IMHO

I just finished building a mmc-3 based test cart with sockets made a mistake on the prg pins 30-31-32 but I was too bored atm to fix it, for now I just burned 1.27 and got it working just fine with some quick'n'dirty soldering

I don't know if you got this working, but if you did it's really great. Keep in mind most emus will be inaccurate and will not simulate the DMC stealing cycles to the CPU. Only Nestopia and Nintendulator might emulate this correctly. I'm even pretty sure they only emulate NTSC correctly and have off-timings for PAL. I can always test whatever with my powerpak, as I have both a NTSC and PAL console, if this can be handy.

The current progress is that I am seriously considering which one is a lesser evil: Graphical artifacts or audio artifacts.I managed to get the DMC-aware delay code right, but there's still some jitter of 12 cycles or so at some point. It doesn't help that the bank switching itself takes 76 cycles on VRC6, 72 cycles on MMC1 and 96 cycles on MMC3. The h-blank just isn't long enough to hide the whole switch, especially if there is a rocking of even 8 cycles back & forth -- which does happen because the bankswitching delay is not DMC-compensated for, and even in the delay loop the DMC can steal an unpredictable number of cycles depending on whether it hits store instructions or other instructions, and then a sprite-0-hit test is only accurate to 7 cycles granularity... Right, I also managed to get sprite-zero-hit working, which helps a lot at some point. I will post when there are news.

I just finished building a mmc-3 based test cart with sockets made a mistake on the prg pins 30-31-32 but I was too bored atm to fix it, for now I just burned 1.27 and got it working just fine with some quick'n'dirty soldering

Very cool!

EDIT: Okay. Released version 1.3.0. Please report to me what new problems it caused. The map now has DMC samples enabled on all mappers.