Running out of dynamic memory

Hey guys,

So I’m making a game and I’m using an array to store the rooms.

For example:

short roomData[49] =
{0,0,0,0,0,0,0,
0,0,0,0,1,0,0,
0,0,0,1,2,1,0,
1,0,0,0,1,0,0,
2,0,0,0,0,0,0,
3,0,0,0,0,0,0,
4,3,2,1,0,0,0,};

So I have a ton of these now and I get:

“Global variables use 3093 bytes (120%) of dynamic memory, leaving -533 bytes for local variables.”

However, I’m overwriting old rooms with new rooms in my roomData[] array when the player changes rooms. So why am I running out of memory?

Is there a way I could do this without running out of memory?

Thanks

1 Like

If the rooms don’t change you could just store them in progmem.

You could try using a smaller datatype, short is actually a short int which is 2 bytes wide on the Arduboy, meaning your array takes 98 bytes. If you used a uint8_t which is 1 byte your array would only use 49 bytes.

I suspect the real memory hog is elsewhere in your code.
Perhaps you’re storing images in RAM when you should be storing them in progmem or something?

(Also remember that arrays don’t change size.)

1 Like

So how would I put it in PROGMEM?

Thanks

1 Like

Keep in mind that the screen buffer uses 1K of RAM of the total 2.5K. The libraries use a bit more, plus you need space for the stack and heap used for call return addresses and parameter passing, etc.
You thus have less than 1.5K of RAM available for sketch use.

1 Like

The Arduboy has two types of memory, dynamic memory which is readable and writable, which is where all your variables are normally stored, and program memory (often called ‘progmem’) which is a section of read-only memory where your code is stored and where you can choose to store things.

There’s a decent introductory article to this on the arduino website:
https://www.arduino.cc/en/Reference/PROGMEM

As well as a few other examples here on the Arduboy forums, like this one:

2 Likes

So I could use:

unit8_t roomData[49] =
{0,0,0,0,0,0,0,
0,0,0,0,1,0,0,
0,0,0,1,2,1,0,
1,0,0,0,1,0,0,
2,0,0,0,0,0,0,
3,0,0,0,0,0,0,
4,3,2,1,0,0,0,};

Using “short” is not needed in my case?

1 Like

As long as the values you intend to store in the array are between 0 and 255 (byte or uint8_t) or -128 to 127 (char or int8_t).

1 Like

If you only need values from 0 to 255 then no short isn’t needed and you’ll be fine with uint8_t.
(I’m assuming those numbers are tile types.)

That’s only going to halve the memory your array takes though, you will need other savings in other places if putting some things into progmem isn’t enough. I don’t know what the rest of your code looks like, but a good rule of thumb for is to put anything you don’t need to edit into progmem.
(And of course images have to be in progmem if you’re using Sprites or Arduboy2.)

1 Like

Yes my images are in PROGMEM I can go through all my variables and change them from short to unit8_t that should free up a lot. Because I’m only dealing with small numbers in most cases.

Much appreciated!

1 Like

int8_t could be very handy for me also. Thanks!

1 Like

If the numbers are smaller then 16 you could also pack 2 numbers in one byte (number1 * 16 + number2)

1 Like

I must admit my knowledge on memory is not good.

So I put my variables into “char” and dropped my memory usage from 120% to 84%.

So “signed char” ranges from - 127 to 127 and “unsigned char” from 0 to 255 does this make sense?

“unit8_t"
and
"int8_t”

are not recognized as variable types. Is there something I’m missing here?

1 Like

So if I use a format like:

unsigned char const roomData[49] PROGMEM =
{0,0,0,0,0,0,0,
0,0,0,0,1,0,0,
0,0,0,1,2,1,0,
1,0,0,0,1,0,0,
2,0,0,0,0,0,0,
3,0,0,0,0,0,0,
4,3,2,1,0,0,0,};

it should be a minimal drain on memory?

1 Like

Since it is storing it program memory Instead of ram yes.

You will have to use pgm_read_byte() to read the data though

1 Like

it’s uint8_t not unit8_t.

For the AVR processor that the Arduboy uses,
uint8_t and byte and unsigned char are all equivalent.
int8_t and char and signed char are all equivalent.

uint8_t and int8_t should work in the Arduino IDE without having to #include anything.

2 Likes

That’s correct.
If you want to know why that’s the case, you need to understand binary.
There’s a fairly straightforward explanation here.

2 Likes