You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
Nice!
So each pix is a square of a tetris shape, correct?
So think of an undraw and redraw... then, at worst, it is 8 pix you set... vs 144... so you get ~93% faster or have to draw only ~6.6%... and if you have transition functions for each shape - average 3 for rotation and 3 for falling down you get it 98% faster, that's down to about 4.2%.
Since drawing can be seen as line px set, a line drawing, a line drawing and a px set, and two line drawings at max, you may get down to 4 interactions between source execution state and internal execution state...
When designing the pac man, I simplified the man with two lines in an wider and a narrower angle... which means: 2 line un-draws - drawing the current state/lines in background (black) color - and 2 line draws - drawing the new state in foreground (yellow) color.
In other words, you still need the board for collision detect - and may be for an occasional redraw after a game break and display of something else...
I did not look much into the collision detection algorithm, but any location > 0 (1... are colors) means a free spot... and so you would also treat the border this way, then you do not need extra logic for border detection... in other words, your border is just an other 'occupying color', one you consider stealth / not to be seen/drawn... this increases of course your memory footprint for the board from 144 to 180 - 25%, but you reduce amount of execution logic and complexity considerably...
I have not published yet the drawing of the pac man board... but I had to resort to all kinds of 'short cuts' to fit in memory... But I implemented and published the 4x4 - 16 (or more) pieces puzzle - which are all time and memory critical.
have fun.