Hacker News Reader

Well it has a 168MHz arm, so assuming 20fps, you got 80 instructions to work with per pixel drawing - that’s a bit tight, but not overly so. In the 90s, games (like Quake) worked with much less.

But this assumes that wait states of the memory or a funky way to access graphics don’t screw you over. I did a quick search, and couldn’t find detailed hardware specs (like pano docs for game boy, or gbatek for gba / Nintendo das).

View on HN

It has a Cortex M7 180 MHz MCU. No real SIMD. Reasonable memory at 16MB but it is slow to r/w at about 30MB/s. DTCM 30x faster but you don’t get much to address, e.g. the stack is just 10KB. Framebuffer 12KB. System reserves the rest of the 64KB TCM. There’s just a 4KB cache. So the limiting factor is often memory access not cpu. The 400 x 240 1 bit Sharp Memory LCD has to be carefully addressed in horizontal strips of 32 bit words with weird endianness if you want high performance. It’s very possible to work at the maximum 50fps per full frame and do per pixel work and prep for blit in sub 15 percent of CPU. Almost all devs aim for and achieve 30fps. You can have effective 200fps if you like since not all rows need to be refreshed per frame. An interesting situation is the device had an earlier Rev A before the Rev B that 90% of users have, and with Rev A up to 30-50% slower you have to develop for the base device specs if you want to be inclusive. It makes you wonder about Rev C decisions. All that said, most games are written in Lua which runs 50x slower than compiled C on the device, yet many very fun games have been released. You can compile ARM intrinsics/asm but it’s a rare situation if you can beat the compiler. Working within all these constraints is part of the charm of developing for it. It necessitates a discipline of writing tight benchmarked code, even inspecting compiled instructions, if you want to push it.

Reply on news.ycombinator.com