Calculating main character (sprite) over the background scenery

[Gibstov]

Here is an idea, if I can explain it in a way that makes sense. You could throw RAM at the problem.

 

Basically you have two sets of the background character set that you toggle between every VBI. This could give you more colors, but the plan is in one character set you outline all your floors in a chosen color, and none of the other background graphics use this color. And in the other character set, it doesn't matter you can use it as you want.

 

So then you could use the Jumpman method with the extra sprite, but only check for the ground collision on the VBI that has the floor color.

Edited April 11, 2019 by Gibstov

[emkay]

In a game like Limbo, where only 2 colors were used, it shouldn't be that hard to check, if the byte that is the 1st byte(s) in the direction of movement, where the sprites moves, is empty or not. If empty is a row of eight 1-s or eight 0-s, or 10101010 is depending on the use of the graphics.

To prevent the graphics from some irregular visuals(when walking ascending or descending) , the moving "sprite" should move one dot below the "ground".

Particular in Limbo, the background should be done in a parallax scrolling using PMg .

[Yaron Nir]

Here is an idea, if I can explain it in a way that makes sense. You could throw RAM at the problem.

 

Basically you have two sets of the background character set that you toggle between every VBI. This could give you more colors, but the plan is in one character set you outline all your floors in a chosen color, and none of the other background graphics use this color. And in the other character set, it doesn't matter you can use it as you want.

 

So then you could use the Jumpman method with the extra sprite, but only check for the ground collision on the VBI that has the floor color.

 

this could work, but would complicated things. i am searching for a much staight forward easy method.

 

thanks anyways

[emkay]

this could work, but would complicated things.

It would result in flickering graphics.

 

Depending on the Atari's CPU speed, using character mode or graphics mode is essential.

Limbo could easily be done in Antic F.

Using character modes, will result in some faster and more colorful graphics, but the character boundaries. have to be used , to have a benefit in the speed.

It's obvious. If you want to do a character mode based software sprites that moves as smooth as in a graphics mode, you may find yourself in a very small graphical box. 32 Bytes wide 100 lines high.

[+therealbountybob]

Jumpman uses a single PMG for the main character and uses collision detection to walk over arbitrary slopes. 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. 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... won't know till the next frame when it does the check again.

 

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.

 

It's a cool technique, but the cost is an additional PMG (or, I suppose you could do it with one player with a complicated variable-positioned DLI to reset the collision register for the scan line below the player's feet).

Nice thread :thumbsup:

As my latest game looks like it is turning into a platformer, whether I like it or not, I was also thinking about exactly this (above). In "Gwobby Strikes Back!" (turbo basic) I did the raises through one two playfields and stops on another, this would walk up a big slope etc but does bounce him around a bit. I liked Miner 2049'ers' walking up the slopes on level 1 and wondered how in that and in BBSB (which has the two playfields creating 3d effect) how he sticks to the plaforms so well?

[Yaron Nir]

 

 

Gwobby Strikes Back

 

i've looked at that game. the walking and sticking to the platform is not accurate as in limbo or jumpman game.

the jumpman technicque is indeed super fast , but, unfortunately, my beatemup game already uses entire 4 players and 4 missiles .....

[+therealbountybob]

 

i've looked at that game. the walking and sticking to the platform is not accurate as in limbo or jumpman game.

the jumpman technicque is indeed super fast , but, unfortunately, my beatemup game already uses entire 4 players and 4 missiles .....

yes it was just an example - I had uneven (and animated) pieces of the "raise" playfield in the floors but with a straighter/continuous line of the playfields maybe it would be fairly good

[Irgendwer]

Is there a common practice for this? I know how to convert the PMG unit into char unit and compare, but I want to get the effect of the sticky ground thing.

 

Someone could analyze "Spelunker" as this title does exactly what you want....

 

[emkay]

Someone could analyze "Spelunker" as this title does exactly what you want....

 

No. It doesn't.

The protagonist ist build on a Player, and the Playfield color "brown" is the collision register to react on, when "down" movement is checked.

Didn't he mention there is no Player or Missile left?

[Rybags]

I forgot all about Spelunker, much better example than Pharoah's Curse.

 

