These functions comes from GameBuino but are not implemented yet.
Are there alternatives to measure resource consumption in hardware?
maybe mbed forums could help out, not sure if it works on the pokitto chip
https://os.mbed.com/questions/6994/How-to-print-Free-RAM-available-RAM-or-u/
1 Like
The get free ram methods i’ve seen are all basically the same: check size of maximum malloc before it returns null.
Lets tag this in requests until fixed
1 Like
@adekto just before posting I tried right the method you link. In simulator it works fine (just avoid call it too many times), but with real hardware results was always zero. Maybe I made something wrong.
My needs are to understand how much I can stress Pokitto. With the simulator is not always clear if you’re hitting the FPS caps or it’s only a matter of too much calculations. I have the feeling the results on hardware are always slower and somehow sticky.
IMO hitting an high FPS is a must on games, are there suggestions to achieve smooth and fast animations?
Only draw what you need to, not the whole screen. Use dirty rects to track the background area to be updated. Use buffered screen mode to avoid flicker, unless @spinal gets page flipping to work 
2 Likes
Simulator is not accurate at all its an approximation of the pokitto
Also you only want to call it once
It might be 0 cuz you already allocated everything, just my guess
It doesn’t look possible from what I’ve been reading. Scrolling only supports a single screen width/height and wraps around.
Ok, that is a pity.
Edit: But we can still use it for HW scrolling. E.g. When scrolling to left, blit the new content to the left side of screen and immediately scroll so that the new content gets visible on the right side of the screen. So we save from drawing the whole screen again when scrolling. Maybe it does not flicker if we draw quickly enough.
idk its a bit of a mess to handle and im suspecting the redraw and the scroll dont work together so it may couse flickering on the edges or a “ghosting” efect