Weird stuff happening after a few minutes of play

Hi I have recently purchased an arduboy and have started off by making my own snake clone.

Its not finished yet and I know there are plenty of bugs but something weird is happening after a few minutes of play.

The LED starts randomly blinking usually green or yellow. At the same time random pixels flash white and my score text starts flashing.

I have not seen this happening with any of the sample programs so I am wondering if its something stupid I am doing which is causing the weird behavior.

Its been a few years since I have worked with arduino and I use C# in my day job. :slight_smile:

My code Repository is here : https://github.com/kenjara/ArduboyGames/tree/master/snack

Any help would be greatly appreciated.

Thanks

I can see some possible problems in the code:

p1.Len += 1;

You are increasing that without preparing empty memory after 10 pieces:

  static const int MaxLength = 10;
  Coords *Moves[MaxLength] = {NULL};

I see some modern programming influences in your code (Java, Csharp, etc) and that is totally ok but for simple games it might go against you in limited scenarios like the Arduboy (in my opinion).

1 Like

This is exactly what I want to hear I was thinking my experience with newer languages might be working against me.

You are sport on Java and c# are the two languages I have used most in industry.

I was meant to cap the length at 10 for now but I can see it can be beyond. Silly mistake! :slight_smile:

Update I added a check to make sure I do not try to write outside the bounds of the array and now the issue is gone.

Thank you very much

1 Like

You’re allocating memory with new but never deallocating it with delete.

In C# and Java you never have to deallocate the memory that you ask for because they have garbage collectors to clean up after you. This isn’t the case in C++. In C++, every time you call new to allocate a block of memory, you have to call delete to delete that block of memory, otherwise you get memory leaks and dangling pointer issues which can lead to all sorts of weird stuff happening (like the things you’re experiencing).

Considering the Arduboy has such limited memory, I’d suggest completely avoiding new, trying to avoid pointers where possible and allocating as much memory on the stack as you can.

You should probably learn a bit about how new and delete work so you know how to use them properly in other projects and some of the reasons they aren’t particularly suitable for the Arduboy, but if you want to skip that, just drop your pointers and allocate the data in the array as the objects themselves rather than pointers to objects. If the reason you’re using pointers is because you want some objects to be ‘empty’ then your best bet is to either keep track of the number of objects that are active (i.e. remove inactive ones from the array) or have some sort of means of identifying that an object is inactive/invalid so it can be ignored (e.g. a simple isValid field).

Thanks for the explanation its very helpful.

The active flag is a good idea and more straight forward than playing with pointers.

With the pointer method say the array size is 10 and I fill it up with instantiated objects and these live then live for the lifetime of the game. Then the game ends I iterate over the objects and delete them ready for the next game to start.

Is that any worse than using the pre allocated method?

Cheers

You’re still risking various bugs.

Some potential accidents:

  • Delete a null pointer (not likely, but possible)
  • Delete a pointer twice (if you forget to set a pointer to null after deleting it, or can’t set it to null for some reason)
  • Forget to delete a pointer (causes memory leakage, fills up the memory to the point the device cannot recover)

In a regular computer program for a more modern/powerful computer dynamic memory is used all the time to ensure a program only uses memory as and when it needs it (because there are multiple programs competing for memory). The ability to do so comes with some overhead for bookkeeping (the dynamic memory system uses memory itself to track which bits of memory are in use) as well as its own drawbacks like memory fragmentation (when the sizes allocated differe wildly, leaving small gaps of unusable memory that soon mount up). Garbage collectors are one of the ways of averting some of these side effects, but they come with their own troubles (like the fact the GC has to run on a separate thread and keep track of various objects, where they’re being used and other things, which in turn requires more memory).

The Arduboy, however, is an embedded system with a small, limited amount of memory. It can manage dynamic memory, but not very well because it has so little to begin with and it would eventually be fighting the stack for it, which is why it’s better to statically allocate the majority of the memory you’re going to use in advance (i.e. with static variables) and any memory used dynamically for computation is left to live on the stack (i.e. with function-local variables). You wouldn’t actually be saving memory by using dynamic memory. Your program will take as much memory as it requires (and it’s better to over-estimate in order to prevent error than under-etimate and end up with a situation you can’t handle) and it has free roam of memory (it’s not fighting other programs for resources).

That’s a great explanation thank you.

I like that the Arduboy has limited resources and the challenges it brings. It makes it much more fun than working with something that has so much memory that you don’t really have to worry about it.

No problem. I learnt C# before I learnt C++ so I remember well how hard it can be to suddenly have to be worrying about memory management. The best advice I can give is to read into it at every opportunity, and don’t be afraid of the low level stuff - a good knowledge of the low level aspects like hardware and how the stack works will serve you well.

I half agree about the memory limitation. I like the limitation but I still wish it had just a bit more memory.
Also I think people should still worry about how much memory their programs use on any system (even modern desktops), but these days most people don’t because they assume all modern computers have tons of memory to spare.

1 Like