This may be a Windows-only issue, but in 1.1, when you run the simulator from the command line with a build path as an argument, the build appears not to open, and the simulator starts with the system launcher instead.
What is actually happening is that the build does open, but the launcher is opened a frame or two later. There doesn't seem to be a way to prevent this.
This appears to be an unintended consequence of Launcher.pdx being included (or correctly located) in the SDK, whereas previously it wasn't. It's possible this behavior existed previously but didn't surface.
A workaround for this is to rename
Launcher.pdx in the SDK's
Data/System/ folder. The attempt to open the launcher fails silently and your build remains open.
Can confirm it happens on Linux as well
I'm still experiencing something similar in version 1.13.0. I'm on Linux (Fedora distro). The PlaydateSimulator won't use the build path that I provide as an argument.
In my case, renaming
$PLAYDATE_SDK_PATH/Data/System/Launcher.pdx does nothing.
A quick test (from within the bin dir) with this command works for me on Fedora:
How are you trying to launch the Simulator?
Well, originally I had the bin, along with the
PlaydateSimulator, in my path and I was launching it that way, but I just tried it your way as well:
# In my bashrc:
# export PLAYDATE_SDK_PATH=/home/birdlunch/.local/opt/PlaydateSDK
# And also...
In both cases, the Playdate Simulator launches, displays a prompt with the analog clock lock screen in the background:
The Playdate Simulator runs at your computer's speed, much faster than an actual Playdate.
Regularly test your game on a Playdate during development
| OK |
And then launches to the settings screen with no other apps available in the sim.
Is there anything else I could try that would help narrow down the issue? Should I build and launch a different game, or temporarily put some of my resources in another location? Maybe there are some details about my system that I could provide?
Oh also, I don't know if this is significant but perhaps it will offer a clue: the PlaydateSimulator didn't work out-of-the-box for me.
When I first installed it, it gave a command line error on launch:
./PlaydateSimulator: error while loading shared libraries: libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or directory
I fixed it by running
dnf install webkit2gtk4.0 . My machine had 4.1 and 5.0, but not 4.0. I saw that there was a development package for webkit available as well, but I decided to try the user package first. I'm still running it with that user webkit package.
Is the first version of the SDK you installed 1.13 by chance? It sounds like your preferences aren't saving so it can't find the correct SDK which is noted here.
You nailed it! Version 1.13 is my first SDK install. Creating the
~/.Playdate Simulator directory as suggested in your linked ticket fixed the issue after a second invokation. I thought it was odd that it wasn't saving my settings either…
Thanks for your help! I don't know if I'd have ever found that on my own. Solved.
Just wanted to mention that on the Version 2.0.0 SDK, I'm still seeing the issues that @BirdLunch ran into on Fedora (Not having
libwebkit2gtk4.0 and having to create the
~/.Playdate Simulator directory). Once those are done, the simulator runs smoothly though!
The ./Playdate Simulator directory bug was reintroduced inadvertently in 2.0 and will be fixed in the next release. Installing webkit2gtk is 'normal' and just a thing that has to be done on some distros.
I am getting the same behavior as reported by BirdLunch on 22-Feb.
I am on Windows 10 Pro. The SDK I'm using is 2.0 (installed via PlaydateSDK-2.0.0.exe, which I downloaded on 2-July). I just got my Playdate on Monday, and I installed the SDK on Tuesday.
I have the
playdatesimulator binary in my PATH, and when run with the .pdx folder as the only argument, the simulator starts, shows the analog clock/lock screen, then the "Heads up/Regularly test your game on a Playdate" modal pops up, and when I click through that, I see the playdate home screen with "Settings" selected. This same .pdx runs fine if I open it from the File menu.
Oh, good news, creating the
%USERPROFILE%\AppData\Local\Playdate Simulator folder fixed it for me! (source)
After creating that folder, I had to run the Playdate Simulator once so it would write its ini file, now when I run
playdatesimulator project.mdx on the command line, it works as expected!