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

[Jorge D. Fuentes]

When can we actually play this?
'cuz that's really the only update I care about.

[TheouAegis]

What part of ADD/ADHD don't you understand? You'll never get to play it!

J/K.

... Or am i?

Notice Or am i looks like a mutilated Orz guy?

I already have interactive elements in place. But every month I overhault he coding. For example, the previous versions used collision_line and collision_rectangle. Now they use hard-coded pixel-by-pixel collision check loops to speed things up a bit. So the whole system has to be rewritten for that. So the game should be faster but the coding's taking longer. ... Yeah, something like that.

Also, learning ASM through decryption isn't very fun. Movement will be nearly identical to CV3's in sooo many aspects. I haven't even really bothered verifying if I've set image_index=image_speed for all the objects yet (which is how it works in CV3 because of the order of processes).

I'm cutting out a lot of stuff from my planned schedule to try to hurry things up a bit, I tell ya. I swear!

[Jorge D. Fuentes]

Oh man, you're that type of programmer.

Spongebob Time Cards

[TheouAegis]

Did you really forget all those times I said I'd upload something in the morning or after work and then it never got uploaded until the next month?
Yeesh. Nice to know you follow my status so closely. 

[Jorge D. Fuentes]

Don't mind me I'm just being facetious.

[Inccubus]

I'm mostly just interested in the basic Trevor & platform engine. I don't need the enemies as much, or the NES style graphics engine since I'm gonna change all that anyway. I still find them interesting, though.

[TheouAegis]

The graphics engine is dropped for the time being. It suffers the fatal flaw of sprites needing their origins centered, which renders currently Sword Skeletons buggy.

[TheouAegis]

I've been hard at work lately... playing League of Legends. But before I go to bed I spend an hour watching ASM in CV3. So continuing on with my analysis of Konami's programming...


Image Speed
Image speed is simply hadled by an alarm that counts down every step. When it hits 0, the sprite changes.

Horizontal and Vertical Movement
Each direction uses four variables: coordinate, integral speed, and two variables for fractional speed. The integral speed is set once and in some cases is changed when certain conditions are met, but toherwise it's a static value which is added to the coordinate with the carry bit of the status byte added. The first fractional speed variable is initialized to 0. The second one is set in such a way that the fraction is determined by how many times that variable is added to the first variable and when that variable exceeds 255 the carry bit is set (hence the fractional part). So if the second byte is set to 128 and the integral speed byte is set to 1, the instance will have a speed of 1.5. If the integral speed is set to 255, the instance will ahve a speed of -.5.

Sine Waves
The starting coordinate is saved to a specific byte. The current coordinate is compared to the starting coordinate and the difference is subtracted from another byte. If that byte doesn't drop below 0, the carry bit is set and added modifies the integral speed. The fraction speed is negated at that time as well.

Reversing Direction
An alarm is set. When the alarm reaches 0, the integral speed and fractional speed are negated.

Winged Demons
These guys use a sine al crescendo. When the image speed's alarm reaches 0, it adds 1 to a counter. That counter is applied to the Y address (not to be confused with the y coordinate), which forces the game to set the integral speed to s specific value. (I haven't tested in a horizontal stage, but I'm guessing if you could lead a Wing Demon far enough along, based on the values I saw it would go back to a low amplitude and then just drop off the map.)

Sprite Size
Sprites in CV are either 8x24, 16x24, or 16x32. A sprite that has a graphic height of less than 24 will have a true height of 24.

Sprite Origins
Belmonts have a sprite y-origin below their feet, which in most cases is at y:32. All other instances have y-origins 1 pixel above their feet. So a 16x32 sprite would have it at y:31 and a 16x24 sprite would have it at y:23. This means Belmonts stand above ground and enemies stand in the ground.

[TheouAegis]

HAHA! Horizontal Hit Detection is soooo simple in Castlevania!

abs(Trevor.x - Enemy.x) < 14

That's all there is to it! There are no hit boxes! Haven't checked vertical collisions yet, though.

Still not sure how block collisions are handled. I know it ANDs $F0 to snap to the grid, but not sure how it determines when to do that.There are just so many variables to watch. If it's as Nocturne at GMC said, they used a tile map but I don't know what address that'd use if in fact that's what's going on.

[Inccubus]

Wow. That's ... really wierd, in modern terms anyway. I'd thing they'd do something similar for vertical collisions with enemies.
I really wish I had more time to learn more 6502 asm so I could do the same thing with megaman and smb3.
Keep it up! I for one find all this fascinating.

[TheouAegis]

Found an error/flub on Konami's part in the actual coding for CV3. Well, it wasn't so much an error but dirty programming, which is kinda surprising when you consider how well thought out the rest of the coding appears to be.

