Topic: NES-Style Castlevania Belmont Engine for GameMaker! (Version 0.3 UPDATE!)

[Inccubus]

Nice work, my friend. Well done indeed.

[TheouAegis]

So I had an idea for use in my game if I ever get around to actually making it, but first I wanted to see if it would even work in a CV3 hack. So, I tried something maybe other people never tried: I moved a stair trigger from the top of a staircase down to the middle of the staircase. My theory was Trevor would climb the stairs, hit the trigger and then fall to his death because there was no floor under him. What I learned was that stair triggers don't do anything except tell Trevor where the stairs start; he stops climbing when he actually reaches a platform.

So this totally blew my idea out of the water. Then I started wondering if I should redo my stair triggers so they work as in CV3 (just make Trevor start climbing until he reaches a prt_ground) or if I should keep them as they are currently in my engine (tell Trevor when to start climbing and when to stop climbing). What do you guys think?

[Inccubus]

Question: What the hell do the stair top objects in CV3 do then?

[TheouAegis]

Just tell Trev when pressing down starts his stair climbing back down, opposite for stair bot objects. I guess it makes sense. 

[Inccubus]

OK. Then if you want to be as accurate as possible to the original rearrange your set up accordingly. Functionally, I think it will be of little consequence either way.

[TheouAegis]

I just realized it would matter in the Forest stage and stages like that. Note you can't walk back down those stairs leading to Stage 2 (the part with the crushers is stage 1). There's no stair object there so he just walks up until he hits ground and starts from there.

... I dunno, I think I will change it after I get my enemies working again (changing over to my new collision method messed them all up).

[Jorge D. Fuentes]

I thought that was awesome, the way he just 'rose out of the ground' and ends up in the forest part after the clocktower.
It's as if there was a trap door there, hidden, that he happened to rise out of.

[TheouAegis]

As some like Inccubus probably already know, I already have a near-complete Sword Skeleton, but it's far from perfect -- it uses 6 or 7 timelines randomly to simulate the movement in CV3. Of course some people might argue that is pointless since the movement could just as easily be done with some random variables and alarms without timelines.

When tracing the random movement patterns for Bone-Throwing Skeletons and having accumulated 8 or 9 distinct patterns in the measurements, each spanning 42 steps but with varying distances, I realized I needed to do something Esco seems to be vehemently against -- trace and read the ASM. Well, it took me a while for it to even bear any fruit, but I figured out the code and how it works. Right now the only reason it's not complete is because, I think, I have conflicting conditionals or a faulty collision check telling the skeleton to throw its bones instead of jumping. But the important thing is I have the movment down.

Bad news for Inccubus: the enemy movement script is getting an overhaul to accomodate enemies like these skeletons that have this random moment type.

I haven't verified yet if this is the same format of random movement code used in Bone Skeleton and possibly even the platforms from hell that I mentioned in my argument with Esco, but I have a strong hunch this is indeed the same method. Once I get the Bone-Throwing Skeleton finished, I"ll be able to check on that.

Here is the gist of CV3's random movement method, at least with the Bone-Throwing Skeletons:

One byte (when I say "byte" I mean a variable that does not exceed 1 byte in size) sets the direction and "speed" of the skeleton. This byte is either set to $FE (-2) or $01 (+1) and is augmented each step toward 0; specifically, it is added to $FF (-1) with the carry bit of the status flag. In conjunction with the next two variables, this speed gradually decelerates ($FE becomes $00, $01 becomes $FF). When the skeleton runs into a wall it can't jump over (it jumps over one-block walls) this byte is subtracted from $100.

One byte is set to $30(+$A0 if the byte above is negative) and then adjusted by 4 opposite the direction the skeleton is moving. So if the skeleton is moving right (positive), the byte is decreased by 4; if the skeleton is moving left (negative), the byte is increased by 4. When the byte exceeds 0 or 255 and the carry bit is set, the byte above is adjusted toward $00. After the bone is tossed, the byte is reset to $30(+$A0 if the byte above is negative). When the skeleton runs into a wall it can't jump over this byte is subtracted from $100.

One byte starts at $0 when the enemy is spawned and is increased by whatever value the byte above is set to. Everytime this byte exceeds 255, the carry bit is set. The first byte is subtracted from $FF unless the carry bit is set, in which case there is no change. In this way the skeleton will appear to slow down before throwing his bone (if you watch the movement in slow motion, it does in fact decelerate).

The rest of the movment -- the bone toss and the jumping off ledges -- are just typical "you can do this with a timeline" routines.

[Inccubus]

That's pretty cool, actually. I've personally always thought that reading the ASM is a good way to as near to perfectly reproduce the movement of an object in a NES game without having to reverse engineer the code from the data.

[TheouAegis]

I'm still here and still working on GMVania. If i worked the graveyard shift, I"d have more time to work on GMvania (I used to do most of my sprite ripping and programming during my 3 hour break at work, also got decent exercise lugging my old laptop to work with me every night).

Lately I've put scripting platforms and game mechanics on hold. The draw_clipped() script was begging for attention, refusing to draw my Sword Skeleton correctly (it worked for my Axe Knight, though), so I decided to scrap it for now (the code will still remain in GMvania but the function will be disabled by default). Instead, I set my sights on cracking movement codes in CV3. I'm not much interested in Simon's jumping mechanics, although later I may work on cracking that after all; what I have been really interested in cracking is the movement for those damned platforms that bob up and down. I realized in order to do that I would need to acquaint myself with a similar movement code -- Medusa Heads. That's right, I wanted to crack Konami's method of sinusoidal movement in Castlevania.

