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
The 'easily' may be challenged by the really strange pixel order as mentioned by @Gordon. Separating logic (model) from display (view) is good and longstanding practice. Anytime later, logic and display can be optimized and enhanced independently... especially the graphics you would like to enhance over time. Furthermore, it will allow you to pick any display... such as a 320x240 262K color display (with touch screen) - ... where shoving around of full screen buffers is just not an option... after all it's 153600 bytes, 1228800 bits, and this over SPI is ... (call it what your imagination likes...)... and it is only with 16 bit color depth... If you plan to go 24 bit - 1.6M colors - and with some LED displays you need an extra intensity byte - it becomes 32 bits per color!
Yes, you can take advantage of a combination of Espruino memory Graphics Buffer and Display memory buffer and the knowledge about their inner workings... On the other hand - when you go that into the intrinsics - you can use then graphics controller that sits on the display to do such operations like shuffling around areas... This is much faster: since your block is already displayed, you just give commands to move graphics areas around - with tetris, it is two (2) rectangles at worst (the higher the resolution the more optimized is the amount of command bytes vs the amount of shoved around bits / bytes.
I wondered the (rare?) redraw reason... and therefore just drew an empty board - which is in the end just a single rectangle, and then drawing the blocks that have settled and the active one... It may not beat the redraw from a buffer, but since it is rare and not in time critical phase of a game - for example on resume after a break with something else displayed, redrawing time does not matter that much.
On the collision detection: when I was thinking about super fast collision detection a week-end ago - I was considering bit operation & instead of any loops with zero/null-checks. All blocks cover only a 4x4 bits area - 16 bits - and this information fits in an UInt16. So every location - 16*8 has a 16 bit value that represents the (combined) occupation information about the z/y location itself and the neighbors... Whit this setup, a collision detection boils down to a single & operation wether a particular x/y location is busy. The only draw back with this is a bit more code when a block settles to aggregate the UInt16s - and of course some memory consumption. Rotate would also be very simple, because it is just replacing one 16 bit value by another one... This will speed up your logic to the point for very very fast playing.
Does not speed increase with level?