News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - darkmoon2321

Pages: [1]
ROM Hacking Discussion / MMC3 IRQ Problem
« on: September 19, 2018, 02:39:15 am »
As part of the Deadpool hack of Ninja Gaiden, I've converted the game from MMC1 to MMC3 and am now using IRQs to trigger the split screen effects rather than sprite 0 hit detection.  For the most part, things are working fine.  However, in one stage I implemented parallax scrolling, which looks perfect in FCEUX but has issues on more accurate emulators and on real hardware with an Everdrive/Powerpak.  The problem is that sometimes the screen will appear to shake, shifting up and down by a single pixel.  With some help from the beta testers I was able to determine that the shifting coincides with a palette change.  Regarding the MMC3 IRQ counter, from Nesdev:

The counter is clocked on each rising edge of PPU A12, no matter what caused it, so it is possible to (intentionally or not) clock the counter by writing to $2006, regardless of whether PPU is/is not rendering.

It is normal for the game to write to $2006 during NMI when setting the address to update for the status bar on that frame.  But sometimes I write to $2006 when manually updating specific tiles or palettes during NMI also.  Will doing this always result in the IRQ triggering a scanline early?  Also, is there a fix for this other than going back to a sprite 0 hit?  I could also create a "hacky" fix that changes the IRQ reload counter based on whether I'm transmitting other data to the PPU on that frame.  However this will probably cause the screen shaking to occur when playing on FCEUX instead.  Also, I don't notice any additional screen shaking due to scrolling, despite the fact that loading new level data results in several writes to $2006.

This is a project I've been working on for a few months, and I have made some good progress on it:

The main window isn't a whole lot to look at right now, but it already allows you to edit the scene scripting through importing and exporting of the data to text files.  Here's an example of what the scene scripting looks like after it has been exported:

Scripting edited via the text files can then be imported back into the ROM and saved.  I have plans to incorporate editing into the GUI itself rather than using txt files, but for now it works well enough to change all aspects of the scene scripting.  It took me a long time to be able to handle all the quirks in the scripting language for the scenes in this game, but it seems to be working pretty well now.  Editing of backgrounds, objects/sprites, and dynamically loaded background images is going to be handled in separate dialog windows.  The background editor is currently functional:

The sprites/OBJ editor window is only partially done currently, and I haven't started the editor dialog for the dynamic background images yet, although they can be viewed in the folder with the ROM after using the "Export All Data" button.  After the image editing dialogs are complete, the plan is to allow editing the scene scripting from within the main window itself and then create a preview pane where you can view parts of the scene to verify the changes you made.  I initially started this project to improve on the quality of the cut-scenes in the Deadpool NG hack, so I have a few extra script commands built into the editor that I created for that hack.  However this editor is fully compatible with the original NG as well.  To prevent any confusion, I will most likely do a separate build without the extra commands, although there is no harm in attempting to use them in the original game (doing so has the same effect as using the "blackout" command).

I have plenty of experience hacking ROMs and making command line utilities, but making a GUI editor is pretty new to me, so I could use some opinions/advice.  In particular, the background editor may be functional, but I'm not happy with the appearance/layout.  I can put some labels on the clipboard viewer and tile viewer, but I still don't really like the way it's organized.  The "Recommend Colors" button makes a popup appear and suggest colors to use to best match the image currently on the clipboard.  I originally wanted it to automatically set the palettes to best match the clipboard image, but the results weren't turning out well, so for the moment I left it up to user discretion on how to set the colors after presenting the recommended ones.  Copying and pasting an external image into the editor DOES work, and matches as well as it can to the current palette, so long as there are enough free tiles in the CHR page to use.  Ctrl+C and Ctrl+V are used for copy and paste operations, and Ctrl+Z / Ctrl+Shift+Z undo/redo actions.  It feels natural to use for me, although relying on keyboard shortcuts without presenting a button or menu interface for the user to see the controls may not be best practice.  There is a "stamp" mode radio button that you can use to paste images directly into the background arrangement with only a click though.  The "show used" checkbox overlays a partially transparent image onto the CHR page showing the usage of tiles: green is unused, orange is used only by the current image, and red is shared or used by other images.

Any feedback is appreciated.

ROM Hacking Discussion / Wizardry V Switch Screen Opinion
« on: January 08, 2017, 04:20:20 pm »
I'm working on a little hack to make the Japanese version of Wizardry V more friendly to English players.  There is an existing English only version of the game, but it is highly censored, both in the graphics and text.  The Japanese version already contains both English and Japanese versions of almost all text, but the switch/options menu was mostly untranslated:

I've replaced this menu with a much simpler text only interface:

The first five options in the original Japanese menu each changed different parts of the game's text from English to Japanese.  I've simplified this into a single option that converts all the text.  The existing English version of the game, while still containing much of the original Japanese text in the ROM, does not have the option to display the Japanese text:

The menu looks better than mine, but is missing the English/Japanese option.  I could have just copied over the menu from the English game, but it just feels weird to remove functionality from a game.  Would it be better just to go this route?  Japanese players already have an uncensored version of the game designed for them, so it wouldn't really prevent anybody from experiencing the game.  I also looked at porting the uncensored content to the existing English version, but moving the graphics to make everything fit would result in a huge patch size.  The final option would be to mimic the English menu but add the additional language option.  This would probably look a little strange, as the font size would either have to be very small to fit within the boxes, or I would have to abbreviate "English" to "Eng." and "Japanese" to "Jap."

Note: I'm not removing the ability to change the background color, I just haven't added the text back in for it yet.

ROM Hacking Discussion / SNES Scripting and Code Compression
« on: April 22, 2016, 09:56:14 am »
I'm currently working on a fork of bsnes-plus that outputs a text file with a full disassembly of all executed SNES code, as well as descriptions for game script.  I designed it to work with Romance of the Three Kingdoms II, but I'm trying to modify it to make it more game independent.  It works nearly flawlessly with Rotk2, and I'm testing on Secret of Evermore now, but I have some questions.

First off, I've heard talk of both scripting and compressed code.  Is there really a difference?  I would imagine that the compression procedures used for graphics and such would be pretty terrible at compressing code.  Logically scripting would be the most effective way to reduce the size of code.  By scripting, I'm referring to using a series of sequential ROM values that are used to determine the destinations of one of the indirect jmp/jsr opcodes.  So kind of like reading a series of indexes to a function pointer array, in the SNES way.  As far as I can tell, there isn't really very clear terminology for discussing the subject.  Games that use scripting run a lot like emulators, where each "opcode" is part of a totally new instruction set.  I've been referring to them as "script commands" to differentiate, although I'd love to know if there is better existing terminology to use.

Second, does anybody know of any examples of games that use scripting OR otherwise compressed code?  I know Rotk2, SoE, and some more Koei games use scripting, but I'm sure there are more.  Is there any game that uses a compression procedure other than scripting for code?

Pages: [1]