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

Pages: [1] 2 3 4 5
Can you explain what the different colored boxes mean? I think you covered it in a previous thread, but it's not included anywhere in the program explanation (and there's no help file). I may edit this post to change after searching through this long forum thread.

With event editor open and selecting an event:
* Red Box - event trigger (X works on block boundary, Y works on pixel boundary of event position)

Event specific:
* Purple Lines - palette/graphics/tile dynamic changes.  If you click a graphics change the editor will attempt to let you know which enemies are loaded after the event: red - not loaded, green - loaded in the forwards direction of the event, yellow - loaded in the backwards direction of the event, blue - loaded in both directions of the event.  The subId is split into 2 nibbles that index into a table for forwards/backwards lookup depending on the direction X is traveling when crossing it.
* Green Boxes/Yellow Lines - Camera locks.  When event is triggered if X crosses into the green box then the camera bounds are changed to the yellow lines.

Event type.  If the editor doesn't know how to display them they end up being pink squares.  Most event types 0 and 1 show up this way.
* 0 - usually objects like powerups
* 1 - various scripted events
* 2 - palette/graphics/tile dynamic changes and camera locks
* 3 - enemies and some interactive objects like elevators and platforms

The editor uses windows API calls directly - probably because it was originally written many years ago.  I just searched API calls from the source and read Microsoft's documentation on them.  That coupled with running it in a debugger is how I learned.  I've played around with MFC (SCV4 Randomizer) and QT (bsnes-plus) since.  QT is pretty intuitive and there are plenty of examples available.

The executable is only at the link in my previous post.  I never got around to adding it to the github repository.

You're going to be disappointed about the comments - they are only slightly better than what was there originally.  Another thing to add to the list of things that should be redone/rewritten is the core library should provide a proper interface to modify the contents of the ROM.  A lot of the editor dialogs go in and directly modify the binary which makes it hard to maintain.  The SCV4 editor did a better job at this, but it still wasn't great.  With a solid core library to access the various data structures in the ROM you could then rewrite the GUI code and clean up a lot of the hacks.  I basically learned about snes architecture and rom hacking by working on the editor.   In the process I wrote some ugly code and it's way past the point of needing a rewrite.

The editor source isn't a good place to learn how the ROM works.  You're better off looking at traces and stepping in a debugging enabled emulator to look and match that with what the editor does.  There are a few people I know who are doing mmx1-3 hacks including Justin who can also probably help you understand the game engine.

I've lost time and interest in doing snes hacking for now so hopefully someone will pick this up and rewrite it in a more modern framework.  Major problems with it:
- Graphics should be decompressed in the expanded version (which should all be expanded to 4-6MB).  I wasted too much time trying to get everything to fit in the original locations.  It's too easy to break the ROM now.
- Game code changes should be written in ASM with help from an assembler to insert them rather than modifying the binary directly.
- Expanded ROM should be better planned out for what it needs to support.  Expanding things in later versions is a huge mess especially if people expect backwards compatibility.
- The editors dialog boxes have a lot of redundant code making them hard to maintain.

Here's the last version I compiled late last year.  Maybe it fixes the problems your observing:

The source is at:

Good luck to whoever takes it up.

Great work on the debugging features.  This is the first time I've tried any variant of bsnes and it along with the additional features have now become my new favorite snes tool.  Thanks for making the source code available.

The hotkey problem that Justin is having is due to how bsnes provides support for modifier as single keys.  The way it works right now is all modifiers work as single keys if you click the checkbox and any existing mappings that use modifier+key result in both pressed separately.  I added a temporary workaround that saves a single modifier key as both the modifier and the actual scancode pressed.  That looks to have solve the problem.  Now bsnes thinks you are pressing the modifier + another key (which happens to be itself).

I coded up a prototype memory location label tool which can be loaded/saved as an xml:

Personal Projects / Re: SC4ED - Super Castlevania 4 Editor
« on: November 01, 2016, 08:50:08 pm »
I need a break from the editor.  Contra 3 is heavily scripted making it more painful to make an editor for than CV4 or Gradius 3.  No real progress on Contra in this version.

Here's the latest version:

