Hello all, I have been working on something kind of cool. As the title says, bringing SDL support to Playdate! There is quite a bit of work to do still, but I finally got video to work. Here is a Minecraft clone (M4KC version) running on the simulator. I think the simulator uses SDL2 as well, so this is kinda funny. Should work for hardware, but not sure about perf, seems great on sim (better than lua). The Malloc log also seems paltry. But probably cause it’s not using Lua at all.
Basically the video driver converts the surface provided during run loop to a b&w image then dithers, once that is complete it writes directly to the frame buffer and flushes. Very little optimization currently, also am not a fan of the dithering algo (half-tone? I think?). Plan to put out in the open once I get some level of input working (gif is just hard coded values for mouse X/Y). The game in gif is: GitHub - sashakoshka/m4kc: Minecraft 4k: decompiled, translated to C using SDL for graphics and input, and improved upon with modification to support pd runloop. This has been a very fun way to both learn (more) c, the pd low level apis, SDL + SDL driver creation, and a bit of math. Trying to create a real patch to submit to SDL org is the goal.
Initial Ports
video
sensor
joystick/pad
audio/mic
battery/power
keyboard (?)
SDL_GetPreferredLocales
Started this because I was looking for inspiration in C voxel game engines, came across the M4KC repo and learned about what SDL was. Original idea was to build something in the 3D example but I know next to nothing about 3D graphics programming, and once I got just a little bit working, realized I knew even less better at the interface between art and computers it seems!
Another thing to note that is hard to capture in the gif is just how smooth this runs. Will try to make a better video, if course it’s just sim. Porting the C code to device should be too challenging, I had it partially working but did something to my project that broke. Hope to get all this cleaned up over the weekend.
Porting the game wasn’t too hard but has a simple main. Was easy to also make compile for a regular desktop OR a Playdate, sharing the rest of the codebase. Felt so good when the view actually worked (I looked at scrambled mess for hours while trying to figure out a decent dither algo / how the LCD panel worked)
Extremely incomplete. I started last night and only finished with video today. Joystick, sensors, maybe keyboard / mouse emulation should be pretty straight forward. Making sure it works on the device also should be straightforward. I’d guesstimate a few more hours of continuous work (hard for me to come by). The music support I am very unsure about, and cant estimate. A lot of the C apis basically provide what is needed by SDL anyway, the harder thing for me was learning how SDL is setup project wise and how to write decent code for it, and of course figuring out the display maths aren’t my strong point.
Edit: Would also like to add that there isn’t any OpenGL support either, I’m also unsure of how that goes. I’ll get everything in working order with a clean set of commits then open it up for others to play with. There isn’t exactly any parallel SDL drivers I could find, pd is a little unique in how it’s APIs / programming is done.
I suspect that it will be unavoidable to simply not support features that do not make sense for the Playdate. For example, there is no keyboard or mouse, and the buttons can be mapped to the first joystick/gamepad.
There actually is a software keyboard that can be triggered. how that is supported on psp/vita may be relevant to pd as well. But yes, no mouse. Working on joystick now! Looking good.
I suspect that OpenGL could be made to work on the Playdate. Whether it will run well is an open question. Someone may have ported it. I am not sure. I am willing to look at math.
Keyboard hardware will not be generating key events on the Playdate. Do you know if the software keyboard on the PSP/Vita generates the exact same key events as a hardware keyboard? In any case, the Vita has touch input, but the Playdate does not. Personally, I do not think a keyboard would be intuitive enough on the Playdate to be worth the trouble.
Perhaps there is a better model for the Crank, but absolute angle could be mapped to the X-axis on an analog stock. Maybe the relative angle change could be mapped to the Y-axis on the same analog stick? Docked status can almost certainly be mapped to a button.
Audio/DSP is its own world. I really want to see the SDL2 audio functions ported to the Playdate where they make sense, but I do not have the domain knowledge to be of much use.
Okay, time for a bit of code! This is definitely not enough to start using SDL on the playdate, but it is all the necessary bits required. The files missing currently are hacks that I am now trying to get rid of! Luckily there aren't many. I will publish a sample project (or fork of that game) with PD support properly set up. First, going to get back to compiling for device.
Anyone with a device mind testing? I doubt this will do anything but crash, but it is compiling for device now with fairly minor changes. Not sure if it will cause any problems tho... so use at your own risk. But if it does work... you should likely get a super laggy Minecraft like game! It might work on sim for ARM Macs- in case you are just curious to play around.
Edit: this will def crash, it is not using the right allocators (fixed now) and on top of that, it is WAY too RAM hungry to even think of running on device lol. Reason for this is textures are all generated and stored in ram up front. I will find a simpler example.
I'm afraid the .pdx crashes on launch. I didn't see any useful logs myself. Something like Minecraft is likely too much—maybe a simpler example would work?
Yeah, I realized it would crash after I posted it. I forgot to switch over to using the pd allocators, so I went ahead and did that, then found a REAL nasty memory leak in the frame buffer driver, which was making the whole thing totally useless... but I have since resolved that problem and now the Minecraft demo should actually work and fit in a ram! However, during my hacking around I have somehow completely messed up my ability to do device builds. So I am trying to fix that and then will post a new pdx.. and that pdx should work!
This one miiiighttt work on device. I am stubbing a few syscalls that are probably important. Solved for this previously, so it should be fine once I can get the stubs out!
This launches, and shows the start screen. It then goes into "Generating world…" and reaches about 85% of the progress; then it overflows the stack and the run loop stalls
Yes! Okay, then I can fix that. Just make the world one more notch smaller The creation / holding of chunks in memory is pretty high pressure. The simulator was showing 13mb with the current settings which I know is pushing the limit! Try this one: m4kcv2.pdx.zip (616.1 KB)
oh and:
left/right arrows is look left or right
up/down forward back
a is jump
b is break blocks
and yeah I know you can't do much of anything else lol. this game was obviously optimized for the pc ha.
Aww man. I’ll probably need to wait till I have some hardware in hand to be able to fix things like this. I’ll create at least small demo to demonstrate
Do you know if a previously running app might be holding on to some memory? Maybe lua engine. Not sure, curious how the hardware really works. Back the drawing board it seems though!
Without a world or textures the heap is ~4MB the simulator claims. Wonder what all that’s even doing.
I pressed cancel on a lot of emails after crashing during the development of this. Heh. Looking at a few open source games, will port one if it’s not too hard.
better at the interface between art and computers it seems!
The creation / holding of chunks in memory is pretty high pressure. The simulator was showing 13mb with the current settings which I know is pushing the limit! Try this one: