Yo @zep,

By default, split(str) has a go at each split element to see if it's possibly a number, presumably using tonum(elem). You can disable this with split(str, false) or split(str, delim_or_width, false).

Unfortunately, unlike tonum(str, 1), you can't hint the format of the number, like I could by saying tonum("fe", 1) to get 254 aka 0xfe. I tried replacing the split() boolean arg with a number, but it didn't seem to get passed through.

I don't know if you're actually using tonum() inside split(), so maybe I'm assuming too much, but if you are, could you just pass any numeric conversion flag direct to it? That'd let us convert hex directly to numbers with something like split("baadf00d", 4, 1) returning {-17747,-483}.

Hey @zep,

Do I remember right? I think when I asked for state-changing funcs like color() or clip() to return the previous state, I'm pretty sure poke() (and its 2/4 friends) was one of them. Seems like it always returns 0 now.

(Also, if it's meant to return the previous state, remember to return a tuple of old values if you're given a tuple of new values.)

@zep

Okay, so the functionality is there, but you forgot to add it to the list you get if you type config by itself. Currently this is all you get:

> config
config [setting]

available settings:
volume
theme
gif_len
gif_reset_mode
gif_scale
screenshot_scale
splore_filter
tab_width

Might wanna check and make sure there aren't any other additions you've missed adding here.

Hey @zep,

I tried exporting and running an app, didn't do anything special except to load up a working cart and type "export blahblah.bin" and then run the resulting executable from the blahblah.bin/windows/ folder, and the window came up offscreen.

I used some tools and also some estimates to figure out where the app actually came up, and I'm pretty sure it's because I have a rather uncommon desktop arrangement.

Here's an image showing my desktop arrangement from Windows' display settings, with all of the extra info I found/deduced annotated and the position of the exported app when it launches. I hope this helps you figure out where you, e.g. copy/pasted some math and flipped or repeated a coordinate:

