Crawling Implemented

http://www.youtube.com/watch?v=OVYFqyhbBOE

Crawling implemented with some slight glitches and background parallax fixed.

Background Scrolling

Fixed the parallax problem at the room boundary by making the background image 192 pixels wide instead of 256, because 192 is a multiple of 48 (tile size) and 256 is not.  Later, I still want to go back and add some transparency effects for the background between two rooms, just in case I want to have rooms with different backgrounds.  However, this results in 6.5 background tiles per screen which leaves me with the same problem of the background image not aligning to the room size.  I would rather not reduce the background image to 96 pixels wide, because it would make the background tiling really noticeable.  After doing some calculations, I found that the room size (1248) is divisible by 156, which would make the background image repeat 8 times for an image 156 pixels wide, so I went with that size for the background image width.

Map Drawing

Created a new method specifically for drawing a room.  Previously, I had separate loops for drawing the blocks of each room, but only drew the enemies and doors in the current room.  That is why those would disappear as I crossed the room boundary.  With the enemies and doors (and eventually projectiles) drawn in the room draw method, those no longer disappear, because I always call the map draw method for the room to the left and right of the current room.  This did uncover another issue, which is that the enemies are not updating (moving) when the player is not in the current room.  Therefore, in the game update method I now call update for the enemies and projectiles in the adjacent rooms.  True to NES game fashion, I’m not going to bother updating enemies more than one room away.

Crawling

I added crawling to the game, which allows the player to go into spaces that are only one tile high.  When the player presses down, then a crouching flag gets set to true if the player is not jumping or falling.  When this is set, the player’s bounding box size gets set to 48×48 (previously 96×48).  The first time I tested this, I was surprised that the bounding box was correctly aligned to the floor, instead of floating in the air since I didn’t update the player’s Y position to account for the crouch height.  However, I realized what was happening was that once the player crouched, then they would fall to the ground to account for the 48 pixel vertical gap that is created when the player crouches.  This worked fine, but when the player released down the crouching boolean gets set back to false and the bounding box is set back to 96 pixels high.  Since the player’s Y position was not modified, this resulted in the player being stuck in the ground.  For now, to fix this I just subtracted off 48 from the player’s Y position when they release down (go back to standing).  This seems to work well, unless there is a block above the crouch position, which will cause the player to rise through the block.  I will need to add a check to see if the player will collide with a block when going from crouching to standing, and if they do collide then keep the player in the crouching position.

I fired up Blender and moved my simple model into a crouching position, then I exported the image which I scaled and cropped with Gimp.  One other problem is that the player’s sprite is much wider (94 pixels) than the bounding box’s width (48 pixels).  I centered the sprite horizontally on the bounding box, but I’m going to leave the overhang for now.  I could go back later and make the bounding box when crouching 96×48, but I think that could result in the player getting stuck in some instances if not careful.