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

Pages: [1] 2
ROM Hacking Discussion / Re: Gauging interest in Castlevania II Editor
« on: January 14, 2019, 12:43:37 pm »
Super helpful! My own feeling was that this game doesn't have particularly good mechanics. I think I'll not write an editor for it unless I happen to have an inordinate amount of free time.

ROM Hacking Discussion / Re: Gauging interest in Castlevania II Editor
« on: January 13, 2019, 01:42:14 pm »
I do happen to have a Castlevania 2 editor on me, I uploaded it here, so you can take a look at it. I added the OCX file already, I hadda the the editor as Administrator in Windows 10. So if you can make a better CV2 editor better than this one, I'd be happy to try it out. 8)

That's awesome! However, I couldn't get it to run. On windows 7 and also on wine, I got the error "component mscomctl.ocx or one of its dependencies not correctly registered." Looking it up, I found the file online, but its SHA1 seemed to be wrong, so I opted not to install it. I imagine this has something to do with Visual Basic, but I am not sure it is even possible to attain Visual Basic or its dependencies anymore.

I'd be curious to see any screenshots if you have them. I noticed in the readme you support metatile editing (are those the 2x2 tiles?), which is cool. Does it also support editing metatile arrangements and section connections?

ROM Hacking Discussion / Gauging interest in Castlevania II Editor
« on: January 12, 2019, 05:52:40 pm »

I've some diving into Castlevania II asm to make some edits to the terrain. I've already accomplished what I've set out to do, but I have learned how the map data is stored. Would there be any interest in a level editor? I wasn't able to find any functional editors online anywhere. I feel like this game has some hack potential.



I've been doing some Castlevania II hacking lately. My controls improvement hack should be stackable with a number of other hacks. On the project page, I've listed some hacks which are confirmed to work with it

Bisqwit's Select-screen Map hack
is probably the most interesting hack to try to get compatibility with. It does jumble some stuff around, I think. I had to make a special version of the controls improvement to be compatible with it.

Here is some of the data I've uncovered while hacking CV2. You're welcome to peruse it and if you can ever figure out how to log into Data Crystal, feel free to add it. Feel free to ask me any questions also -- I don't really know very much about ROMhacking, but I have figured out a few things about the Castlevania assembly at least!

Programming / Re: Recommended source control for a hack
« on: July 08, 2018, 02:32:31 am »
The basic idea is that code sections are named and you can move these named sections around in the ROM space wherever they need to be placed.

Oh, this is exactly what I wanted. That's incredible. Does it work for NES or just SNES?

Newcomer's Board / Re: Cannot log on DataCrystal
« on: April 08, 2018, 03:21:36 pm »
mantidactyle, are you able to elaborate on your solution? A non-user-friendly solution is better than no solution!

Programming / Re: Recommended source control for a hack
« on: March 16, 2018, 12:14:50 am »
The successful romhacker's toolkit is full of hopes, dreams, a little duct tape and blind luck.  :thumbsup:

It's as I feared. I guess I'll have to cobble something together. Thanks!

Programming / Re: Recommended source control for a hack
« on: March 15, 2018, 06:00:41 pm »
This is really cool. What's a good way to get an assembler to insert chunks of code into the ROM at specified points? Is this a common feature? I imagine it's rather unique to hacking.

Programming / Re: Recommended source control for a hack
« on: March 13, 2018, 06:04:33 pm »
Fair enough. But in the build scheme you're suggesting, can't you just use git directly as is on the source files? (Possibly leaving the clean ROM out for space or copyright concerns, of course)

I may be mistaken but I believe the OP asked about tracking changes to the binary directly.

Programming / Re: Recommended source control for a hack
« on: March 13, 2018, 04:56:07 pm »
This seems backwards. Wouldn't you rather be keeping track of a series of files relating to the hack which get applied via a build script, turning an untouched rom into the completed hack? In that fashion you have true source control and versioning, and are able to roll back code, not just patch versions.

That's exactly right. The ips patch is the file relating to the hack, and it gets applied to an untouched ROM.

When using FCEUX, the easiest workflow for editing the patch is just to edit the patched ROM directly and regenerate the patch.

Programming / Re: Recommended source control for a hack
« on: March 13, 2018, 01:22:23 pm »
After getting frustrated with keeping copies of backups manually, I wrote a githook to make it easier. In the system I've put together, the hack itself is never stored, only the patch. The githook forces the patch to be up to date with the (not stored) hack; scripts are provided to make this very short work for the user.

Here's my cv1 repo:

Now, this works very well for a single user without worrying about merge conflicts. Unfortunately I haven't yet written hooks to handle merging the ips patch yet.

