[CPP] Guide: C++ on Playdate

SDK Development Discussion
,
18

This is really great and much easier to setup than previously.

I do have one request is it possible to add the following ?

image
image1007×313 20.5 KB

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

19

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.

20

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

21

I tested some more and it seems this might be better MINGW — CMake 3.28.0-rc2 Documentation

it works perfectably fine for compiling under msys2 using gcc mingw for compiling windows binaries / dll's

so basically the less broaden way would be to do

    
	elseif (MINGW)
    add_custom_command(
        TARGET ${PLAYDATE_GAME_NAME} POST_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy
        ${CMAKE_CURRENT_BINARY_DIR}/lib${PLAYDATE_GAME_NAME}.dll
        ${CMAKE_CURRENT_SOURCE_DIR}/Source/pdex.dll)
22

Excellent, I've added it to the repo.

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.

23

Hey all,

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!

1 Like
24

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.

1 Like
25

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?

image
image954×838 47.5 KB

26

I think the example sets the refresh rate to 20, as 20 was initially the default refresh rate of the Playdate. https://github.com/nstbayless/playdate-cpp/blob/main/examples%2Fhello_world%2Fmain.cpp#L116

1 Like
27

OMFG -- i feel stupid for not seeing that.

image
image492×518 33.8 KB

Thank you @Jackson_57

28

Pretty awesome. The Arduboy StarField lib was ported in ~ 10 min due to the CPP work y'all did. <3

image
image958×924 69.7 KB

1 Like
29

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):

3 Likes
30

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.

2 Likes
31

Love this idea!

I plan to port Evade 2 (a game i co-developed for the arduboy), along with the forked version of LibXMP and I'll be in touch afterwards. :slight_smile:

32

i've added my games.

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

33

@MrBZapp ,

Given that there isn't a specific C++ category, I figured it would be best to ask this question here.

In porting a C++ game, I learned that for some reason, use of malloc() before eventHandler() is called, cause a SIGSEGV.

An example of this is below.

image
image1178×948 86.5 KB

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 =)

image
image1766×1482 401 KB

34

Ah yeah, that makes sense.

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:

1 Like
35

Thank you. I appreciate your insights for sure. =)

Looks like converting this game is going to require a bit more surgery :grin:.

36

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..)
  • Some more stuff can't think of right now.
3 Likes
37

It's worth mentioning that you're not limited to 30 fps. If your app is fast enough, you should be able to push it to 60 fps.

1 Like