The current flap strength makes the game a lot more difficult than
other flappy games. Decrease the flap strength to make it a little
easier to get higher scores.
Before this change I could only get past 3 or 4 obstacles, now I can
get 15 or 20 in, which seems more on par with other flappy games.
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
This also has the added benefit that after a restart we don't get the
same random numbers all the time because we forgot to initialize the
RNG with srand().
Applications previously had to create a GUI::Menubar object, add menus
to it, and then call GUI::Window::set_menubar().
This patch introduces GUI::Window::add_menu() which creates the menubar
automatically and adds items to it. Application code becomes slightly
simpler as a result. :^)
The game doesn't handle resize events.
It's a pretty lazy fix. The proper way would be to actually allow
the game to be resized, with some scaling trickery, but most games
here don't do that anyway, so I guess that's good enough.
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
This matches basically all other Spider implementations I've played,
and makes playing much easier :)
I have left click-to-reveal in place, but mostly incase there is a
condition I've forgotten about.
Scoring is designed to mimic Microsoft's implementation - starting at
500, decreasing by 1 every move, and increasing by 100 for every full
stack.
Fixes GH-5319.
The crash happens very rarely and is hard to reproduce so it is
hard to know for certain, but I am confident this fixes it.
I previously delayed the start of the game-over animation by one
frame, but neglected to check m_start_game_over_animation_next_frame
wasn't set. This means multiple calls to start_game_over_animation()
on the same frame (or rather, before the first timer_event) would
each call Object::start_timer(). Now that we do check the flag,
that should no longer be possible.
Fixes#8122.
Better information is now shown to the player. Instructions are shown
when first loading the program, and any available scores are shown on
the game over screen.