Newcomer's Board / Can't log into Data Crystal
« on: February 06, 2018, 03:54:38 pm »
Hi, I have some possibly useful RAM and ROM map entries to add to Data Crystal, but I'm not sure how to log in. It says I can log in with my account (NaOH), but it doesn't seem to work..?

Anyway, just wondering what the common pitfalls might be. I tried resetting my password also to see if that would help, but it didn't.


Personal Projects / ipsnect, an IPS patch inspector
« on: February 03, 2018, 08:42:34 pm »
While trying to track down a stray byte I edited in the ROMhack I'm working on, I decided to write my own utility to aid in the search.

IPSnect is a command-line utility that displays a list of all hunks in an IPS patch, and the content of each hunk. You can also provide it with a binary file to compare against, and it will show you the new bytes, original bytes, and an optional surrounding context of bytes.


Sample output:

Code: [Select]
$ ./ipsnect patch.ips base.bin

====== IPS summary ======
hunks: 3
regular hunks: 2
RLE hunks:     1
sum of hunk lengths: x00000044 bytes (68 bytes)
========= hunks =========

regular hunk on bytes x017F17-x017F3B (37 bytes)
------------- in unpatched binary: ------------
---------------- in IPS patch: ----------------
A0 00 8C 09 05 AD 20 05 10 01 60 A5 2A 29 04 D0
F9 A2 10 A9 00 20 DE FC D0 F0 EA EA EA EA EA EA
EA A2 00 8A 48

regular hunk on byte x03965D (1 byte)
------------- in unpatched binary: ------------
---------------- in IPS patch: ----------------

RLE hunk on bytes x001016-x000FF6 (30 bytes)
------------- in unpatched binary: ------------
A5 2A 85 10 A2 00 A9 16 9D 00 04 A9 00 9D C1 05
A9 09 9D A5 2A 85 10 A2 00 A9 16 9D 00 04
---------------- in IPS patch: ----------------
FE FE FE FE ... (repeats for 30 bytes)

ROM Hacking Discussion / Re: Version control for ROMhacking?
« on: August 30, 2017, 02:18:39 pm »

It's much simpler to only store what's needed for building in repository and have the build script produce the binary (patch, in this case).

The tricky thing is, since I'm using FCEUX, I am editing the .nes file directly as part of my workflow. I imagine a lot of people will be editing their .nes file directly, too. So this introduces an unusual dependency; the patch affects the ROM and the ROM affects the patch. So there needs to be two scripts, as I have: apply and make-patch.

ROM Hacking Discussion / Re: Version control for ROMhacking?
« on: August 27, 2017, 05:40:00 pm »
Today I tried making a solution to how to store a ROMhack in a repo without the actual ROM, without having to manually create patches a bunch.

Pretty much how it works is, when you download the repo, paste in an unmodified ROM, and run the setup script, it generates a modified ROM based on the patch that's stored in the repo. Thereafter, before committing, a githook forces you to make sure the patch is up-to-date with the modified ROM.

