320B color question

[Lillapojkenpåön]

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

 

 

[+Pat Brady]

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.

[Lillapojkenpåön]

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.

 

 

 

[RevEng]

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.