Hey @zep,

I've been messing around with software synth via the PCM trick and I feel like there's sort of a fundamental problem that's detracting a lot from the quality of what comes out the back end, needlessly so, not to mention making it uncomfortable to the listener's ear.

As far as I can tell, you're feeding the 5512.5Hz signal into the audio version of a "nearest neighbor" sampler to upsample it to the host OS' audio hardware sample rate, which is typically gonna be either 44100Hz or 48000Hz. That means repeating the sample values as many times as necessary to fill the gaps. In this case it'd repeat the same value around 8 times. This of course produces stairsteps on the 44100Hz+ "curve".

The issue with that is that modern audio hardware has really good fidelity and it's going to reproduce those sharp stairsteps very faithfully, effectively overlaying a constant 5512.5Hz triangle wave on the original wave that pulsates its amplitude based on how big the deltas between samples are in the original wave.

Like, if the original wave was a 262Hz middle-C sine wave tone, you'd get a 5512.5Hz buzz overlaid that gets strongest each time the wave crosses 0, where the rate of change is maximal. It crosses 0 twice per cycle, so you're getting an audible crackling buzz at 524Hz.

That's not what would have happened on old analog audio output circuitry. There would be ramping time between levels, some sort of acceleration, deceleration, and maybe overshoot too, as the line settled at its new level. Basically the audio version of an LCD pixel's "response time" or "gray-to-gray time". The overlaid triangle wave would be closer to a sine wave, more of a tone than a buzz, still present and still distorting the intended wave a bit, but much less harsh to the ear.

I dunno what options you have to change the upsampling. If you're doing it by hand, your options are open, but if you're relying on hardware, you might need to experiment. You probably don't want to change it over to using full interpolation, because that'll make it hard for people to do deliberate buzzing.

If it were me, I'd try doing a manual nearest-neighbor upsample to 22100Hz (edit: or maybe just 11050Hz) to retain the low-resolution stairsteps you'd expect the low clock rates to produce on retro hardware, but I'd let the host OS/hardware do interpolation to upsample it the rest of the way to the true output rate of 44100Hz or 48000Hz, which will simulate the ramping up/down time. This'd take the edge off, for the sake of the listener's ear.

I've discovered that printing the "\b" character (8) moves the cursor back based on the width of the most recent glyph that was printed.

So, @zep, I can understand where your mind was going with this, because you wanted it to be possible to back up over something like a kana character or a PICO-8 emoji with a single backspace. That does make sense.

However, I think unless you're going to keep a long history of what was printed before that, and where the cursor was for each glyph, it's going to cause problems, because right now it's only guaranteed to work for backspacing over one character, not more.

For instance, if I print("abしd\b\bcd"), it doesn't put "cd" in the right place, as shown below, where I highlight the overprinting in the second print by changing the foreground color to orange:

Point being, you're trying to be helpful to the user by remembering the width of the last glyph, but it's not helpful to the next user who wants to back up over two glyphs. It's not a game I think you can play to win. I think it'd be better just to set backspace.dx to a constant for the font, be it oem or custom.

You should probably just set backspace to be literally a backwards space. Let the user deal with double-wide or narrow glyphs if they need to—they know what they're printing, after all.

(Another option would be to give us a command code to set the backspace size, e.g. "\^<4", and default it to 4 or whatever is appropriate for a custom font. Leaving it in our hands solves all the problems, honestly.)

I noticed this while looking at load/save behavior for my QoL idea.

You can load a file that has no extension, because load will try the raw filename first without adding an extension.

However, when you save that file, it will automatically add ".p8" to the name, possibly overwriting an existing file while not overwriting the file you actually loaded.

Probably not going to happen much in practice, but potentially disastrous when it does happen.

At the command prompt, if you try to load a filename with no extension:

load somefile

It'll try these in order:

somefile
somefile.p8
somefile.p8.png

It'd be nice if #include worked the same way.

e.g. with vector.p8 in the same folder:

#include vector

I think simply re-using the logic from load would work, because it behaves exactly the way I'm suggesting.

As for Lua files, it's probably best if the .lua extension has to be typed out explicitly, because you're essentially leaving the sphere of PICO-8 by using a raw lua file and it makes sense that PICO-8's name abbreviation would not apply. Plus this is the same behavior load already uses, so minimum effort required. ;)

@zep

