@zoranc we're just as keen on getting the d-pad right. Hopefully the beta testers will help us do this- although the parts we're using have already been battle-tested and - like you say - we're using the hardware ourselves so we'll certainly catch all but the subtlest of problems.
The prototype is - I'm pretty sure - much closer to a GCW Zero in size. Albeit I must admit I don't have a GCW Zero to compare it to. We're talking 15cm x 6cm approximately.
I'd say we expect more software to use the analog stick, since it's a bit of a modern twist to the retro handheld- but the stick is far more proud than the D-Pad and we've only got a single PCB to mount these to so I dare say they wouldn't swap well without the analog getting in the way of d-pad use.
@Pickle it's all about developing retro-styled games for a basic system so the RAM limits aren't concerning. This RAM is what's available inside the MCU itself and external parts (we'd be looking at things like Quad-SPI FRAM) have neither the capacity nor the low cost you might expect from DRAM.
I'm doing okay running a textured raycaster with 5k sprites on-device. If you look at the MCU datasheet you'll find the RAM is also split into non-contiguous banks which lend themselves well to handling different features- we hope to provide peek/poke access to these as if they were hardware registers, and recapture a little of the classic programming vibe. It doesn't *need* to use palette-based assets but I personally prefer them. We have an asset packer that supports 1-8bit graphics in indexed palette mode, and also support for regular RGB and RGBA. I've started doing pixel art just to test it!
@levi we're targeting 160x120 (pixel-doubled to the 320x240 display) and consider this limitation a feature. It's possible to run the screen at native-resolution but with 4x the pixels you have to consider carefully what you do with it. That said we've run our awful unoptimised in-house demos at native res for giggles at pretty respectable framerates. The system is double-buffered between an RGB565 320x240 display back-buffer and an RGBA32 160x120 in-game drawing surface.
There's no Linux-OS and what little OS we do have will be extremely minimal- just a bootloader with our engine and Lua VM baked in and the ability to load in and run user games from flash- whether they're written in C++ or Lua.
Note that technical details of the software are all subject to spontaneous change as we get a better feel for what works.
While I don't like comparing us to PICO-8 - we have a good relationship with Zep and don't want to detract from the fantastic product/community he's built - the 32blit really is more "PICO-8 with hardware" than us putting together a hamfisted emulation console. Although we'd still love to see emulators!
By and large we're listening intently to what people are saying about the device and asking for.
