when helping someone out on the playdate discord with a crash on the device, i noticed the user had a watchdog_reset error but it mentioned also he used around 10mb of heap memory.
- watchdog reset at 2023/10/19 01:13:44---
r0:00000000 r1:00000000 r2:00030b5a r3: 00000000
r12:006d3000 lr:080353ef pc:08035134 psr: 61000000
heap allocated: 10105440
Lua totalbytes=2399200 GCdebt=-1188061 GCestimate=1199653 stacksize=80
The information was sparse so did not know the real cause but we noticed that in a certain cmake file for the C Api these values get passed
does that mean that the limit for HEAP is actually around 8MB ? and is that the same value in both LUA as in C Api games ?
the problem for the person in question was solved by compressing the wav files, he seemed to be using sampleplayer for a lot of them and probably thats part of the big heap size (music should use fileplayer). but now i wonder did he somehow reach the 10 second time limit loading the big samples (and other assets) into memory or was the heap thing the problem ? the person in question does not have hardware to test it himself it is hard to tell
But that made some use wonder if the heap limit for both lua and C Api games is around 8 mb or not ?
Edit: we tested some more and it seems the issue was caused by hitting the 10 second time limit, but i would like to know what those heap values in the CMAKE Files are as it seems i could allocate 12 MB on the heap in a c api game
Lua is a dynamic garbage collected language so your “usable” heap (the heap you as a dev can use) will always be smaller than if you were just using c.
I don't think HEAP_SIZE and STACK_SIZE serve any useful purpose any more, so feel free to ignore those values. The external memory chip is 16 MB, and is used for game code and heap. I think the 8 MB heap limit was so the linker would complain if a C game's pdex.bin took up more than half the memory but I don't see that assert in the ld file any more.
I just tested sample loading, took just over one second to load a 14MB file into memory. Must be something else in the startup that's running too slow.
Hi dave the sample loading was only part of the problem but compressing the wav's did lower loading time so he did not hit the 10 second limit, there was other "initialization" code that already took several seconds, by reducing the size of wav files the assets for that part at least loaded faster which probably prevented him for hitting the 10 second limit. With the compressing of the wav files and potentially using fileplayer instead of sampleplayer for the music the 10 second limit was not hit anymore. The same code now still took about 6.5 seconds (for all intialization) so it was most definatly the 10 second limit thing. I never knew how many and how big a his initiali assets were but with the change i only know it still took 6.5 seconds in total (only for the asset loading part) its possible an initial frame still needed to be draw / processed after that as well.
Thanks for explaining the heapsize and what it was used for, i did not understand it and it had confused me.