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.

Messages - AWJ

Pages: [1] 2 3 4 5 6
ROM Hacking Discussion / Re: SNES Scripting and Code Compression
« on: June 20, 2017, 08:50:18 am »
I've wanted for some time to look into transplanting the English script from the SNES version of Lord of Darkness to the Mega Drive port.

I'd be very surprised if any of the Mega Drive versions use this bytecode. The most likely reason these games were compiled to bytecode on the NES is because the 6502 is almost uniquely ill-suited to C, mainly due to having only a 256 byte stack. That isn't a problem with the 68000 at all.

ROM Hacking Discussion / Re: SNES Scripting and Code Compression
« on: June 16, 2017, 09:05:19 am »
Necrobumping this topic to link my own research into the bytecode found in Koei NES and early SNES games. Executive summary: the bytecode is almost certainly the output of a C compiler.

Here's one that wouldn't be easy... but I think it might be possible:

An MMC5 hack for NES Double Dragon 2 that takes advantage of separate sprite/BG CHR banks to allow different types of enemies to appear at the same time, and to allow weapons to persist between fights, like in the arcade version.

You'd have to rearrange all the sprites in the CHR ROM to work as 8x16 sprites, and put all the weapon sprites and the sprites that spilled over from the 8x16 conversion into a common bank. I'm not sure if you could make it all fit--most of the characters in DD2 are 40 pixels tall, so there might be quite a bit of wasted ROM space in 8x16 mode. You might need to use a dynamic banking scheme, where the sprite banks change with the pose each character is in and not just with which characters are present.

I dunno, I just think it'd be cool to see an MMC5 hack that uses the mapper for something more interesting than 1 MB PRG ROM.

That looks like incorrect nametable mirroring. The Retron5 probably uses a hash database to determine the mirroring for cartridges in which it's hardwired (e.g. all mapper 0/2/3 cartridges) and since your cartridge is a ROM hack its hash isn't in the device's database. The reason the hack works when run from a .nes file is that the .nes header specifies the mirroring.

I think it would be possible for a Retron5-like device to detect the correct mirroring for a cartridge that's plugged in, but that capability would have to be designed into the hardware from the outset--it's not something a firmware update could add retroactively.

The relevant posts got lost when the site went down, but someone was interested in the custom script dumper I made for Dragon Quest 4 (Famicom), so here it is:

The dumper works with either Python 2.7 or Python 3.3+. It outputs the script dump to stdout, so you should redirect the output to a text file, and you may have to set PYTHONIOENCODING=utf_8 (or whatever encoding you want the output to be) if you get an error about Unicode. If you want to disable the heuristic kana detection (DQ4 uses the same glyph for へ and ヘ and for り and リ), remove the call to prettify(), i.e. change prettify(decode(expand(sextet))) on line 263 to just decode(expand(sextet)).

Programming / Re: Locking HUD Movement on BG3?
« on: November 28, 2016, 12:47:09 am »
SMB3 doesn't work like SMB2. SMB2 scrolls the BG layers using the hardware registers while SMB3 always keeps BG1 fixed in hardware. So all 'scrolling' in SMB3 on that layer is done via regular tilemap/tiledata updates

Err, what? SNES SMB3 certainly does use the scroll registers. Simulating scrolling by redrawing the entire screen pixelwise every frame would be impossible without a coprocessor.

As for how the HUD is fixed in place in SMB3, it's done with an IRQ that rewrites the BG1 scroll registers on scanline 192... probably because that's how the NES version did it.

OP, are you trying to create a transparent HUD like SMB1 and SMW, or a fully opaque one like SMB3? If you want it to be transparent, you're probably going to have no choice but to use sprites. The thing is that SMB1 doesn't scroll vertically at all, and SMW only uses BG3 for graphics that don't scroll vertically, like the clouds outside the Ghost Houses, so in those games the HUD and the clouds never have to coexist on the same horizontal line. SMB2, on the other hand, uses BG3 for clouds everywhere, including the many areas that do scroll vertically. So if you put a HUD on BG3 it won't be able to coexist with the clouds. The clouds will just have to abruptly disappear at the top or bottom of the screen (whichever side you put the HUD on) which kinda spoils the whole "transparency" effect.

Thanks, the Wii game does sound really good so I'll probably check it out. I'd like to try Shiren the Wanderer and the PS1 game first though.

For me it feels great when you make proper tactical decisions in combat or can predict outcomes to some extent and be rewarded for it, not as much when it's pure luck.

AWJ: The first one, as pictured. Mine explosions do affect enemies but I guess the thing about equipment not carrying over to the bonus dungeon/hard mode wasn't a bug then. What was weird was that your wife talks about the vault, and then she discovers the box and that triggers the ending instead, then your items are all gone.

Thanks, I'll probably play Shiren (SNES) next.

