So, this was an interesting challenge, and with the help of @gamax92, we figured out a way to do it.
Pico-8 0.1.7 only has one release, and it was for the PocketChip.
The function menuitem() was added in 0.1.7, and a memory glitch was fixed in 0.1.8.
We use these two points of information to identify that:
- The current version has menu item (thus is 0.1.7+)
- The current version has the memory glitch (thus is 0.1.8-)
With that, we can lock down the version to 0.1.7
As @gamax92 mentions in discord, this will only identify 0.1.7. You can run different versions of pico8 on the pocketchip, but it's not bundled with a different version.
@zep - would totally love a VERSION global of some sort please!
As PocketCHIP is integral to sales of PICO, I would suggest as you do, that Zep make some easy system variables in the next update.
Windows, Macintosh, Raspberry PI, PocketCHIP.
To retrieve the version number or status of the current PICO system running. As of now, "1.9"
I don't see why you'd need _console or _version. PICO-8 is supposed to just be PICO-8 and offer the same exact features despite running on Windows or OS X or Linux or rpi or C.H.I.P.
The only reason I could see _console is because of GPIO space being different between the various devices. But accessing the GPIO area is something that requires Administrator or root access so, it's probably not the highest of concerns.
Version could be used when certain items do not run well, Gamax. Remember the problems with the 60FPS posts earlier ?
Many changes were made in version 1.9 that were not available in 1.8.
As MorningToast wanted to know, how can PICO know it is running in PocketCHIP ?
I do remember that 0.1.8 had 30fps exports, but ... does adding _version help you with that at all? Nope. The BBS gets automatically updated to the latest versions and if you want to be able to open newer carts that use newer features you'll have to download the latest version of PICO-8. It's not even that the cart will function partially, but more that PICO-8 outright refuses to run it because the version number in the cart itself is newer than what your version accepts.
So, is _version for the times when the internal cart version number isn't incremented and you have a user who hasn't updated their PICO-8 yet?
It makes sense for PocketCHIP since they're not updated yet, but it's not like it's intentional, zep's stated that NTC's working on some other stuff atm iirc. Eventually they should be both brought back up to the same version.
It might help some people if code is ever listed in a format outside of .p8 or .p8.png, like text for instance.
I know the PET computer had to do this a few times for some complex commands when they posted their code in a magazine. In their case, they PEEKED a binary number to determine the hardware specs on how to handle the display.
At least you think _console is useful. :)
I'm not sure what _console would be good for. If you want GPIO detection, it would be far better to have a gpio_enabled() API function to let you know that GPIO is available on this platform, and the user has run pico8 as root so the cart can read and write. I can't think of anything else you'd use it for (game difficulty?) that wouldn't be better done in game UI.
Fweez, as long as there is SOME way to detect the console type. That is the focus. It doesn't have to be specifically named "_console."
If your gpio_enabled API is a better route to go than a function that tells you outright, I say take it.
I suspect that adding a way to detect host platform / version number would do more harm than good. It means that cartridge authors become responsible for whatever problems that would solve, when they should really be solved by PICO-8 itself. The 60fps inconsistencies will be resolved before too long, GPIO address are already mapped to a standard 0x5f80..0x5f87 for both raspi and CHIP, and I think labelling buttons X and O is less confusing than some carts adaptively changing button name strings.
I realise the inconsistencies between 0.1.7 (CHIP) and 0.1.8 call for a short-term work-around, and @josefnpat & @gamax92's detection method should be good for that. But in general, I'm planning on the version syncing across platforms being much tighter. Are there other reasons for doing it?
Zep ... I hate to admit it but you are making a great deal of sense here.
I can see someone checking the version or console type and then taking advantage of a 'backdoor' method that only works on one type of version or console.
When in fact, you, as the author, would want to have 100% compatibility through ALL platforms, releases, and hardware; not one being better than the other.
I mean it is just 128x128 display when you get down to it, how hard can it be to maintain compatibility with a few teething problems that are always being addressed ?
@zep I'm just worried mostly about backwards and forwards compatibility.
Forward compatibility - I'm not sure how often the PocketCHIP debian jessie users will update - with so many new functions, and functions having the way they work change, I imagine that many carts in the future will not easily work on older versions of pico8.
Backward compatiblity - Already there are threads on the CHIP forums saying that quite a few of the older pico-8 carts do not work. While I don't mind updating my own stuff, I imagine that with a normal churn rate of a community, not everyone is going to update their own stuff.
At the end of the day, it's always fair to say, "it's not 1.0, eat dirt". At the end, it's a question of how many historical carts do we want to keep in the catalogue.
Personally, as for the GPIO, I think those should be accessible via an API, rather than being exclusive to PocketCHIP and RPi, and have an additional program/whatever included with the PocketCHIP and RPi version that integrate into the API. One example this could be used for is using PICO-8 as an interface for a simple music player script I have running elsewhere. When I open the music player, it would open PICO-8 with a special cart that uses the GPIO ports. When the cart loads, the script uses the API to send PICO-8 a list of the available songs, which PICO-8 presents to the user. After the user selects a song in PICO-8, it sends the selected song back through the GPIO, making the script start playing the song, and PICO-8 shows music controls.
[Please log in to post a comment]