Lillapojkenpåön Posted November 13, 2020 Author Share Posted November 13, 2020 hmm, something is weird, I'm using the same code that worked in my 160A project, but something is wrong with the numbers it works something like this for collisions with the foreground tiles const playerHeight = 16 const playerWidth = 16 const playerHeightMinusOne = 15 const playerWidthMinusOne = 15 const tileHeight = 8 const tileWidth = 8 const tileHeightMask = %00000111 const tileWidthMask = %00000111 if !joy0right then skipRight playerX = playerX + 1 temp7 = playerX & tileWidthMask ; how far into the current column are we x = (playerX + playerWidth) / tileWidth y = playerY / tileHeight charValue = peekchar( tilemap, x, y, 28, 28 ) ; top right if charValue > bgTile then playerX = playerX - temp7 : goto skipRight y = (playerY + playerHeightMinusOne) / tileHeight charValue = peekchar( tilemap, x, y, 28, 28 ) ; bottom right if charValue > bgTile then playerX = playerX - temp7 skipRight The constants are correct, and up and down seems to work as it should, but when going right as in this case, it's as if the maze is exactly twice as wide as it actually is, you don't collide with the right wall until you're way outside it, I would have thought that the fix would be changing the tilewidth constant from 8 to 4, even though I don't get why when my tiles are 8 pixels wide, but that's not it, not only atleast.. since I start plotting my tilemap 48 pixels from the left, do I need to take that into account with peekchar? plotmapfile tiledMap28x28.tmx tilemap 24 0 28 28 ; 24 = 48 pixels because doublewide, i think? I think it's some combination of those two things and the fact that I don't fully get things yet, like for example there still only seems to be 160 horisontal positions for sprites in 320 mode. oh with that in mind I just changed these const playerWidth = 8 const playerWidthMinusOne = 7 const tileWidth = 4 const tileWidthMask = %00000011 and it gives the correct collisions but offset by 48 pixels as I suspected, I'm gonna eat something and solve this before I even post my question.. BOOM! const screenOffset = 24 x = ((playerX - screenOffset) + playerWidth) / tileWidth Quote Link to comment Share on other sites More sharing options...
+Pat Brady Posted November 14, 2020 Share Posted November 14, 2020 30 minutes ago, Lillapojkenpåön said: I think it's some combination of those two things and the fact that I don't fully get things yet, like for example there still only seems to be 160 horisontal positions for sprites in 320 mode. This is correct. From the Software Guide: "Another factor concerning 320 modes is that the horizontal positioning still happens like 160 mode. This means that in 320 modes, objects can only be positioned in 2 pixel increments." It makes sense: allowing 320 horizontal positions would require 2 bytes. If you really need 320 positions, you can use two bitmaps, one for even columns and one for odd columns. I'm doing that for the player sprite in 7ix because it helps with transparency artifacts, but in many cases it's probably fine to just move 2 pixels at a time. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 14, 2020 Author Share Posted November 14, 2020 Why doesn't this work? incgraphic playerSprite16x16.png 320B 0 0 3 2 incgraphic playerSprite16x16_2.png 320B 0 0 3 2 frameCounter = frameCounter + 1 if frameCounter = 60 then frameCounter = 0 : frame{0} = !frame{0} plotsprite playerSprite16x16 4 playerX playerY frame 2 first frame is good, second frame is half frame 0 and half frame 1, like inbetween them, tallsprite options doesn't improve it putting the frames next to each other in one png doesn't work and putting them under each other in one tall sprite gives the same result as this. My zoneheight is eight and my sprite is 16 pixels tall. Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 14, 2020 Share Posted November 14, 2020 Yeah, looking at my source, the tallheight parameter isn't quite as documented. It's been a while, but I think originally the parameter was made to overcome when a sprite is plotted prior to being incgraphic'ed. Basically it provides the zoneheight info that the incgraphic statement normally would. I'll need to have a look at updating it to work as documented. In the meantime, you can adjust your frames by the height (2 in your case) to get a proper result. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.