And I must say, it's pretty nifty in its simplicity.

The sword and bone skeletons made more sense to me than the Medusa Head's code at first, but cracking what some of the variables actually referred to helped it make more sense.

The first thing I had to learn about reading enemy movement code was to stop thinking in terms of hspeed and vspeed, since the NES games strictly modified the x and y values directly. However, CV3 did actually use hspeed and vspeed to an extent. Certain bytes were set to either 0 or 1 for positive hspeed, or -1 or -2 for negative hspeed. The carry bit of the status flag was added to those bytes, so at any time the hspeed was -2, -1, 0, +1 or +2. Ok, so far, so boring.

The next thing I realized was the same script was used for every skeleton -- from the normal, slow-plodding skeleton to the spry whip skeleton. Recognizing this script was the key to breaking the enemy movement code. Of course, like my Password Generator, I didn't actually take the time to translate the script into attractive GML, deciding instead to simply transliterate everything into compatible GML. This script followed this format:

Code: [Select]

A+=B;
carry=A>255;
X+=hspeed+carry;

That's the gist of the horizontal movement script of the skeletons. What's the big deal? Well, when I tried to crack the code for Medusa Heads, this was the first script I saw:

Code: [Select]

C+=D;
carry=C>255;
Y+=vspeed+carry;

And right below that in the debugger was the horizontal code above.What this told me was, as I suspected after cracking the skeletons' horizontal movement codes, that the Medusa Head's vertical movement code was at its most basic level the same (or at least very similar) function as the acceleration/deceleration horizontal movement in sword skeletons. The question left in my mind was, how did Konami tell the Medusa Head to change direction regardless of where Trevor was in relation to the Medusa Head?

For the skeletons, it was a simple case of set an alarm (yes, CV3 had the equivalent of alarms) then adjust the movement when the alarm is executed. I knew the general address which would hold any alarm used by the Medusa Head, but when I ran the game there were no such bytes to be found. I was perplexed, so I delved farther into the code. It didn't make much sense at first because there was a glaring issue I had overlooked -- Medusa Heads' y-origins are 5 pixels below their sprites! I kept staring at this byte set to C4, but Trevor was standing at C0 and the Medusa Head was knee-high. When the Medusa Head went up, the byte decreased, and vice-versa. Once I got that sorted out, I noticed in the code another byte also set to C4. It was in the same address as where an alarm byte would be, but as I ran the game I noticed it never increased or decreased. It occurred to me what I was looking at is the GM equivalent ystart. So now the code was staring me right in the face.

Code: [Select]

B-=(y-ystart);
carry=B<0 || B>255;
vspeed-=1-carry;

Er... I think that's what the code loosely translates to. Unfortunately the Ethernet port on my laptop is bent to hell, so I can't just copy-paste the ASM up to here.

[Inccubus]

Sounds intriguing. So these basic calculations cover all enemy movement in the game? I'm not so good at ASM, so I'm glad you're studying CV3's code. Please take lots of notes!

[TheouAegis]

So far I've only noticed two (basically) styles of movement codes. I'm guessing that falling is handled similarly whereby two bytes are summed and then the vspeed has the carry added to it, but whereas Medusa Heads (vertically) and Sword Skeletons (horizontally) will alter the bytes at some point, the falling code, I hypothesize, will just let the bytes keep summing up. As for why some objects fall at different rates than others, I have no clue. Things like Bone Skeletons (yeah, I probably could have cracked its jumping code when I was working on it) apparently have a vspeed lock hard-coded in. As for Trevor, though, I theorize he uses the same style of code as the Medusa Heads.

[Inccubus]

Hmmm... very interesting. Dude, if I wasn't neck deep in a full-time job and starting up my game company I would totally be helping you with this as much as possible. Just the technical achievement of a near perfect replica of CV3 for people to use for their own projects will be amazing. Not to mention, I still want to use this engine to complete my remake of CV1.

[TheouAegis]

In case anyone is interested, I think (although I haven't tested this) the limit on instances allowed active (note there is a difference between being active and being on-screen) at any time in CV3 (note this may be different in the other games) is 13. Like I said, I haven't tested this. The best way to test it may be to put in a couple Fire Men and use the duplicate spawn trick (walk away from the enemy's start location without losing sight of the enemy -- a lot harder than it sounds -- and then walk back to the spawn point, causing another enemy to spawn), then once you get three Fire Men on the screen they shouldn't be able to create fire if there are also candles/torches on the screen. Or maybe candles and torches are handled separately. All I know is I saw the branch conditional CMP X #$13 and I know that when X was 0 it handled Trevor and when X was 1 it handled the instance whose code I'm studying. So that leads me to believe Konami set the instance limit to 13.

[TheouAegis]

For the life of me I cannot get the floating platforms to bob correctly! Either a bad loop is causing them to prematurely cycle or that same loop is causing them to completely ignore a variable. So right now it bobs as if the range (refer to reVamp) is always set at 0. That might suffice but you won't be able to recreate CV3 without that added function.

ARGH! Been working on this problem for almost a month now I think. Or maybe it's been a couple weeks, but I think it's really been getting near a month. The ADD ain't helping, the whiny cat in my kitchen ain't helping, and sleep ain't helping! ... At least it's back to bobbing. As of Friday I had ruined it so it wouldn't even bob and had to recode from scratch twice over just to get back to where I am.

....

Durrr.... I think it was a rookie mistake. Still learning ASM after all.


Edit: Also, when I said 13 enemies, I goofed. It's $13. So you can have 19 or so objects or enemies/moving-platforms active at a time.