From a Black Screen to Smooth 30 FPS on Evercade Hardware
Cloudstrike is an Android and desktop game, but recently I started experimenting with something very different: running it natively on Evercade-compatible handheld hardware.
The first target is a HyperMegaTech Super Pocket. It has a 320×240 display, an ARM processor, limited memory and an older Mali GPU. In other words, it is exactly the kind of constrained hardware that exposes every inefficient rendering decision.
The first approach failed
My initial plan was to run Cloudstrike directly through DRM, EGL and the proprietary Mali graphics driver.
That sounded straightforward in theory. In practice, it led to a long sequence of display initialization failures, incompatible EGL paths and black screens. There is no normal desktop environment or Wayland session available to fall back on.
Eventually I looked at software already working reliably on the device: RetroArch.
RetroArch uses SDL2 to handle the display, controller and platform integration. Instead of continuing to fight the graphics stack from the outside, I placed an SDL2-based Cloudstrike launcher beside the original Mali launcher and used the same general platform route.
That was the breakthrough. Cloudstrike finally rendered on the actual device.
Then came the controls
The built-in controls did not appear as a normal SDL game controller. Reading RetroArch’s configuration suggested keyboard-style mappings, but those events still did not reach the game reliably.
The solution was to inspect the Linux input device directly. The handheld exposes its buttons through
/dev/input/event0, so Cloudstrike now translates those native input events into its engine-neutral actions.
Movement, firing and pausing finally worked.
Sound and stable game speed
The next step was audio. The Raylib version now uses its native audio backend for music, engine sounds and effects.
I also separated simulation speed from rendering speed. Cloudstrike continues updating at a fixed 60 Hz, even if the device renders fewer frames. This prevents the entire game from slowing down whenever the GPU misses its target.
The result is currently a surprisingly smooth and consistent 30 FPS on the handheld.
The bridge problem
Most of the game already ran well, but every landscape transition caused a noticeable slowdown. It happened while the river and bridge were visible and disappeared immediately after the bridge left the screen.
At first this looked like a memory problem because two environments are present during the transition. The real cause was GPU bandwidth.
The transition renderer repeatedly built full 840×480 offscreen images for:
- the old terrain
- the new terrain
- two middle cloud groups
- two foreground cloud groups
Those images were then copied back in narrow strips along the moving river boundary. That is a lot of work for an old Mali GPU especially when the final screen contains only 320×240 pixels.
I replaced the cloud cuts with direct crossfades and moved the landscape transition into the existing tile pipeline. The bridge is now 128 pixels wide, aligning it to the 16-pixel grid, while semi-transparent riverbank edges blend the two environments.
This removed the expensive full-screen transition passes. The improvement on the real device was immediately visible.
Rendering only the pixels that exist
Until now, the Super Pocket build rendered the 640×480 playfield into an intermediate texture and then scaled it down to the physical 320×240 display.
That produced the right image, but it meant processing four times as many pixels as the screen could show.
The newest build keeps the original gameplay coordinates but transforms every sprite, tile, rectangle, line and triangle directly into a native 320×240 render target.
Conceptually, it changed from:
640×480 world → intermediate texture → scale to 320×240
to:
640×480 world coordinates → rasterize directly at 320×240
The visual composition remains the same, but the GPU now renders only the pixels that reach the display.
Where it stands
Cloudstrike now has:
- native ARMv7 execution
- SDL2/KMSDRM display output
- working physical controls
- music and sound effects
- fixed-step gameplay
- tile-based landscape transitions
- native 320×240 rendering
- smooth gameplay at approximately 30 FPS
This is still an unofficial hardware experiment, not an Evercade release or distribution method. I am testing only my own game and assets while exploring whether Cloudstrike could eventually become a suitable official cartridge title.
There are still optimizations to make, but seeing the game become genuinely playable on such compact hardware has been one of the most satisfying milestones of the project so far.
The next question is simple: how much further can this little machine be pushed?


Discussion