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 was able to run the C++ hello world and found it strange that the FPS indicator goes down to 20. I'm on a M2 Max, so this machine should be plenty powerful (The C-Hello world goes to 30fps).
I'm using the 2.1.1 (latest?) version of the SDK, fwiw.
Is there anything I could have done wrong?
not sure if it has any extra benefits but maybe we should start with a made with playdate-cpp page somewhere ? with links to source code or so, or a collection on itch.io ?
For me porting my old games has become very easy now, as i no longer have to convert c++ code to C code first which was tedious and time consuming.
Currently these games of me, use playdate-cpp (links to source code on github can be found in the more information section on itch.io):
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.
It's also possible to find projects using playdate-cpp on github by searching for code for it, i found a project named klangstrom and a gameboy emulator using it ( https://github.com/search?q=playdate-cpp&type=code ) but did not find the projects on itch.io so could not add them
Seems that any use of malloc invoked by __cxx_global_var_init would crash the program. I can't seem to find any technical reason for this. Any thoughts would be greatly appreciated =)
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..)
Thank you. I did brig it up to 50, as I read somewhere that 50 was the limit. I hadn't considered bringing it up to 60 though. . I'm still very very new to this platform.
I'm going to attempt to run it on the device today and see if I can even get it to run as/is.
Hey gents, how does one overcome the situation where ld fails with an error like .data has both ordered ['.ARM.exidx.text.__aeabi_atexit' ... and unordered ['.data.__atexit_recursive_mutex' ... sections. ?
Then dealt with a undefined reference to '_gettimeofday' error by having to define it (incorrectly). The code now compiles, runs, albeit incorrectly as I don't have the
#include <sys/time.h>
// This function is called once upon boot up of the game and not through the gameplay.
// Returning 0 seems to be fine Β―\_(γ)_/Β―
extern "C" int _gettimeofday( struct timeval *tv, void *tzvp ) {
return 0;
}
.
. I'm still very very new to this platform.
