[Discuss] Arduboy2 Development Library

Just tested this out in Ardu Valley, great stuff!

The procgen i use uses the drawPixel function heavily, so improvements here have smoothed out some parts of the game, which is awesome.

3 Likes

Knew someone would benefit from that. :slight_smile: How do you use it exactly? The bad part about the function is it has to calculate the address for every single pixel every time… if you were able to inline the code manualy yourself in a routine that could calculate the address less often (say you were writing a bunch of horizontal pixels in a row, etc) you could get a LOT more speed.

I might have to look into that.

Basically i have a seed value, and i run a horizontal pass over the value, setting a bit on if the bit is 1, and leaving it if 0.
Then, the next row uses the bits of the previous value to determine its bit pattern, and does the same thing.
The process repeats to a set height or when the bit pattern is all 0’s

So yeah, it would be a massively fast operation if bits were horizontal major in the sBuffer, but as it stands they are not.

And yeah, there is for sure some room for improving it, but at the moment i am saving that to fix gameplay stuff.

Yeah you might find it’s more than fast enough without optimization - depending on what exactly you’re doing and how large the area of effect.

Nice work on the update, @MLXXXp.

Can I make another request? Where possible, can you make the methods static where possible in the same way that the Sprites library does?

I have been building a sideways scrolling car game where the cars are objects that detected collisions between themselves and render themselves. The rendering I can perform using the static methods of the Sprite class but I have had to incorporate a reference to an Arduboy2 instance to do the collision detection.

In C++, static methods can be invoked directly from an instance of the object so this will (should?) have no impact on people’s existing code but will make it simpler to consume the static methods from classes.

@filmote, Can you give more details or provide an example for how making library functions static would help you?

No problem @MLXXXp - I am only using a handful of methods but others may user more.

In my game, I have a class that represents a car and in the main .ino file I have a collection of cars. Each car instance is responsible for keeping track of its own x and y positions and to move itself based on an algorithm. It does this by holding a reference to the same collection of cars and iterating through them testing for collisions. Finally, it renders itself for display.

In my example, the car only requires the Rect structure and the ‘collide’ function.I have two options: create an instance of Arduboy2 in each car or pass a reference to an existing Arduboy2 library as I construct the cars.

The methods in the Sprite library are predominantly static so I can simply Sprites::drawOverwrite() (or whatever) without having to isntantiate one.

1 Like

Why can’t you create the usual global instance of the Arduboy2 or Arduboy2Base class at the start of the sketch, like every other sketch does:

#include <Arduboy2.h>

Arduboy2 arduboy;

and then call the collide() function of that global instance:

  arduboy.collide(rect1, rect2);

from the functions in your car class?

1 Like

I am not 100% sure what you mean. Do you mean create a single .ino file with the classes defined within it and then define a ‘global’ variable they can all see? I used to program in a language called RPG III where every single variable was global and there was no such thing as a local … but that was in a language released in 1978.

I am not a gun C++ programmer - and I have a lot to learn - but I have created my classes as separate .h and .cpp files for many reasons not least of all that they are easier to maintain in the IDE in separate tabs. I have a base class which my car, player and obstacles all extend and they are getting quite lengthy and maintainability is becoming an issue. I guess I could do this in a single .ino file but it doesn’t seem right to me.

You can have ‘global’ variables and separate class files but to do this I would need to create a header file specifically for storing this ‘global’ variable so that it can then be visible to my base and sub-classes. Again, this doesn’t seem right to me.

As mentioned earlier, static methods can be invoked directly from an instance of the object so this will not cause any compatibility issues. I am not sure what others think of this suggestion - am I asking for something that has not value to others or is it a relatively simple change that may have benefits?

1 Like

Then create a global instance of the Arduboy2 (or Arduboy2Base) class in the main .ino file, as normal:

#include <Arduboy2.h>

Arduboy2 arduboy;

In any other file (probably a .cpp) needing access to the arduboy instance, put:

#include <Arduboy2.h>

extern Arduboy2 arduboy;

I guess I could do that. Long live the global variable !

If all the classes have a common base class you could have a static Arduboy2 arduboy; member in the base that is accessible to all the inherited classes. Then you only need to initialize that one static member.

Yes, that could work. However, you would have to do all Arduboy2 library access from functions within this single class hierarchy, since you shouldn’t create more than one instance of the Arduoby2 class in a sketch so as not to waste memory.

I suppose you could make the arduboy instance public, which means calls to Arduboy2 functions outside of the class hierarchy, could be done like:

myclass.arduboy.nextFrame();

or

MyClass::arduboy.nextFrame();
1 Like

One small oversight:
@Mr.Blinky suggested one of the changes to drawCompressed().

1 Like

I’ve added @Mr.Blinky to the release notes on GitHub and in the post above. I’m sorry I can’t add him to the commit log because I don’t like to “rewrite history” after publicly and officially releasing.

3 Likes

The post above was all I was expecting.

2 Likes

Whoa! My game went from this 10489 to 10368 bytes from recompile! thanks!

1 Like

Great and detailed release notes!

1 Like

Awesome to see a major update on the the Arduboy2 library @MLXXXp and thanks for the credits. Pleased that I could contribute. Looks like I have some work to do for the homemade version now :slight_smile:

1 Like

Another appology: I realised I forgot to credit @Dreamer3 for the concept of how to remove the USB code. This has been corrected in the release notes (but unfortunately, again, I can’t add it to the git logs).

1 Like