Hi all,

I'm just getting into Picotron, but have dabbled with PICO-8 for a long time.

Given the way /ram/carts main.lua works, what is your initial directory structure like and how are you doing source control (git, github, gitlab, codeberg, etc)?

Are you mostly using the Picotron or have you switched to a parent OS IDE like VSC or NeoVim?

THX1138 in advance, Pond.

(PS - here is a screenshot from what I'm working on, PacHac, a Pac-Man roguelike.

Following, because I still haven't figured out a good workflow.

But since the best way to get an answer on the internet is to post a wrong answer, here's what I'm doing, which does the job but rather poorly:

I'm editing in vscode, and using git. I have my dev directory as a mount in my picotron config file. Then, I type the following in the Picotron editor:

cd("/dev")
include("main.lua")

Then I save it as /ram/cart/main.lua and run with ctrl-R. I have to re-type this every time I re-open Picotron. I tried saving this as a cartridge and running it by double-clicking it in the file manager, and it runs once, but it doesn't seem to load it into RAM - ctrl-R runs the default blank cartridge, and double-clicking the cartridge again opens a 2nd instance of my game.

I have my sprites saved as 0.gfx inside this directory, I'm loading them with this method, and I can edit them by opening my file in the sprite editor. But since this isn't loaded as the actual 0.gfx in RAM, I can't use it with the map.

It's not a great workflow, but I haven't figured out anything better yet - I feel like I must be missing something obvious here.

I've not had a need for source control yet. I like the idea of working fully within Picotron at the moment. So if I'm making massive changes that I may want to revert, I just create a new file and copy what I have in there. But thankfully it being super quick to test whatever I'm working on I usually know if I'm going iin the right direction pretty quickly before I mess things up big time.

@Keytarminator
You need to use load from the terminal to load a cartridge into RAM. It'd be nice if there was a "Load to RAM" option in the file browser but currently there isn't.

I also use an external editor. Mainly because decades of muscle memory makes it extremely slow-going to edit in anything else.

In my native OS:

• Desktop
  • Pico
  • project_template
    • lib
    • src - util.lua, driver.lua
    • imports.lua

The Pico directory on my desktop contains all my Picotron/Pico-8 projects. Each project has its own directory with two sub-directories lib and src and one file imports.lua which contains all my include statements. The src directory contains a util.lua file which is initially empty. I have a giant util.lua file elsewhere which has tons of functions that I use all the time. But I never use them all so as I need them I'll copy individual functions from that giant file to the project's util.lua file so each project only has what it needs. src/util.lua is usually the first thing included in imports.lua. driver.lua is where I have _init, _draw and _update. It's usually the last thing in imports.lua.

When I start a new project I just copy/paste and rename the project_template directory.

Finally, I add a link to Pico in Picotron/drive.

In Picotron

From the Pictron terminal I can cd Pico/some_project.

If it's a new project

In the code editor I add:

cd'Pico/some_project'
include'imports.lua'

And then back in the terminal:

save dev_some_project.p64

If it's an existing project

load dev_some_project.p64

Then I can work in my external editor and hit CTRL-r to run the code.

When the project/version is done

Copy lib, src and imports.lua to /ram/cart. I actually do this from my native OS not from within Picotron. Picotron is a bit picky about filename extensions and will not copy the whole directory if it sees something it doesn't like. My editor creates automatic backups which cause copying to fail in Picotron. So I do it from my OS and also get rid of the automatic backups while I'm there.

In the code editor, remove the cd'Pico/some_project line and in the terminal save some_project.p64[.png].

That gives me a development version and release version.

I don't really bother with git versioning. Pico projects are more casual for me and dealing with git just adds a layer of annoyance I don't really need. If I put stuff on github it's usually just to make it more easily available rather than because I care about the revision history.

I store my Picotron folder (executable and my /drive folder) in Dropbox and then I point my config file to mount / from there. This gives me very basic file versioning, but the big plus is that every computer I use not only has the same version of Picotron, but also has the same working copy of my /drive folder. If I (or Picotron 😬) delete something, I can easily get it back.

I tend to work in Picotron itself as much as possible, not an external editor. (I do the same in PICO-8 too.) I just like it. My enjoyment of the experience of working inside the Picotron environment tends to win out over the need for the powerful streamlined workflow of, say, working in VS Code.

In terms of working on carts themselves, I have a /desktop/carts folder where I keep all my projects, and if they're big enough, they get their own folder inside that carts folder.

I did create a loadcart utility that allows me to load up carts from that folder no matter where I am in the filesystem. So I could be in, say, /system/util and type loadcart maze and it's the same as typing load /desktop/carts/maze.p64.

Has three folders one with .p64.png's, one with .p64's and one with .sfx files.
Doing everything in Picotron as still new to all this.

i make a folder /projects/name/ and save a cart at /projects/name/cart.p64 with the following in main.lua:

cd '/projects/name/'
include 'main.lua'

I edit my files in vim, then to run it i do in picotron:

load /projects/name/cart

and run with control-R.

i have a file /projects/name/build.lua that contains something like:

local source = 'cart.p64'
local target = 'output-name.p64.png'
cp (source, target)
cp ('main.lua', target .. '/main.lua')
-- ..copy more files here
store_metadata (target, {
  title = 'name',
  author = 'my name',
  version = '0.0'
})
print('build done')

which i run by cd'ing into the project folder and typing build. it copies the cart to a png, replaces the dummy main.lua with the real main.lua, then sets the cart metadata. it will automatically use the label from cart.p64 if there is one.

Interesting question! I enjoyed reading about your different approaches. I myself love working inside the engines, always have. I worked and coded inside of Pico8 and I do the same here. I find it enjoyable, even though I miss certain functions such as CTRL+D to double a line or CTRL+1/2 to move a certain line. But I do hope we'll get these features eventually.

I have a projects folder inside of picotron which I use to store all my projects as .p64.png's.
Inside of each project I always have a scripts/ folder that contains all of my include scripts. I use that a lot, similar to how one would use the tabs in Pico8. For userdata i always create a subfolder in appdata for whatever game or program I'm working on.

I do hope I'm not alone in working within Picotron, because what is the point in this engine if nobody uses it to develop their games? If I wanted to use other software or editors I would also use other, more powerful or straightforward languages. But I like doing everything in-engine, because I like the 80's computer feeling it provides.
And I also regard it as art, I interpret Picotron's existence as an art project by @zep. The limitations MAKE this enjoyable for me, I don't want to miss out on them.

@taxicomics I also mostly work in engine. Have moved out of it once to do some quick refactoring but for the most part I've done pretty much everything in editor.

I do definitely have some issues with it, that I'm hoping will be addressed in due course, but at the same time it might be addressed with the programs the community builds. The fact that anything that is currently missing from picotron is only as far away as your effort and ingenuity is awesome.

Finding the boundries of and within picotron as it currently stands is going to give us a better understanding of what's missing and what still needs to be implemented and the way @zep has set it up means we can find our own way around those boundaries/limitations.