Best practices for managing lots of assets

SDK Get Help
21

I'm not asking you to do more work on this, I just wanted to note that since our artist can't update his Mac to use the most recent SDK, he's switched to building on Windows. And I could not figure out a reasonable way to run this makefile on Windows; so we're just gonna compile art assets on Mac and then he'll build the game on Windows.

Does anybody happen to have any advice for running a makefile like the one in Autotable on Windows 10?

23

I'm not familiar with Autotable, but I'm looking at the Makefile right now. I think you could make it work with a build of GNU make for Windows, with some modifications.

  1. The variable CMD is assigned the path to the root of the SDK. You could replace the magic Unix commands there with a hardcoded path assignment, like SDKBIN=c:/whatever/playdatesdk/bin

  2. The "pre" target is executing a PHP file. Don't know what it does, but you'd need a Windows PHP interpreter installed with (I think) the gd module. It doesn't look like it does anything platform specific.

  3. The "compile" target is just running pdc on the source code, as you normally would, to build the Playdate game from source.

  4. The "open" target would, on a Mac, launch the simulator with the built .pdx. You could just ignore this target.

  5. The "test" target would, on a Mac, copy the built .pdx to the simulator's filesystem, and open the Simulator into the Launcher. Again, you could just ignore this.

Hope this helps?

1 Like
24

Thanks, @stevenf! As I figured, it's just gonna take a fair amount of setup that each team member will need to do individually, including people who are not experienced with command line stuff. Theoretically I could set up an install script for those folks once I had the process nailed down, but that's out of scope for the moment. I'll just run this on a Mac, commit the updated imagetables, and that'll work for now.

25

So. :sweat_smile: 7 months later I discovered a bug that resulted in this only loading a single asset per frame regardless of how much time remaining was available. Basically it was comparing a millisecond value to a second value (eg. 33ms vs 0.33s) causing the outOfTime() function to always return true. :man_facepalming:

You can just replaced your Assets.lua with the updated version. If you’ve modified the source it’s just a simple two line fix. In Assets.lua , first remove the default value for local frameDuration. Then replace:

frameDuration = 1 / playdate.display.getRefreshRate()

with:

frameDuration = math.floor(1000 / playdate.display.getRefreshRate())

2 Likes
26

@shaun Oh, wow! Great to know. This library has been a lifesaver anyway, including showing me how to implement similar systems for other uses. I'll make this change and give it a test!

1 Like