"Are you there @zep? It's me again, Margaret Felice."
I was thinking about how the option to show additional screens could open up the ability to write on-target dev tools to complement the existing IDE, and yet we're not really seeing any of that (yet).
I don't think it's a big deal that these additional screens are officially unsupported and you have to alter the pico8.exe command line to use them at all, because only a dev needs dev tools, and devs know how to alter command lines. I don't think that's why.
I think the problem with dev tools and debug libraries comes in the form of the token limit.
Any and all dev tools are going to take up tokens, and once you go past 8192 tokens, your app can't even launch. So someone with a nearly-finished app that's utilizing most or all of the allowed tokens is going to be absolutely unable to use any form of dev tool, debugging library, or even just print() debugging.
So...
Would it be possible to add a command-line option to increase the limit from 8K to, let's say, 32K tokens?
e.g. pico8.exe -dev_mode
That's similar to the 1:4 retail-vs-devkit RAM ratio on a PS2 devkit, for instance: 32MB vs 128MB. We had that extra RAM to hold debug libs, extra sanity-checking code, trace logs, etc., and it was absolutely invaluable.
And, most notably, this would only work when run from a proper pico8.exe with a command-line option set, meaning it is NOT supported under normal conditions and will NOT work in an exported/.png app, maintaining PICO-8's cozy limitations under normal circumstances.
Oh, and note that you should also increase the Lua heap to 8MB in this mode, btw. Or more. More code means more data.
Afterthought: This also might encourage people to write stuff that will, in turn, give you ideas to improve PICO-8, Voxatron, or whatever comes after. In fact, the reason why I'm posting about this is that someone on the Discord mentioned that some of the Respriter ideas may have worked their way back into PICO-8. Synergy is food for the dev's soul!
Yeah this would have been MASSIVELY helpful during MYRRH'S EDGE, where we had an #include for our debug tools, but had to stop dev of the full cart because needed them up to the wire.
It's been pointed out that this might encourage a side-environment where people trade .p8-format games instead of using the BBS or itch.io.
Personally, I think this is a non-issue because you're really limiting your audience if you release apps this way, like homebrew games on hacked consoles.
But it's also an option that, say, a 10%-transparent moving watermark (e.g. the PICO-8 logo+emblem) could be moving around screen 0 to make it annoying to run your game in this mode.
Another thought is that you have to have as many screens as your token/ram multiplier:
- 2 screens = 2x tokens, 2x ram
- 3 screens = 3x tokens, 3x ram
- 4 screens = 4x tokens, 4x ram
So you either deal with having a window with a lot of dead space or you have to actually render all of those screens, eating up CPU. For a tool, that's fine, because those extra screens are probably lightweight. But a game suddenly having to render 4x the pixels is going to suffer.
Personally, I always feel anxiety when anything new is brought to or suggested for pico-8 because it is precisely that it doesn't change that gives me the most joy about it. I can see why folks might want this, but power users can always develop additional tools outside of PICO-8 with something else. I'm just hoping we see 1.0 some day and thenceforth it never changes. The extra screens thing already feels like something weird and not console like to me. But that's my inner old fart talking. Just thought I'd throw in my two cents as I'm a rabid fanboy of this console.
Note: I acknowledge concern for preserving the cozy design space was already expressed, but, as a dev, I guess I want to be constrained like I'm really actually in a real console, not some weird patchwork quilt thing haha (or to even know that option is there). If anything maybe fork into a totally new tool that's some kind of in between of pico-8 and voxatron. I just want pico-8 to be itself.
Being able to include extra code at development time would make a big difference to me.
I have a couple of tools like this variable inspector I find hugely useful, but always have to rip out again once the program reaches a certain size.
(This is not something that could be implemented as an external tool either.)
Yeah, what you show there is exactly the kind of tool I have in mind when I propose this.
You know, I suddenly remembered that the very idea of enabling temporary token limit to be exceeded just for dev has actually occurred to me in the past, so it is possible this really is just old man yells at cloud on my part.
On the other hand, it does kind of separate PICO-8 as a development system/game engine from it being an experience of a console BOTH as developer and as player. It does tempt fate for it becoming more of an engine than a console. So I still am a bit uneasy about it.
BUT! It's being suggested as a command line option so I'm trying to remain open to it.
Selling a devkit version is another good idea! Makes a little extra money for @zep, and also makes it less likely that people will try to make games for the actual devkit mode, since far fewer people will pay extra for it.
For just the tokens, it seems like a #devinclude would suffice. Tokens loaded by #devinclude aren't counted—and aren't exported. One would have to take care to test the exported version of their cart to make sure it runs without the #devincluded code. But the same is true for temporary #includes.
Increasing Lua RAM with a dev option sounds like a dicier proposition to me. It seems like it'd be easy to write code that succeeds with expanded RAM and fails with stock RAM, and this could go unnoticed without pro-grade testing. I'd want to know more about real world use cases. Maybe if a #devinclude tool becomes popular but is demonstrably constrained by Lua memory, that feature could be considered later.
My fantasy dev tool feature is a formal way to add tool extensions to the IDE. Each tool extension has a tool tab, an update/draw loop that runs when the tab is active, tool-specific APIs, and access to the cart data and active runtime via an object. It's otherwise just like a cart, wired in via config.txt. (Something something extension dev experience...)
Maybe extension code would have no token limits, and maybe it would run with expanded Lua memory. I wonder if it would run without artificial Lua timing constraints too. I imagine a fun thing to do would be to call cart code, such as to step through the cart's game loop, draw overlays, etc. so either all Lua code remains time constrained or it does something especially fancy so that only cart code is constrained. I imagine it'd be difficult to prevent an extension from collaborating with a cart to break out of limits, and I'd be disappointed if there were published carts that required specific extensions to run. But the same moral hazard (such as it is) would exist for #devinclude: you'd have to go to lengths to set up a devkit to play such a cart.
I think we've seen that anything that can't be shared on the BBS doesn't really take off as an "abuse" vector. I like that the multicart feature exists so I can fantasize about making a big Zelda-like, but nobody really seems to use it for much in practice because multicart games can't be shared on BBS/Splore. So maybe dev-only features that relax limits won't tip any scales.
Just wanted to say, there's some great discourse here - some great ideas (and valid concerns) being mentioned.
The idea of augmenting the existing IDE with new "dev-made" editors sounds fascinating. I had to abandon a fairly complicated editor years ago (SCUMM-8), because I hit the Token limit & ultimately lost interest.
But part of the reason for this was because something ~20% of my code was recreating the PICO-8 UI components (Tabs, Buttons, Checkboxes, Text boxes, etc.). So, perhaps if such a (potential) dev-kit feature could also (maybe) have a subset Controls library/API. I imagine that could save ppl lots of time.
I always found it cool (+powerful) how other engines, like Godot, allow you to easily create custom plugins for the editor UI using the same tools of the editor (kinda Inception-like!).
I share the concerns of potential abuse, but agree with @dddaaannn's assessment that previous expansions have kinda naturally self-regulated themselves.
Either way, will watch this thread with interest.
P.S. - Shout-out to @Mot's awesome table tree-view inspector - that's a really neat idea!
(and while I agree, that couldn't be done with an external editor - perhaps with @dddaaannn's #devincludes it could?)
UPDATE #1 "In-Editor Manual/API Ref":
It just occurred to me that potentially powerful "bonus" of adding some kind of Editor customisation (e.g. custom tool tabs, as being proposed) is that someone could re-create the PICO-8 API Reference (or even the full Manual) as a separate tool tab - all accessible within the single PICO-8 IDE. It could even be interactive, with search capability and real-code/animated examples (think @2darray's DemoMan).
However, as cool as I'm initially thinking this could be - it would probably add weight to the argument for this to be available (somehow) to all - as it's more likely the beginners that would appreciate such information "on tap" (or just those of us longing to code "off-grid", in a log cabin in the woods!
(Dunno - maybe this idea is more of one for the wishlist for PICO-8 base product - I was just thinking out loud, and potentially allowing others to take on the maintenance of such a resource)
I prefer #devinclude to outright expanding the token limit. It doesn't "hide" as much, the idea is analogous to other features in PICO-8, and it makes the limits of what you can do much more explicit- you still have 8192 tokens to write your game in. I'm a little uneasy about anything that pushes the limit past what it is now, but I don't think I would be unhappy with adding #devinclude, or something like it.
I do, however, dislike simply expanding the token limit, even for just the development enviroment. It's a fairly large design change for the benifit of only a small portion of the userbase: those making large scope games, and large scope games are meant to be difficult to develop. If you're making a game on this scope, it makes sense to need external tools- devkits were often hooked to workstations.
In most situations, I agree with the idea of lifting limits like this in development, but I argue the pushback of making games close to the token limit contributes near as much as the hard limit itself; you're on the edge of the scope that you're meant to make conveniently, and so making things becomes less convenient.
(A bit of a tangent: I like the extension idea, but it doesn't fit into the PICO-8 design. It's more in line with some of the clones; it's an interesting feature, it would add to development, but it would be a balancing act to hold away from bloat.)
oh and thank you @Mot very cool.
> For just the tokens, it seems like a #devinclude would suffice. Tokens loaded by #devinclude aren't counted—and aren't exported.
+1 to this idea; I have definitely run into debug-related annoyances which would be alleviated by this!
I can understand the concern. "Hey, here's my cool new game. Make sure to run it in dev mode, because I went over the token limit."
Personally I can't think of a silver bullet that wouldn't be open to some sort of abuse. But there are some pretty smart cookies around here and zep has a knack for finding a good compromise.
Keeping developer tools separate from the main cart (like the #devinclude suggestion) definitely feels like it would help.
I'm not sure what the difference is between the two following statements:
> "Hey, here's my cool new game. Make sure to run it in dev mode, because I went over the token limit."
> "Hey, here's my cool new game. Make sure to put extra.lua in the same folder, because I went over the token limit."
I both like and dislike the #devinclude idea.
I do think that it is nice to have debug inclusion. The major problem that I can see is that it doesn't fit with the all in one environment that pico8 is so nicely trying to carve out. Launch the window do all your editing in there.
Having said that I don't use the pico8 code editor I don't find it confortable. The lines of text are too short I can't see a lot of code at the same time.
It is cool however watching videos of people who just do that.
I also worry about selling seperate devkits, and not because of the money but because pico 8 is literally an IDE. People who have purchased it have purchased a development platform. As far as I can see that the main reason its purchased. It already is a kit for doing development on it, seems wierd to sell a devkit on top of that.
As mentioned in discord the main thing I would like is a 2bit per pixel mode that gives a higher resolution and for the code editor to use that mode.
Well, you asked for feedback, so here's mine : I don't like it.
-
Partially for the reason already stated. My hope for pico8 is a fixed, cozy target. There's a million new capabilities that could be added, and you could make an equally passionate argument for each of them individually, but to me that defeats what I love about Pico8. It's the standardized, almost-unchanging limitations that make it something special, and distinct from just being yet-another-game-making-toolkit.
-
I would hate to see creating a separation of "dev mode" and "game playing mode". That's part of what's so neat about Pico8. They're the same mode. You don't need to boot into pro mode, or install the pro tools, or anything like that. There's no advanced grown-up mode that you can learn to activate when you're worthy of it. Nope. You turn it on, and you're playing with the same blank page as everybody else.
- Being able to switch into "extended token mode" would be a trap for new players. "[type type type] Out of tokens? What's that mean? [google,google] Oh, there's a switch? Ok whatever. [type type type]" Pico8 is so carefully crafted to avoid those kinds of gotchas, it be a shame to introduce one at this late date.
Obviously, nobody would force me to use any new features, but I still think it be a small step away from what makes Pico8 unique and what makes the Pico8 community unique.
I'm more worried about the dev experience than distribution loopholes. With an expanded memory dev mode, there's risk of getting your game to work in dev mode only to realize that it doesn't work in prod mode. With #devinclude, it's clear what it's for and how it works. You won't accidentally put prod code in a #devincluded file.
Notably, this kind of accidental overstep is already possible with the character count limit, and it's frustrating. It wasn't meant to be this way. The original fiction justified the character limit as having to physically fit within a fixed number of bytes. PICO-8 had to compromise this fiction to transition the effective limit to tokens, while still restricting code containing arbitrarily long strings. To that end, PICO-8 ignores the char limit for .p8 files, and only enforces it on export. This feels unfair when your cart appears to be working, but then you discover it's over the char limit when you export. I think PICO-8's stricter behavior around the token limit is meant to feel more fair in this way, like the original physical byte limit was meant to be.
As I mentioned, I'm less concerned about a culture of "dev mode only" carts cropping up, because the requirements for BBS participation do a pretty good job of discouraging distribution loopholes. There are plenty of ways to escape PICO-8 limits if you're willing to trade away the BBS: just built a Tic-80 game. ;)
(FWIW I agree that my "extension" design doesn't fit with the PICO-8 design ethos. It's too heavy and inaccessible to anyone not dedicating a lot of time. I just like the thought experiment of how inline IDE tools could be written like carts.)
> There's no advanced grown-up mode that you can learn to activate when you're worthy of it. Nope. You turn it on, and you're playing with the same blank page as everybody else.
Aren't external toolsets like picotool exactly that, though? You grow out of what PICO-8 can do internally so you learn to activate "external tool" mode.
The main difference being that external tools are ... well ... external, and don't have useful direct access to runtime state/data, and usually require you to install and learn third-party software like python.
I think a lot of people prefer external tools because they aren't internal- they feel like you've surpassed PICO-8's limitations, rather than the limitations being raised for you.
Even if you use someone else's tool, you've increased your capabilities independent of the things given to you outright.
It feels like you're fighting to beat the limits, not asking to beat them.
(and people like feeling accomplished)
> I always found it cool (+powerful) how other engines, like Godot, allow you to easily create custom plugins for the editor UI using the same tools of the editor (kinda Inception-like!).
This would also be my preferred way to enable dev tools in PICO-8 - having a way to add editor tabs with plug-ins, with the code running these tabs not counting against the cart limit. This would let an ecosystem of tools that feel native to PICO-8 spring up and let you easily share/mix-and-match tools between carts.
I'm a person whose carts pretty much always bump against the various limits (usually both token and compressed size limits), but I still don't think "just raise the ceiling for dev mode" is the best solution for tools specifically. I'd rather see a dedicated solution.
That said, I'm also not vehemently opposed, and I probably do way less tooling than others when working on PICO-8 stuff. I'm probably also in the minority in that I actually enjoy doing 99% of the work inside PICO-8, including writing the code with the internal editor.
Are many people using external tool chains?
btw I'd be for #includedev if it was a seperate code window in the IDE
> > I always found it cool (+powerful) how other engines, like Godot, allow you to easily create custom plugins for the editor UI using the same tools of the editor (kinda Inception-like!).
>
> This would also be my preferred way to enable dev tools in PICO-8 - having a way to add editor tabs with plug-ins, with the code running these tabs not counting against the cart limit.
I agree, this would be ideal.
> but I still don't think "just raise the ceiling for dev mode" is the best solution for tools specifically.
I actually don't either.
But, realistically, (and sorry @zep but I have to say this) zep isn't likely to be bothered with a big system like that unless it was his idea in the first place. To be fair, humans have finite time and zep has a job and a family, so he has to dedicate his time to his own Big Fat Ideas.
My goal was to obtain something approximately like what I wanted to see without asking zep to do something I didn't think he would want to tackle.
Thank you for opening the discussion:
+1 for #dev-include that are not exported or contribute to the token count ( or have their own token count ).
These dev-includes can very well leverage the additional screens if you want.
One thing that would be useful for "dev-tools" is to be able to modify the sprites, maps, sfx and music OF THE cart. So that modification made while running the cart persists once you press ESC. This is very similar to poke(0x5f2e, 1) that allows to persists the palette at the end of the program. The bits 6 and 7 of memory slot 0x5f2e still seem to be available as a way to enable this feature.
This would allow to write and include tools to re-order sprites, maps, use meta-tiles, and even 3D editors WHILE working on our games, and to easily save the updates made with these tools.
/cc @zep
How about one of these two options:
-Power users who want these features can just use Voxatron slices and use that as a mega super awesome dev IDE for a single PICO-8 cartridge.
-Someone can just spruce up pico-love and bam, you now have your mega sprawling 8 bit engine that isn't really a fantasy console anymore.
...It occurred to me zep made a comment not too long ago about already working on a tool that's more of an engine than a fantasy console, perhaps he's already planning on releasing a second product with some of the above features for power users, with its own website, and it can optionally export a pico-8 cartridge (like voxatron slices? I haven't used it. really an in between product)
and finally I'm guessing the folks who want these features are < .1% of the users of pico-8 in all likelihood. I'd almost call myself a power user, only I am joyfully and happily staying within the confines of the console, because that is actually THE THING that pico-8 offers. If that breaks too much I might as well just use Love2D.
Yeah it sucks to not be able to still use debug code when you're nearing 8192 tokens but we're big boys/girls, we can read and reason about code or comment out unaffected features in order to debug that one last thing.
What if there were some better ways to link carts together in order to be able to use one cart as a modular system to debug/dev the other?
For example, a bare bones implementation would be:
Game cart exports a text file (printh is already there) every couple of frames.
Debug cart, running simultaneously, reads this and displays and or modifies it.
Basically, being able to open arbitrary files in pico8 closes the last item needed to turn this from a games console to a development computer.
Of course, this also opens up all the opportunities to do “scary stuff” like read or write the wrong files or self modify code.
Maybe the more advanced file read write stuff only works in a single folder inside the user directory.
Feature:
PicoDrive folder inside of the User, pico8 directory
Any file in this folder (and only in this folder) can be opened, edited and saved over by any cart.
Add open file command
Open files as binary (array of 4 byte numbers) or as text
Optional—open and edit different parts of carts (can already kinda do this with cstore) be kinda nice to edit the code text section as well, but I’m not sure how well that would work in practice.
Add dir command — returns a table of filenames
Add a check modified command
(This would really help me because I am using a cart for file conversion where I have to copy the contents of a obj file into the clipboard, paste it into a running cart, have the cart process and save the data to the desktop and then open and paste that data into another cart.)
I feel like this would stay true to the pico8 vision by being similar to editing sprites on a disk on the C64. Some people would still use “other dev computers” for work, but more and more tool chain tasks could be moved into the pico8 ecosystem and easily shared on the bbs.
We can’t read arbitraty files, but developers can run 'pico8 -i output_from_tool.p8l' so maybe that’s how the idea could work.
If dev include could load carts from the BBS, we could get a nice community of tools.
Folks could publish tools on the BBS for anyone to dev-include to work on their own project/game.
#dev-include #some-cart-posted-on-the-bbs |
What do you think ?
How about a special "debug" namespace?
debug = {} -- could be built-in, with some built-in debugging tools?
debug.myprintstuff = function(somestuff) ... end
debug.myprintstuff(myactualstuff) |
- nothing defined within debug gets counted as chars or tokens or cpu
- full debug code saved in p8 only, everything debug gets filtered out on export...
Pretty sure all of the alternative ideas so far seem to have the same issue that's being used as a complaint about the original proposal:
All of them can be abused to make a much bigger game than current system allows, in some cases without any limits at all.
Worse, some of them allow it to be done through the BBS ecosystem, effectively destroying the deterrent inherent in my proposal, which is that anyone running your oversized cart has to use a manually-modified local installation (or as suggested later, a license upgrade), which will dramatically narrow the potential audience and thus the incentive to make such a game.
By the way, as an example of what I was saying when I said all of the alternatives have the same issue as my suggestion, there was the idea of using a slice in Voxatron so there's no token limit.
How is using a Voxatron executable, which has to be purchased separately, different from using "devkit" PICO-8 executable that has to be purchased separately?
If anything, it's far more likely that your potential audience already has Voxatron, because the bundle is so cheap.
At least with a "devkit" PICO-8 the price could be high enough (let's say $40... 4x the tokens for 4x the price!) that only the supposedly-tiny group of "power users" people say need this mode might be interested enough to pay for.
(Except, of course, this sucks for anyone not in a good financial position... being a "power user" isn't synonymous with being an adult flush with cash. Whereas my method is available to anyone who paid for PICO-8 and can be arsed to edit their local install, which any "power user" can do regardless of the contents of their wallet...)
@dddaaannn said:
> Increasing Lua RAM with a dev option sounds like a dicier proposition to me. With an expanded memory dev mode, there's risk of getting your game to work in dev mode only to realize that it doesn't work in prod mode.
I agree there's a risk of that, but if we recall that almost everyone arguing against the idea says that this is only something "power users" would use, I think we can say that the target demographic probably has its act together enough to consider and recognize that caveat.
By the way, a late-breaking argument from me:
We already have a form of this in the way a .p8 file can contain considerably more code & data than a .p8.png file can.
Being able to run a .p8 with up to 64k of data compressed into a string hasn't caused any of the issues described so far, despite data being the main thing people need more space for.
That makes sense to me at least. You can already make .P8 files that are over the storage limit, you just have an indicator telling you that you're over it. I don't personally see why a similar approach couldn't be taken for tokens.
My favorite potential of this topic is the ability to make tools for other people to use, not just so people can make tools for themselves. As target demographics go, I'd want on-platform tooling capabilities to be friendly to novices. If expanded Lua RAM were available to my code when I'm trying to use someone's variable inspector, I could accidentally write code that only works in that mode. Better if the expanded capability were only available to the tool.
100% agree that there's rich potential for on-platform tools that can access the runtime, run simultaneously to loaded carts, etc. cstore()/reload() enables tool carts that can edit other carts, but they can't access or affect code or runtime state. It would be a fun (albeit expensive) project to empower such tools while keeping the cart under development in its prod-sized sandbox.
All I know is if pico-8 gets broken from what it IS some day, I'm going to lose interest and just make 2D retro games in something generic. And the ironic thing is I think zep already detects that some of his userbase wants something like this, cause I'm certain I saw him make a brief comment somewhere about creating a more generic engine that is fantasy console like.
I think it's partly OCD on my part. I like things to be pure, simple, small and unchanging. It's nearly impossible to find that in the software development world. pico-8 for all intents and purposes has become the bedrock of my mental sanity (in software). Haha
It's kind of an analogue to the overall fundamental modern problem: There's literally too much of everything. So now you can find markets by REDUCING the size and scope of things. Take Trader Joe's for example. Small set of products, small store, less choice. Hugely popular. Take social phenomena, as another example. You frequently hear the phrase "create a space." Zep has created a space. Things that reduce noise and create boundaries become very popular because of how overwhelming the rest of the world is. Anyone could make PICO-8 like features in any Lua based engine without much difficulty. If PICO-8 becomes yet another Lua based engine there won't be anything to really differentiate it from anything else, except its historical relationship to when it was smaller and simpler.
@dddaaannn said:
> If expanded Lua RAM were available to my code when I'm trying to use someone's variable inspector, I could accidentally write code that only works in that mode.
You could say the same about the library itself. Often the presence of debug tools and libs at runtime affect the app itself by having hooked into various areas and changed memory access patterns. It's just a hazard inherent in using debug tools & libs.
> Better if the expanded capability were only available to the tool.
Indeed, but I'm not sure the Lua runtime can support two separate GC heaps while still allowing one heap's code to access the data in the other heap. You'd pretty much need two full interpreters running in parallel that talked to each other through some kind of messaging/pipes. I think Lua has debug hooks, so maybe something through those.
Still, that's a ton more work than changing a variable that says how big the heap is and another one that says what the token limit is, and I'm trying to consider @zep's time/energy for this kind of change. If this were a communal project where we could all contribute changes, it'd be a different matter, where the people wanting stuff could also provide the energy to do it, but it's just zep.
@gradualgames said:
> All I know is if pico-8 gets broken from what it IS some day, I'm going to lose interest and just make 2D retro games in something generic.
Ideally, what I'm proposing won't change the PICO-8 platform. I personally don't want PICO-8 to change either. I actually dislike some of the recent changes that have changed the platform (and quite significantly, I might add).
I'm only looking to make doing what we can do as devs, while developing, different. I'm not looking to make our actual games, at runtime in front of a player, different. I want to avoid that.
I expect that "retail" builds (e.g. the ones on the BBS, the ones on itch.io, etc.) should be the only ones an average gamer would be able to see or want to play. These "retail" builds should not be able to access the expanded resources that are intended as dev/debug aids.
@Felice To me, the offering of PICO-8 was for a feel and experience for developers AS WELL as for players. To me what makes it a fantasy console is precisely that regardless of whether you are a developer or player, you are entering the cozy world of PICO-8 when you turn it on. You can hit ESC and see the code regardless of whether you are a developer or player. Nothing stops you of course from creating external tools that help produce PICO-8 cartridges or assets or compression, but PICO-8 itself shouldn't help you---that's its core feature as I see it.
To attempt to play devil's advocate against myself lest I'm seeming too contrarian, PICO-8 does already allow breakage of limitations through multicarts. Actually, given that observation, why couldn't one desiring more powerful dev tools (written in PICO-8) just leverage multicarts with the multiple screens option? Boom, done, zep doesn't need to do anything.
@gradualgames
Because you can't run multiple carts in parallel with the multiple screen option. Also, they need to be able to talk to each other to be dev tools, so they can't really run in parallel unless you have a connection and a protocol.
Objects in Lua memory stay resident though so you could switch back and forth between your running game and your tool by loading one cart and then the other and back. Not ideal perhaps, but probably still a step up from totally separate tool creation vs. game creation.
@gradualgames
That's only useful for one subset of tools. I'm including things like runtime profiling and variable examination tools, along with things like sanity-checking or logging code. There's a whole spectrum of stuff you can do, both outside and inside the game, that aids development during runtime while not actually being part of the game.
Maybe an ability to run multiple instances of pico-8 that could communicate across GPIO or SERIAL? Maybe someone already suggested this above. I thought someone even demoed this recently but maybe it was with something they wired up with the web player manually. That would feel less like breaking PICO-8 and more just like daisy chaining multiple consoles.
Inter-process communication can be done with standard streams or the -i/-o parameters + a wrapper program to orchestrate. Example here: https://www.lexaloffle.com/bbs/?tid=38732
@merwok
True, but even that requires dedicating some tokens to the streams. Probably quite a few since you'll need some kind of protocol to encode/decode and act on the info in the streams.
Looks like zep as always a good steward of this world he has created is going to provide a win-win solution:
Machine 3 tweet
(っ◔◡◔)っ ♥ PicotronFTW ♥
(Nah, just joking)
While I am *very* excited for the FC#3 - I'm sure I will always keep coming back to PICO-8, it's just too damn "cozy". 😊
Which is why I can absolutely see, and share, where ppl may have concerns of risking damaging that with any future improvements - but I have faith in Zep's judgement (and the community as a sanity-check), that they won't happen. 🤞
[Please log in to post a comment]