It'd be really intuitive and helpful if the select() function also detected a boolean value for the first argument, and returned the first arg if true and the second arg if not.

A lot of us write our own ternary function that does this anyway, because it can work around some gotchas with the cond and tval or fval structure, so this would obviate the need for it while extending the existing API in a very intuitive way.

e.g.

-- this works as you'd expect a C/C++/JS-style "cond? nil : that" ternary op to work
this = select( cond, nil, that )

-- this doesn't, it returns 'that' regardless of 'cond'
this = cond and nil or that

Plus I think this would evaluate faster on the host.

Should probably also treat nil as false, btw, for maximal usefulness and congruence with Lua's concept of conditions.

I can't see a way to disable the new "\#n" background-fill mode once it's been enabled. I've tried "0" for color 0, "G" for color 16, and "W" for color 32, but they just set the BG to black, and all other "0-Z" just repeat the palette. I've tried supplying a "-" for the color instead, I've tried repeating the "\#" code or just "#", I've tried various other symbols and the puny letters, and anything not in "0..Z" just sets it to black.

Is this a missing feature or is there supposed to be a way to do it? The manual says nothing of turning it off. Right now I have to start another print() to get back to no-BG mode and that seems... unintended?

I feel like it ought to be "\#-", based on the convention with the "\^" commands. Alternatively, "G" (or anything through "V") would technically make sense if you just consider bit #4 of the color to be a "transparency" bit.

Edit: Just to be clear, I mean within the same print string. You can print again and the flag will be cleared, but for the sake of tokens, I'd like to do it within the same string.

Before the most recent update, you could print anything below chr(32) and get an actual glyph in the output, aside from the obvious exceptions like \n and \t. For characters below chr(16) this is no longer possible, aside from chr(5), which I suspect is an oversight. In fact, that oversight is the "bug" that brought me here.

The thing is, this is a waste of 16 glyphs in the character set, and potentially up to 32 in the future if you add more control codes.

Can we get some kind of "raw" printing mode, where control character behaviors are completely ignored and their glyphs are simply printed?

Maybe turn the two oem/custom font selector characters into a single oem/custom toggle to free up chr(15), and use that as a raw-mode toggle, as in this pseudocode, where raw mode allows everything to be printed except the toggle itself, unless it is repeated:

fn print(s, ...)
    raw = false
    just_toggled_raw = false
    for each char c in s
        if c == raw_toggle then
            if just_toggled_raw then
                // escape the toggle
                draw_glyph( c )
            // remember if it was a lone toggle, forget if it was doubled to escape
            just_toggled_raw = not just_toggled_raw
            raw = not raw
        else
            just_toggled_raw = false
            if raw then
                draw_glyph( c )
            else
                ...insert existing print code here...

Apologies if I've missed some existing way to do this.

This is to do with the so-called "outpost" value, or the two's-complement wrap point, which in PICO-8's number system is 0x8000, or when printed as signed decimal, -32768.

Like the origin, 0x0000, it's technically not really signed, or maybe it's better to say it covers both signs simultaneously. Conventions assign the origin to the positive side, and the outpost to the negative side, but that's just a pragmatic choice for numbers that unavoidably behave strangely due to the encoding. The origin and the outpost are complementary values in this way.

(This is why 0 == -0 and -(-32768) == -32768 with a 16-bit signed integer, by the way.)

That being said, this is what I currently get for the outpost value:

> print(tostr(abs(-32768),true))
0x0000.0001

Obviously, there's no "good" result when we can't represent +32768 with a signed 16-bit integer.

But this result is just plain wrong in every way, because it has no connection to anything someone might expect to get as an alternative to the impossible correct result. It's not equal to -(-32768), it's not close to +32768, and it's not even exactly 0.

• Technically, I think it should return 0x8000 a.k.a. -32768, just like -0x8000 a.k.a. -(-32768) does. This way, -abs(-32768) returns what it should, which matters in some cases. This is basically in keeping with the usual properties of the outpost value.

• An option, albeit one I don't approve of because it's not symmetrical if you try to undo it, is to return 0x7fff.ffff, or not quite 32768. This would make the one rare edge case where someone was pushing numeric limits on PICO-8 work almost correctly, but honestly I think any calculation with a number this size is still going to fail and really ought to be done differently, so it's better if it fails obviously. Holding the hand of a new programmer in a rare edge case isn't worth breaking the behavior a seasoned one would expect in the same edge case.

