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!
I am not convinced this actually belongs in the PR, so I am going to put it here.
When it comes to audio, what sort of workflow is the composer/arranger going to be looking at? Does it make sense for work to be done in something like Cubase before a final playback file is exported?
Playdate has generative audio capabilities. Has anyone written a portable generative audio package that works with SDL2? Implicit in this question is that such a package needs to be able to run on the Playdate too.
I canāt really speak well to your first question (I think it depends, but if you are targeting playdate you should be keeping its limitations in mind)
As for the second question: probably. You can mess with the audio buffer directly. As for exposing the underlying synth apis for play dateā¦ there isnāt anything to gain. SDL2 is an abstraction layer and in this case I think the abstraction is mostly around simple audio manipulation (which can be augmented).
SDL2 will handle audio conversion into whatever format works best in the driver. That said; ideally the developer keeps these limitations in mind and doesnāt stress the system too much. You can also still totally interact with the system directly. Iāve seen plenty of apps that donāt bother using the SDL file api and instead going straight to fd.
When you need it, you go bare metal. Even all major video games have a little non-portable code in them.
The goal is to keep as much portable as possible. That makes the project easier to manage.
There are two problems here- runtime playback, and file size. MP3 should be fine for runtime playback because it is premixed, but a lot of music will bloat the size of the final executable. The Playdate documentation mentions that generative audio can keep file sizes down. That is great, but I want portable generative audio so my game can be run on different platforms.
After SDL2 has been ported, do you have plans to port SDL_mixer? It has dependencies, and I have no idea what implications are for file size and porting-related headaches.
Finally, it seems like mixing 1 BGM and 2 SFX ought to be a reasonable load.
Portability isnāt the only benefit. Familiarity with the API surface is another big plus. I.e I makes games and donāt need to learn exactly how the apis work on Playdate to make a game.
The way audio works with SDL2 the only real option is play the raw buffer data. How it gets to the driver isnāt something SDL cares about.
Hi, dev of m4kc here. The reason it's running out of memory is not because of the textures - its definitely the world size. Currently the world is split up into 27 chunks which each have 64x64x64 blocks, and each block ID is stored as an int. This works out to hundreds of megabytes of memory needed for just block data. In order to get this to run on lower end hardware, the world size would need to be decreased.
At some point I am probably going to change the data type the blocks are stored in to an unsigned 8 bit integer, which would be much more memory efficient.
Did not expect this little project of mine to make its way outside github, pretty cool what you all are doing here 
Update: Just pushed a commit switching block IDs to u_int8_t. This nearly quarters memory usage.
2 Likes
Oh wow! I did not expect to see you here either! I also made quite a number of other changes to move the game loop out & add controller support. I would love to keep trying to get this to run!
I had attempted to make the world very small and somewhat succeeded also dropped menus etc. But no dice. Thanks for coming over here!
oh and I forgot to mention- I got heap allocation below 16mb, it's the stack that blows on us.
1 Like
Hmmm... that's odd, to my knowledge there aren't any large blocks of data allocated on the stack other than the textures, but that's only around 300 kilobytes of data. (Apparently global variables don't go on the stack). I'll probably have to look deeper into this.
1 Like
Has SDL2 for Playdate stalled, or is it moving forward?
1 Like
Quite busy with other things at the moment, but do finally have my hardware.
4 Likes
How are things on this? I have a game engine that uses SDL and I came across this and got excited!
1 Like
Kinda stale, probably needs to be overhauled. I have a long todo list. But the PR is open on SDL2 repo for anyone who may want to take over.
1 Like
Hi, I was looking into porting VVVVVV to Playdate, would you recommend trying to build with your repo, or putting more effort into properly merging your changes into the latest SDL2 build?
I've only just started learning SDL, but going off docs I see there are two 1-bit surface types, SDL_PIXELFORMAT_INDEX1LSB and SDL_PIXELFORMAT_INDEX1MSB available. Or possibly better since it'd avoid bit manipulation might be SDL_PIXELFORMAT_INDEX8, where color 0 and 1 could be set to black and white (or white and black). Could those provide a more direct and performant way for working with the screen or is there a reason they couldn't be used?
my repo is missing a lot of pieces but it also has a lot of the pieces you would need. I think the bulk of what needed to be finished was getting it to integrate with the SDL build system (I hacked around) and at the time the PD SDK had certain things that were hard to do which I think are fixed now. it's probably worth approaching with fresh eyes the core and then using the existing pieces.
1 Like
the SDL2 PD implementation I did translates all surfaces I think. there was some debate on this and I think ultimately what was decided was we would only support the 1 bit surface types. The video driver blits the buffer directly, so its as performant as it can be.
1 Like
Okay, I know that @icculus was working on the initial pull and wanted to give him space to do his work. Once heās done I will keep you all posted if anything comes of if.
I was just updating it to apply cleanly to the latest SDL2 revisions, which I have done. I don't plan to go any further without help, as I'm feeling in the dark beyond this point.
(With help, I'd still love to see this thing get merged into SDL2 and/or SDL3!)
I havenāt followed very closely, and itās been years since I wrote any SDL code, but Iām curious: how did you end up solving the run loop problem? As far as I remember SDL applications run their own main loop, which clashes with the Playdate OS insisting on doing that itself, or am I mistaken about that? Do the applications need to be modified to patch out their run loop?