Revert nextFrame() back to the original version

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.
This commit is contained in:
Scott Allen 2016-09-15 18:12:27 -04:00
parent fd4cef7025
commit 15d1b0dab4
6 changed files with 10 additions and 29 deletions

View File

@ -7,7 +7,7 @@
"type": "git",
"url": "https://github.com/MLXXXp/Arduboy2.git"
},
"version": "2.0.2",
"version": "2.0.3",
"exclude": "extras",
"frameworks": "arduino",
"platforms": "atmelavr"

View File

@ -1,5 +1,5 @@
name=Arduboy2
version=2.0.2
version=2.0.3
author=Chris J. Martinez, Kevin Bates, Josh Goebel, Scott Allen, Ross O. Shoger
maintainer=Scott Allen saydisp-git@yahoo.ca
sentence=An alternative library for use with the Arduboy game system.

View File

@ -112,7 +112,6 @@ void Arduboy2Base::bootLogo()
void Arduboy2Base::setFrameRate(uint8_t rate)
{
frameRate = rate;
eachFrameMillis = 1000 / rate;
}
@ -123,7 +122,7 @@ bool Arduboy2Base::everyXFrames(uint8_t frames)
bool Arduboy2Base::nextFrame()
{
long now = millis();
unsigned long now = millis();
uint8_t remaining;
// post render
@ -144,26 +143,8 @@ bool Arduboy2Base::nextFrame()
}
// pre-render
// next frame should start from last frame start + frame duration
nextFrameStart = lastFrameStart + eachFrameMillis;
// If we're running CPU at 100%+ (too slow to complete each loop within
// the frame duration) then it's possible that we get "behind"... Say we
// took 5ms too long, resulting in nextFrameStart being 5ms in the PAST.
// In that case we simply schedule the next frame to start immediately.
//
// If we were to let the nextFrameStart slide further and further into
// the past AND eventually the CPU usage dropped then frame management
// would try to "catch up" (by speeding up the game) to make up for all
// that lost time. That would not be good. We allow frames to take too
// long (what choice do we have?), but we do not allow super-fast frames
// to make up for slow frames in the past.
if (nextFrameStart < now) {
nextFrameStart = now;
}
nextFrameStart = now + eachFrameMillis;
lastFrameStart = now;
post_render = true;
return post_render;
}
@ -783,6 +764,7 @@ size_t Arduboy2::write(uint8_t c)
write('\n');
}
}
return 1;
}
void Arduboy2::drawChar

View File

@ -222,11 +222,10 @@ protected:
static uint8_t sBuffer[(HEIGHT*WIDTH)/8];
// For frame funcions
uint8_t frameRate;
uint16_t frameCount;
uint8_t eachFrameMillis;
long lastFrameStart;
long nextFrameStart;
unsigned long lastFrameStart;
unsigned long nextFrameStart;
bool post_render;
uint8_t lastFrameDurationMs;
};

View File

@ -169,7 +169,7 @@ void ArduboyCore::bootOLED()
LCDCommandMode();
// run our customized boot-up command sequence against the
// OLED to initialize it properly for Arduboy
for (int8_t i=0; i < sizeof(lcdBootProgram); i++) {
for (uint8_t i = 0; i < sizeof(lcdBootProgram); i++) {
SPI.transfer(pgm_read_byte(lcdBootProgram + i));
}
LCDDataMode();

View File

@ -5,7 +5,7 @@
#define FONT5X7_H
// standard ascii 5x7 font
const static unsigned char font[] PROGMEM =
static const unsigned char font[] PROGMEM =
{
0x00, 0x00, 0x00, 0x00, 0x00,
0x3E, 0x5B, 0x4F, 0x5B, 0x3E,