Right, even in SNES Torneko monsters can be killed by landmine explosions if they're next to you when you set one off. You had me confused because in later games in the series there are items and abilities that render monsters directly vulnerable to traps, and I thought that was what you were talking about.

Yeah, things get a bit screwy in SNES Torneko if you beat the game before fully "evolving" the town. And IIRC when you retrieve the Box of Happiness for the first time and trigger the ending, you always lose the items that you were carrying in your winning run. But that's not what I meant by not being able to take vault items into the hard mode. Once you finish the game, you can play either the normal dungeon or the hard-mode dungeon, depending on whether the normal town music or the Box of Happiness music is playing when you leave the town. The normal dungeon works like before, but the hard-mode dungeon strips all your items and just gives you one bread each time you enter it.

If you've only played the SNES Torneko then you're in for a real treat with Shiren. It's vastly more complex and adds many mechanics that went on to become standard for the series. It's got jars that you can put items in to expand your inventory capacity, some of which have magical properties (like identifying or transforming items placed in them) It's got shops that you can buy from, sell unwanted items to or even steal from. It's got 50 set-piece puzzle dungeons that you can win items for solving. It's got themed post-game dungeons, one where you have to rely on traps to kill monsters (you can't take items into it and no directly offensive items are generated, but you start with the aforementioned item that makes monsters vulnerable to traps) and one where you have to rely on meat-conferred monster abilities (you start with a weapon that randomly turns killed monsters into meat) If Torneko is SNES Rogue, then Shiren is SNES Nethack.


I recently beat the main dungeon in the first one and I while I think it's pretty rough around the edges I liked it enough to want to try some other games in the series. What should I play next? I think I'm OK with untranslated if the game is playable without knowing japanese. I'm also interested in the Shiren the Wanderer games.

What I liked:
-The art style and overall tone of the game
-The interface and controls, for the most part (nice diablo-style mini-map and running/speed up feature)
-Finding more interesting uses for the items, like cloning specific monsters to get 2 of a specific loot item
-Monsters could get hurt by traps and kill each other, even leveling up
-In-game epilogue

Didn't like:
-Overly random difficulty and how a run could go to shit based on bad loot when you're quite far into the dungeon
-Automated shop/home expansion
-How the vault was introduced far in and you could only withdraw 2 items (by trading in the bread you get from your wife when you say bye to her, otherwise 1)
-Repetitive layouts and a lack of puzzles and hidden paths
-You could progress the story/shop expansion more than one step in one dungeon run and would then have to reload the save to make all the changes happen. There's even a bug where if you get the happiness box too early, all items (that you'd want to use for the bonus/hard mode dungeon) are lost before you can put them in the vault.
-Surprise attacks in corridors (inconsistent line of sight) and from traps (you don't get enough torch scrolls and swinging your sword to detect them gets tedious)

By "the first one", which game are you talking about? The first Torneko game is on the SNES, and some of the things you're saying don't apply to it (you can't take vault items into the hard-mode dungeon, and IIRC traps never affect monsters) Are you talking about the PS1 game?

Fuurai no Shiren gives you access to the vault right from the start of the game, and there's no limit on how many items you can take out of it (though, again, you can't take items into some post-game dungeons) It's got an original setting instead of a DQ-based one, but the art style and personality are similar to the Torneko games (and the music is by DQ's Koichi Sugiyama) You can play the SNES version or the DS remake--the remake has a tutorial and more post-game dungeons, but some of the balance changes are hit-or-miss (it adds some extremely annoying and borderline-unfair monsters from later games in the series) The big gimmick in Shiren that isn't in Torneko is that you can eat monster meat (obtainable by various means) and turn into that monster, allowing you use its special abilities but not to use any items until you change back (you keep the attack and defence power of your equipment but not any special properties)

I haven't played the Wii Shiren game but it doesn't have a good reputation; apparently it tries to combine Mystery Dungeon mechanics with a more conventional JRPG (e.g. a full party of controllable characters, and a story written by Masato Kato) and ends up neither fish nor fowl nor good red herring.

The monster-summoning visual effect uses raster IRQs, and will need to be reprogrammed to work with a different mapper such as MMC5. I remember when developing and testing the translation that that effect didn't display correctly in most 1990s NES emulators (e.g. Nesticle). I think LoopyNES was the first emulator to display it correctly (and also the ending text scroll--1990s emus only displayed half of the text)

Programming / Re: bSNES Issue *SOLVED*
« on: September 16, 2016, 02:51:07 pm »
I noticed another potential problem with your code: you're only setting the lower 8 bits of the dividend ($4204). If you're only doing an 8-bit / 8-bit division, you should do a STZ $4205 to clear out the upper byte.

Programming / Re: bSNES Issue
« on: September 16, 2016, 02:35:38 pm »
The SNES multiplier/divider isn't instantaneous. After writing the second operand and before reading the result, you have to wait 8 CPU cycles for a multiply and 16 CPU cycles for a divide. If you can't arrange your code to do useful work during the delay, you'll just have to insert 4 or 8 NOPs.

