I needed to add this manually if i wanted to compile for the simulator on msys2 using mingw what i did was create msys makefiles by running cmake .. -G "MSYS Makefiles" under a msys2 prompt but it kept saying platform not supported because the WIN32 section did not exist so i had to add it manually.
I also managed to change the code to make the arduboy collection (ports) recompile made by eric lewis and i've gotten confirmation from a person that had a REV B playdate with the new cpu that it was working on their playdate
I'm so glad it's working out for you, that's fantastic!
As for adding that block for MSYS2, help me out here a little because I'm less familiar with MSYS2/MINGW than most of the other tools we're explicitly supporting.
Is WIN32 the narrowest possible scope for supporting your MSYS2/MINGW, or are there flags we can use that can target this change to your tools even more specifically? I am wary of casting a large net if a smaller one will do, but ultimately I do want to support this.
it's not just for MSYS2 / MINGW. there basically is no platform set for windows one except visual studio c compiler, which did not work it only worked if i compiled using GCC (but this could be related to the code i was trying to compile), One can download for example gcc compiler for windows (using mingw version or so) and compile from a CMD prompt as well instead of from the msys2 one and then you need that as well. Basically that entry is to support at least some default for the windows platform when using gcc and windows uses .dll's so its the same as the linux one except for the extensions. I'm not sure if there is a way in cmake to explictly detect msys2 i basically wanted a default for windows (in case of not using visual studio) which currently does not have one. If you keep this one always as last one and you have more specific compilers you can add them before this entry. But if specific targets in cmake do exists it might help more to be less broaden but i think a generic windows one when using gcc (nomatter where) should at least exist as you have a darwin (mac) and linux one. Also be aware i only needed todo this for compiling for the simulator because visual studio c compiler was complaining about (probably) certain specific code where gcc did not error out on. Compiling for the playdate itself worked fine straight out of the box but that was using the arm gcc compiler and not visual studio either, so i just replicated the same thing using an x64 mingw-gcc compiler running on windows and that worked fine for running it in the simulator. If anything at all one should detect perhaps mingw compiler instead of msys2 but not sure thats possible at all and if it's possible should probably give visual studio one preference
To your desire to have more things work by default, it's a noble goal, and I support it. I'm kicking around an idea that I'm growing more and more convinced would support sensible defaults much better than the current system, but it's a ways off.
For now, I'm going to make an effort to keep official mainline changes as targeted as this one. Once this idea has been fleshed out a bit more I'll let y'all know, I'll definitely need folks to test a feature branch.
A few quick updates on the project with some new features!
Third party library support
This has technically always been in the build system, but I haven't publicized it up till now because my sample size wasn't super great. Now that it's had some time to marinate and be tested on a few more libraries I'm comfortable putting more of a spotlight on it.
The README has been updated with instructions, basically the idea is that, if you want to use a third party static library, you can use a CMake function which tries to set it up to be compatible with the Playdate.
If you try it out, please report back if it worked or didn't, my sample size still isn't awesome, and I'd like to know about it if there are any edge cases not called out in the README.
A full C++ API for the Playdate, and extensions
I mention this again here since there are a lot of folks following this thread directly, and I have no idea if they hop over to the general SDK Development Discussion forum regularly, but this was released over on this thread:
I'm going to keep updates to the core functionality/buildsystem etc. in this thread, and any updates about the C++ API or the extensions in the other.
That's all for now, hope you all have a great day!
Thank you for all the work you have put into this.
I just got started learning the PD API and while I love C, I began to miss basic C++ quickly. I stumbled upon this thread (and the GitHub repo).
Looking forward to giving it a go. There are a few free open source games that I co-authored for the Arduboy and ODROID GO that I want to port to the play date, and porting them to C would be a huge lift.
Thank you again! Will circle back with any issues.
I love the idea of building an aggregator for pdcpp projects somewhere.
Itch.IO makes a lot of sense, so I put this together real quick.
I've added @joyrider3774 as a contributor, DM me if you want to be added too.
it doesn't feel particularly ideal that we have to go through one person to build a such a community page, but let's try this out for a while, maybe we'll find it does the trick, or maybe we find a smoother solution down the line.
Part of the boilerplate for C++ is telling malloc to use the playdate's pd->system->realloc under the hood. The pointer to that function is going to be uninitialized before the eventHandlerShim gets called, so declaring an object which manages some kind of dynamic memory before the event handler runs is going to result in some pretty fire-y crashes.
An unsolicited recommendation: wrap your entire execution in an object, use a std::unique_ptr declared in main.cpp to hold that object, initialize/destroy it in the relevant sections of the eventHandler, and use a C shim to call a method on the object every update:
I wanted to share my gratitude to @MrBZapp & @NaOH for the work you've done to enable C++ devs to write software for the Playdate. I was able to get the basic graphics & controls working today from our Arduboy game.
Loads more work to do.
Get audio working
Figure out how to plot pixels
Calibrate the gameplay to adhere to the 30fps limit
Loads of cleanup (a call to incbin is hard-coded with a path right now)
Remove code from other consoles & devices (SDL, LDK Game, ODROID GO, etc..)