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

[TheouAegis]

The reason I set it to 16x16 is because floor tiles (the simple square ones) are always 16x16 in CV3.  The tiles themselves, graphically, are 8x8, that is true. However, since tiles are always arranged in 16x16 metatiles (NES limitation), it was faster and more sensible to set the script to work with 16x16 tiles. I have further modified the script in the version I'm working on to check the variable "orient" and shift the y-factor by 8 accordingly. This is because in CV3 levels that progress horizontally are offset 8 pixels (there's an 8-pixel row of solid black at the bottom of the screen that even stairs don't pass through); but in a vertically scrolling level, the tiles go all the way to the bottom. I haven't played CV1 in a long time. I'll download it again and take a look at it, then maybe make "universality" changes if I see fit.

But what's really pissing me off right now are those damned bats. I can't find the looping point in their movement patterns (they have two movement scripts, one for while hanging and one for when appearing off-screen). I also have to make my sprite clipping script work for bats too. So far it works for skeletons, candles and torches. (What is sprite clipping? NES sprites are 8x8, but many game sprites are 16x16 or 16x32. The NES will only draw a sprite if its origin at [0,0] is in view, so as a game sprite crosses the left border of the view, a 16x16 sprite becomes 8x16. I'm working on making this work for all sprites. Note: background tiles aren't affected by clipping.)

[Aridale]

the only difference between a tile and an object is that objects have the overhead of all the states (create step draw etc) thats the only difference. If you made tiles programmable theyd just be objects and as such be way slower. Theyre the way they are for a reason.

[Inccubus]

@Theou: Castlevania 1 definitely uses collision detection in an 8x8 arrangement. They are defined by tile too. Have a look at the Stake editor for CV1 by Dan. When you construct meta-tiles certain 8x8 tiles are automatically set to have collision. The use of 16x16 meta-tiles isn't really a limitation, but rather a technique to save on storage space for the tile arrangement data for rooms in most NES games. With a big enough cart they could store this data by 8x8 tiles. Actually some games also use 4x4 meta-tile groups to further shrink tile data.

As far as the bats, aren't they two different objects? One for hanging and one for off-screen? Maybe you should treat them as such too since you seem to be trying to make this engine as close to the NES games as possible. Speaking of which, why program in the sprite clipping thing? I know that's how the NES did it, but wouldn't it be an improvement to fore go that oddity since GM draws them until they are completely off screen anyway? I don't think most people would notice if the sprites don't clip anymore.

@Aridale: I think they could make a simple system that doesn't make the tile a full-blown object that simply allows you to define a tile as solid. I'm sure we could program an algorithm by which the player object simply checks for the existence of tiles on a certain layer, much how TheouAgis' room init script works, and have the player object act as if there were a collision there dynamically. As a matter of fact isn't it the sprites that have the collision data? There's no reason why tiles can't have collision data too. I don't think that would slow things down terribly since it's the objects that process code and not the sprites or tiles. If anything the problem could be an explosion of RAM usage for storing the extra data for the tiles.At least that's what I think anyway.

[TheouAegis]

Make a backup of my current engine version and then, when I upload my enxt version, compare the two. Visually I guarantee you will notice a difference that will make it feel very retro.

[Inccubus]

I have a back up already.

[TheouAegis]

I have one of the bat timelines fixed. I'm going to try to keep the bat sprite down to a 16x16 sprite rather than the 16x32 I've had it at recently. Will make bounding boxes cleaner. I gotta check out GM handles the offset of an additional 4 pixels though.

[Claimh Solais]

A quick question. How do you apply this to Game Maker? I'm a GM noob, so I really don't know what I'm doing. And is there a specific GM I need to use?

And if you've already posted it, feel free to derp me in the right direction. ^.^

[TheouAegis]

8.0. Supposedly 8.0 pro. 8.1 may or may not work. I've heard 8.1 is derp. I say stick with 8.0, personally. I could also hook you up with the Pro version. I have no desire to upgrade to 8.1.

[Claimh Solais]

Hooking me up with Pro would be great. I somehow downloaded 8.0 Lite, dunno what that means.

[Aridale]

Lite is the standard version the free one. Pro is the paid one. And yes 8.1 is pretty buggy atm Id stick with 8

[Inccubus]

I haven't had any problems with 8.1 thus far. Just sayin'.

Just noticed something. Trevor won't jump if there is an 8x8 block positioned 16 pixels above his head. In other words there's an 8 pixel space, but he still won't jump.

[TheouAegis]

