Windows compiler potentially not cleaning up redundant pdz files

[IGM0937]

SDK 1.13.2 - Windows and Linux

Hi Team,

As I have been working on both Windows and Linux for my game dev, I have come across something strange that I am not sure if it's a bug or something I am doing wrong.

When I compile/build the same code between two OS, I get different resulting sizes.

For example, my game reSnake (itch.io link, github link) when built on Linux using pdc results in a .pdx file size of 117.6 KB and when built in Windows, it is 168.6 KB. The pdc command that I use to build on both OS is:

pdc -sdkpath <path_to_SDK> .\source\main.lua reSnake.pdx

Looking at the .pdx containers of the two variants reveals that the Windows version contains additional .pdz files that I presume represent compiled .lua files, however the Linux version does not.

The image below is of my VSCode project tree showing contents of both game and screens folders in the two .pdx containers.

Looking at the main.pdz, both are around 98 KB. This makes me think that the compiler combines all of the .lua files (via the use of imports) into a single main.pdz file on both OS's, but for some reason the Windows compiler does not remove potentially redundant files.

I tested this theory by compiling the Windows build and manually removing the extra files so that it resembles the Linux build. The game runs perfectly well in the simulator.

Is this by design?

Thanks.

[matt (gingerbeardman)]

I've always passed PDC the source folder, not pointed it to main.lua. Does this change your results?

Docs: https://sdk.play.date/inside-playdate/#_compiling_a_project

pdc requires two arguments: the input (source) directory, and an output directory.

$ pdc MyGameSource MyGame.pdx

[IGM0937]

Changing the argument to point to the folder instead does not change the result. I still get the extra .pdz files.

[Nino (Gravity Express)]

Can you give us a screenshot of the structure of your source folder?

Also, can you give us some examples of how you use the import statement?

Do you use file.run anywhere in your code instead of import?

[IGM0937]

@Nino sure,

In summary, the main.lua and util.lua files are the only files that I have in the root of the source folder. Everything else is dispersed across game and screens folders. I'm not showing screenshot and images folders because I don't think they are relevant and they only contain .png files.

If you want to look yourself, you can see this same structure in the main branch of the Github page.

As a small experiment, I did try to flatten my project structure to put everything in the two folders to the source folder and after building it DID WORK as expected .

Experimental folder structure:

Experimental compile structure:

In the image above, the extra .pdz files are not there.

So it seems to be working as expected when there is a flat folder structure, but not if there are other folders involved. (I did retest this just to make sure I'm not going insane).

To answer your other questions, most of my imports looks like this:

main.lua

import "screens/menuScreen"
import "screens/tutorialScreen"
import "screens/gameScreen"
import "screens/endScreen"

import "game/soundManager"

I don't use file.run anywhere like you suggested.

[Nino (Gravity Express)]

Yep, there are some problems around the import statement.

To be most safe, it is best to keep all lua files in a single folder.
I myself opted to implement my own version of the import statement, but you have to know what the pitfalls are when going that route

Interesting reads:

Lua file seems to be imported multiple times

That's what it should be doing--I patched the Lua compiler so that import statements resolve the file and replace the given path with the full project-relative path--but I must have goofed something up. But I expect it'll be easy to reproduce with your test case and hopefully not too terrible to fix.

Import statement support for paths relative to the project root folder

Unless I'm mistaken, all paths given to the import statement are relative to the file's location. I'm putting together a little dependency management system for Playdate and it would make cross-dependencies a lot easier if we could also use paths relative to the project root folder. Syntax could be simply something like: import '/source/test.lua' which would convert to <Path to the Project Folder>/source/test.lua. Another way to solve this would be to add include paths support for pdc but it…

Import statement needs .lua extension for paths containing `..`

With pdc, using the same Lua file, placed in two different locations relative to the current Lua file, this works: import 'toyboxes/toyboxes' -- WORKS! while this doesn't find the file: import '../toyboxes/toyboxes' -- DOESN'T WORK but this does: import '../toyboxes/toyboxes.lua' -- WORKS!

Gravity Express

Ditching the import statement to improve boot times As per the docs, the import statement is a function available in the Playdate SDK that is not part of standard Lua. Conversely, the require statement is in every Lua distribution except for Playdate. The import statements are not run by the playdate, but instead by the pdc compiler. import "otherfile" basically means: read otherfile.lua and paste everything you find there at the current position in the current file. This way, you as developer c…

I'm getting old, lol.

[IGM0937]

It's more like you are experienced

Thanks for the reads, I'll give them a look and come back if I have questions.

Unless it's been discussed in other threads, it would be interesting to hear if this is being looked if it's considered an actual issue.

[willco (Will)]

@IGM0937 Could you try building with the pdc linked to in this comment and see if it fixes your issue? Thanks! Pdc on Windows doesn't seem to support import path relative to the current file - #7 by dave

[IGM0937]

Hi @willco , I have tested it and it does work correctly.

It looks like the issue is related to backward vs. forward slashes in Windows as @dave mentions in his post.

I have also in turn tested with the latest build of the SDK v1.13.4 and it didn't work. It only worked with the pdc.exe specified in that post (v1.12.3-dev.148654).

Thanks for circling back. Will this be marked for a future SDK build fix? Even though the problem has been found, I wouldn't classified it as solved. Happy to do what you think is best.

[willco (Will)]

@IGM0937 Yeah, we have this fix pending and should make it into a release in the not too distant future.