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

[TheouAegis]

I got it to work. I'm working on the holy relics now. The "simple" solution was to check for no collision 16 pixels ahead of him. Of course it's up to the level designer to make sure no situations exist that would make my solution not work, for if at any time my solution doesn't work, the level is not true NES Castlevania-style.

And something I posted on the Game Maker forums just now: While testing some ledge collisions in CV3, I found what appears to be the NES equivalent to Game Maker's image_xscale=-1 bug. If you're not familiar with it, when you use image_xscale=-1 to mirror an object's sprite, the sprite's bounding box increases by 2 pixels on the left side (or 1.5 on left and .5 on right... don't ask). In Castlevania 3, collisions when Trevor moves left are offset by 2 pixels compared to when moving right. I haven't tested this with other games yet.

And while debugging my engine I think I also figured out how/why the World -1 Easter Egg in Super Mario Bros. worked (and if I did, props to Nintendo for thinking "hey! Let's exploit a bug in our game!").

[Jorge D. Fuentes]

Did you jump towards a 'wall' of bricks, and cause the character to scroll through it? xD

[TheouAegis]

My guess is it has to do with what your Y-value is at the time of the collision with the wall. It's very precise, since they (as you can tell in Castlevania games) very likely just set a vertical variable and didn't calculate every step (which is what my engine does, so in that regard it's different than Castlevania), so it takes a lot of trial and error the first few times you attempt it.

Anyway, it just occurred to me after considering that image mirroring is bugged in the NES just as it is in Game Maker and that, upon inspecting the graphics data in my Castlevania 3 ROM, the sprites initially face left rather than right like in the sprite sheet I've been using, my collision engine is overly complicated. Had I worked with a left-facing sprite sheet all along, my engine would have likely been completed two or three nights ago since I wouldn't have been preoccupied with trying to get Trevor to fall through ledges a certain amount.

And I also realized a 1:2 view-to-port aspect ratio messes up image_xscale=-1 even further. I set my views to a 1:3 ratio and voila the pixels line up at either image_xangle.
*flips his computer the bird then goes to bed*

[Viper]

image_xscale isn't bugged in GM at all.

[TheouAegis]

Prove it. Prove that increasing the bounding box by 2 is precisely what image_xscale is supposed to do.  I threw into my debugger object the following codes:

Code: [Select]

with(all) draw_rectangle(bbox_left, bbox_top, bbox_right, bbox_bottom, 0)
draw_text(x,y,obj_Trev.bbox_left)
draw_text(x+80,y,obj_Trev.bbox_right)

And the rectangle was visibly larger when image_xscale = -1 and the value of bbox_left did indeed change by an offset of 2. That implies there's a bug.

[Viper]

I suppose this is bbox function bug. Or some issues with your sprite's origin.
Just have tried to draw flipped symmetric sprite over non-flipped one - pixels fit perfectly.

Anyway, as long as image_xscale flips sprite's mask, best solution for you is to have symmetric rectangle mask for your character. Maybe even have a separate object for "character with walls" collisions, that helps much by the way.

[Aridale]

yeah if your sprites origin isnt centered your gonna have issues when the character turns left and right. Its best to have a sprite thats an odd number size so theres an exact middle pixel to set as the origin.

[TheouAegis]

Collisions aren't a problem for me now. My collision detection works well enough.

I just noticed last night Trevor's standing attack sprite is 33 pixels wide (if you put all the frames into one sprite) because his upper metasprite is shifted forward 1 pixel. I'll test Aridale's suggestion on odd-value sprites. But image_xscale should, even if sprites aren't odd-valued, still put the pixel offset evenly on the left and right sides, but it puts all of the pixel offset on the left side when it bugs out.

Currently in my engine I'm working on the cross and holy water. I have the dagger and axe more or less finished. Do you guys think I should release just the Trevor Engine or release it with the game room as well (meaning that bit at the top of the screen)? I'm almost ready to share my Trevor code. If you look through the timelines I'm using in it, you might even figure out an algorithm to simplify parabolic motion in the game (interestingly, since Galileo wasn't yet born during the time of Castlevania, objects of different sizes fall at different rates of speed).

[Jorge D. Fuentes]

Parabolic motion for the axe and holy water?
Also, if you make a multi-layer level editor, I'll make stages.  GameMaker's level editor seems to be quite evil.
I can also update the Trevor sprite while keeping it the same size, to make it look modern, just in case you don't want that 8-bit look or would like a modern alternate costume or something.

[Chernabogue]

Wow, it seems to become very serious! Good job!

[TheouAegis]

I was hoping to make an NES-style sequel to LoI, so I would need a CV3-style Leon. I was going to incorporate crystals (make those boss drops do something for once... ok say they did something in LoI too) and possibly allow double jumping or something. It would play like a blend of Simon's Quest and Dracula's Curse in that you start in the countryside near a village and you talk to a few people as you progress (most of whom all die) but it won't be Metroidvania, it'll be true Castlevania. Last night I planned on starting the game in  a forest with owl and cuckoo calls (using the triangle channel I'm guessing, or maybe the square with Duty 1) which overlap with an ominous simple tune and as you progress through the forest, breaking standing torches (like in the beginning of CV3) you come across a town whose inhabitants have mostly been slaughtered and you talk to a survivor, then a cat nearby freaks out and zombies appear then the action proceeds from there.

I'll post sprite specs when I get my engine further developed. I think I'll go work on it some right now until I fall asleep.

And yeah, parabolic motion is weird in CV3. Trevor jumps in a 5----3--------2--1--0-1-0--1--2------3----5----6----7 motion, but the axe moves in a 5--45-4--3--2--1--21--010--12--1--2--3--4-54--5--6--76-7---8---9---10 motion. I haven't looked at the holy water yet. I'm GUESSING it's an augmented axe motion.

As for level making in my engine, at least in this beta version, all  I would need is stages using 3 layers:  Layer 1000000 for solid ledges, Layer 999999 for passable backgrounds, and 999998 for passable foregrounds (don't know if these were ever used in Castlevania games, but i was thinking of something like walking through a graveyard with tombstones in front of you). And yes, the NES can handle foregrounds, but a foreground tile cannot overlap a background tile, so whatever the primary background color is for the room will be what's shown behind Trevor in the transparent parts of the tile (which is typically black in a graveyard). You could also do foreground trees or grass in this way (which some of the Mega Man games did). The Famicom-style remake of Mega Man 8 (I think it was 8, the one with Slash Man) had people saying the T-Rex couldn't be done on a real Famicom, but the remake's designers blended foregrounds and backgrounds with sprite blocks in a way the NES was more than capable of. Anyway, the engine then places a ground object over tiles in layer 1000000 and scales each object to cover the tiles. But more on that later.

[Jorge D. Fuentes]

Ah, I see...

So, none of this, then?

[Aridale]

shit jorge thats awesome! you finish the whole sprite?

[Jorge D. Fuentes]

I could probably get it done by the end of tonight if I get compelled enough, haha.

[X]

Isn't Trevor supposed to have blond hair with a red sash draping from his belt like in the CV3 box art?

-X