Very easy to test and hey presto! Disable all collision detections and the character still hugs the ground, elevators etc as expected.

 

The animated intro disk version has encryption, not sure about the other, so it might be easiest analysed while running.

[emkay]

I forgot all about Spelunker, much better example than Pharoah's Curse.

 

Very easy to test and hey presto! Disable all collision detections and the character still hugs the ground, elevators etc as expected.

 

The animated intro disk version has encryption, not sure about the other, so it might be easiest analysed while running.

What makes me wondering is there is a special Missile detection which Altirra doesn't disable.

[ggn]

What makes me wondering is there is a special Missile detection which Altirra doesn't disable.

 

And Atari800Win PLus 4

[emkay]

I was always impressed in the accuracy of the movement. It allowed a much better detail in controls and what happens on the screen.

 

OK. Prove me wrong...

 

In normal circumstances, the game reads the register, checking the content, and while a VBI happening, the game is acting on the result of the read, and then writing to the register for a reset.

 

What, if the game is doing the following, to assure the properly movement of the "sprite" ?

Starting an interrupt , writing the register to reset, check the bottom, read the register content and write the result into Memory then end the interrupt.

As you might recognize, the protagonist is doing a "down" correction, one pixel, if the "toes" stand in the air.

 

Is the emulation interfering the chip writes or just erasing the readable content?

[Rybags]

If Spelunker used collision detection then your man would be bouncing all the time due to position corrections after he lands from a jump.

That obviously isn't happening.

There are times when he seems to overlap terrain pixels but my guess there is that it's when they're in the adjacent character cell and not considered for the positioning calculation.

[dmsc]

It i easy to simply check in the charset if the pixel just bellow your P/M is used or not, check this simple FastBasic program:

 

' P/M walking test program

graphics 0          ' Setups graphics mode
pmgraphics 2        ' And P/M mode
P0Mem = pmadr(0)    ' Get player 0 address
oldPos = P0Mem      ' and into "old position"

mset P0Mem, 128, 0  ' Clears P/M 0 Memory
setcolor -4, 1, 15

' P/M data
DATA PMdata()  byte = $38,$44,$54,$44,$38
data AndTab() byte = 192, 48, 12, 3

' Initial Conditions
pos.2,14
? "|      \  ___        |"
? "| ------\_____/M-----M"
? "|"
? "M_____________________M"

do

xPos = 96 : yPos = 40 : blocked = 0

