#106 [lbreakouthd] Collision detection failures

[Alex]

Hi, Michael.
After playing LBreakout HD for months, I identified cases when the ball missed a brick or a wall:

(1) In Invasion, when the brick was moving down, and the ball was moving up.
(2) At least in some bonus levels, the brick hit a side wall and the level ended as if the ball was lost.

I thought it could be corrected by some new collision detection (check collisions between trajectories rather than between objects?). However there's another interesting type of collision failure:

(3) In Outbreak, the ball flew through a perfectly static brick, at the exact moment when another brick appeared nearby.

Now I'm guessing that there could be some moments in the game loop when the list of potential collisions gets empty?

That could be a reason for such an effect...

[Alex]

PS. Or maybe the program gets busy in some moments (with things other than collision detection) and doesn't do it in time?

[Michael Speck]

Yeah, that's a tough one... actually it uses trajectories. It computes the target position and travel time. If exceeded the ball gets reset, so it should work with lags as well. Whenever the ball speed changes or bricks change it gets recomputed.

(1) If a brick moving down leads to a ball within that brick, then the ball tunnels through it as only the next bricks in it's way are checked. I guess, that's what you observed? (It's a bug)

(2) Might not be a bug, depends on the mini game. Some do end if you miss the actual target like in Sitting Ducks. I would need a more specific description or video to tell.

(3) That sounds definitely like a bug. A new farther out brick should not lead to a different target if the current target didn't change. Was the ball very close to the first brick? Might be a rounding error then.

I'll look into it but can we assume it only happens with the mini games or do you observe problems in regular levels as well?

[Alex]

(1) Yes.
(2) No, I know, for "Sitting Ducks" it would be normal. It happened in "Hunter", for example. I hit the ball, it hits the side wall and I expect it to be reflected, but instead the ball disappears as if it was lost through the bottom.
(3) Yes, the very moment when the ball would touch the bottom of a brick, another brick appeared at about 2 bricks distance, approximately ahead, and the ball just flew through the first brick.
(I don't recall the ball flying through a static brick before, so it could be just a coincidence that it happened the moment another brick appeared... But that made me think that some moment in computational stage/loop could have something to do with that).

I'll look into it but can we assume it only happens with the mini games or do you observe problems in regular levels as well?

May be. I'm not sure about regular levels, as it was very rare, and I thought it was a general "wall problem", in mini games and regular levels alike, so I didn't pay attention which levels those were. From now on, I'll keep an eye on that.

[Alex]

PS. OK, disregard "the walls problem" for now. I'll need to investigate more. ..

[Michael Speck]

Hunter ends when the "Hunter" brick hits a wall inside the cage. Maybe that just randomly coincided with the ball hitting the wall?

It sounds like (1) and (3) can be fixed with resetting a ball along its trajectory in case it somehow ended up inside a brick before recomputing the target. I should be able to take a look at it during Easter holidays.

[Alex]

Hunter ends when the "Hunter" brick hits a wall inside the cage

Rather I didn't notice that the timer was expiring. I'll try to re-test it recording video. For now, let's consider "the wall problem" unconfirmed. Though I think once it happened in some other level, when the ball reached the top and disappeared. Still, I don't want to burden you with this without proof. :-)

It sounds like (1) and (3) can be fixed...

Thank you very much. thumbs-up

[Alex]

PS. Here, I think I caught one case of that ball disappearance. It seems that when the ball comes into a corner, it increases chances for such event. Here it was a corner between the wall and the paddle. Before that, I recall, it was a corner between the side wall and the horizontal brick barrier (also in a "Hunter" level).
If you still have problems with AVC codec, I can encode the video with some other, just say which one.
https://easyupload.io/w18dud

[Michael Speck]

OK, it took me quite a while to understand, what I did 20 years ago when I wrote the reflection code... it's not pretty. Anyways, I found (and fixed?) a bug in the brick corner check with potentially undefined behavior. But it won't explain what you recorded as far as I understand it, so I don't know if it fixes the issue. But maybe it does. I re-enabled and extended some debugging info. If you configure with --enable-debug it gets available. I also added a visualization of the ball trajectory and target to see if there are weird target changes. And if inside a brick the ball gets reset before getting the target. I tested it with Invaders and it seems to work quite alright, I could record one occasion. So yeah, maybe you can get the latest version from Subversion and run a few games from console in window mode? This way, when recorded, you can see the debug info directly if something strange happens. I played a while in normal sets and nothing bad happened except a lot of "corner to side"-warnings and sometimes the reset position for corners is off. So maybe after all the bug in the corner check was the problem, although it does not explain, why the game immediately stops. I would rather except the ball to tunnel through the paddle or bricks and exit the screen instead. But maybe if it happens again the additional info and trajectory will shed some more light on the issue. Thanks!

[Alex]

Actually I observed a few days ago (in Outbreak I think) when a ball hitting the left wall (with a sharp angle, about 40 degree, from above) was not reflected, but flew visibly on top of the wall until going off screen. I didn't record it.
I think those things happen more often in bonus levels because I use "turbo" key there often (in regular levels I don't use turbo key that much, especially when hitting walls).
Anyway, thank you. It's a very nice game.
I'll probably test the new version soon.

[Michael Speck]

Also Invaders is broken, a wave should end after 20 cleared bricks, not when all bricks are cleared, I will fix this as well.

[Michael Speck]

Interesting. I already replaced the old "time based" target check some time ago, so the speed of a ball shouldn't matter. But a mix of angle, position and rounding errors might cause it. Anyways, as a final workaround for this release, it checks whether a ball has an illegal target and returns it to the paddle if so. So at least you should not lose the ball any more, even if it happens again. But something has been fixed, so maybe it's good now. :) And it was fun to dig into this very old part of the code. So I'll leave this ticket open for another while. If I don't hear back from you I'll close it.

[Alex]

Standard Level 36: the ball jumped through a thin "wall" of bricks.
That level has 2 large horizontal areas of green "restoration" bricks.
When the lower area was partly destroyed, and just one brick thick "wall" remained, the "burning" ball had to hit bricks from below, but appeared behind them. Output:
...
Creating main window with 1920x1200, fullscreen=1
Loading theme /usr/local/share/lbreakouthd/themes/Standard
Added player Alex
LBreakoutHD v1.00: 37 levels
unknown: 13,2: w
unknown: 13,4: w
Game saved to /home/dad/.lbreakouthd/lbreakouthd.sav
Mixer closed
Finalizing SDL
...

[Michael Speck]

Did you configure with --enable-debug? Sounds very much like a bug in the new "reset if inside brick" stuff but that would generate a debug message. If you haven't enabled it can you please do so? If you dislike the trajectory you can remove it from code in view.cpp at line 1713.

[Alex]

With enabled debug it quits saying:

lbreakouthd 1.1.7
Copyright 2018-2024 Michael Speck
Published under GNU GPL
---
Bug reports enabled
---
Loading configuration /home/dad/.lbreakouthd/lbreakouthd.conf
/usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1246: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; reference = char&; size_type = long unsigned int]: Assertion '__pos <= size()' failed.
Aborted