- Added some basic Gradius 3 editing.
- Fixed bugs related to entrances and exits in CV4.

Gradius 3 has the typical level editing stuff supported in the expanded version including events.  Tile collisions aren't editable as that was a lot of work in CV4 that I'm not ready to redo in Gradius or Contra.  One unique thing about Gradius is you have to manage WRAM for enemies yourself instead of having the game engine do it.  The SubId of type == 0 and type == 1 corresponds to the slot in WRAM.  Type == 0 will conditionally check the slot to see if it's in use, type == 1 will just overwrite it.  Some events require multiple slots (3 enemies, 5 enemies, multi-part enemies like the sand dragons, etc).  Some events look like they require specific slots like 0 for the sand dragon.  I attempted to write an automatic slot assignment code, but there are a lot of rules I don't know about so I commented it out the code for now.  Type == 3 are what I'd call sequence events which change music, level, speed, palettes, tiles, etc.  The editor tries to display the resulting change if you select these events with the event editor open.  It's nowhere near done, but with an expanded ROM it's possible to do basic hacks with some trial and error.

In CV4, even numbered entrances are considered "forward" when the game loads up events.  Odd numbered are considered "reverse".  This makes a difference for which direction you are traveling in for an entrance.

Personal Projects / Re: SC4ED - Super Castlevania 4 Editor
« on: October 26, 2016, 09:48:31 pm »
I don't have the patience or time to make an editor for another game, but I did put the latest source on github with basic contra3 and gradius3 support.  I know very little about the genesis/m68k instruction set and graphics processing.  The editor has a lot of snes assumptions in it.  The compression is probably just some variant of lzss, but who knows if they used the same control word encoding as the snes engine.  Maybe someone who has worked on genesis games can help out.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: October 09, 2016, 08:28:19 pm »

Changed default save file name to code.
Updated expanded ROM to use the latest version.
Fixed (attempted) room reverse problem.

Fixed rotating room entrance softlock bug.

Try that version.  I think it's fixed now and had to do with the way the reverse of the previous room (rotating) was being reversed.  Played through a few different randomized versions and didn't see the problem.

Personal Projects / Re: Contra3 Editor
« on: October 09, 2016, 03:27:12 pm »

Added basic tile, block and scene editing support
Added initial event editor.

Stage 1, 3, 4, and 6 will load up with varying graphics problems - more in the later stages.  The problem appears to be that the game reloads most/all tiles in VRAM to transition to bosses and mini bosses.  So the editor would need a way to support this probably through some keys to toggle between those transitions.

The tile, block, and scene editing is mostly untested.  I was able to make some basic changes to stage1.

Unfortunately, the events work completely different than SCV4.  You can't add or delete them, yet, but you can change some basic position and type parameters.  For example, Id=$F are the drops and for SubIds, $1=spread, $2=crush,$6=invincible bubble, $7=bomb, etc.  There are lots of custom events and the game is heavily scripted in parts.  Stage4 seems to be completely scripted and doesn't have individual events (or they are stored and executed differently).  The events look like they are grouped into $100 pixel wide groups and in the ROM are stored as relative positions to that.  The position of the scene is added to the xpos to make the absolute value shown in the editor.  The relative position of the event (negative vs positive) can determine which side of the screen it spawns on.  How exactly the events work is still a mystery, but it's possible to make some basic changes now with trial and error.

Personal Projects / Re: SC4ED - Super Castlevania 4 Editor
« on: October 09, 2016, 03:16:20 pm »

Added expanded camera locks
Added expanded exits and editing
Added expanded level transitions and editing
Added expanded entrances and editing
Added (experimental) level save/load support
Added volume control for internal editor (see internal editor settings)

Camera locks and entrances can be edited in the property editor after expanding the ROM.  The unexpanded ROM has 1-3 entrances per level and they are mostly hardcoded.  With the expanded ROM there is support for up to 8 entrances to a level (standard is typically 2) and they are fairly general.  I'm not sure if all the code that uses the entrance number in RAM has been updated so there may be some bugs with this.  If you startup the internal emulator move Simon to a spot in the level you can hit the record button in the property editor to overwrite the current entrance with the values in the emu.  This may require some manual customization on certain where custom entrances are used.

