It seems to me that some of the latest versions you have of Pico-8 are in fact breaking existing previously working Pico-8 carts.

May I suggest that the cart be read, especially the 2nd line down:

pico-8 cartridge // http://www.pico-8.com
version 37

Which denotes the version and online and in Splore at least, run THAT particular version of Pico-8 so all previously existing carts will run correctly ?

Then we can sift through the newest versions of Pico-8, carefully, and deal with whatever problems they are causing - without affecting previously running perfect code.

Also to add a new command to Pico-8, ver which will state the version # you are currently running. The latest if you are running the EXE, or a different version entirely if you load it from # or splore or it is online.

Also to bring back info() so it can be used in code. Currently it is ignored yet in previous versions it works properly. I used that in my Mildew Manor game to show system specs at the start.

I guess if you're okay with the PICO-8 package massively jumping in size, and then continuing to increase in size with every single release, just to support all previous existing PICO-8 runtimes in the off chance you run an old cart in Splore. (Or not jumping in size, but saddling zep with the gianoromous headache of coding and supporting complex and niggling backward compatibility in the existing runtime based on the version number being run.)

Nono, @MBoffin. Only during runtime would that version be enabled. Once you exit out it would run whatever version you started pico8.exe with and crash if need be.

So I think the best way to handle it is to let the Online games use the correct version they were written in yet Splore and load # might not be so simple.

I'm just thinking of ways to get around the difficulties in this new release that is crashing pre-existing and running carts.

And practice your sarcasm, man. That was neither biting nor laced with enough irony. Let the dark side of the force ... flow from you. :)

I hadn't heard of this. I agree that if it's not likely to break anything, then that would be a good idea. Perhaps the version can be looked for on upload (I think someone mentioned not too long ago that not all of them have it) and then if found then the player in the canvas can be matched with that version.

That said, it is important to note that a version of Pico-8 that can run past versions would likely need a bigger executable. I doubt that each version of Pico-8 that is supported would be a big difference individually, but 37 versions might add up to a significant difference. Furthermore, the complexity required would depend on how the program is structured. If Pico-8 was just invoking the game engine as part of the call to load , then I would expect a simple pointer-to-function or whatever the modern c++ equivalent would be (I use c or c-like c++) to be enough. However, I doubt that's the case given that Pico-8 can stop and start on the fly. In either case, I suspect that having this functionality in Splore is a much bigger request than having this functionality online.

It might help in the mean time to get a list of ones that are breaking and check for similarities. If this is something that's occurring a lot, it might be due to a common source of code, such as a tutorial, doing something that wasn't supposed to be done.

When you say, "that version would be enabled", what do you mean exactly by "would be enabled"? That version of the runtime would have be packaged into the current PICO-8 runtime already in order to run. Or zep would have to do a lot of complicated version-dependent coding to have it run with the logic used from that earlier version of PICO-8.

I'm not being sarcastic or ill-willed, so no need for condescension. I'm bringing up real issues about how this would work and its real-world implications and costs, which are either continually bloating size of the runtime to include old versions or the enormous and mentally-exhausting task of coding in backward compatibility support with each new version.

With regard to the web players on the site and which version they run, I guess it could work to have a different version of the web player kept around for every version ever and the site picks and chooses which version to use for every cart page that loads. I imagine it would be quite a big uptick in the complexity of the site's backend code, which makes it that much more work to maintain.

I imagine there's a decision that has to be made at some point on whether to maintain and support old versions forever, or just draw a line in the sand and say, "Welp, some old stuff is gonna break from this change, but it's a cost I'm willing to bear." Being a one-man-show, I imagine that point is much nearer than, say, a large company with dozens (hundreds?) of developers and a bottom line, and shareholders, and legacy, paying customers, and so on.

Nono @MBoffin.

Looking at it a bit more closely I can see this would likely only work Online, where a plethora of Pico-8 versions could be stored.

