-SkyLock24- 2022-04-05 23:48
So I decided to give tile collusion a try and I tried using Cell.c commands to make this Sprite move only if the buttons are pressed and the cell.c returned is 0.
But the X still goes through the blocks.
Would someone please mind showing me how to fix this?
McPepic 2022-04-06 00:45
Hi! I know that tile-based collision can be a little confusing. There are several things to keep in mind while making it. Basically what your doing is checking one pixel at a time to determine if it is inside a filled tile, and you're definitely on the right track. I usually use a subprogram to check for collision:
SUB COLLIDE(X,Y,OUT)
OUT=CELL.C(X\8,Y\8)<>0
END SUB
This way, you can define the pixel (x and y) you want to check for collision at. You can define these coordinates as (first of all) the corners of your sprite. Your sprite is 16x16 in this case, though. This means that if there is a single tile, it can fit in the space between the pixels you're checking. This just means that you need to check some pixel spaces in the gaps to prevent a tile from getting through your collision checks.
I hope this made sense. Please feel free to ask if you have any specific questions.
was8bit 2022-04-06 01:58 (Edited)
Actually lets test a few things..
Take your code..
BG SOURCE ROM(3)
BG 0
BG COPY 0,0,32,16 TO 0,0
BG 1
BG COPY 0,16,32,16 TO 0,0
And try this..
BG SOURCE ROM(3)
BG 0
REM BG COPY 0,0,32,16 TO 0,0
BG 1
BG COPY 0,16,32,16 TO 0,0
what you discover is that BG COPY 0,16,32,16 to 0,0 is actually blank..
So BG 0 has the maze, and BG 1 is blank
Now, what is the last BG command, it was BG 1..
So when you do CELL.C command, it is checking BG 1, and it is NOT checking BG 0
CELL.C does NOT check both backgrounds, it will only check whatever the last BG # command was ....
BG SOURCE ROM(3)
BG 0
BG COPY 0,0,32,16 TO 0,0
BG 1
BG COPY 0,16,32,16 TO 0,0
BG 0
Will make it start working again :)
was8bit 2022-04-06 02:16
It is simpler to limit movement from cell to cell... pixel perfect movement it alot harder to do as lowresNX does not have a pixel background, it has blocks of cells...
I have reworked the movement to simulate smooth movement, but it also restricts movement from cell to cell...
was8bit 2022-04-06 02:22
The code has 2 modes...
1) not moving, so can take player input
... in this mode it awaits player input, and once it gets player input it loads up variables for the next mode, which sets it into the next mode
2) in this mode, player input is ignored, as it is busy smoothly moving the sprite into the next cell...
... once movement is finished, the code automatically switches to mode 1
DX,DY is the key... if both are zero, we are sitting still, so get input.... if one or both are not zero, we are moving....
was8bit 2022-04-06 02:24
If you've noticed, the code also allows for diagonal movement ;)
was8bit 2022-04-06 02:26 (Edited)
For an advanced look at this topic, i recommend this:
was8bit 2022-04-06 02:33 (Edited)
A little tip for finding problems..
To see things in real time, you can use TRACE..
example...
TRACE CELL.C(X,Y)
and be sure when running the game you turn DBUG MODE ON by tapping the upper right corner in touch screen ios devices, and you get to see the results in real time as you play test your game :)
was8bit 2022-04-06 02:34
Or...
TRACE X,Y,CELL.C(X,Y)
Would show x value, y value, and cell value, in one line ;)
G-9 2022-04-06 04:20
You can pass thru the walls by going diagonal on the corner ;)
was8bit 2022-04-06 04:55
Corners, yes ;)
was8bit 2022-04-06 04:56
Also, if 2 straight walls met together only on the diagonal, you can easily pass thru the 2 touching corners... a "trick" you can actually account for visually if the squares were actually rounded...