repeat
 ' Draw at current pos
 exec MovePm

 ' Generate new position
 j = stick(0)
 oldX = xPos
 xPos = xPos + (NOT (j & ) - (NOT (j & 4))

 ' Check slope
 exec CheckBack
 if blocked
   yPos = yPos - 1
   exec CheckBack
   if blocked
     yPos = yPos - 1
     exec CheckBack
     yPos = yPos + 1
     if blocked
       xPos = oldX
       yPos = yPos + 1
     endif
   else
     yPos = yPos + 1
   endif
 else
   yPos = yPos + 1
 endif

until Key()

poke 764, 255

loop

graphics 0

END

proc MovePm
 y = P0Mem + yPos
 pause 0
 pmhpos 0, xPos              ' Set new horizontal position
 mset oldPos, 5, 0           ' Clear old sprite
 oldPos = P0Mem + yPos
 move adr(PMdata), oldPos, 5 ' Draw at new vertical pos.
endproc

proc CheckBack
 xc = xPos - 45
 yc = yPos - 11
 xm = AndTab(xc & 3)
 ym = (yc & 3) * 2 + $E000
 xc = xc / 4
 yc = yc / 4
 pos = dpeek(88) + yc * 40 + xc
 char = peek(pos)  ' Char under sprite
 ym = ym + 8 * char
 p = peek(ym) ! peek(ym+1)
 blocked = p & xm
endproc

pmwalk.bas

pmwalk.xex

[emkay]

...

Looks good. Next step is to do that with with several objects, software sprites, scrolling... still curious, even if Spelunker might use something similar.

[Yaron Nir]

dmsc, thnx

 

please expalin the following calc in your above code:

proc CheckBack
 xc = xPos - 45
 yc = yPos - 11
 xm = AndTab(xc & 3)
 ym = (yc & 3) * 2 + $E000
 xc = xc / 4
 yc = yc / 4
 pos = dpeek(88) + yc * 40 + xc
 char = peek(pos)  ' Char under sprite
 ym = ym + 8 * char
 p = peek(ym) ! peek(ym+1)
 blocked = p & xm
endproc

[dmsc]

Hi!,

 

dmsc, thnx

 

please expalin the following calc in your above code:

proc CheckBack
 xc = xPos - 45 ' gets X and Y position of the pixel in playfield for the
 yc = yPos - 11  ' corresponding pixel in the P/M, adjust with the correct shape!
 xm = AndTab(xc & 3) ' gets the position inside the character mode for the pixel
 ym = (yc & 3) * 2 + $E000 ' for Y, we also add the chbase value
 xc = xc / 4 ' gets the character, assuming 4x4 pixels (P/M have half resolution)
 yc = yc / 4
 pos = dpeek(88) + yc * 40 + xc ' and the address of the character in screen memory
 char = peek(pos)  ' read the character at the address
 ym = ym + 8 * char ' gets address of memory for the character data
 p = peek(ym) ! peek(ym+1) ' read the byte and beloow
 blocked = p & xm ' and use the mask to get the pixels
endproc

 

[Yaron Nir]

dmsc tnx!

 

clearly i need more info,

 

so let me break the questions down:

xc = xPos - 45 ' gets X and Y position of the pixel in playfield for the
yc = yPos - 11 ' corresponding pixel in the P/M, adjust with the correct shape!

Why minus 45 and minus 11? this is graphics 0 correct? so it is 24 lines of 40 chars right? so i am not sure what is this calculation

xm = AndTab(xc & 3) ' gets the position inside the character mode for the pixel
ym = (yc & 3) * 2 + $E000 ' for Y, we also add the chbase value

this i don't undestand at all. if you can explain exactly what is done here it would be helpful

xc = xc / 4 ' gets the character, assuming 4x4 pixels (P/M have half resolution)
yc = yc / 4
pos = dpeek(88) + yc * 40 + xc ' and the address of the character in screen memory
char = peek(pos) ' read the character at the address

this i perfectly understand

 ym = ym + 8 * char ' gets address of memory for the character data
 p = peek(ym) ! peek(ym+1) ' read the byte and beloow
 blocked = p & xm ' and use the mask to get the pixels

this i don't get at all

[R0ger]

The first part with xc and yc just adjust the coordinates. PMG has 48 invisible pixels on the left, and 16 on top (both depends on dlist and screen width). So if you want to convert PMG coordinates to playfield coordinates you have to adjust for that. I usually just use good old trial and error method for correct amount

 

As for the rest, it seems you are confused by & sign. That's for bitwise AND. It's used for getting bits of a number .. X and 3 for example extract bottom two bits, as 3 is 00000011.

Here it is used for modulo. XC & 3 is the same as XC mod 4. Note this only applies for numbers 2^x (2,4,8,16,32 etc).

 

I'm not sure what AndTab does either.

[dmsc]

Hi!

 

The first part with xc and yc just adjust the coordinates. PMG has 48 invisible pixels on the left, and 16 on top (both depends on dlist and screen width). So if you want to convert PMG coordinates to playfield coordinates you have to adjust for that. I usually just use good old trial and error method for correct amount

 

As for the rest, it seems you are confused by & sign. That's for bitwise AND. It's used for getting bits of a number .. X and 3 for example extract bottom two bits, as 3 is 00000011.

Here it is used for modulo. XC & 3 is the same as XC mod 4. Note this only applies for numbers 2^x (2,4,8,16,32 etc).

 

I'm not sure what AndTab does either.

The table is basically a mask with 3*4^(3-i), the bits you need to check for a give pixel: 11000000, 00110000, 00001100 and 00000011.

 

Regards,

[Yaron Nir]

I am pretty familiar with bitwise AND. I just wast sure where did the fixed numbers came from but after the explanation it makes some sense.

 

The demo seems to be working pretty well.