Activity for Michael Speck
-
Michael Speck created a blog post
New LBreakout Levelset
-
added new levelset Picky
-
Windows Ports
-
LTris 2.0.1 Released
-
LTris 2.0.1 Released
-
updated JustGoForIt
-
ltris2: segmentation fault on launch (GNOME/Wayland on openSUSE Tumbleweed)
-
Hi, thanks for the feedback! I'm back now and right after a system update I ran into the same problem. Libgame's dummy surfaces used a bad hardcoded pixel mask and weren't always created. Should be fixed now (also added some error messages). Thanks for the patches, I applied both, although I slightly changed the latter one. I can't remember properly but there was an issue with not expanding the ~, so it is always expanded now. There will be a release in the near future but you can already test it...
-
Build failed. Outdated config.guess and config.sub file in the last release of LBreakout2.
-
LBreakout2 is no longer supported, please try LBreakoutHD.
-
LTris 2.0 Released
-
LTris 2.0 Released
-
LBreakout2/HD Levelset Update
-
updated levelset JustGoForIt by anonymous
-
LBreakoutHD 1.1.9 Released
-
tagged release lbreakouthd 1.1.9
-
ltris: gamepad: Interpret gp_pause to pause during game.
-
Thanks for pointing out, I've applied it. :)
-
added missing check for gamepad pause button
-
LPairs 2.3.1 Released
-
LPairs 2.3.1 Released
-
tagged release lpairs2 2.3.1
-
added menu button
-
allow right mouse button to restart game
-
Sure, I just released 1.3.2.
-
LTris 1.3.2 Released
-
tagged release ltris 1.3.2
-
[ltris] cross-compiling broken again with aarch64-buildroot-linux-gnu-gcc
-
Well, I don't know what the issue was but now it works again. AM_PATH_SDL invokes AM_PATH_PROG for sdl-config and sets SDL_CONFIG properly. The actual sdl.m4 was missing so maybe this caused the issue. I've added it. If there are any troubles in the future I'll just use your workaround and remove the macro. But I guess I just made some mistake... So please test the latest commit. Thanks!
-
use AM_PATH_SDL and SDL_CONFIG again
-
Not yet, but it should work. The question for me is why does the AM_PATH_SDL macro does not work anymore? Because that is supposed to set this variable, also for cross compiling. I tested it on a different computer with a new sdl.m4 but same result... Or do you set SDL_CONFIG via command line? I think in two weeks from now I have some time to look into it. If possible I would like to get AM_PATH_SDL to work again otherwise I will apply your workaround. Thanks, Michael
-
Exactly, but it might take a while for a new release. But you can checkout the latest commit from Subversion.
-
lbreakouthd 1.1.8: non-standard icon location for Linux
-
Yeah, that's already reverted. I thought it wasn't working properly, but it does.
-
updated icon location
-
install icon according to specification
-
LBreakoutHD 1.1.8 Released
-
[lbreakouthd] Collision detection failures
-
tagged release lbreakouthd 1.1.8
-
updated german translation
-
removed m4 directory from Makefile.am
-
don't get target for stopped ball
-
I reverted it because SDL_CONFIG is not defined and it won't compile for me with it. I had to remove sdl.m4 since it was outdated. If I'm right that macro defined SDL_CONFIG. So how to properly get SDL_CONFIG defined?
-
configure option to select clipping algorithm
-
added simplified ball get target algorithm
-
LBreakoutHD 1.1.7 Released
-
LTris 1.3.1 Released
-
tagged release ltris 1.3.1
-
updated german translation
-
updated german translation
-
changed winner message
-
show stats for all players after game finished
-
properly increase level in game mode Figures
-
fixed bug in creating figures
-
properly install icon
-
leave game over screen only with ESC, SPACE or RETURN
-
removed AC_CANONICAL_TARGET from configure.ac as it breaks mkinstalldirs
-
updated icon location
-
Updated LTris AppStream metadata
-
thanks, applied!
-
Updated LTris AppStream metadata
-
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...
-
fixed another bug in ball reflection
-
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.
-
don't round positions in debug messages
-
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.
-
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...
-
fixed potential crash when reading empty lines
-
properly read windows files in preview and editor
-
updated levelset JustGoForIt
-
properly read level preview from windows levelsets
-
"burning" is the one going through bricks, right? or the red explosive one?
-
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.
-
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...
-
LBreakoutHD 1.1.7 Released
-
tagged release lbreakouthd 1.1.7
-
added levelset JustGoForIt
-
return ball to paddle for illegal targets
-
fixed bug in Invaders
-
fixed mini game Invaders
-
[lbreakouthd] Collision detection failures
-
Also Invaders is broken, a wave should end after 20 cleared bricks, not when all bricks are cleared, I will fix this as well.
-
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...
-
reset brick position if inside a brick before getting target
-
show trajectory of balls when debugging is enabled
-
reenabled bug report, removed option linear_corner and adjusted corner position and size
-
LTris 1.3 Released
-
added comment
-
some more indentions
-
formatted ball_get_target
-
properly handle carriage return for levelsets made in windows
-
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.
-
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...
-
LTris 1.3 Released
-
LTris 1.3 Released
-
tagged release ltris 1.3
-
updated tooltips
-
added new eval parameter clear for tetrises
-
verbose test stats include clears
-
demo uses hold if style modern
1 >