• Another option would be to return exactly 0, rather than slightly more than 0, to make the "bad input" situation more clear to the dev so they can fix it, because a dev trying to work with abs(0x8000) is not going to have a good day anyway and they should probably find out as soon as possible. This feels like a sketchy idea, though. And it brings us to the final option....

• The most draconian option would be to trigger a runtime error, since it's literally impossible to represent the result. I'm not sure how I feel about this. It'd definitely help devs find problems with their math, but there's always the chance it won't happen to the dev during development and will happen to the user in the wild, which is not okay. A glitch in the wild is bad but tolerable, a crash isn't.

Anyway, as you can probably tell, I think abs(0x8000) should just return 0x8000, which means in layspeak that abs(-32768) returns -32768. That may (and should) feel nonsensical to a junior programmer, but everyone needs to learn the weird rules about the outpost value eventually anyway, so I think it's the real pragmatic choice.

/me steps off of soapbox

I noticed in this post that @choo-t doesn't turn into a user link.

Must be the hyphen?

I'm surprised I haven't noticed this before.

I'm not sure if this is a regression in 0.2.1b or if it got outright broken, but @zep, I swear you fixed it in the past. But in 0.2.1b pack() is always setting the table.n value to 0:

Hey @zep,

I know this is pretty minor, but I often find myself adding this to my programs so that I can use it in tables of functions/behaviors or other similar circumstances:

function nop() end

It'd be cool, and kind of in keeping with the half-lua/half-asm feel of PICO-8 to have a handy built-in nop() function for such occasions:

function assign_behavior(o,b,f)
  o.behavior[b] = f or nop
end

-- saves me having to do this elsewhere:
if(o.behavior[b]) o.behavior[b]()

I can't be sure, but I bet it might be useful for some tweetcarts too.

Seems like it'd be trivial to add as an efficient built-in C-side function as well. No need to handle args or closures or anything, just spot it and return the empty set immediately.

Anyway, I know it's about as minor a request as a person could possibly make, but still, I figured I'd at least ask. ;)

PS: Honestly, I think even vanilla Lua could use this as an actual built-in, like a pseudo-keyword. In some cases it could be as useful as nil.

@zep

Why does clicking the Forum link in the site ribbon always take me to the BBS > PICO-8 > Cartridges subforum?

I feel like it ought to be taking me to the BBS > PICO-8 root forum.

Even if your intent is to lead new users to the Cartridges subforum so they know it exists, it should really only do that from outside of the forum itself. Once I'm actually in the forum it feels very off to click Forum and end up with nothing but carts instead of general PICO-8 discussions. I keep doing this intuitively to return to the root forum, and then I remember I have to click the penultimate breadcrumb instead of the intuitive Forum link.

I saw this mentioned on Discord, so I tested it, and found it to be true. I can't think of a reason for it to be this way, so I figured it should be written up as a bug.

This code:

local c=x+y

is faster than this code:

local c=0

Here's a dead-simple test cart. Hold a button down to switch from running the first assignment per pixel to running the second. I get stat(1) = 0.7709 for c=x+y and 0.8296 for c=0, when at best they ought to be at least identical.

c=x+y vs c=0 performance test

Cart File | Forum Post |

	More cartridges by Felice

More Cartridges [View All]

 

c=x+y vs c=0 performance test

by Felice

Cart #rutesujaju-0 | 2020-08-03 | Code ▽ | Embed ▽ | No License

4

Hey @zep,

I notice you can use the double-width katakana glyphs as identifiers, but I don't think you added the new printable single-width characters below chr(32) to the "legal chars" set for identifiers.

So I could use ta/た in a variable name, but because I need the single-width dakuten at chr(30) to make da/だ, I couldn't write a variable named, e.g., だくてん.

I figure if it's not a placeholder glyph (like the first 10 or so) and not reserved for Lua, it ought to be legal for identifiers, based on how every other glyph has been. Am I right?

I'm asking specifically because I'd like to use one particular character in place of 'self' in my code, to keep my code concise on the tiny PICO-8 screen, but I can't currently use it because it's not legal.

Hey @zep, not sure if this is a bug or intended, but I just realized that, in a fresh cart, sfx 0 is speed 1, while all other sfx are speed 16.

Is there some reason for this?

