samdze / playdate-nim Goto Github PK
View Code? Open in Web Editor NEWNim bindings with extra features for the Playdate SDK
Nim bindings with extra features for the Playdate SDK
I get the above error when compiling the example on an M1 Mac, with Nim installed from source. Details below - any help would be greatly appreciated!
% nim -v
Nim Compiler Version 1.6.18 [MacOSX: arm64]
Compiled at 2024-01-11
Copyright (c) 2006-2023 by Andreas Rumpf
% nimble -v
nimble v0.13.1 compiled at 2024-01-11 20:22:03
git hash: d13f3b8ce288b4dc8c34c219a4e050aaeaf43fc9
% arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0/libexec/gcc/arm-none-eabi/13.2.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --target=arm-none-eabi --prefix=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0 --infodir=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0/share/info/arm-none-eabi --disable-nls --without-isl --without-headers --with-as=/opt/homebrew/opt/arm-none-eabi-binutils/bin/arm-none-eabi-as --with-ld=/opt/homebrew/opt/arm-none-eabi-binutils/bin/arm-none-eabi-ld --enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
Error message:
% nimble device
Executing task device in /Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/playdate_example.nimble
Verifying dependencies for [email protected]
Reading official package list
Checking for playdate@any version
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Building playdate_example/playdate_example using c backend
Executing /Users/sdwfrost/Programs/Nim-1.6.18/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.8.0 --path:/Users/sdwfrost/.nimble/pkgs/playdate-0.12.0 -o:/Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/playdate_example /Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/src/playdate_example.nim
Hint: used config file '/Users/sdwfrost/Programs/Nim-1.6.18/config/nim.cfg' [Conf]
Hint: used config file '/Users/sdwfrost/Programs/Nim-1.6.18/config/config.nims' [Conf]
Hint: used config file '/Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/config.nims' [Conf]
..........................................................................................................
CC: setup
CC: ../../../../../Programs/Nim-1.6.18/lib/std/private/digitsutils.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/formatfloat.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/dollars.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/repr_v2.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/utils.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/graphics.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/system.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/file.nim
arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
compilation terminated.
import os
sleep(1000)
Gives a OS module not ported to your operating system error
When trying to compile the basic example project after following all the instructions, I get the following errors:
nimble simulator
Verifying dependencies for [email protected]
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Executing task simulator in /Users/simjnd/Documents/Lab/pdnim-test/pdnim_test.nimble
Verifying dependencies for [email protected]
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Building pdnim_test/pdnim_test using c backend
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/std/typedthreads.nim(51, 10) Error: Threads not implemented for os:any. Please compile with --threads:off.
Tip: 4 messages have been suppressed, use --verbose to show them.
nimble.nim(229) buildFromDir
Error: Build failed for the package: pdnim_test
stack trace: (most recent call last)
/private/var/folders/41/034yz3fs4f3_lj9tkvwjvw5m0000gn/T/nimblecache-189809156/nimscriptapi_3428472986.nim(210, 16)
/Users/simjnd/.nimble/pkgs/playdate-0.7.2/playdate/build/nimble.nim(78, 5) simulatorTask
/Users/simjnd/.nimble/pkgs/playdate-0.7.2/playdate/build/nimble.nim(10, 5) nimble
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/nimscript.nim(265, 7) exec
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/nimscript.nim(265, 7) Error: unhandled exception: FAILED: nimble -d:simulator build [OSError]
Tip: 3 messages have been suppressed, use --verbose to show them.
nimscriptwrapper.nim(160) execScript
Error: Exception raised during nimble script execution
When trying to disabled threads, the following error message appears:
Verifying dependencies for [email protected]
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Building pdnim_test/pdnim_test using c backend
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/osalloc.nim(218, 10) Error: Port memory manager to your platform
Tip: 4 messages have been suppressed, use --verbose to show them.
nimble.nim(229) buildFromDir
Error: Build failed for the package: pdnim_test
Hiya!
I've been working on debugging a device-only crash that I think is related to memory corruption. I started a thread about it on the playdate forum here:
https://devforum.play.date/t/device-crash-for-c-nim-based-game/16205
While investigating, I noticed that it doesn't appear that Nim is using the malloc
implementation provided by the playdate SDK. I tried adding logging into the memory allocating methods in setup.c
from the Playdate SDK and they were never being called. It look like Nim directly calls malloc
from <stdlib.h>
, as seen here:
https://github.com/nim-lang/Nim/blob/version-2-0/lib/system/mm/malloc.nim#L5
Does that sound right? Have you looked into overriding the default Nim malloc implementation to use playdate's realloc? Or have I got this all wrong?
I see the main repo contains tests, but the playdate_example
doesn't. The Nim docs mentoin the existence of the unittest
module and the testament
executable. Briefly tried testament, but I think it tried to compile my project for the host system (apple arm64) and failed. Decided not to dive into that rabbit hole. My testing requirements are simple:
My current approach uses a bunch of asserts, which are placed outside of the src
folder. The runTests
proc is wrapped in a catching function that prints a stacktrace to the playdate error console, which halts execution. Therefore, it only shows the first failed test
So I'm wondering whether there is a recommended approach for this, and what you think of my current approach: https://github.com/ninovanhooff/wheelsprung/tree/rider/
In lua, it's common to alias the api's like gfx = playdate.graphics.
In nim, playdate
isn't initialised yet when top-level code is executed. What is an efficient and safe way to do this?
I found that proc gfx(): ptr PlaydateGraphics = playdate.graphics
works, at least. But it's a shame it is evaluated on every usage.
So I guess
var gfx: ptr PlaydateGraphics
proc init() =
gfx = playdate.graphics
Would be the way to go, although it has the requirement of no access to gfx before init is called?
๐ figured I'd start with some easy feedback. It's very possible I'm just missing something. Right now when I build, the output is a playdate.pdx
. That means when I upload to device via the sim, other apps with that PDX name get overwritten.
It seems like this should be easy to change by updating the bundlePDX
build proc to use projectName()
:
exec(pdcPath() & " --verbose -sdkpath " & sdkPath() & " source " & projectName())
This change seems to work well for me locally, but I'm not sure whether there's a specific reason it's set up like this, so I figured I'd open an issue instead of just PRing.
This might be developer error on my part, but let's see...
When this lambda is invoked a few times, the debugger hangs on a SIGABRT after a few invocations. Note this might not happen when you set a breakpoint, because that reduces the amount of times per second the function will be invoked.
Happens on both sim and device
let fSpriteSetImage: TestLambda = proc() =
playerSprite.setImage(testSprite, kBitmapUnflipped)
(discard)
Reproduce:
bench
branch of this project and run it. That should run without troubleThis project is a benchmark that invokes api methods multiple times. Note that setImage is used in other places as well (1x per sprite) without problem
(name: "spriteSetImage - Bench Error?", lambda: fNotImplemented),
to (name: "spriteSetImage - Bench Error?", lambda: fSpriteSetImage),
Note1 that the debugger shows that the free
property of image is true. Not sure what that means but it might be relevant.
Note2: the name of the testSprite
in this project is misleading, it is actually of type LCDBitmap
I've installed it on windows according to all the docs and I get this error no matter what I do.
playdate\api.nim:53:28: error: conflicting types for 'NimMain'; have 'void(void)'
53 | return -1
This is just using the test setup in the documentation
The module is a mapping of the C API, but it also provides other extra features, so, it would still be very useful to have in-editor support with full documentation coverage.
The C API documentation is available on the official Playdate SDK website.
Inside Playdate with C
Problem
The example project currently will not compile when used with the bindings downloaded from Nimble. This is because multiple breaking changes have been introduced (audio player finish callback and buttonsState rename.
Reported here by user Dork
:
https://discord.com/channels/675983554655551509/1229190504583921694/1246518505176694898
Fix
Create a new release so Nimble is up to date with main
Prevent regression
To prevent this from happening again, a develop
branch should be introduced. develop
is only merged to main
when a new release is made, so that main
always represents what users will get when using requires "playdate"
. This then also applies for the README.md and the example project.
The idea is to explore whether/how NimScript can allow us to plug-in custom tasks to perform when the user builds the project.
Here's an examples of a use case, but can be applied to all kinds of assets pre-processing:
A task that searches for image files with a predetermined suffix and generates spritesheets containing rotations of the original images. Useful to optimize rotated images drawing on device.
The pluggable tasks could be other packages, but this is still to be decided depending on ease of use and amount of setup/configuration to be done.
An implementation of the use case above can initially be provided embedded in this module.
For profiling device code on Mac, an .elf file is needed. This is currently not generated.
I'm assuming this would be, if we could build device debug builds on mac.
The source mentions this is currently not supprted. I'm wondering what would be needed to make this possible
Using this code
#volume
if currentPlayer.volume.left < 1.0f:
currentPlayer.volume = min(1.0f, currentPlayer.volume.left + 0.1f)
if fadeoutPlayer != nil:
if fadeoutPlayer.volume.left > 0.0f:
fadeoutPlayer.volume = max(0.0f, fadeoutPlayer.volume.left - 0.1f)
else:
fadeoutPlayer.stop()
fadeoutPlayer = nil
I get this output for nimble all
: simulator bulids fine, but on device there is an implicit conversion from float64
* Executing task: nimble all
Executing task all in /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example.nimble
Verifying dependencies for [email protected]
Reading official package list
Checking for playdate@any version
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Building playdate_example/playdate_example using c backend
Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:simulator -d:debug -d:NimblePkgVersion=0.8.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
.................................................................................................................................
Hint: [Link]
ld: warning: ignoring duplicate libraries: '-lm'
ld: warning: ignoring duplicate libraries: '-lm'
Hint: dsymutil /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example [Exec]
Hint: gc: arc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
103863 lines; 1.094s; 146.242MiB peakmem; proj: /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim; out: /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example [SuccessX]
Verifying dependencies for [email protected]
Reading official package list
Checking for playdate@any version
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Building playdate_example/playdate_example using c backend
Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.8.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
................................................................................................................
CC: ../../playdate-nim/src/playdate/sound.nim
CC: bike_engine.nim
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c: In function 'updateBikeEngine__bike95engine_15':
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c:534:21: warning: implicit conversion from 'float' to 'NF' {aka 'double'} to match other operand of binary expression [-Wdouble-promotion]
534 | if (!(T26_.Field0 < 1.0f)) goto LA27_;
| ^
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c:551:15: warning: implicit conversion from 'float' to 'NF' {aka 'double'} to match other operand of binary expression [-Wdouble-promotion]
551 | if (!(0.0f < T37_.Field0)) goto LA38_;
| ^
Hint: [Link]
Hint: gc: arc; opt: speed; options: -d:release
When changing the nim api of volume to use explicit float32 instead of float...
proc volume*(this: SamplePlayer): tuple[left: float32, right: float32] =
privateAccess(PlaydateSound)
privateAccess(PlaydateSoundSampleplayer)
var left, right: cfloat
playdate.sound.sampleplayer.getVolume(this.resource, addr left, addr right)
return (left: left.float32, right: right.float32)
The warning disappears.
Should we do this for all of the nim api?
It seems the nim-bindings take care of closing files when they go out of scope. This is kind of nice, but it was unexpected for me.
This creates opportunity for a dev to trigger a double free: when the game-dev uses file.close() the file is free-ed, and subsequently by the nim bindings =destroy again. This could lead to a SIGABRT: double free with a stacktrace that leads to:
/home/nino/.nimble/pkgs/playdate-#main/playdate/file.nim(35) =destroy
Note that this has only been observed when building for Linux, with the fPIC
compiler argument. (I added that argument because the compiler itself suggested to do so). When building for mac, win or device, this behavior is not triggerd
I'd say that the bindings should not expose file.close() if it is not intended to be used by game devs. Indeed the example project doesn't use it either.
As it is, I think it is easy to trip up here. Even in menory managed languages like Java, devs are expected to call file.close()
I adopted the sample project, and it took me some trial and error to find out what the naming requirements were for various parts.
My project is called wheeelsprung
I was unaware that the name of the nimble file defines the project name, and that there exists a requirement for that to match the value of bin
in that nimble file.
At some point I used main.nim
as the entrypoint for my game and also used
wheelsprung.nimble
bin = @["main"]
accordingly. I then had some file not found errors. When changing main
to wheelsprung
everywhere to match wheelsprung.nimble
, the problem was resolved.
Perhaps, I would not have run into this problem when starting from scratch (nim setup
).
My suggestion: add a comment to the example .nimble file:
## the main entrypoint of your game. In this example the file `<project root>/src/playdate_example.nim` is
## the first nim file that is executed when the game is started
srcDir = "src"
bin = @["playdate_example"]
The recommended extension should become this one, which is the new official Nim language support extension for Visual Studio Code.
Feel free to ignore this since I don't actually need this import. I'm mostly recording this issue for posterity.
But; when importing std/logging
, compilation for osx simulator still works fine, but nimble device
fails with:
โฏ nimble device
Executing task device in /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung.nimble
Verifying dependencies for [email protected]
Reading official package list
Checking for playdate@any version
Info: Dependency on playdate@any version already satisfied
Verifying dependencies for [email protected]
Reading official package list
Checking for https://github.com/ninovanhooff/nim-chipmunk-playdate@any version
Info: Dependency on https://github.com/ninovanhooff/nim-chipmunk-playdate@any version already satisfied
Verifying dependencies for [email protected]
Building wheelsprung/wheelsprung using c backend
Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.2.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src --path:/Users/ninovanhooff/.nimble/pkgs/chipmunk7-7.0.3 -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/wheelsprung.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
...........................................................................................................................
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(1226, 22) Error: undeclared identifier: 'Tm'
candidates (edit distance, scope distance); see '--spellSuggest':
(2, 1): '$' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(1165, 6)]
(2, 1): '$' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(718, 6)]
(2, 1): '*' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(780, 6)]
(2, 1): '*' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(788, 6)]
Error: Build failed for package: wheelsprung
... Execution failed with exit code 256
... Command: /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.2.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src --path:/Users/ninovanhooff/.nimble/pkgs/chipmunk7-7.0.3 -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/wheelsprung.nim
stack trace: (most recent call last)
/private/var/folders/ww/sx_qg7z51jz6bgr15k4_5y8m0000gn/T/nimblecache-3905360933/nimscriptapi_3772293278.nim(187, 16)
/Users/ninovanhooff/PlaydateProjects/playdate-nim/src/playdate/build/nimble.nim(85, 16) deviceTask
/Users/ninovanhooff/PlaydateProjects/playdate-nim/src/playdate/build/utils.nim(22, 10) nimble
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/nimscript.nim(273, 7) exec
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/nimscript.nim(273, 7) Error: unhandled exception: FAILED: nimble -d:device -d:release build --verbose [OSError]
Error: Exception raised during nimble script execution
proc getLevelPaths(): seq[string] {.locks:0.} =
playdate.file.listFiles("levels")
The above code snippet triggers a declared lock level is 0, but real lock level is <unknown> [LockLevel]
warning.
Can be fixed by adding {.locks:0.}
to the listFiles function.
But I wonder: can we disable this check altogether, since lck are for thread-safeness and we don't have threads on Playdate?
If that is not acceptable, can we add locks:0 to the {.push}
pragma in all the api files?
This had me stumped for some time because the background music keeps playing, so really only the screen freezing gives an indication that something went wrong.
Am I missing something?
I would expect a stack trace in the simulator console and attached debugger console.
Here is a workaround: wrap the update call with:
import strformat
proc catchingUpdate(): int =
try:
return update()
except:
var message: string = ""
try:
message = &"{getCurrentExceptionMsg()}\n{getCurrentException().getStackTrace()}\nFATAL EXCEPTION. STOP"
except:
message = getCurrentExceptionMsg() & getCurrentException().getStackTrace()
playdate.system.error(message) # this will stop the program
return 0 # code not reached
... and set catchingUpdate as the update callback.
Produces
index -1 not in 0 .. 99
/Users/ninovanhooff/.nimble/pkgs/playdate-0.10.0/playdate/system.nim(38) privateUpdate
/Users/ninovanhooff/PlaydateProjects/nim_snake/src/nim_snake.nim(135) catchingUpdate
/Users/ninovanhooff/PlaydateProjects/nim_snake/src/nim_snake.nim(110) update
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/fatal.nim(54) sysFatal
FATAL EXCEPTION. STOP
Rather than doing this in the program itself, playdate/system.nim might be a better place for a catch-all.
Playdate OS 2.0 brought some changes to how C games are built.
This unexpectedly made the example Nim project unable to compile.
This is the error the compiler outputs:
...
fini.c:(.text.__libc_fini_array+0x20): undefined reference to `_fini'
collect2: error: ld returned 1 exit status
make: *** [build/pdex.elf] Error 1
Workaround:
manually defining and exporting to C a _fini
function somewhere in the codebase fixes the issue:
proc fini() {.cdecl, exportc: "_fini".} =
discard
The error seems to be caused by Nim generating C code that calls exit
, which is not supported by the Playdate.
The exit calls generated by Nim seem related to exception handling.
Are there any plans to make this repo available as a nimble module?
I know there are some specific build configurations required to allow a module to build, but I think those can also be vended.
Cheers!
My Use case: I'm thinking of building a game that is mostly in Nim, but uses comic-style cutscenes. The Panels library is perfect for this: https://cadin.github.io/panels/docs/cutscenes.html
Unfortunately only available in Lua. Basic Lua interop is needed to realise this.
The recommended Panels api might be difficult to call from Nim
Example: Panels.startCutscene(comicData, callback)
requires to call a function in a "namespace" (a global lua table, really) and requires two complex parameters.
I propose a more practical approach:
isCutsceneRunning = false
local cutsceneFinishedCallback = function()
isCutSceneRunning = false
end
function getCutsceneRunning()
return isCutsceneRunning
end
function startChapter2Cutscene()
local comicData = [..]
Panels.startCutscene(comicData, callback)
isCutsceneRunning = true
end
-- nice to have / stretch goal: support for simple parameter types like int and bool:
function startChapterCutScene(chapterNumber)
Panels.startCutscene(comicDatas[chapterNumber], callback)
isCutsceneRunning = true
end
let (result, errorMessage) = playdate.lua.callFunction("startChapter2Cutscene")
proc update(): int
var (result, errorMessage) = playdate.lua.callFunction("getCutsceneRunning")
(result, errorMessage) = playdate.lua.callFunction("updatePanels")
return 1
hmmm. At this point I realise that the playdate api doesn't allow for reading lua globals (isCutSceneRunning
), or getting a return value from a lua function. In the example above, result is just an int indicating whether an error occurred.
If I'm not missing something, this implies we would also need to implement the playdate.lua.addFunction so that we can
var isPanelsCutsceneRunning = false
proc panelsCutsceneFinished()
isPanelsCutsceneRunning = false
proc handler(event: PDSystemEvent, keycode: uint) {.raises: [ValueError].} =
if event == kEventInitLua:
let addFuncError = playdate.lua.addFunction(panelsCutsceneFinished, "onPanelsCutsceneFinished")
We can then call this from lua:
function startChapter2Cutscene()
local comicData = [..]
Panels.startCutscene(comicData, onPanelsCutsceneFinished)
end
So, in summary, I would like to have available:
I would encourage implementing the outerror that the playdate api returns, so that I as a developer can check whether the calls were succesful
importing std/random
or std/re
fails. There may be more, but these are the ones I encountered so far
I'd say random is quite essential for game dev, would be great if it could be added.
nim-1.6.16/lib/pure/os.nim(63, 10) Error: OS module not ported to your operating system!
I wouldn't give the regex module any priority at the moment.
I wonder how many Std modules are OS dependent?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.