Implementation details: the hack requires three files: base.nes, which is the clean ROM file; working.nes which is the edited ROM file; and patch.ips which is generated from the diff between base.nes and working.nes. I also wrote a script for people new to the project which checks for the existence of base.nes and generates working.nes from the patch.ips. It also sets up the githook to prevent you from committing without making sure the patch is up-to-date (which is as easy as running

I'd also like to write a githook that automatically patches the ROM when checking out a commit. Handling merges seems the trickiest. (Successively apply patches from both branches? Still not clear how to check for merge conflicts though.)

I'll let you all know how this works out. If you'd like to try this, you can grab my repo and just use your own patch.ips for your own project. (Also, delete the FCEUX ROM map for castlevania :P).

I like it so far

YESS!!  The Rondo Stair jump!!  You are doing awesome so far!!  This is will be the best CV3 hack!!  :D

Thank you! I'm really glad to hear that people are interested in this.

Which "most games" are you talking about ? "Most games" does not have the awful stairs system Castlevania has, including even later Castlevania games. You mention Super Smash Bros but it's completely different from Castlevania so it makes no sense comparing them.

My philosophy here is that I should disregard the way that CV3 was intended to be played in favour of making the controls (and the way the player interacts with the world) standard and intuitive. As such, CV3 should have the same control scheme that any sensible modern platformer game would have. Smash Bros. is, in my opinion, the greatest platforming engine ever devised; movement in Smash Bros. is absolutely flawless and is completely intuitive. Even though the in-game objectives of Smash Bros. and CV3 are quite different, they are both -- at the fundamental engine level -- platformers in my mind, and therefore warrant similar control schemes.

In Smash Bros., there are not "stairs" as such, but there are slanted ramps that one can jump and fall through. In my mind, this is actually exactly the same as a stair and I see no reason to treat stairs and ramps differently at all. They are both slanted platforms the player can stand on, walk along in either direction, and fall through.

Therefore, stairs in CV3 should function in precisely the same way that ramps do in Smash Bros.

My only point of comparaison is later Castlevania games who DO have stairs, those are Super Castlevania IV, Rondo of Blood and Castlevania Bloodlines. You'd want to behave
like those whenever possible.

Of these, I've only played SCV4, which as I recall had an annoying control scheme as well. I wouldn't personally want to model the controls off of that game. I suspect that most people who haven't played any Classicvanias would prefer a Smash Bros.-style control scheme, and some people who have gotten used to the SCV4-style control scheme would prefer that to a Smash Bros. style.

The original CV3 has consistent and predictable behaviour, yet we both agree it's controls suck.
How does it make the controls inconsistent ? SCV4 probably does exactly that. If the stairs go "down", you autoland on them, as this avoids falling through stairs like shown in this video. If they go "up", you don't autoland and simply pass through. This is absolutely consistent and makes sense. If you jump in front of stairs going up, you just do it as if the stairs weren't here. If you jump over stairs going up and fall in a bottomless pit, and die which is the correct behaviour. If you jump hop onto stairs going down, you land on them, as opposed to the original game, again the correct behaviour.

I suggest checking the vertical position as a simple way to distinguish stairs going "up" from stairs going "down" but if there is another preferred method, go for it.

Firstly, "up" and "down" are not properties of the stair, but of the player -- any stair could be either an "up" or "down" stair depending on perspective. The only difference in stairs is whether they are parallel to y=x or y=-x.

Secondly, even assuming your other premises, sometimes "up" stairs ought to be solid/auto-catching, such as the stairs just before Dracula. So "up"/"down" is not a good qualifier for whether a stair should be auto-catching.

Thirdly -- the reason I would consider that proposed behaviour "inconsistent" is that it depends not only on the current state of the character (x,y coords, velocity, health points, subweapon) but also on the path the character has taken to get there (i.e. whether the player used to be higher or lower). Look up "State function vs Path function" for a more rigid definition of these terms.

I believe controls should always be sensitive to the state of the player, but not the path. I would call path-sensitive controls "inconsistent" because the player would not always predict how their controls will influence the game based solely on the information presented to them on-screen.

Players generally assume that controls are state-sensitive and not path-sensitive; as a result, I believe they would find controls to be less learnable if they actually did depend on state as you suggested. Instead, the player would be confused why sometimes they fall through stairs by default and sometimes they land on them by default.

And that would be horrible.

I can't actually remember any game with staircases like in castlevania. What games are there?

Off the top of my head: wanderers from ys 3, and smash bros if you count passthrough ramps.

I feel like it would be intuitive to not auto land on stairs, but instead only land when holding up or down, or when the stair is "solid" (like in that example from the let's play video). Since there seems to be no way to tell when it is solid or not, I'd go with only when holding up/down.

I could release an additional hack to change the controls to require the up button be held instead of auto landing. But I'd say that since most games have autolanding, the correct thing would be to implement autolanding. After all, the whole point to this hack is to be a sober second thought about the control scheme.

edit: maybe it would be good to auto land on stairs that have no bottom end. Like stairs that go to the bottom of the screen. Because on these cases not landing on them means death.

I would prefer consistent controls over "smart" controls that try to predict what the player wants. Those are rarely ever a good idea.

For example: if I did do this, there are places  where it could mess up.  For example,  in the final stage just before Dracula, there is a clearly "solid" staircase that has no top end and should clearly have autolanding: falling through it will cause death.  However, there are other instances of stairs which have no top but still shouldn't be solid; for example, in  Death's stage and possibly in  stage 2 (the clocktower).

Since there is no obvious consistent solution to me, I would prefer not to go this route.

ROM Hacking Discussion / Re: Version control for ROMhacking?
« on: August 09, 2017, 05:24:09 pm »
Some have tried with git and patching formats

This sounds like a headache to figure out but also potentially very lucrative. Could you link me to a project that does this? Is there any scheme doing this that is known to work, or any documentation for how to work with this?

Also, would there be interest in the community at large if I were to investigate a good way to do legal open source development / version control with ROMhacks?

Well, because you're more likely to just want to jump normally and ignore the stairs completely.

In most games I've played, one auto lands on stairs unless, say, one holds down to pass through them. This is how it works in Smash Bros. With passthrough platforms and ramps, for example. I believe it is far more intuitive and standard to auto land on stairs, plus it's safer as it means the player won't fall through them into a pit.

The most important thing is to have consistent and predictable behaviour though, otherwise a player who has mastered the controls will get annoyed when they suddenly work differently than expected. So I wouldn't make it check your starting jump height.

Pages: [1] 2