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 - RedGuy

Pages: [1]
Personal Projects / Contra3 Editor
« on: October 05, 2016, 12:14:11 am »
Konami used the same base engine for Contra3 (and Gradius3) as Castlevania4 so I started adding some support for C3 to the SCV4 editor.  The editor is not in a useable state, yet, as it takes a good amount of time to understand the differences between the games and find all the ROM addresses for various things.  I'd like to add support for basic event and scene/block/tile editing for the non-mode7 levels.  However, the development will be slow.  There's no usable editor to share right now, but people may want to take a look at the uncompressed tiles.  Here's a link to the utility that will expand a US ROM (1MB, CRC32 - 84DA7CFE).  The decompressed data can be found in the 2MB-4MB range.

ROM Hacking Discussion / pseudo random number generators
« on: August 18, 2016, 12:08:29 am »
I started looking at the Super Castlevania IV pseudo random number generator to see if it's possible to make the game "more" random or at least a different type of random that's less repeatable.  That got me into reading about LFSRs, LCGs, and other PRNGs.  I also looked at SMW and MMX2 to see what they do with their PRNG.

SCV4 - Has a 16b LFSR that is left shifted by 1 and then XORed with $2125 if the output bit is 0.  It carries the output into another 16b value in memory which is also used in certain functions that need a random sample.  This actually is a bad mask for a typical LFSR as gets into the illegal state pretty quickly.  But it compensates when this happens by reseeding with the global frame counter.  It also seems to step the LFSR a fixed number of times per frame, but then certain enemies (skeletons?) it also steps for AI.  So this adds some variability based on how the player works.

MMX2 - 16b PRNG with gets seeded with $D37.  LCG-like except the adder isn't constant.  The equation is something like the following.
X[15:0] = (3 * X[15:0] & $FF00) + ((((3 * X[15:0]) >> 8) + X[7:0]) & 0xFF)

The lower 8b are a sum of the upper 8bits post multiply and the original low order 8bits without a carry.  The period is pretty long @ ~43.5k and it never gets in an illegal state.  Like SCV4, this will get stepped a variable number of times depending on what's going on in the game.

SMW - Has a 8b LCG and separate 8b LFSR (fibonacci, XNOR).  They both are stepped together, XORed to form the upper 8b of the random number, and then the step and XOR is repeated for the lower 8b.
LCG[7:0] = 5 * LCG[7:0] + 1
LFSR[7:0] = ((LFSR[7:0] << 1) | (LFSR[7] XNOR LFSR[4]))

X[15:8] = (LCG_0[7:0] ^ LFSR_0[7:0])
X[7:0] = (LCG_1[7:0] ^ LFSR_1[7:0])

There are two things I'm interested in looking at:
1) Having a different PRNG that provides good random information (in the bits that the game uses) with a sufficient period.
2) Seeding (and possibly reseeding) the PRNG to make the sequence change.

Reading up on PRNG theory got me thinking that how the game uses the bits is probably more important then picking a theoretically "good" PRNG.  And the SNES has limited processing time to produce the next number in the sequence which limits what can be used.  So maybe something as simple as picking another mask in SCV4 could make a noticeable difference without changing the entire function.

The more interesting thing is probably (2) and how to seed (reseed) with different values to change the game behavior.  Using stuff like controller input history, time spent in menus, and maybe even the name entered to the game might be interesting ways to change the game behavior.  The game already does some of that as the frame counter starts counting on the name entering screen and doesn't get reset.  Any ideas on how to produce unique seeds?  Anyone look into PRNGs and/or have some ideas to share?

Personal Projects / Super Castlevania 4 Randomizer
« on: August 14, 2016, 06:36:41 pm »

SCV4Randomizer is able to randomize the following things in Super Castlevania IV:
- Simon's health
- Enemy health
- Level (room) order
- Level timers
- Candle drops

There is some limited control over the randomization:
- Difficulty
- Type (static/dynamic)
- On/Off controls

It's a work in progress and likely has bugs.  It uses the same base code as the editor to expand the ROM which will hopefully lead to some form of level platforming randomizations.

The level reordering was a little painful to implement since the game has 10+ places it makes a custom change to the level number.  So all of those had to be found and rewritten to use the randomized stage transitions.  Randomization can be done all pre game or also use the in game RNG.  Static decides randomized value before the game starts and saves it in the ROM.  Dynamic uses the in-game LFSR-based pseudo random number generator to further randomize a few things (candle drops, enemy health).  The dynamic randomization needs some improvement and that's the idea behind the "Random Function" checkbox which hasn't been implemented yet.

The difficulty level is a general set of rules applied when randomizing.  They currently have a limited effect which needs to be rebalanced when more things are randomized.

The seed is a 32-bit starting value for the randomization engine in the randomizer.  That combined with the version of the editor and the values of the check boxes forms a code after randomization.  This code can be entered into the same version of the editor (File->Enter Code) to produce identical results.  Setting the seed alone is not sufficient.

(Select settings)

source -

Personal Projects / SC4ED - Super Castlevania 4 Editor
« on: May 07, 2016, 09:25:50 pm »
What was supposed to be a two day break from the mmx editor turned into a week long hack to start a Super Castlevania 4 editor.  It's not much right now, but there's enough to display one (hardcoded) level segment.  It also only loads BG0.  Since I borrowed the mmx editor code the emulator works as-is and you can see a paused screen in the picture below.

A lot of data in the ROM is compressed.  Much more than mmx which only really compressed tiles.  It has a decompression routine that looks at control words in the stream to: (a) decompress LZ, (b) copy the input stream, (c) zero extend 8b to 16b, (d) decompress RLE using a byte in the input stream, or (e) decompress RLE using 0.  This wasn't too difficult to understand and code up.  I haven't coded a compressor, but that shouldn't be too bad.

I couldn't find any previous work on SC4 and had to look through traces to figure most of it out.  If anyone knows of some documentation on the ROM/RAM layout or really anything about the game I would appreciate a link.

ROM Hacking Discussion / mmx 1-3
« on: February 23, 2016, 09:02:18 pm »
I didn't see a recent thread on mmx (megaman X) 1-3 hacking so I figured I start a new one up.

I've been trying to work out how the object (mainly enemy) properties are stored.  I figured it would be useful to be able to modify them in a gui MMX editor.  There's another post about where active objects are stored in RAM so I tracked back to how they are setup.  Looks like it's a series of jump tables (switch statements?) indexed by Id as well as state to say if the object is already active.  Unfortunately, it's not a simple table reference as things like HP and damage modifier are loaded as constants into A and stored to the correct offset into RAM.  I've made a real basic hack to following the jump table and string match for the LDA and STA operations.  Any better ideas on how to approach this?

The RAM stores what looks like 64B entries with things like xpos, ypos, current hp, damage modifier, sprite frame info, and a lot of other information.  Some of them come from constants.  Some of them look like preprocessed state of other values in the entry to speed up execution.  Has anyone worked through what all of these mean?

Pages: [1]