Math Practice App I Made

(Boardkeystown) #1

My code is a little sloppy but hey I just wanted to test out some stuff on the arduboy.
I started it a few months ago. Took a long break on it. Finished it out over 3 day weekend.
What do you guys think?

4 Likes

(Matt) #2

I’m on the road right now so unable to give it a go. But the video makes it look nice. I like assigning answers to buttons and the green LED is a nice touch.

0 Likes

(Boardkeystown) #3

Thanks. Has you know there is only 6 buttons so coming up with a way to do 10 inputs (0-9) I had to get clever.I felt for this app the way I did inputs it is better than a grid of numbers to select from like on a calculator. Because you could input them in faster.

0 Likes

(Kevin) #4

Lol this is a good app I didn’t see it before. I think it is the first homework app for Arduboy. How come more people don’t do homework apps? :smiley:

1 Like

(Boardkeystown) #6

Thanks! Maybe kids might be able to use it.
I didn’t create it to be “homework app”. It is more of a demo app to test different things from arduboy2 for a particular purpose. This sketch for me the most complete arduboy sketch I’ve made so far and felt I should share it to see what people thought. I intended to add more things to it and make more the code more modular and less redundant. I wanted to add a better way to randomize the numbers so its not sequential when you pick a operation. Also I should have used sprites instead of bitmaps which eats a lot of memory unnecessarily in my opinion.

The thing I liked most about making this was coming up with a way to input all 10 numbers (0-9) with only 6 buttons. Most people use some kind of slider to select numbers which is slow if you want to add numbers quickly. However, the way I mapped the inputs you can enter in numbers in pretty quickly once you get use to it.

Maybe I’ll come back to this after I am done working on my game which I hope will be a smash hit here. I’ve looked at a lot of the games people have made so far and I haven’t seen anyone create something like I am working on.

0 Likes

(Simon) #7

I am not sure what the difference is here.

Bring it on! What are you working on?

0 Likes

(Pharap) #8

arduboy.initRandomSeed().

For best results, call it after a title screen or when changing ‘gamemode’.

I second @filmote with this, I’m not sure what you mean.

Do you mean using Sprites instead of arduboy.drawBitmap?

1 Like

(Boardkeystown) #10

Yes!

Do you mean using Sprites instead of arduboy.drawBitmap ?

I made a small sketch that filled the screen one that rendered tiles to the screen with drawBitmap and one that used Sprites. I noticed that using Sprites it used like 1% less memory for the same thing. I believe from what I have been reading in the forums that Sprites are better for rendering and can be used to take up less memory runtime.

In this sketch MathPractice I made for example the function displayOutline() is pretty inefficient looking back at it. I could save a lot of memory runtime by breaking up my bitmaps into chunks based on a tile grid. That’s just one example of what I mean.

I mean hey the why I did MathPractice works but I am learning how to do things differently and more efficiently.

0 Likes

(Pharap) #11

There could be various reasons for that, but usually it’s because with the Sprites image format the image dimensions are stored directly in the image data (thus reducing the number of arguments that need to be pushed onto the call stack or the number of registers that need to be saved).

Personally I tend to use Sprites 99% of the time for this reason.

That seems true.

But you could have potentially saved a decent amount of memory simply by splitting displayOutline up into smaller functions and using smaller datatypes for your loop counter (though sometimes the compiler can figure that out for itself).

void drawHorizontalBar(int16_t x, int16_t y, uint8_t length)
{
	int16_t xPosition = x;
	for (uint8_t i = 0; i < length; ++i)
	{
		arduboy.drawBitmap(xPosition, y, horizontal_bar, Num_Width, Num_Height);
		xPosition += 7;
	}
}

void drawVerticalBar(int16_t x, int16_t y, uint8_t length)
{
	int16_t yPosition = y;
	for (uint8_t i = 0; i < length; ++i)
	{
		arduboy.drawBitmap(x, yPosition, vertical_bar, Num_Width, Num_Height);
		yPosition += 8;
	}
}

void displayOutline()
{	
	// I didn't bother to calculate the coordinates properly
	// I tried, but got bored about halfway
	drawHorizontalBar(5, 2, 17);
	drawVerticalBar(119, 9, 2);
	drawVerticalBar(3, 9, 2);
	drawHorizontalBar(5, 25, 17);
	drawVerticalBar(26, 9, 2);
	drawVerticalBar(26, 9, 2);
	drawVerticalBar(26, 9, 2);
	drawHorizontalBar(5, 25, 10);
	
	// Left dpad
	arduboy.drawBitmap(5, 38, dpad, 21, 26, WHITE);

	// Right dpad
	arduboy.drawBitmap(103, 38, dpad, 21, 26, WHITE);

	// Button A
	arduboy.drawBitmap(45, 48, button, 15, 16, WHITE);

	// Button B
	arduboy.drawBitmap(65, 48, button, 15, 16, WHITE);
}

This is probably marginally slower because of the extra function calls,
but it also probably uses a lot less progmem.
(I didn’t compile to check.)

Note that speed is almost never an issue on the Arduboy.
I know of only one (unpublished) game where speed was an issue.
There’s probably less than 10 published games where processing speed has been an issue.

Indeed.

Don’t be afraid to ask if you want a few tips,
it would save you learning the slow way.


Upon a quick glance the things that stick out the most are minor redundancies.
E.g.

  • Putting return; at the end of a void function is redundant, a void function will always return when it reaches the end
  • The casts in arduboy.drawBitmap((int)40, (int)13, are redundant, integer literals are int by default
  • isAnswercorrect could be simplified to just having one switch (e.g. if (abs(answer) == solution))

There’s various other things that probably wouldn’t improve efficiency but would improve the code quality, most of which can just be chalked up to not having encountered them yet.
E.g. constexpr variables, scoped enumerations (enum class), references

There’s also stuff like swapping the order of checking mode and currentButton in update.
That way you could do

switch(mode)
{
case MODE_PLAY: updateModePlay(); break;
case MODE_SETUP: updateModeSetup(); break;
}

I.e. another case where adding more functions actually results in smaller code overall.

Equally there are some cases where you might be increasing the overall code size by using a function instead of putting up with boilerplate (e.g. menuSelectAdjust).

Knowing when a function is likely to decrease overall code size and when it’s likely to increase overall code size is something you can only really get with experience.

Understanding some of the compiler optimisation rules helps though, e.g. the compiler is more likely to inline a function if it’s used 3 times or less, after which the size of the function becomes the more important factor.

I’m going to stop looking or I’ll end up finding a laundry list of stuff.


By the way:

  • You can quote a post by highlighting the part you want to quote and clicking the ‘Quote’ tooltip that appears
  • You can edit a comment by clicking ... and then selecting the pencil icon (hovering over each icon tells you what it does)
1 Like

(Boardkeystown) #12

Wow,

thanks for your input. All great points to consider. I like the idea of breaking up the displayOutline() into smaller functions. Much cleaner and more reusable that way.

I diffidently will ask more questions that I can’t easily figure out on my own. This community is very helpful and supportive.

Cheers!

1 Like