sBuffer and Arduboy's advertised RAM

I notice in Arduboy.cpp that sBuffer is a fairly important part of all the drawing functions, which makes sense, it’s good to draw to a buffer and then transfer that to the screen all at once.

I noticed that it’s just a regular char array, and it should take up exactly 1 kilobyte.

Is that factored into Arduboy’s advertised 2.5 kB RAM, or do we actually have only 1.5 kB RAM to work with? Or does it exist elsewhere and I’m missing some important information about how the device is set up?

I hope it was already considered as pre-claimed space, since it’s so critical for the display, and that we have an extra 2.5 kB on top of that.

EDIT: Looking at the ATmega32u4 spec sheet, it’s not looking good, as the listed specs are exactly the same as the ones on the kickstarter page (32 kB flash ROM, 2.5 kB SRAM, 1 kB EEPROM).

It’s true, the frame buffer takes up a majority of the memory, but in practice it isn’t that much of a problem. It seems like the limited flash memory for code space and content is the first ceiling you hit. There is no doubt that it will take some clever programming to take full advantage of this hardware. We are looking at lots more memory for Arduboy 2 so we love to get feedback! Thanks!

Hey @unclesporky, I think @bateske sent off an email to ya, so maybe check for that. The global buffer used to contain the offscreen draw will be occupying space in available working memory. However, we certainly haven’t created a repository for the official library yet, and there is much to be done. As it stands, it is worth goofing with the source code and seeing what solutions may exist besides what has already been suggested, if you come up with something good, don’t hesitate to make some posts about it here or even a PR on github. Although we will most likely create a repository for just the libraries in the near future, and input before hand is much appreciated.

I ordered one of the dev kits on Tindie, I don’t know if there’s much messing I’ll be able to do until I receive it. :snail: There’s a lot of stuff I want to try though.

Are you one of the coders of an existing game? I’d be really interested to hear about limitations you ran into, things you tried that didn’t work out, or things that work better than you expected. @bateske mentioned that the 32 kB memory might be more of a limitation than the RAM, so I’m curious which games are already bumping into that, or how much space the bootloader is taking up, that sort of thing. However I’m sure you’re all very busy with the kickstarter going on and might not have time to answer questions.

Hey @unclesporky RAM issues typically cropped up when we were trying to do a lot of floats at the same time, arduino’s string class is also a troublemaker. But as long as you are working with integers and character arrays, things stay mostly in control.

@chris is our primary programmer and the one who complains to me about the RAM size already.

We are looking at new chips in the future to solve this, but for now we wanted to keep the arduino functionality, and along with it (unfortunately) a lot of it’s limitations. We are excited to see what processors and configurations of off-board memory we can add to the next version.

Thanks!

Of course you could do all sorts of things to help reduce that memory footprint.

  1. Pixel doubled (or quadrupled) resolution. Even more retry graphics and you’d cut the memory requirement in half or more.
  2. Render from tiles vs a buffer… you do have to store the tiles in your program memory but the refresh routine could simply render the screen each time from tiles as it’s needed - never storing the whole image in RAM at all… so RAM needed for buffering would be 0.
  3. Render to a single “page” at a time. The display is composed of 8 horizontal pages of pixels. You could render to them one at time and then push that render to the hardware, then switch to the next page to render. Then you’re only buffering 128 bytes vs 1024. The hardware supports this.
  4. If you were developing an all text or mostly text game you could just buffer a 25x8 character display instead of a graphic display.

The big advantage of the buffer is it makes random drawing operations (lines that go from corner to corner, random pixel writes) much easier to manage. And allows you to keep track of what you’ve drawn to the screen.

The Squario example on the arduboygames codebender site uses a bufferless drawing system.