I'll try to recreate that, but I think you messed up on your map design if that happens. I think there should only ever be a 3 or 4 pixel gap over Trevor's head. Tiles were never placed in 8-pixel gaps in CV3. Trevor isn't supposed to jump if a block is 32 pixels above ground.

[Inccubus]

This is me coming from the CV1/versatility point of view. In CV1 you can place 8x8 blocks and it would make your engine more versatile in general to allow it. Just a suggestion.

Also, if the blocks in CV3 are only ever in 16x16 configurations then there should never be less than a 16 pixel gap between Trevor and the ceiling, right?

BTW, shouldn't it be that Trevor can't jump if a block is directly over his head?

[TheouAegis]

Look at Trevor's sprite. There's a 3 pixel gap over his head. His sprite isn't 32 pixels high.

I'm working on a conditional to prevent that from happening. And that reminds me, I have to d/l CV1 still. Oh wait, I know something easier.

Ok I'm looking at the maps. Help me out here: where are the ground tiles laid out on an 8x8 grid? A stage at least would be nice. I'm looking at the Stage 6 Clocktower and the beginning map so far and both of those are aligned to a 16x16 grid.

Okay, I think maybe we have a misunderstanding and I think you may have a serious misunderstanding. When I'm talking about 16x16 tiles and being aligned to a 16x16 grid, I mean every block -- that is, every ground tile that serves to obstruct Trevor's vertical and/or horizontal movement -- is comprised of a 16x16 metatile comprised itself of four 8x8 tiles, with each metatile aligned to a 16x16 grid such that if at any time any two blocks occupy the same scanline, they share 16 scanlines, which means they're always aligned to a 16x16 grid. When designing your rooms, you can and should place tiles on an 8x8 grid, but always bear in mind that the block metatiles must align to a 16x16 grid (offset vertically by 8 pixels in horizontal rooms). Everything I'm seeing in the NES version of Castlevania 1 validates my explanation. Are you perhaps talking about MSX or Commodore Castlevanias instead?

Here is how a Castlevania map is designed:
The strictest map is a horizontal one, so we'll go over that one. A map must be 224 pixels high or 256 pixels wide. Since we're dealing with a horizontal map, we will limit ourselves to the 224px height and set our map length to a multiple of 16 larger than 256, such as 512 (yeah, I'm lazy). However, there is a trick we will want to use to make it simpler (in Game Maker). Set the room height to 240 pixels, which gives us an extra 16 pixels to work with. The status window is 40 pixels high, or 2.5 metatiles (a metatile is 16pixels x 16pixels). We will deal with that .5 later, but fill in the very top two rows in your room with a black box. In a horizontal room, the very bottom 8 pixels are solid black, so fill in the very last row of metatiles in your room with a black box. In between these black boxes you can design your map aligned easily and properly to a 16x16 grid. When your map is finished, make sure you're in the Tiles tab in the Room Editor and click the Shift Tiles button, then shift the tiles vertically +8. Do this with each tile layer (in my engine, you would need to shift 1000000 and 999998, but if you added layers you would need to shift them too). Then click on the Objects tab in the Room Editor and click the Shift Objects button, then shift the objects vertically +8. Now set the room height to 224 pixels and you're set! TIP: Don't set the room to 224 pixels until you're ready to release.

[Inccubus]

The small 8x8 blocks underneath the first door inside the main hall that make up the right most wall are not aligned horizontally to a 16x16 grid.

Now I just double checked in both the Stake editor for CV1, and the ReVamp editor for CV3 and the metatiles or TSA's as they are called in those programs are not in fact made up of 4 8x8 tiles. They are in fact made of 16 8x8 tiles. The difference between CV1 and CV3 is that the collision data in CV1 is assigned to the pattern table allowing you to place them anywhere on an 8x8 grid. CV3 seems to use some wierd 16x16 metatile arrangement but only for the collision data. You can still place 8x8 tiles anywhere, but they aren't recognized as solid unless they're arranged into a standard block. I checked out the behavior of solid 8x8 tiles in CV1 and they work fine horizontally, but a little wierd vertically. If you place an 8x8 solid tile at an off height it freaks out when you land on them from above making Simon kind of slowly spasm forward until he falls off the tile. From below they work more or less fine not blocking Simon's jump even if the are at an off height, but they continue to process side collision even if Simon is in the middle of jumping through an adjacent one. So they aren't fully supported, but they are present and usable as walls. Now regardless of all that, alls I'm saying is putting in support for an 8x8 tile grid would make your engine far more versatile even if it isn't exactly like how CV3 did it. It would allow users to make SCV4 and CVC style stages too.