Lots of work to be done on optimization heh, thanks for checking it out!
Most of these are very very bad ports from projects I find on GitHub. Plenty of mangling going on, so maybe a more concentrated effort would be better 
once I get device I can better profile what is going on.
We can do that. Gonna let Eric keep working until he's comfortable with the state of it and then I'll review it with the intention of trying to get it merged.
Eric, is it totally too soon to start using your SDL2 port for prototyping? FWIW, I plan/want to use Rust-SDL for development.
You could, but I wouldn't since there is lot's of perf stuff to be shaken out once I get an actual device.
Edit: had to write that on the way out the door, so now that I’m home I can expand: you could because it’s functional (and would be helpful for figuring out problems of course) but the reason why I say I wouldn’t is that even a simple snake game isn’t getting very good FPS, the raytracer demo is getting 2.5 fps, and I have no hardware to trace down exactly what part is being slow, therefore my optimizations are purely theoretical, and I would hate for you to sink time in to using this and the perf never quite getting there.
rewrote the framebuffer code in the video driver:
Based on my testing in simulator, it went from averaging ~40-70 fps as measured by SDL to ~100-150fps. Not bad considering no GPU acceleration, I suspect the raycaster might actually be functional. Anyone with a device and is willing to try these out, please try both and report wether the rolled or unrolled seems to be faster/more performant. Snek includes the FPS meter on screen, but both games output FPS to the console every 500 frames.
Checked out the ASM for these and interestingly is using SIMD commands under the hood.
raycaster_unrolled.pdx.zip (596.4 KB)
raycaster_rolled.pdx.zip (593.6 KB)
snek_rolled.pdx.zip (572.9 KB)
snek_unrolled.pdx.zip (575.3 KB)
even more efficiencies, using precomputed rows & updating rows that have changed only
snek_v3.pdx.zip (427.8 KB)
give it a test and report back!
Alrighty! I am going to start submitting patches upstream soon. In the meantime, here is the (almost) complete patch for supporting playdate: https://github.com/ericlewis/SDL/pull/3/files
The biggest missing piece is configure/make changes that might be necessary.
I had a random thought that woke me up. Does SDL2 support for 1-bit bitmaps? This leads to the next question. Are there any places where SDL2 can obviously be optimized on Playdate?
It does not support them directly. The most important place thus far has been the frame buffer. Everything else is quite fast from my tests. but until I have a device I can't say for sure what needs optimizing.
What is the issue with the frame buffer? Do you know if there are issues with running out of memory?
There is not an issue anymore. It can hit memory limits if the games are sloppily ported.
So it sounds like SDL2 can be used to make truly portable games as long as the Cortex M7+16MB RAM is sufficient to run them. From an architectural standpoint, could it make sense to just use color graphics and let SDL crunch to 1-bit and do the dithering? (Obviously, custom 1-bit graphics will almost certainly give crisper results.)
I will provide hints to control dithering eventually.
you do just use color graphics. it is automatically dithered and rendered directly to the framebuffer.
The upstream draft lists threads as the ideal solution for handling SDL2 audio. C API threading support for Playdate is inconclusive, but pthread may be available. It sounds like someone would need to make a test project to find out.
pthreads aren’t supported. neither is memory management, high resolution clocks, etc. it might be possible to implement those in some way however. At this point I’ve got a micro kernel on my hands lol.
Looks like the official word is that threads are not supported. Regarding memory management, you can always do the equivalent of malloc()ing the entire heap. Then memory can be handed out as you see fit.
you can always do the equivalent of
malloc()ing the entire heap
SDL has implementations of some significant parts of the C runtime built in, for systems where the C runtime isn't available or trustworthy. One of these things is an implementation of malloc() that can operate out of a preallocated block of memory...so SDL_malloc() and friends can work as expected even if the system just says "you can use this block of the address space and that's it."
(just as a heads up, I'll likely do technical discussion on the pull request page, so if I don't reply here, it's just because I live and die by my GitHub notifications nowadays.)
Yep! Also, PD does support malloc etc if you setup correctly. I was just using that as an example @sgeos 
Also, totally understood on the discussion thing. Now that the process has begun it is better we do all discussing there!