The Sprites class has been given direct access to the screen buffer so it
doesn't need a pointer to been given to it.
Also updated README.md and keywords.txt, and made minor indent changes in
the .h files.
- Version changed to 2.1.0
- Added sprite, button and collision functions from ArduboyExtra
- Added drawCompressed() function from Arglib
- Updated LICENSE.txt
- Removed CONTRIBUTORS.md (now covered by LICENSE.txt)
- Changed banner name from ARAKNOID to BREAKOUT.
- Set frame rate appropriately for the corrected nextFrame() function.
- Removed dead and non-functioning code.
- Cleaned up save, load and display of high scores.
- Made pausing the game work.
- Display the achieved score on the "game over" screen.
Also: Minor refactor of function nextFrame()
A change made to nextFrame(), from the Arduboy library, caused it to not work
correctly. The original version works as designed.
Also:
- Changed longs to unsigned longs for better type matching.
- Removed the frameRate variable. It was being set but never used.
- Added a missing return value to the write() function.
- Changed a int8_t to uint8_t in function lcdCommandMode() to address a
compiler warning.
- Rearranged the specification of the font[] array to address a compiler
warning.
paintScreen() used instruction padding for a delay to allow a byte to be sent
to the display using SPI. This delay became to short with the new gcc version
in Arduino IDE 1.6.10
The function has been changed to test for the serial transfer to complete
before sending the next byte.
Mainly to give an indication that the device is in "flashlight" mode
for units that have the RGB LED installed reversed.
Also, the test for the UP button is moved to within flashlight() itself.
Instead of PWM, basic digital output is used to control the RGB LED in the
bootLogo() and flashlight() functions. This reduces code size for sketches
which don't use the setRGBled() function. In bootLogo(), instead of dimming
the red LED, the red then green then blue LEDs are lit in sequence at full
brightness.
digitalWriteRGB() was added as a public function and is also used for the
changes above.
Checks if the "B" button is being held down when begin() is called.
If so, waits for other buttons to be pressed to control system functions.
Functions implemented:
"UP" button: Set "sound enabled" in EEPROM.
"DOWN" button: Set "sound disabled" (mute) in EEPROM.
Based on Arduboy library V1.2 development as of April 2, 2016
- Class Arduboy2 replaces class Arduboy.
- Removed files ab_printer.h and ab_printer.cpp. Integrated their
functionality into class Arduboy2 (as with Arduboy V1.1).
- Added new text functions:
- getCursorX(), getCursorY() to get the current cursor position.
- setTextColor(), setTextBackground() to allow inverted text
(black on white).
- clear() is overridden to set the cursor to 0, 0 in addition to clearing
the screen buffer.
- New Class: Arduboy2Base which contains most of the Arduboy functions and
is inherited by Arduboy2. It doesn't inherit Print, and doesn't include
text display and cursor control functions. Using it instead of Arduboy2,
in sketches that don't use text functions, frees up some code space.
- Function drawChar() is in Arduboy2 instead of Arduboy2Base.
- Made setRGBled() static. Not making it static was an oversight.
("Tunes" functions are still moved to the separate ArduboyPlaytune library,
as they were in Arduboy V1.2)
previosly timing was calculating the next frame based on now + duration
when the correct timing should have been last_frame + duration.
This would have the effect of slowing the game down the higher your CPU
usage. A 0% CPU usage game would play at the request frame rate,
but a 100% CPU usage game would play at only half the requested frame rate.
(RR is render time below)
Timing with the bug:
60FPs requested, 35FPs actual, 3 frames, 87ms.
| 29ms | 29ms | 29ms |
| RR 12ms + 17ms sleep | RR 12ms + 17ms sleep | RR 12ms + 17ms sleep |
Timing after the fix:
60FPs, 60FPs actual, 3 frames, 51ms.
| 17ms | 17ms | 17ms |
| RR 12ms + sleep | RR 12ms + sleep | RR 12ms + sleep |
After this fix you may need to change your games timing mechanics or
adjust your frame rate (to slow things back down). Your game will run
faster after this fix, even if you were using "100% CPU" before.
Scott Allen
rogosher
Josh Goebel