Vegz78
October 2, 2023, 5:49pm
2
Wow, this was a difficult challenge, at least for me, who exhausted my attempts to wrap my head around around a solution…
It is such a trivial example that really should work well, and I am starting to suspect that this could possibly be some kind of small bug and/or maybe a case for the the experts, like @jwunderl , @richard , @shakao and others at the @makecode team?
Has it to do with any of these subjects?:
opened 06:19PM - 19 Jul 20 UTC
closed 10:13PM - 22 Jul 20 UTC
I have a Pacman game that within the last few weeks of updates to Arcade Beta ha… s stopped working properly. I believe the bug is in combined updates to change pxt-common-packages/libs/game/physics.ts and sprite.ts.
Here are two test cases:
1. Keep refreshing the gameboy and watch the ghost move to the right. When the ghost hits the right corner of its maze, it can move down or back the way it came. If it ever decides to move down, it gets "stuck" on a wall of the maze, setting its velocity to 0 and preventing our game logic from enabling it to continue moving.
https://makecode.com/_JCD3RAYmkA7d
2. This program is the same as the previous, except we added a pink border to the righthand edge of the ghost sprite in the sprite editor. This expands the ghost's hitbox on the right. Now, if you watch the ghost, it will never get stuck on the wall of the maze, no matter what direction it tries to turn.
https://makecode.com/_19Rgj9emMCRm
I'm unsure of what the exact cause is, however, looking in the checkin history for physics.ts and sprite.ts, I notice two suspicious changes. First, in sprite.ts, the accessors for x, y, left, right, top, and bottom no longer return rounded integer values for the position of the sprite, but instead return unrounded floats. Second, there's been an addition to the tilemapCollisions() code in physics.ts that starts with the comment "// Now that we've moved, check all of the tiles underneath the current position for overlaps" that appears related.
The main effect the change to sprite.ts had was on my extension abegel/pxt-turtlelogo. I have a function called spriteContainedWithinTile(Sprite) that checks whether the left and right (and top and bottom) when mapped to the tilemap coordinate system are equal to one another, indicating that the sprite is wholly within a single tile and can now change directions in my rectilinear maze without inadvertently hitting a wall. The change to left, right, top, and bottom produced different answers because the old values were "rounded" (e.g. (val + 128) >> 8) vs. the new values which are not rounded (val / 256). I modified my code to round the numbers since in the cases where the value was close to the edge of the tile coordinate, it gave different results.
However, this only fixed part of the problem. I believe there's some additional change to the collision logic in physics.ts that is causing the sprite to get stuck on a block that it should be able to smoothly pass without touching.
Can you help me figure this out?
Thanks!
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
Add screenshots to help explain your problem. You can copy paste the screenshot in the github report. The .gif screen recording is very useful as well.
**Desktop (please complete the following information):**
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]
**Smartphone (please complete the following information):**
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Browser [e.g. stock browser, safari]
- Version [e.g. 22]
**Additional context**
Add any other context about the problem here.
opened 06:08PM - 28 Apr 23 UTC
enhancement
physics
We should extend the physics engine to support overlaps handlers that are sync a… nd not in a separate thread. We don't need to add a block for it, but it should be available in ts so that I can add a block in an extension.
The scenario where this causes trouble is projects like these:
https://arcade.makecode.com/S45144-04924-72402-03834
This uses an overlap event to resolve collisions, but because it's async you see one frame of the sprite overlapping with the platform even though all code in the overlap handler is synchronous.
https://forum.makecode.com/t/problems-with-overlap/16442/3 https://forum.makecode.com/t/how-to-debug-performance/8681/2