Platforming and Collision Code

[Connors]

I've re-updated an older version of an unfinished tile engine beta. And if you can believe that...

I'm attaching the file as it is so far. Use with SC 2.0b3.1. The collision is near perfect except at absurd speeds. I'm going to have to tweak it if/when I add enemies but the collision and "physics" code should work with many objects!

Always save incrementally gentlemen. It could save you hours of work.

The biggest difference is I changed the collision code to output what tiles each corner is hitting for x and y, for a total of 8 variables in the array called cp$(). The array helps me check more than one with ease.

Oh and i scribbled a new logo on top of the old one because i got bored.

[Connors]

I've got a peculiar bug to pin down in my collision code where he reaches the edge of a block and snaps to the edge of the next one over. This is because somewhere it returns the wrong tile to stop at the edge of.

It is most easily recreated by running to the left starting from a standstill over the tops of the single blocks in a row.

My only leads are that it seems to only occur if x and/or y speed is negative, and if you are hitting the corner of a tile. It is the same bug that on rare occasion makes you warp upwards onto a ledge if you hit a lower right corner. Which could be a total game breaker.

[Gan]

Biggest issue I've found is the Command key is a bad jump key. Cause when I move and jump, it flips my screen into Dash Board.

I'm still trying to recreate the bug you experienced.

Edit: I can see it. Hmm. I'm going to have to do a screen recording and slow it down to take a closer look.
Video: http://cl.ly/2G3Y07080R3B

So strange.If you move too fast the bug doesn't happen. If you move just slow enough.... he skips to the left. Interesting.

Edit 2: I've pinpointed the bug. It is in this chunk:

Code: [Select]

IF xvel(obj) < 0 THEN
   //left
   LET nextx = ( xpos(obj)+xvel(obj) )
   FOR n = 0 to 1
      LET nexty = ( ypos(obj) + (sizey(obj)*n) ) -(1*n)
      
      LET cp$(5+n) = maptile$(mapx(nextx),mapy(nexty))
      
      IF cp$(5+n) = "1" THEN  //
         LET xvel(obj) = 0
         LET xpos(obj) = mapx(xpos(obj))*32-32
      END IF                                                                    //
   NEXT
END IF

Now if I comment these two lines, the game appears to play the same, but without that jumping:

Code: [Select]

IF xvel(obj) < 0 THEN
   //left
   LET nextx = ( xpos(obj)+xvel(obj) )
   FOR n = 0 to 1
      LET nexty = ( ypos(obj) + (sizey(obj)*n) ) -(1*n)
      
      LET cp$(5+n) = maptile$(mapx(nextx),mapy(nexty))
      
      IF cp$(5+n) = "1" THEN  //
         //LET xvel(obj) = 0
         //LET xpos(obj) = mapx(xpos(obj))*32-32
      END IF                                                                    //
   NEXT
END IF

[Connors]

Yes Gan you have effectively disabled him stopping when he detects a wall on the left.
I'm almost certain it has to do with my maptile$() method. All collision does is if his next position, based on velocity, would be inside a wall, he instead stops at the edge of that tile. I think I have some more things I can try now actually.

[Gan]

Ah hahah.    So that's what that code does....

Hypothesis:
That code makes him stop from going into a wall on the left side.
The movement skipping only happens when he's moving left at half max speed.
Half max speed means he'll still go over the tile, but he drops ever slightly mid-gap.
Lets say he is moving left at half speed. He drops a few pixels into the gap but he's still moving fast enough to the left. Then collision happens, but another piece of code sees that he's not low enough so he can still go on top. Therefore the other piece of code hoists him up back on top, while the left collision block code still activated, saying he should stop at the block edge. But cause his position was hoisted up, it snaps him to the opposite edge.

That's my hypothesis why the snapping doesn't occur when you disable the left blocking code.

[Connors]

Well Gan you're right about the cause, but it was a side effect of me using a weird position for mapx(). Mapx() and mapy() return the tile map coordinate of an x or y position, respectively. I have code that snaps him to the edge of the tile he is on so he hits the wall. I checked the map position with the very edge of his sprite not knowing that it could overlap and return the coordinate of the next tile. I have fixed the bug by giving mapx/y() a coordinate toward the center of the tile.

[Gan]

Epic sauce!

I suppose the next step would be to fix tunneling.
If you fall in an endless loop, you eventually move fast enough to go straight through a block.
Therefore I propose to make the logic steps into a for loop that runs steps in small increments depending on velocity.
For example, hardly moving and it does 1 logic step per timer tick.
Moving fast then chops the frame into 10 logic steps per timer tick.
So each logic step is pretty much the same amount of (tiny/incremental) movement so block dude doesn't skip over any blocks.

[Connors]

Actually I'm just gonna put a cap on velocity that's less than the size of tiles. The speed required to warp through a tile is far greater than a reasonable limit.

[Connors]

I'm trying to make the game decide which tile to use based on what tiles are nearby, so that they fit together. If nothing's above it, it's grassy, if nothing's below it, it's got a rough bottom, if nothing's above or below it has both, otherwise it has neither. That's only four sprites. And guess what Gan? If I try to do checks above and below it draws everything in the wrong place. It's impressively glitchy considering it should only draw a sprite if the FOR loop's on a solid tile.

[Connors]

I'd like you to run the program, and then comment out the following in the method " drawmap " and tell me why this makes it draw all tiles 1 square beneath.

Code: [Select]

         IF maptile$(x,y-1) = "1" then
            LET sprite$ = "above"
         END IF

[Gan]

Fixed!

Turned out to be a problem involving how SilverCreator handles global variables.

This is your code:

Code: [Select]

LET sprite = 1
LET windowTXT$ = "Start"
FOR x = 1 to 25
   FOR y = 1 to 18
      LET pic$ = maptile$(x, y)
      IF pic$ = "1" then

         LET sprite$ = "neither"
         IF maptile$(x,y-1) = "1" then
            LET sprite$ = "above"
         END IF
         
         CREATESPRITE sprite, sprite$
         MOVESPRITE sprite, x*32-32, y*32-20, TRUE
         LET sprite = sprite + 1
      END IF
   NEXT
NEXT

Notice how you call maptile$(x, y-1)?
Now look at the maptile method code:

Code: [Select]

IF x < 26 then
   IF x > 0 then
      IF y < 19 then
         IF y > 0 then
            LET tile$ = NTHFIELD$(map$(y), ",", x)
            RETURN tile$
         END IF
      END IF
   END IF
END IF

The problem is that all variables in Sc are global. And cause in Sc you have X and Y as parameters for this method, when you call maptile$(x, y-1), you are setting x = x and y = y - 1.
That is why there is that offset!

Easy fix, just change the method to this:

Use different non-used variables for the parameters. x1 instead of x, and y1 instead of y.

[Connors]

Isn't this a bug?
I've NEVER had variables change when I used them for parameters. Plus if you toy with the original file one more time you'll see that using (x,y+1) doesn't mess it up!

[Gan]

This is certainly and interesting predicament.
Though it appears to be on the safe side, it is best to use different variables for parameters.

Anywho, can you change the jump key? It is a tad annoying.

[Connors]

I think it's still affecting my FOR loop if I do checks within that since I had array out of bounds errors.
EDIT: Fixed, thanks to Gan. Don't know how I got outside the field of play but NOW IT'S OK.
I'm finishing the magic tile alignment thing.
EDIT: IM POSTING THIS B*TCH.
CAPS = ENTHUSIASM.

[Zoo]

add a goal, make a level editor. I will help.