In my game, I have three differently-sized pink straight-line sprites:1x16 , one with a size of 1x120 , and the otherwith a size of 2x120 .
However, I’m encountering an issue where the ‘overlaps’ function doesn’t work when my sprite size is 1x120 . But when I create sprites with sizes 1x16 and 2x120, the ‘overlaps’ function does work.
What I want is for the ‘overlaps’ function to destroy the overlapped ‘badGuy’ whenever any size of player sprite overlaps it."
Here is the link to my test project：https://arcade.makecode.com/S01986-07977-86647-19137
1 Like
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
That’s fascinating. I’ll share with the devs and see if we can figure out what’s happening here.
2 Likes
Vegz78
October 4, 2023, 11:51pm
4
MakeCode:
That’s fascinating.
Gets even more fascinating! Look what happens a minute or less into the program…:
Vegz78
October 4, 2023, 11:51pm
5
Can’t let it go… Just tried all the way back to v0.9. Almost same result, some versions destroying some sprites further behind, but never exactly on overlap… I give up now.
…well i can tell you why the game slows down after a minute! you’re not destroying any of the sprites!
once you get to huge numbers of sprites the game engine will slow down.
1 Like
the missing overlaps behavior certainly seems like a bug. i bet it’s something to do with rounding errors… might explain why the slower game causes the overlaps to fire at certain x values.
1 Like
Vegz78
October 5, 2023, 12:06am
8
True! I experimented with less frequent game updates and slower moving BadGuy sprite, and that got more hits and sprites destroyed, but not all.
Glad and hope you are onto something with the rounding or whatever this might be!
Vegz78
October 9, 2023, 10:43pm
9
richard
October 9, 2023, 10:45pm
10
no, feel free to file it!
Vegz78
October 9, 2023, 10:52pm
11
Ok! -On the condition that it gets assigned. Deal?
richard
October 9, 2023, 10:54pm
12
i can’t guarantee that we’ll work on any issue immediately!
we’re working on an update for another MakeCode editor at the moment so arcade issues won’t be prioritized until after we’re done with that release.
2 Likes