To transition between levels.
1) Spawn event with type=2, id=$15, subid = exitSubId  (some levels use custom events that require a hex editor to change, e.g. the first one with the drawbridge)
2) Check exitSubId against exit comparison
3) Use exitNum to find nextLevel and entranceNum in transition data
4) Start new level and load up all info using entranceNum including Simon's position, the camera positions, camera locks, etc

Saving off an individual level as a SCL file is now possible.  This was added to allow making new levels for the randomizer, but it may also be useful for other things.  This is experimental and likely to change in future versions of the editor.

Double-click right also moves an event now.

The expanded ROM layout will continue to change as more compressed regions are found and uncompressed regions get grouped together to facilitate editing.  So don't rely on data being in a specific location.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: October 06, 2016, 11:06:59 pm »
i cannot see your images, also the one in the OP...dont think google (drive) allows hotlinking. YOU can probably see them, but i dont think anyone of us.

also i meant 4-3 not 4-4, guess it has to do with mov speed idk

Fixed the images - picasa direct links are no longer valid for everyone.

Was 4-3 (the mode7 level with the dropping platforms and skeleton spawns) running forwards or reverse?  It can randomize the level to run in the opposite direction and you have to exit on the left.  The exit on the right is removed when that happens.  I couldn't reproduce it in of the randomizer in the forward or reverse direction, but it could be related to something else that wasn't randomized in my roms.

I moved the link to of the randomizer into the first post.  Here's where it probably would have helped if I saved the code somewhere in the filename to make it easy to reproduce.  I need to rewrite part of the randomizer after changing a bunch of things in the editor.  Once I do that I'll test it again and post a new version where it defaults the file name to the code.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: October 05, 2016, 12:25:34 am »
did u remove "items in walls" secrets? if not, how hard would it be to add completely new ones??

4-4 softlocked, couldnt exit to the right

suggestion: when clicking save, set the default filename to be the string containing the randomization details
can u edit/randomize whip attack speed? how awesome would it be to have a faster leather whip :D

With dynamic randomization of candles it changes the candles as well as the wall drops to be random based on the in-game pseudo random number generator.

In 4-4 (Koronot?) is the circled place in the following pic where you softlocked?  If so, make sure you are using the latest version of the randomizer posted and not the one linked in the first post.  With increased speed the randomizer fills in that gap so you can't get in there.  If that wasn't the softlock then where did it happen?  After killing Koronot it didn't advance?

I will make the default filename the randomization code.  That's a good idea.  As for the whip speed, I'll take a look at it sometime since several others have also asked for it.  Not sure how easy that will be to modify.

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.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: September 21, 2016, 10:16:47 pm »

Added more randomization.  The most notable thing is a lot more rooms can be randomized to play in reverse.

I'm realizing some of the randomization that was added may be more annoying than fun, but there are knobs to turn those things off.  You'll know what I mean if you play it...

Personal Projects / Re: SC4ED - Super Castlevania 4 Editor
« on: September 04, 2016, 04:45:45 pm »

- Added expanded events.
- Added support for adding/deleting events.
- Added expanded collision mapping tables with custom lookup code.
- Added support for editing whip properties and movement properties.
- Fixed various bugs (and probably introduced some)

There are still a lot to be figured about with events, but generally you can go to the event type you want to add/copy (0=enemy, 1=candle), click add and then change it to what you want, move it to where you want (middle mouse button will do this), and then click sort to reorder them properly.  Converting enemies to candles and candles to enemies requires some more work.  And type 2=custom events are not something you can just randomly add/delete without writing assembly.  Expanded events lets you put a total of 2800+ more events across all the levels.  There are likely other engine-specific limits when adding events.

Expanded collision supports lets you add a tile in a blank spot and assign it any collision property.  This required rewriting the collision checking code in the game so that it's not dependent on the order of the tiles.  That tile can then be added to a new block and the new block can be added to a scene.  I tested it by adding a new step type to a few different levels.  The game still relies on certain tiles to be in certain positions so don't expect to modify an arbitrary tile and have it work correctly.  Level 1 has custom collision lookup code for foreground/background.  Also, the mode7 rooms are all custom in how they deal with collisions.  You're on your own if you want to edit those.  Some levels don't have any spare room in the decompressed tile data.