[Michael Speck]

"burning" is the one going through bricks, right? or the red explosive one?

[Alex]

The explosive. Sorry I forgot to use "enable-debug". facepalm
I'm gonna recompile now and report later with more info.

[Michael Speck]

Ok, that's hard to tackle... . Looks like an illegal position, when accessing a string with []. It works for me since this assert is not present for me. I cannot trigger it with buggy code. Please try the following (only one step at a time):

1) Checkout the latest version from SVN. I fixed something which could lead to such a crash when reading empty lines from a file just a few minutes ago.

2) make clean; make (sometimes inconsistent compile flags cause such trouble when linking)

3) put #undef WITH_BUG_REPORT (but --enable-debug is still on for configure) at top of tools.h right after the #ifdef ... #define stuff
if this works it narrows it down to some debug message (though very unlikely) but you also won't see debug messages

If all fails: Either your debug gcc stuff is buggy (unlikely) or I have an out of bounds string access anywhere in the code which my gcc debug version doesn't care about since out of bound access just leads to an empty result for me. In that case: The only way to find it is debugging and see where exactly the bad access occurs. Nearly impossible to find it otherwise. Are you familiar with debugging?

[Michael Speck]

Ok, I wasn't thinking straight yesterday: If 1) - 3) doesn't work just compile without --enable-debug and manually set WITH_BUG_REPORT by adding #define WITH_BUG_REPORT in tools.h line 17. Actual debugging is not used for the messages I just combined it to have only one configure option.

[Michael Speck]

Actually, can you please checkout from SVN again first, please? I think this is about rounding errors so all decimal places are no shown in debug messages. Previously, I did some rounding.

[Michael Speck]

Ok, I think I've got it. Had a good idea today while being away and just implemented it. I also created a small debug level (attached) with tons of walled up balls. And indeed if I speed them constantly up I get quite a few "inside brick" messages. But now hits opposite the moving direction are ignored so if a ball ends up in a brick after reflection it doesn't matter anymore. That's what caused the "tunneling effect" because the ball got reset at the wrong side of the brick it just got reflected on. And with 90+ balls on crack for 3 minutes I did not get any illegal exits. So I think this is fixed. Except for chaotic reflections from corners. Then there is a chance for the "target but no target" bug which I haven't seen in many years. But the ball gets returned in this case so it is not game breaking and extremely rare. So please try the latest SVN checkout and tell me it works. ;-)