5/21/2023 0 Comments C64 sprite master![]() ![]() ![]() If the shadow has a collision with the floor color and the player also has a collision with the floor, the Y position is decremented because the character's foot is touching the floor and must be going uphill. won't know till the next frame when it does the check again. If the shadow doesn't have a collision with the floor color, it increments the Y position of the character, which could mean the character is falling or just going down a slope. ![]() The method used requires sacrificing a 2nd PMG as a one pixel high "shadow" below the Jumpman character that tracks what the character is walking on. Jumpman uses a single PMG for the main character and uses collision detection to walk over arbitrary slopes. I would like to know if there is a better way? But I use this routine to get all tiles for the 3 surrounding places depending on the direction. I can optimize this by knowing that floor is always direction bottom right, bottom, bottom left. Then I compare these tiles coordinates to the map at the exact position and if it is floor - all good. So each frame (WSYNC) I set the 3 tiles at the current moment depending on the direction of the sprite into an array. So for each of the 8 direction the sprite could move I have 8 times 3 tiles that I can compare against. įor example, if sprite moves right then the following 3 tiles will be checked : upper right, right, bottom right. Now I came to an understanding that the best way would be to determine to which direction does the sprite move and always user 3 tiles surrounding to that direction. using the collision HE detection is also not good as the empty tile is combined from the transparent color and I use tile to draw it. since this is a multicolor mode and scenery is combined from tiles with several colors per character inside a tile (4 chars equals a tile) I cant compare with background color by itself as it is used for other graphics in the scene. ![]() I am building the char with tiles and I have a map of tiles Of the screen. Sooo wrathchild you truest understood my post These can be looped through to determine which is relevant based on x-position and then an in-or out of check done done based on the y-positions and a correction to the player's ypos made appropriately. To assist with that here are the main questions to consider:ġ) Is the main character going to be implemented with software or hardware sprites.Ģ) If using h/w sprites, do you want to take advantage of player/playfield collision detection.ģ) Are the 'floors' going to be of a specific color or will that colour also be used within background graphics.Īs a very basic example, a simple test is to start with a scene where the player is placed above the floor with some artificial gravity to increment the y-position if not on a floor.Ī) In the h/w sprite realm, the detection of a sprite being in collision with a floor colour can lead to, say, subtracting 1 away from the y-position.ī) In a s/w sprite realm, the detection of the sprite being in collision with a floor colour is done by 'peeking' the pixel colour below and where the feet are drawn, again reacting accordingly.Ĭ) A alternative (and perhaps useful in the Limbo example due to the foreground graphics having the same colour as the floor) is to use a set of rectangles to mark game areas. I think the OP needs to be a little more specific on which way he wants to go as the A8 is going to present various ways of doing this in s/w. Tutorials etc on YouTube tend to be geared to modern engines that are handling sprites in a more abstracted way and so aren't so useful in this case. The OP has given Limbo as an example, he's more after the algorithms for handling such animation. ![]()
0 Comments
Leave a Reply. |