Helpful Tip: Make Visual Studio Automatically Open/Close Simulator


I have found a much easier way to do this by simply setting up Visual Studio to use the simulator in debugging. Please see this thread for how to do that. This is actually preferable to simply launching the simulator when building, since it allows you to use debugging features like setting breakpoints in your code.

The Issue

When I was playing around with the SDK and using the C API in Visual Studio 2019, I started getting annoyed that every time I wanted to build the project I had to manually close the simulator if it was already running the project (this would cause an error in the building process) and then manually reopen it to test the changes. I spent the a decent amount of time finding a way to make Visual Studio do these actions for me, and now I want to share them with the rest of you, since this is the kind of thing that really streamlines the development process.

The Solution

Visual Studio has what are known as Build Events. These are categorized as Pre-Build, Pre-Link, and Post-Build. The first and last one of these are the ones that matter for this situation. To view these events, you can right-click the main project (the one that builds the DLL) and view its Properties, from there you can expand the section for Build Events.

The Pre-Build Event

This is the event that's going to make it so that, if the simulator is running, it will be closed before building the project. The reason we have to do this is because if the simulator is currently accessing the .pdx folder, Visual Studio complains and errors out, since accessing that folder is part of its build process.

The easiest way I found to kill the simulator is with a batch file. Go to the place where you have installed the SDK, and go to the bin folder. In here, make a new file called kill_simulator.bat and copy-paste the following inside of it.

tasklist /FI "IMAGENAME eq PlaydateSimulator.exe" 2>NUL | find /I /N "PlaydateSimulator.exe">NUL
if "%ERRORLEVEL%"=="0" taskkill /f /im PlaydateSimulator.exe

Afterward, go to the Pre-Build Event in Visual Studio and paste this in the Command Line field:

cd $(PLAYDATE_SDK_PATH)\bin && kill_simulator.bat

The Post-Build Event

The easiest way I found to get Visual Studio to bring back the simulator after completing the entire build process is to call a powershell-specific command.

When you go to the Command Line field of the Post-Build Event, you're probably going to see a bunch of commands that had been auto-generated by CMake. Don't touch any of them, since this will most likely mess up the build process. Instead, click on the little arrow that lets you expand a drop-down menu and choose "Edit"

A window will open up where you can see all the contents of the Command Line field at the top, and enter some new ones. Find whatever the command is, put a new line under it, and paste this

powershell start-process $(PLAYDATE_SDK_PATH)\bin\PlaydateSimulator.exe 

Click OK to save the Command Line and OK again to save the Properties

After this, you should be all good to go. Now whenever you go to build your project, the simulator will auto-close, and come back as soon as it's had a successful build. Because the simulator will default to reopening whatever .pdx folder it was last running, you now have a really quick way to reload the simulator with your latest changes.

Happy programming!


Thanks for this! I was having similar issues with having to close and open the simulator after building. However, I am using CLion on Windows instead of Visual Studio. I couldn't really figure out how to set this up exactly in CLion, but upon researching I found that you can get identical behavior just by using CMake pre-build and post-build commands. Just add this to the end of your CMake file:

	add_custom_command(TARGET ${PLAYDATE_GAME_NAME} PRE_BUILD COMMAND START /wait taskkill /f /im PlaydateSimulator.exe )
	add_custom_command(TARGET ${PLAYDATE_GAME_NAME} POST_BUILD COMMAND powershell start-process ${SDK}/bin/PlaydateSimulator.exe )

The only downside is this bypasses the IDE you are using, so it won't detect when the exe is running. This is also not useful for using the debugger since you need to launch the simulator from the IDE for that. However, for quickly testing changes to your code this makes things much easier.

1 Like

Just curious, ware you able to put breakpoints in visual studio and debug the C code with the simulator? If so, can you provide any pointers on how to do that?

1 Like

You could use closeSim.ps1, tasks.json and launch.json from

for this purposes. :smile:

1 Like

Believe it or not, I hadn't thought to even try and set this up until I read this just now. I managed to get the simulator to launch and attach itself to a debugger.

I made another post to serve as a guide for anyone in the future.

Hi, I believe there is a simpler way to start/stop the simulator during a debug start/stop session...

In the generated Visual Studio Solution, go to the "hello_world" project properties, in the "Debugging" tab,

  • point the "Command" entry to "$(PLAYDATE_SDK_PATH)\bin\PlaydateSimulator.exe"
  • "Command Arguments" to " $(TargetName).pdx"
  • "Working Directory" to "$(ProjectDir).."

Now, when you press F5, after compilation & linking, simulator should start and boot the pdx.
When you stop the debugging process with SHIFT+F5, the simulator will quit...

1 Like

Yup, I myself discovered this after doing some tinkering and ended up making a different thread about it to let others know.

any idea on how to do this on a mac?

On Mac you can do /usr/bin/open -a "path/to/Playdate" "path/to/Game.pdx". I like the way this repository sets up the VS Code launch configuration: GitHub - cadin/playdate-vscode-template: VS Code template with tasks for building and running in Playdate simulator.


i've set up the template but i don't know what to do with this error message
error: main.lua or pdex.bin required
The terminal process "/usr/local/bin/zsh '-c', 'mkdir -p bin/Output.pdx; pdc source bin/Output.pdx'" terminated with exit code: 1.

@Rusty That error message means that there is not a file called main.lua in the source directory within your project (assuming you're using Lua).

i did have a main.lua file it was that i didnt have it in a source file thanks for the help though i got it sorted out on discord

1 Like