Hey All! I've been trucking on some Picotron stuff a bit lately, and I've added a lot of it to the current build of Picotron Playground which you can play around with in your browser here:

https://www.lexaloffle.com/picotron.php?page=playground

A quick recap for some context: Picotron is a fantasy workstation that aims to be extremely hackable and flexible. It is not quite in production yet, but an experimental web version is available ~ that's what "Picotron Playground" is. The desktop version of Picotron, with built-in dev tools + HTML exporter are planned for later this year.

For more background, see also: Part I: The release thread

Code Editor

The code editor is now implemented as a GUI component that anyone can embed in their own programs. This will make it easier to create things like bespoke programming toys and scriptable level editing tools. Have a look at /demos/proggy.p64 to see how this works (although, that api might change a little later). It is still janky, but now janky in a more powerful way!

cd /demos
load proggy.p64
--> CTRL-R

Click a button to load each snippet, and type for live changes. For example try copying and pasting the 'paint' snippet into the bottom of 'decay' or 'sand'.

Side note: proggy.p64 has multiple tabs open when you load it-- each of these is a running a separate process (edit /system/tools/code.lua). This way, tools can focus on having a single file open, and let the WM handle having multiple files open in a unified way.

Palette

The palette has changed a little since v7, and I think possibly this will be the finished Picotron system palette. 16 is a smidgen duller, 23~26 are slightly brighter, and 30 is now a much brighter magenta. I don't know if anyone has gone very deep into the palette yet, but here's the new version for reference:

It is possible to set RGB values for the palette in Picotron, but windowed applications will need to lean heavily on the default 32 colour palette, and I think it will often be used as a starting point for building other palettes.

Graphics API

The graphics pipeline design document now including a step-by-step summary of how a pixel is drawn (near the end): https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html

Indexed Display Palette

v.8 now includes an indexed display palette (64 bytes starting from 0x5480) similar to PICO-8's one. It defaults to an identity palette (0, 1, 2..) and so has no effect. The display palette provides an easier way to do palette swaps & cycles etc at the end of each frame without having to mess around with the RGB display palette.

Separate Target Mask for Shapes

Shape drawing functions (circfill etc) now get their own separate target_mask at 0x550b that defaults to 0. The target mask is applied to whatever value is already in pixel to be drawn over, so 0 means "don't care about what is already there". There are two reasons for this:

The first is that the default behaviour when drawing colour 0 is now for it to be drawn solid, while sprites can at the same time be drawn with transparency for colour 0. This is much more intuitive and also matches PICO-8's behaviour.

The second reason is that drawing horizontal spans can be optimized when not caring about what colour values are being drawn over: when target_mask is 0, each output value is only a function of the draw colour(s) and fill pattern. I've reduced the (fantasy) cpu cost in this case by 50% and can likely reduce it further later after optimising that code path.

Default Colour Table Stencil Bit Values

The behaviour of pal() and palt() have been changed to make it easier to set (and ignore) stencil bits:

https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html#Colour_Tables

(near the end of that section)

Setting palette entries

Instead of poking, you can use pal(1, 0xrrggbb, 2) to set rgb palette entries.

pal(1,0xff0000,2) -- too red
circfill(200,100,50,1)

It can also take a table of entries like PICO-8:

pal({0xff0000,0x00ff00,0x0000ff},2)
for i=1,3 do circfill(200 + i*50,100,20,i) end

PODs

PODs (Picotron Object Data) are strings that store the contents of Lua values, sort of like JSON. They're used for many things internally, but none of them are very relevant to Picotron Playground (yet?). v.8 includes some improvements to the POD format, and the result is that it will eventually possible to store images, maps and other data very quickly, with reasonable compression built in -- straight from the Lua object to disk and back again. If you're curious, you can find some details here:

https://www.lexaloffle.com/dl/docs/picotron_pod.html

Trivia: since the start of Lexaloffle I've been working with .pod files, generated by my in-house editing multitool called Poido (from "Pointy Dough" because it includes a low-poly modeller, but I use it mostly for bitmap editing and palette design). I thought that with Picotron I'd finally be free of pod files, but it turned out to be the most fitting name once again!

One thing you can try: paste this POD into the code editor and hit enter a couple of times to get an embedded image (that as legal lua source code returns the scrawled star sprite that is being shown in the editor).

--[[pod_type="image"]]unpod("b64:bHo0AO4AAAD8AAAAcXB4dQBAAAAEANABAAAAAwTw0B8d8C0uAwCwLD7wK17wKW7wKH4DAPEBJ57wJa7wJL7wI87wI97wIgMA_UEh7vAg-gHwCn6w-gLwCr5w-gPwCf4AMP4VcP4ogP4lsP4kwP4i4P4g8AH_HvAC-h3wBP4b8Ab_GPAJ-hbwCv4V8Az_FPAN-hPwDv4S8A-_EQQAABQAAAQA8CMN-gIwzvAN-gBgvvAN7oCu8AzuoJ7wC97QjvALvvACbvALjvAGXvAKfvAIXvAJfvAKXgkA8BEMXvAIPvAPTvAHPvARPvAHLvATLvAHHvAVDvAvDvD-gw==")

It is a userdata object compressed (first with RLE encoding and then with lz4) and then re-encoded back into a text-friendly form as base-64. Whenever you copy an object in Picotron (like a sprite or section of map), it will be encoded like this for easy sharing between programs and other users.