A lot has changed with the new expanded ROM and I've attempted to check as much of it as possible, but it's likely to be buggy.

The expanded ROM layout will continue to change as more compressed regions are found and uncompressed regions get grouped together to facilitate editing.  So don't rely on data being in a specific location.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: August 28, 2016, 10:31:10 am »
Fixed corruption of Death's death code
Added limited randomization for Rowdain (no other bosses randomized, yet)
Added some randomization of ring (swing) acceleration

Great program, dude!  I'm glad to see somebody's making CV4 stuff.  Everything worked fine, except that the game would invariably crash immediately after beating Death.  I tried it on multiple seeds, same result.

Thanks for catching that.  There was a last minute change that had an address typo which corrupted Death's code.

Personal Projects / Re: Super Castlevania 4 Randomizer
« on: August 26, 2016, 09:47:43 pm »
Added randomization of Simon's speed, gravity (y acceleration), whip damage, whip length, a select set of enemy speeds, and a few other things.
Added death counter in place of player lives
Added reverse direction for some levels that support it without changes
Removed level timer
Fixed graphics reload bug when a later level (usually boss level) transitions to a level in that same stage
Fixed 4-4 softlock with extra speed

Simon's speed and acceleration isn't randomized by default since it has a significant change on how the game plays.  I had to remove the scripted movement Simon has when entering levels on stairs to avoid having him run into pits with higher speed.

The game engine supports a whip length of 1 link longer than the second chain whip without major modifications.  The randomizer forces the leather whip to be of that length and then randomizes the length of the two chain whips.  The whip upgrade is a random drop and will cycle back to the leather whip if it's collected 3 times.

Big thanks to DrunkenDraconian and others for testing several of the prior versions.  Also, big thanks to DarkSamus993 for working out a lot of the WRAM layout which I frequently referenced.

Boss AI/speed and enemy AI/speed is going to take some work and I'd really like to see those added next.  Event position, event type, and platforming randomization would also be cool, but will require a lot more work.

ROM Hacking Discussion / Re: pseudo random number generators
« on: August 19, 2016, 03:47:28 pm »
My plan was to combine all the seed generation techniques to generate seed.  So using the name (hashed version) is a convenient in-game interface for users to affect the seed.  I agree that time is definitely one of the better forms of seeding especially when combined with varying delays caused by player behavior.

I'll give one of the statistical test suites a try on the PRNGs.  It will be interesting to see which PRNG fails what test and if there are simple changes I can make to improve them.

I did try a one-line script to generate the period of the SCV4 PRNG.  It's actually pretty interesting what happens.  It doesn't actually have an illegal state like I thought (at least not by the typical definition) for its LFSR, but it's possible for it to get stuck in a small sequence almost indefinitely unless the player causes it to jump out.  Basically, it starts at 0 which is in a sequence that has a period of ~7k.  It goes through that pretty quick since it's calling the function to step the LFSR almost 50+ times per frame.  Not sure why it's called that frequently.  Then it loads the frame counter as a seed - this one happens to also be in the same sequence as 0 so it quickly gets back to 0 and loads a new frame counter.  This new one is in a different sequence where it gets stuck until it is reseeded with the frame counter (on room transitions?).

I tried a few things:
- Changed the current value to $2A7C which has a period of 4.  This resulted in the skeletons in the first stage to repeatedly make small movements and throw a constant stream of bones.
- Changed the mask from $2125 to $002D which has a maximum length period (2^16 - 1).  It still loads the frame counter which causes it to jump to a different starting position in the single sequence.

[smallest number in sequence (hex)]: Period: [period (decimal)]
$0000: Period: 7140
$0001: Period: 7140
$0002: Period: 7140
$0004: Period: 7140
$0005: Period: 7140
$0006: Period: 7140
$0008: Period: 7140
$000e: Period: 1020
$0016: Period: 7140
$0017: Period: 7140
$00be: Period: 84
$03c3: Period: 84
$0412: Period: 84
$2a7c: Period: 4

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 -

Pages: [1] 2 3 4 5