Seems like this is something that might lead to confusion at times. The user will probably figure out what's different pretty quickly, but still... I thought I should at least put it on your radar as a possible mistake.

As an aside, "Speed" really isn't the right term here. It should be "(note) duration", or something similar. I dunno, I don't have an audio background so there's probably a more concise term.

In my qsort() thread:

https://www.lexaloffle.com/bbs/?tid=38679

If you click the "Code" button on the embedded cart and scroll down to qsort() or iqsort(), you'll see a line near the top of each function that says, if l then, but the line inside the cart is actually if l<r then, so if anyone grabs the code for the function, they get a corrupted version of it.

I'm guessing this, and possibly other, reserved HTML elements are not being escaped properly...?

A while back I posted an implementation of an in-place dual-pivot quicksort, which is the default sort algorithm most standard libraries offer these days. I've since tweaked it a bit to save a few tokens, and today I wrote up a sample cart that does some primitive testing as an example of usage.

This includes both a general 221-token qsort(), which can accept a custom comparator function (defaults to a less-than comparator for ascending order), and a tweaked 199-token iqsort(), which inlines the comparisons as simple "<" operators, producing a smaller and faster sort in return for the sort order and index not being customizable.

See tab 0's header comment for more details.

(Side note: I realized while implementing comparators that you could sneak in shuffle functionality just by sorting with a random coin-flip comparator. Handy.)

Edit: WARNING! Do NOT grab the function from the "Code" flyout on the embedded cart below! There is a bug on the BBS right now that deletes a "<" comparison! Click the "Cart" button to download the .p8.png version!

Dual-pivot qsort() test/demo

by Felice

Cart #putikutuke-0 | 2020-07-04 | Code ▽ | Embed ▽ | No License

6

Feel free to use it in any way you wish. I didn't invent the algorithm, and the implementation was inspired by looking at several other people's implementations (which in turn were inspired by other people's implementations, and so on). I'm not going to claim any original work here. I just did some grunt work tidying it up and applying ducktape where needed.

Please let me know ASAP if you find any bug. I think it's solid, but I know I'm not perfect.

Yo @zep,

This thread isn't the first time I've seen people ask about inserting values into the middle or start of arrays/sequences:

https://www.lexaloffle.com/bbs/?tid=38249

It occurs to me that a lot of carts probably have similar boilerplate code like the ins() function I wrote for that person. I think it would be nice, and better for PICO-8's host-machine performance, if there were a C-side implementation of that insert code, and I think you could do it simply by taking an optional third argument to add(), effectively implementing something like this Lua code on the C side:

function add(t,v,i)
  i=i or #t+1 -- default to extending the list
  for j=#t,i,-1 do
    t[j+1]=t[j]
  end
  t[i]=v
  return v -- return the added value for convenience
end

This shouldn't break any existing code, since there hasn't previously been a third arg, and the default value produces the existing behavior.

(Come to think of it, I'm not sure if you have add() on the C side or as hidden Lua. If it's not already on the C side, you might want to put it there, because it happens a lot in carts and doing it through interpreted code is definitely going to slow things down on the host hardware. Same goes for any other oft-called hidden Lua code.)

I have a cart used as an ongoing reminder alarm, simply showing the previous alarm, the current time, and the next alarm. It runs continuously for very long periods, e.g. weeks. Indeed, this instance has been running since the week 0.2.0i came out.

Today, for the first time I've ever noticed, the display was showing a pattern of corruption. I took a screenshot, but there was no corruption in the screenshot, so I tried saving a gif. I have my gif len set to a couple of minutes, so the result is quite long.

If you pay attention, the gif shows the parts of the pattern changing every second or three:

And yet when I saved a screenshot at the same time, there was no evidence of the corruption:

I assume this is because the PNG is saved from a point in the pipeline that comes before the corruption, while the GIF is saved after the corruption.

This means the cart itself isn't producing the corruption. It's happening somewhere in the frame presentation pipeline.

Not long after I saved these, I tried to save another GIF, and the actual executable crashed.

I'm surprised I haven't noticed this before today.

If I have my tabs set to two spaces, and then I cursor up or down across lines with varying numbers of tabs indenting them, the cursor column will shift left or right depending on the number of tabs at the start of the line. See this example gif for a demonstration:

Edit: as I discovered below, this also happens with double-wide glyphs:

The editor should be trying to maintain a virtual on-screen column, not an in-document column.