You might also notice some .info.pod files lying around -- these are used to store per-folder metadata but will eventually be hidden. Per-file metadata is stored within the pod format itself.

Other Stuff

• Proper CPU model -- infinite loops won't bring the system down, and each frame, the available CPU is shared around each process.

• 64-bit pokes: you can use poke8 / peek8 and the new peek operator *

• aliasing can be implemented by mounting files -- "ls" is now aliased as "dir"

• see /demos/stencil.p64 for an example of using stencil bits

• try out rnd_blend and/or stretch at the start of /demos/chonky.p64

Thank you! Er... is there anywhere a "help" command, just like in Pico-8 ?

Where can I access v0.7 for comparison?

It seems like this version has more issues with high refresh screens:
1) deletes 2 chars in terminal
2) flickering and complete freezing in code editor
3) not clearing mouse cursor
4) cursor blinking/moving still faster (even faster in editor)

Could have to do with alt+tabbing/chaining focus out or into the editor.
Tested with Firefox.

I got the flickering issue too (but on a 60Hz screen), also on Firefox (Windows 10). And the right parens key issue on AZERTY keyboards (it triggers both escape and the right parenthesis) is still present.

Other than that, looks neat! I can't wait to see what people will brew with that!

The ability to pal() to any hex code is pretty amazing. Very excited for a full version :)

@Cesco I added a placeholder help, but it doesn't have an API function topics yet. I'll add to it as I go!

@Shoozza @Eiyeron

I don't have a copy of v7 online, but the CPU works so differently, I don't think a comparison would be useful (v7 was "cheating" by letting the window manager have magic uncounted cpu).

It really shouldn't be dependent on the host environment though; at the worst it should run slowly without flickering. Does it happen right from the start when there isn't much going on? You can use the following command from terminal to get a list of processes:

for p in all(_get_process_list()) do print(pod(p)) end

(or printh to copy text from the browser terminal)

I've also added a cpu counter in the code editor when the mouse is at the bottom right -- please let me know if it is ever going close to 1.0 when its flickering. Deleting 2 chars instead of 1 sounds like it is frame skipping (which causes a known bug in the key handling).

@Eiyeron Thanks for the keyboard report -- I couldn't figure it out right now but will have another stab at it for v10.

v9 changes:

- added: binary number notation ?0b10.1 --> 2.5
- added: fillp(v0,v1..v7) // to set 64-bit full pattern (big endian!)
- added: faster tline3d code path when masks == 0x3f and fillp(0) // see highway.p64 
- added: help command placeholder
- added: fps counter in code editor when mouse at bottom right (for debugging flicker)
- changed: long hlines (e.g. during circfill) now 4x as fast when target_mask == 0
- fixed: fetch"foo.png" only colour fitting to first 16 colours
- fixed: ctrl-r outside code editor does not build from most recent state of src

The binary numbers and fillp() calling style allow setting fill patterns in the source with bits appearing in the correct order:

function _draw()
    cls()
    fillp(
        0b11110000,
        0b11110100,
        0b11110010,
        0b11110000,
        0b00001111,
        0b00101111,
        0b01001111,
        0b00001111)

    circfill(240,135,80,0x0708)
end

@zep, I'll check that once I get it to happen again, thanks! I'll be on the lookout for the key fix, it'll be a game changer!

EDIT: the flickering happened after a while. My computer was busy with something else in the same time, so I guess it might have not helped?

EDIT 2: Looks like Alt-GR+keys don't work either. I cannot type []{} and more due to lacking the ability to on FR-AZERTY

Oh, hey, neat, v.8! (and, uh, now v.9.)

(Sorry, long post again. I'm really bad at writing short posts.)

First off, I noticed that the pinboard (y' know, the 'screen behind the screen' thing? Apparently, it was called the pinboard in the code.) is missing in this version. You can't drag the top of the screen down and clicking the Picotron logo just tells you the current version number. Now, to be clear, I'm not specifically asking for this to come back. I mean, I'm not saying it shouldn't either, but that's not the point. The point is...

Uh, no, neither is the point that the right-click and middle-click bits were swapped and how that ruined the controls on my Minesweeper program, though I'm glad they were swapped to make it make more sense and be closer to how PICO-8 did things, so I'll just have to update my program which I was goingtodoeventuallyregardlessbutanywaysthistangentisgettingreallylongsolet'sjustgetstraighttothepointshallwe?

...Actually, wait, one more thing, first off, I'm a bloody liar and you shouldn't trust me when I say 'Just one more thing...' and second... I'm not sure I prefer the predominantly white/gray color scheme compared to the mainly pink one, but then again...

(I had to screenshot the post because the BBS HATES it when you give it URLs that contain an at-sign and just gives you stuff that doesn't make sense. Do you know how often me and the BBS formatting code butt heads?)

Okay, let's just get to the damn point already. THIS is the point:

v.7 and prior had no desktop background. It LOOKED like they did, but you were actually seeing the pinboard, and in fact you could tell because it didn't move when you dragged the top bar down. But now with no pinboard, there's no background at all, so you just see the previous frame buffer. Not. Good. I think now's probably a good time to implement the background shown in the Mastodon screenshot above. Or just a cls(). That would work too.

Oh, and, uh... look, it wasn't intentional that I took the screenshot at 4:20 okay!? It was an accident, I swear!

@zep, do you have an executable of the playground?