For instance, a common problem is when people seem to think they can just jump out of a function and write in their own DMA.  They don't realize that there's a thread that manages E/PI requests and it uses messaging to ensure that the device is not utilized until it's ready, delaying requests until they can be filled.  When you do things behind it's back you could sporadically execute a DMA when the device isn't ready, and the results range from bugginess to full-on crash.  Not fun to debug.  The alternative is to figure out which message queue takes requests and send it one.  It's foolproof and much lazier.

That sounds closely analogous to all those SNES translations that jump out of the original game's text printing routine and try to write the translated text directly into VRAM (which works on ZSNES, but not on real hardware or accurate emulators)

Personal Projects / Re: Final Fantasy II: Refurbished
« on: July 17, 2016, 10:46:13 am »
Anyone know if Square did any bug fixes for that compilation?

They fixed the ならかった typo in the opening text; apart from that, the FFII portion of the ROM is identical to the original, IIRC. The FFI portion has some but not all of the same graphic changes as the US version (e.g. the redrawn Beholder/Evil eye).

Programming / Re: Display graphic on the Snes
« on: June 11, 2016, 10:01:06 pm »
The problem is when I wrote to $2121 and $2122, it effects BG1 (the portrait) and BG3 (tex).
What should I do to seperate one palette for BG1 and one for BG3?

In mode 1, BG3 uses the first 32 colors in the palette. You need to make your BG1/BG2 tiles use a color attribute that doesn't overlap with the colors used by BG3 (i.e. 2 or greater).

Gaming Discussion / Re: Obscure FF3 NES questions
« on: June 10, 2016, 04:55:02 pm »
One cheap tactic you can use vs. Garuda is to make an all Dragoon party

That's not a "cheap tactic", that's what an NPC in the game specifically tells you to do. Just like another NPC tells you to make three black mages the first time you have to Mini your party.

Gaming Discussion / Re: Obscure FF3 NES questions
« on: June 09, 2016, 07:48:40 pm »
In the forced-mini dungeons, putting all characters in the back row works really well, nonsensical as it is. So does equipping shields in both hands for characters who can do so (evasion still works when you're mini)

FF3 has much less emphasis on elemental defence than other games in the series do. 90% of monsters in the game only do basic physical attacks. It's almost like the developers responsible for the battle system spent all their time on the job system and never got around to designing interesting enemies.

FF3 actually has both targeting modes, which is why I thought it was pretty modern for its time in this regard (I don't remember exactly which later FFs had group targeting+target all but not the SNES ones, right?).

Single/group/all targetting goes all the way back to Wizardry, the granddaddy of party-based CRPGs. In Wizardry it's fixed per spell--some spells affect one monster, some affect all of one type, a few high-level ones affect everything. Dragon Quest stuck with the Wizardry system (Blaze hits one, Firebal hits a group, Bang hits everything) FF1 simplified things by only having single and all, no group. FF2 allowed you to select between single and all (but with reduced effect) for any spell. FF3 added group targetting but put back per-spell restrictions (Raise can only target one, Meteo always targets all)  FF4 removed group targetting but otherwise kept FF3's system. Later games introduced random targetting (Roulette), level-based targetting (Lvl 5 Death) and everyone-on-both-sides targetting (FF6's version of Quake)

Programming / Re: 65816: Direct Page vs Absolute Operand
« on: May 23, 2016, 11:25:57 am »
Indexed addressing definitely can straddle banks on the 65816. The exception is indexed indirect jmp (jmp (jumptable,x)), where the pointer is fetched from the program bank rather than the data bank, and apparently it wraps within that bank (assuming bsnes is correct, and I believe its 65816 simulation has been extensively tested, down to edge cases like BCD arithmetic with illegal BCD values)

Programming / Re: 65816: Direct Page vs Absolute Operand
« on: May 22, 2016, 03:58:22 pm »
The only difference that I remember in practice, was that a lot of assemblers supported using square-brackets instead of braces for indirection, i.e. ...

Code: [Select]
  lda [$01],y

instead of

Code: [Select]
  lda ($01),y

This was seen as a good-idea by most progammers because it separated the syntax of expression-evaluation from indirection.

On the 65816, lda ($01),y and lda [$01],y are two different addressing modes. The first is indirect (dereferences a 16-bit pointer into the current DB), the second is indirect long (dereferences a 24-bit pointer).

Personal Projects / Re: Super Pitfall NES (improvements)
« on: May 09, 2016, 07:24:02 pm »
I think we are talking at cross-purposes. My point was that non-interrupt-safe code isn't at all limited to games written in compiled languages (DQ6 and Mega Man are both pretty definitely hand-written assembly language) and it isn't just outsourced shovelware games that have bugs.

Pages: [1] 2 3 4 5 6