First off, the Winged Demon is bugged like I suspected. It was never meant to be used outside of vertical stages. What happens in horizontal stages is the Winged Demon will increase the amplitude of its waveform then reduce it back down again. After it has returned to its normal amplitude it kicks in to crazy mode and starts spazzing out, jumping to the top of the screen then the bottom of the screen. The reason for this, as I predicted in its programming, is the vertical speed changes from +/-1 to +/-64. I had predicted it would drop off the map and be auto-deleted because I interpreted the +/-64 as +/-208 originally (it was written as $C0 in the code, but was handled as -$C0, which is 64).

Now, Trevor's code shows Konami worked on him first. The code was probably recycled from other games. Either that or they had a different programmer coding him. I haven't delved very far into Trevor's code yet, but just from the jumping code alone I've noticed two things:

1) Trevor uses the same horizontal and vertical movement code structures as enemies, but his code is hard-coded just for him. Enemies and platforms all function in arrays (basically), such that you have code like LDA $041D,X ADC $0538,X STA $041D,X. Since people like Inccubus don't know ASM yet, in GM terms that's basically var1[a]+=var2[a]. In Trevor's case, the code is sliiiiiightly different: LDA $041D CLC (clear the carry bit) ADC $0538 STA $041D. When the game adjusts (in this example) $0538, it does so with soft code just like with enemies, but the actual movement code was hard coded with its own extra address.

2) Trevor's jumping code wastes a lot of memory. It is by far the dirtiest code I've seen in the game yet. Trevor's integral vertical speed (see previous posts) is ultra-hardcoded. Not only does the game actually store Trevor's vertical speeds in the ROM itself (as opposed to enemies and platforms who have their vertical speeds calculated), each step is stored in the ROM. It's the equivalent of a Switch statement in GM:

Code: [Select]

switch step_counter
{
  case 0:
  case 1:
  case 2:
  case 3: vspeed=-5; break;
  case 4:
  case 5:
  case 6:
  case 7: vspeed=-3; break;
}Each case has a corresponding address in the ROM (in case you ever wondered why a Switch statement is slightly faster than a bunch of IF statements, that's why). There's something like 26 bytes dedicated just to storing Trevor's actual vertical speed in the ROM.

[Inccubus]

Interesting. I'm guessing here, but I'd say that dirty-ass code was inherited from CV1 & 2. The enemy code is probably newer and more efficient since they seemed to be basically re-coding all of them presumably as a way to make it easier to create lots of variant enemies that use similar movement which CV1 & 2 didn't have.

[TheouAegis]

Obviously right now I'm working on Trevor's code. I still don't know how collisions with tiles are handled. I found the TSA map in the ROM, but have no idea how any of that ties in with the RAM. I'm working on the stairs right now. Discovered my current stairs were a tad off by about a pixel. Since there are no physical bounding boxes, just deviations from x/y, my collisions can get a little more accurate. What I really want are the measurements for Trevor's base (what interacts with the floors) and for his face (what interacts with the walls), as these are clearly not the same.

By the way, stairs are

abs(stair.x - belmont.x)<13


UPDATE: Found the hitbox dimensions for enemies. I haven't checked for all enemies yet (assuming bosses have a larger hitbox, projectiles have a smaller hitbox), but at least for Skeletons and similarly sized enemies, hit detection is calculated as follows:

collide_horz = abs(belmont.x - enemy.x)<$0E
collide_vert = abs(enemy.y-belmont.y)<$1A

[Inccubus]

Sweet.
It just occurred to me that the ROM hacking community would probably be very appreciative of your notes on this. In particular I and many others would love some insight on hoe levels are structured. The biggest problem with hacking CV games on NES is that no one has really cracked the level structure so everyone is stuck making levels that have the same basic shapes with little or no variation at all.

The hit detection for the enemies is uber simple. I'd even call it eloquent.

[TheouAegis]

Whip detection seems to be

abs(belmont.x - enemy.x)<$18 for whip levels 1 and 2
abs(belmont.x - enemy.x)<$28 for whip level 3

Not sure what the y detection is for whipping. It's slightly different. I'll find it tonight. I was working on other Belmont mechanics and got sidetracked by candle drops.

Speaking of drops, collision is kinda small (naturally).

collide_horz = abs(belmont.x - drop.x)<12
collide_vert = abs(belmont.y - drop.y)<10

I think those were the values. Did it off the top of my head. Not sure if small hearts are the same. I got those numbers off a coin purse (which 90% of share the code for).

Drops are destroyed if

x-view_xview & $FF < 4 or x-view_xview & $FF > $FC
y-view_yview & $FF < 8 or y-view_yview & $FF > $E8

Again, citing figures off the top of my head and my memory isn't THAT good, so I could be off by a few pixels.