(sorry, it's hard to write with a mouse)

Also, just in case it matters, I launched the app from a windows explorer window on the center/primary monitor.

Let me know if I can offer up any more info to help you track this down.

The post formatter is putting the " @User" concept at too high a priority. It screws up Mastodon links, and also adds an extra space for no reason I can tell. Edit: Even on this line, the " @User" placeholder has an extra space in front of it that I didn't type.

Here's a link to one of your posts, just pasted as plaintext, to use as an example of how garbled it can get:

@zep/109507080931110623">https://mastodon.social/ @zep/109507080931110623

Here it is as an inline code blurb https://mastodon.social/ @zep/109507080931110623.

Here it is inside a code block:

https://mastodon.social/    @zep/109507080931110623

This is what I actually typed, as an image:

Just gonna repeat what I said on mastodon:

@zep
I just had what MIGHT be a good idea. Emphasis on "MIGHT".

Currently PICO-8 does not honor the concept of insert/overwrite mode like DOS used to. Indeed, many programs don't.

How about using the [Ins] key to toggle puny mode?

This post was brought to you by People Like You and Me Who Hate Doing Ctrl-key Sequences™.

Also it'd be nice if you followed this common PC editor convention so I won't need to fake it with AutoHotKey:

shift-del = cut
shift-Ins = paste
ctrl-ins   = copy

So much easier to use on the fly. I learned this and never went back to ctrl-x/c/v.

Hey @zep,

I think it'd be really nice to allow us to swap in the 32-color Picotron palette, which has the 16-color PICO-8 palette plus the revised upper 16 colors that you've been carefully tweaking for Picotron's system palette.

I'm gonna bet that the iteration you're doing with them to improve usefulness would be really nice for PICO-8 games, and would additionally homologize the two platforms with respect to color palettes.

Maybe just a single bit somewhere that swaps out the secret palette for Picotron's 16..31 colors?

Or, I suppose, you could subdivide one of the two ranges. You'd still want an enable bit though, since people rely on index bits 4,5,6 not mattering.

In fact, what the enable bit could do would be to switch to using the same indices 0..31 Picotron uses, instead of 0..15 and 128..143 on PICO-8, and then that's just the Picotron system palette. Basically a Picotron-palette mode.

That'd make using the extra colors a lot less cumbersome than using the current secret palette, though the original secret palette could still live above 128 at the same time too, in which case all the enable bit would do would be to put picotron_pal[16..31] into pico8_pal[16..31] and everything else would remain the same.

I dunno, just throwing out ideas here. What do you think? Does any of this sound reasonable?

Yo @zep,

It'd be nice if draw_tabs were one of the options in the config command.

Indeed, it would probably be a good idea to do a once-over on the whole config.txt and see what else would be good to add to the command.

I say this because someone noted on Discord that there's no way to make tab characters visible on the edu version. Probably among other things that people on the edu version would benefit from.

Personally, I love visible tab characters, so I want everyone to have the option to try them.

Edit: as requested below, for anyone unsure what I'm talking about, here's a sample image with draw_tabs set to 1 (and also tab_width set to 2). Note the wine-colored vertical line at the left edge of the tab characters, which also neatly masquerade as scope guides.

(Also edit: Woo, BBS thread #50000.)

It's not intuitive that these two blobs of code have different token costs, even though they do exactly the same thing:

local a = 1    --  3 tokens: a, =, 1

local b        --  1 token:  b
b = 1          -- +3 tokens  b, =, 1 -> total 4 tokens

I think the disconnect here is that the b in local b is being treated in the cost analysis as a variable reference, which it isn't, because the variable isn't referenced or assigned. It's just forward-declaring a conceptual attribute of the variable (its name), like the zero-cost local keyword does (its scope).

The reason why this bothers me is that I often find myself doing stupid stuff so I can do tuple assignments to save a token, which makes my code ugly. Gross stuff like re-using existing vars or function args, rather than declaring a new local, so I can put them all on the same tuple-assigning line without having to split out a new token-stealing "local" declaration that wouldn't work inline with the tuple assignment.

Here's a really-contrived example you'd never actually write, but hey, I need an example:

function if_period_at_start_move_to_end( s )
  assert(#s >= 2)

  local p                 -- this forward declaration is necessary
  p, s = s[1], sub(s, 2)  -- because we can't mix declare-assign with re-assign here

  if p == "." then
    -- put it where it should be
    s = s..p
  else
    -- phew it wasn't a period, put it back
    s = p..s
  end
  return s
end

Granted I could simply use two new vars when I take the potential period off of the front of the string, thereby allowing myself to merge the local declaration into the tuple assignment, but I guess that just feels like stack clutter to me. I know, nit-picky, but still... it's the little things.

Anyway, unless there's some reason why it would be bad to nix the cost of an empty declaration, would this be an acceptable tweak? I did try to think of some harm or abuse that could come of being able to forward-declare a bazillion locals for free, but the only problem I could see would be in the head of the author who did it.

And, like... at heart, the argument is just that local a = 1 and local a; a = 1 are functionally identical, which I'd hope would be enough in the first place. The rest of the above is just me trying even harder to make a case which I think is already made.

Yo @zep,

I realize returning nil out of bounds is less "friendly"-seeming, but after reading another post in here, I realized it's way more useful.

For one thing, it should make this work:

plain_text = "my thing that is mine"
label = ""
for c in all(plain_text) do
  if c == ' ' then
    label ..= '_'
  else
    label ..= c
  end
end
print( label )  -- "my_thing_that_is_mine"

(Right now it never stops because the iterator keeps seeing "" instead of the nil it needs to terminate.)

And for another, returning a nil is much more likely to alert a programmer that their code is probably malfunctioning than returning an empty string. Accessing out of bounds is usually erroneous and should therefore trigger errors.

I realize some apps are probably already abusing the fact that you get an empty string when referencing past the end of the string, but really that's a bad programming pattern to be teaching people anyway. It's lazy, you should know where the end of the string is and stop there instead of expecting the OS/API to be your nanny and stop you from walking off of a cliff.

Presumably this should apply to negative offsets as well, meaning negative offsets big enough to go back past the start of the string.

@zep

Every now and then I get directed to a BBS post with a cart that I genuinely to see, but which is making my headphones screech into my ears because it's so loud.

Thing is, I already have both my system volume and my app-specific browser volume set to sensible levels for all other content, so I can't reasonably dial down the volume pre-emptively.

Unfortunately, sometimes it's appropriate for a game to do something loud, albeit briefly, so I wouldn't expect you to limit it in the player either.

Really, I think the solution is to have a slider of some sort on the web player. Even if it's limited to 8 different levels, like PICO-8 is internally, that'd help.

Maybe if the user right-clicks (or presses and holds) on the speaker icon, it pops up a slider that can be adjusted?

I dunno if it should be persistent and/or global. For reference, Youtube seems to be both, i.e. the most recent change you made becomes the default for the next video, regardless of how many windows you have open with different settings.

Thanks!

@zep

Hey! Remember when I suggested putting next in the globals, since we could get to it anyway by doing next=pairs{}? You did! And that's been great!

Would it be okay to get inext the same way? It seems to be present, since I can get it by (similarly) doing inext=ipairs{}, and it seems to work the same way, just limited to index,value instead of key,value.

It's just not officially exposed.

I'm asking because there's a token saved when you switch from the first to the second implementation here:

for k,v in pairs(t) do ... end
for i,v in ipairs(t) do ... end

-- these are a little less clear to the reader but they work the same and save a token
for k,v in next,t do ... end
for i,v in inext,t do ... end

Technically it also shaves a couple of cycles off of the loop setup by inlining the return tuple from pairs()/ipairs(), but it's really the token savings that would be handy in some cases.

I don't know if this is expected behavior, but I thought I should ask:

Is it expected that stringifying the table var/ref will give different results when it has a (blank?) metatable attached?

> Changed: Controller inputs are accepted even when PICO-8 is not the foreground application

PLEASE change this back. This is totally counter to how apps are supposed to work in a windowing environment. If an app doesn't have focus, the whole point is that it's not the one receiving input.

This is causing problems for me already because I can't safely pause a PICO-8 game while I play something else that uses a controller.

I saw @zep's tweetcart and wanted to fiddle with it to produce something like the pattern on the bag he showed in the thread. I use Voronoi cells to apply multiple patterns to each image.

Unfortunately, with the limited resolution, our eyes can't pick out patterns unless they are at least half the size of the screen and very regular, so I had to use a limited number of cells with a reduced amount of randomness in each pattern. It sorta works, but it'd be way more effective on a hi-res screen with more cells.

zep's hitomezashi with voronoi cells

Cart File | Forum Post |

	More cartridges by Felice

More Cartridges [View All]

 

zep's hitomezashi with voronoi cells

by Felice

Cart #rajadadaji-0 | 2022-01-01 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

5

Yo @zep,

On discord and here on the BBS, we get a lot of people who basically need to get to the auto-backup of a cart they've lost somehow. It'd spare a lot of time writing blurbs like this if people could simply type "backups" and have it work like the "folder" command except it drops them in the 'backups' folder instead of 'carts'.

In all but one case I can think of, PICO-8 specifies screen rectangles as X1,Y1-X2,Y2 (inclusive).

The case where it doesn't is clip(x,y,w,h).

This has always bugged me. But worse, I noticed recently that the virtual hardware registers for the clip rect are actually set up like the other API calls: X1,Y1-X2,Y2 (inclusive), which means the API is actually translating between the paradigms.

Now I realize clip() can't suddenly change to work the other way, but...

What if we had a new command next to it called clp(x1,y1,x2,y2) that worked the same as everything else, worked like the virtual hardware, returned the same values you'd get by peeking the virtual hardware registers, etc., and simply marked clip() as deprecated, much like mapdraw() is deprecated?

It would hardly be the only abbreviated API call, e.g. sgn().

What do you think, @zep?

Right now, tostr(n) converts to decimal, and tostr(n,anything_except_nil_or_false) converts to hex.

Could it use the optional second arg as a base if it's a number? e.g.

>?tostr(255)
255
>?tostr(255,false)
255
>?tostr(255,true)
0x00ff.0000
>?tostr(255,16)
0x00ff.0000
>?tostr(255,10)
255
>?tostr(255,2)
0b0000000011111111.0000000000000000

For the sake of simplicity, you could limit it to the bases the parser can read. I think that's just decimal, hex, and binary.

"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!

I just discovered there's "> ..." quote block feature.

Except there isn't...?

If I do this:

this is my introduction

> this is my quote

this is my response

I get this in the preview:

But when I click [Publish] it comes out like this:

Also, if this feature is intended to work, it should be in the [Formatting Help] helpbox.