So let's say Freedough makes a game called, "Alien Antics." Well it doesn't run in the current version of Pico-8 so there is a play triangle appearing in the top-right-hand corner, smaller than the main center one.

You click that and it attempts to run that cart using the version it was written in. Yes, it's a lot of work, few things in this world are productive except with hard work.

But yes it would also solve a lot of the version problems we're experiencing and have experienced in the past.

If this is not easily possible, then, like most things in Pico-8, it's just an idea. A suggestion. An attempt to untangle a problem we've had for some times now.

No need for sarcasm as in your initial reply. Let's all try to get along here.

Hi @kimiyoribaka.

I think for it to function properly it may only be available if you run a cart online. MAYBE for Splore as the version could also be read online but that might be a lot more work.

@dw817
Sorry about posting something so similar to mboffin. I usually check the thread for new posts before clicking submit, but I forgot.

Regarding the fixing of the actual issue, do you know what versions are typically having a problem, or what version might be the cutoff? I played through my own games "basement", made in version 29, and "journey through deathsbog", made in version 35. Both of those ones work fine, but I don't think either use any particularly unusual tricks. I ask because if the versions where compatibility breaks occurred can be pinpointed then any solutions, be it just posting possible fixes to posting tips to your versioning suggestion, would likely be easier. Should versioning be done, having only a few compatibility versions covering a range would be far less work.

Hi @kimiyoribaka:

My solution would be for PLAYERS, not coders. Nothing surely must be so frustrating as a player who wants to play a particular cart, has so in the past, and then finds it won't run now with the newest version of Pico-8.

The solution is only for the players while @zep makes the necessary changes to the newest version so it will run it properly again.

Thus the suggestion of 2 buttons. One to play normally and the top-right that would play it using the very version it was written in.

Then that at least counts out the players who are having a difficult time with the newest version of Pico-8 - leaving us, the coders, to fight and fend with it.

The solution is only for the players while zep makes the necessary changes to the newest version so it will run it properly again.

I think, as with any beta software, that we can't and shouldn't rely on this. There will at some point be changes that break old carts unless the carts are updated. Players might lose games to varying degrees, ranging from temporarily while the dev updates the code to permanently because neither the dev nor the players want to bother trying. That's just the nature of beta software. Quite frankly, zep's done a pretty amazing job developing PICO-8 in a way that keeps the majority of carts running for years unchanged across many beta releases. Things breaking is no fun for anyone, but I think it's more encumbent on us game devs to keep up than it is on zep to build backwards compatibility into beta software. We're all working toward 1.0 along with him, so we have to be willing to ride that wave until it crashes ashore - sometimes that means falling off your board or having a shark bite your toe off along the way :).

Hi @2bitchuck.

As stated, it is just a suggestion. If it can be done, great, if not, then it might very well be up to us, the coders, to provide working games.

And if Pico-8 breaks, that becomes our responsibility to fix our code to match where it is breaking.

I think bundling legacy runtimes is not a bad approach in principle in some very specific cases, but would be a horrible source of complexity for PICO-8. What happens when you load a 0.2.1 cartridge in 0.2.5? Do you continue editing it in "0.2.1 mode"? Do all of the exporters need to handle exporting to all previous versions? Bugs caused by version + platform combinations would be extra nasty. Do you risk fixing annoying or unsecure behaviour in previous version runtimes? etc. etc.

HTML exports already bundle the matching runtime and cover a good number of carts in question. Breaking changes have rarely affected > 1% of BBS carts, and then normally only temporarily. That will be quite close to 0% at 1.0, at which point the runtime will be completely frozen and it won't be so much of an issue.

Hi @zep.

I was just thinking of the broken carts. Giving players two buttons to select from, current Pico-8 or the Pico-8 version that it was written in.

I suspected exporting to JS/HTML/EXE would be correct as you bundle that particular version with that cart. I didn't know if that was the case in posting directly to Lexaloffle.

Thanks for addressing this issue.