The engine was written entirely in C by me.
Custom made interpreter uses shunting yard algorithm to parse lines. It has a call stack to run functions and branch code.The renderer uses a buffer that stores the state of the pixels on the screen and updates the screen depending on the mode:
-
Normal This mode is used for all the editor UI. It bipasses the smart renderer and manually draws rectangles and text onto the screen, clearing only when required. Great for UI, but not for quick refresh rates.
-
Fast but Flicker This mode clears the entire screen and redraws it every frame. Light for the CPU, but causes flickers and refresh delay
-
On Change (default) This mode draws only the pixels that have changed between frames. It is the recomended mode as it is the quickest overall.
-
Slow but Smooth First this mode scans for pixels that have changed, and creates a pallete using the colors on the screen. Then an algorithm takes each color and converts it into the least number of rectangles. While very smooth, it requires more CPU time making it slower than "On Change".
The collision engine first parses space into "cells" that completely cover all of the colliders of the objects. Then each cell is iterated over to check for collisions using Seperating Axis Theorem (SAT), which allows for collision detection while the objects are rotated.
The Raspberry Pi Pico W has 2 cores. To maximize efficiency, tasks are assigned to the cores dynamically based on load. This ensures that neither core is idle during runtime. The primary purpose of core 0 is object manipulation, script execution, and load balancing. Core 1's primary purpose is rendering. If core 1 finishes early, it will start processing collisions, reducing idle time and allowing core 0 to catch up. The cores communicate with eachother using FIFO stacks.
All of these processes combine together to run the user programs. This flowchart shows the interaction and ordering of the processes.
