You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are reaching the point where accurate emulation matters. Automatically testing edge cases especially for some API drawing functions may be useful, e.g. to optimize code more aggressively while reducing the testing workload.
Test-driven development would make sense in some cases while implementing the API. String rendering, RNG, and some other things could benefit from this approach, in particular.
We could probably do some nice testing against PICO-8 by injecting a printh of the PICO-8 memory somewhere in update functions. This would allow detecting subtle bugs and differences in the implementation especially if performed automatically.
Fuzzing the API to detect differences in parameter count handling or argument type handling may unravel some inaccuracies in the interface implementation.
This raises a few issues:
CMake does not support cross-compilation for different architectures within the same build directory. Making two build directories is possible, but this would likely need some tinkering with VSC so that the CMake integration isn't dogcrap to use. If external development is ever opened up this has to be tackled. Ideally only one command should be run to compile for both arches and execute tests, at least as an option. Emulating ARMv6-M with qemu or something is an option but would be complicated to set up, would make instrumentation difficult, and is of limited use since recent bugs that were difficult to debug happened both on the Pico and on the desktop builds.
How to even execute tests? We could use CTest from CMake, but how about running the tests themselves? Integration tests might be easier to implement in pure Python, unit tests might be a lot easier to make using Catch or a similar library.
The text was updated successfully, but these errors were encountered:
This would be a huge nice to have by now because:
printh
of the PICO-8 memory somewhere in update functions. This would allow detecting subtle bugs and differences in the implementation especially if performed automatically.This raises a few issues:
The text was updated successfully, but these errors were encountered: