When using the emulator, I mark files as ‘copy to SD’ to have the copy as the game launches the emulator. How do you do this in the simulator? I have marked the files to be copied but they do not seem to get there.
On the simulator it requires the path to the file on disk. I’m not at my computer ATM but I figured out a way to add a PREFIX_PATH to the compile time defines. From there instead of file.open("/path/to/file") you do file.open(PREFIX_PATH"/path/to/file"). When building for the sim it would define PREFIX_PATH to the project’s root folder and "" otherwise. Will post the mod to project.json tomorrow for better details.
2 Likes
OK … that’s interesting (and like a lot of things undocumented!).
1 Like
I’ve never had to use a prefix path. Doesn’t P-Type’s music work out-of-the-box in the simulator for you? That doesn’t have a prefix either.
The issue with this is it’s not always cross platform (though it won’t work for distributing a binary, but I don’t think we’re distributing sim binaries). Here’s the modifications I made to the project.json (I also successfully modded Karateka and L’Abbaye with this method).
In project.json find the section "CPPFlags":
locate the array "Pokitto":
add "-DPATH_PREFIX=\"\"" to the end of the array
Then under the "Desktop": [ array under "CPPFlags":
add “-DPATH_PREFIX=”${projectPath}""
Then for your resources use PREFIX_PATH"/path/to/file" with a / at the beginning of the path. As long as your project folder is treated as the root of your SD then it should work. For instance if your project folder has a music folder with a bunch of music files and that goes in the music folder on the root of the SD then you would use something like PREFIX_PATH"/music/filename.raw to access it. This doesn’t work for distributing a simulator binary, but when someone downloads the source code and compiles it for the simulator it will adapt PREFIX_PATH to the exact location of the project on their system.
4 Likes
This worked well!
Some minor updates to @tuxinator2009’s code above.
In project.json find the section "CPPFlags":
locate the array "Pokitto":
add "-DPATH_PREFIX=\"\"" to the end of the array
Then under the "Desktop": [ array under "CPPFlags":
add "-DPATH_PREFIX=\"${projectPath}\""
Then for your resources use PATH_PREFIX"/path/to/file" with a / at the beginning of the path.
3 Likes
This is extremely ugly as a solution on so many points, code-wise and other. It also forbids you to distribute your .exe - unless you make the user have the same exact path for their resources…
Wouldn’t setting a proper Current Working Directory for the sim be much better?
1 Like
I’ve just discovered that SDL2 has a function to get the path of the executable in a cross-platform way. Since the sim alreadys uses SDL2 it might not be too difficult to automatically handle this.
4 Likes
or you could use main’s first argument to deduce it so 
Really, if the CWD is properly set it shouldn’t be an issue at all. That’s also the very point of having a CWD
Maybe the launching of the executable is the thing that isn’t properly done
Agreed but it works for me. I am not actually planning on distributing the code in any other form than a Pokitto bin, I just needed to be able to test my code in that environment.
2 Likes
This is inherently what libs like SDL2 and Qt5 do in the background. The difficulty is there’s no cross-platform standard way of doing it. So better to let the library manage the different platform stuff in the background.
Actually, as of C++17…
https://en.cppreference.com/w/cpp/filesystem/current_path
Better late than never I guess. ¯\_(ツ)_/¯
Be cardful though. Current path is not the same as application path and isn’t guarenteed to point to the folder the program is in like the function provided by SDL2.
1 Like
Still, has anyone tried to just point the CWD at the right place (simulated SD card root) before execution? I’m pretty sure you don’t even need current_path this way.
It’s the closest of what’s happening in the HW imho, and wouldn’t need any code adaptation if done correctly.
Also, the very first argument of main is the path to the executable, possibly relative to the current CWD.