Just to keep an organized and succinct checklist, I guess.

Splore:

• Keeps the cartridge loaded from its internal "BBS" location when you exit it and overwrites the BBS cart when you save changes you made yourself. (as opposed to the cartridge using cstore, which would be fine) If this is intentional, there's no clear way to explicitly redownload a fresh copy from the BBS without manually going into the folder and deleting it yourself.
• Replaces the Esc menu with a copy of the Pause menu, meaning you can't jump to the editor directly (is this intentional?) unless you return to splore and then exit splore first (which leads to the bug above, since splore leaves the last loaded cartridge loaded)
• Search function only operates once and then can never be reset unless you fully exit and restart the application, and even then you still see the previous search results.

Save/load animation:

• Plays whenever run()-ing a running cart, even if that cart has no save data and shouldn't be being written to and wasn't swapped.
• Appears to negate or corrupt at least one byte of user memory, not sure if the exact behavior is actually documented anywhere.

Misc:

• += inside strings breaks preprocessor.
• Multi-line strings (using [[ ]] same as multi-line comments) in the syntax highlighter / token counter are not processed.
• Single-line strings (using "") in the syntax highlighter / token counter can (but should NOT) continue across multiple lines, even though in Lua that should result in a syntax error unless something weird is going on. (eg. encasing the entire script in [["]] ... --" so it counts as only one token)

I was able to break the token limit using the += bug.
The program below works, but only has a token count of 5.

print(",0+=0)

x = 0
cat = "dog"

function _update()
 x = x + 1
 if x > 127 then
  x = 0
 end
end

function _draw()
 cls()
 circfill(x, 64)
end

print(",0+=0) evaluates to something valid like print(",0 = print(",0), but the original version contains a trailing string, so the rest of the code is interpenetrated as part of the string.

Using any shorthand math operators or if () shorthand seem to break this though. Strings work but they add to the token count.

Thanks for the great list. I've fixed everything here for 0.1.7, except this one:

• Appears to negate or corrupt at least one byte of user memory, not sure if the exact behavior is actually documented anywhere.

Do you mean the spinny cart animation itself appears to mess with RAM when it is visible? Or that loading/saving does not reliably retrieve/store every byte correctly? I wrote some stress testers for this, along with peeking and poking into the full range of memory, and couldn't find a discrepancy.

Here's hoping the Stamp Tool section of the manual gets finished.

Have you looked at the key issue on the RaspberryPi? (it is maybe an SDL issue)

Zep: I think it's the former - I remember people were having trouble getting Picoware working on 0.1.6.

Thank you for your attention, zep. :D I know a lot of individual little threads get buried and lost between your visits, so I figured keeping a central organized list of everything I know like this would be helpful.

I don't know if it's the spinning cart animation specifically or what, I just know that some parts of the 0x4300~ space of RAM seems to get reset when run() (and POSSIBLY load) is called, resulting in Air Raiders never triggering its "weather changes when reset a certain number of times" easter egg, and PicoWare Inc. playing only a single microgame before immediately game overing you (Notably, it DOES record your score of 1 point if you successfully completed the minigame, however!)

I honestly don't know more because I haven't taken the time to seriously look into the details of what's causing this. The large artificial delay the spinny cart animation adds is off-putting and makes the entire "rapid microgames across several individual cart modules" concept become impractical, to say the least, but I was stalled out on it anyway so I'm willing to just let it go.

I've run into a few as well:

1. The inplace operators seem to have higher precedence than the method colon, or maybe are just misparsed. For example,

obj = {}
function obj:meth()
	return 5
end

x = 3
print(x)
x += obj:meth()
print(x)

3
runtime error
x += obj:meth()
line 8: attempt to perform arithmetic on global 'obj' (a table value)

A workaround is to wrap the right-hand side in parentheses.

2. The map() function's layer argument is documented as drawing tiles that have ALL of the given bits, but actually draw tiles that have ANY of the given bits. (Note that you can emulate the current behavior by just calling map() multiple times, but there's no simple way to emulate the documented behavior.)

3?. I had a global with a name of the form _foo_bar (leading underscore + inner underscore) and got a very strange parse error. Unfortunately I renamed it without noting down the old name, and now I can't figure out how to reproduce.

I've also had stack traces point back to the wrong place on occasion, but didn't note down how to reproduce those either. Dang. I'll keep an eye out.

4?. Out of memory errors don't give a stack trace, which is quite confusing when the actual problem is runaway recursion. :)

5. Every leading underscore on a name counts as a separate token, even if following a dot or colon, and is highlighted in the editor as though it were an operator. Lua's special metamethod names (like __add) thus count as three tokens each.

6. -1 is counted as two tokens, which could be argued either way but still feels wrong.

7?. Home, End, and Ctrl-arrow work in the editor, but do nothing on the command line, which hampers its use for live debugging.

Also the command line history is only half a dozen lines or so, which isn't much.

8. Numbers don't print with enough precision to distinguish them from one another. print(1 - 1/256/256) (the smallest possible fractional value) produces 1, but the exact value is 0.9999847412109375.

9. A few more shortcuts in the other editors would be appreciated. :) For example, I don't think there's any way to change tabs in the sprite editor from the keyboard (Q and W just move the cursor off the screen), and I can't scroll through a pattern in the music editor with any of the mousewheel, Home, End, PgUp, or PgDn.

Also I would love to be able to middle-drag to pan around the map. Currently, pressing the middle mouse button is interpreted as a right-click.

Oh, speaking of: right-clicking the map editor to select a sprite changes the "current sprite" widget and the selection in the sprite list, but doesn't change what sprite the sprite editor is currently editing.

10. Documentation nitpicks:

• No mention that colons and end aren't counted as tokens. (Thank you for those!)

• sub() is only mentioned in passing in the section on strings. The documentation is these two examples:

		print(sub(s,5,9))  --> "quick"
		print(sub(s,5))  --> "quick brown fox"

...but nothing ever says what s is supposed to be. It took me a minute to figure out that the signature is sub(string, start, end) rather than sub(string, start, length).

• Probably worth mentioning that division by zero produces 32768. Lua's behavior of returning infinity will be pretty obvious; a number in the tens of thousands is modest enough to look like a valid value.

• The example Lua syntax has a lot of superfluous parentheses around conditions, which might lead new Lua programmers to waste precious tokens.

• No mention of elseif. I know it's not a Lua manual, but I think Lua's the only language with that particular spelling.

• "Hexadecimal" is misspelled as "Hexidecimal".

• The music looping controls are sort of glossed over and took me a while to figure out. I didn't expect the default behavior to be to continue to the next track and tried to use "loop start" to opt into it.

• The "specs" section still lists the cartridge size as 32k, but it seems to be 64k now (plus ~36k for graphics and sound).

• There are several mentions of compressed code size, and my current game is even over that limit, but I have no idea what that means or when it comes into play. I assume it prevents me from saving as a .p8.png? If I try, the console claims to have saved, but no file appears.

Another documentation issue: It never mentions that shr is arithmetic and shl is logical. (Honestly having that discrepency at all is arguably a bug...)

The docs still mention source code access from peek and poke.

Pico-8 gets confused with backslashes in the path - while the current directory is set correctly from the command prompt perspective (you can load and save in the specified directory), but it fails to reload other cartridges from within the game. Front slashes work in both cases.

Ah. Apparently exceeding the "compressed" limit prevents both saving as .p8.png and exporting to HTML. That's good to know, now that I've exceeded it by 50%. :) I barely squeaked by (two bytes under) by deleting every single comment, which seems a shame for an otherwise open-source-friendly platform.

The error messages for both problems are completely unhelpful. If I try HTML export, I get:

failed: 32k block not generated
exported filename.html

While it's true that filename.html was created, the accompanying filename.js was empty, with no indication as to what the problem was.

If I try .p8.png export, I get:

saved filename.p8.png

But the resulting image is just a regular image of the entire spritesheet.

you don't use export for p8.png, you use save. I find that confusing, too.

the documentation of flr is outright wrong, it states that flr(x) is the "Same as (x%1) for positive values of x". Did you perhaps mean x-(x%1)?

I did use save for the .p8.png (though I agree that it's confusing). If the code is too big, it seems to fall back to exporting the spritesheet and reporting success anyway. After squeezing out all the comments, exactly the same command created a playable cart image as expected.

The HTML5 player seems to have a little trouble with line numbers: https://twitter.com/orcaowlart/status/734629808609595392 (I do not have 28k lines of code)

I've seen fractional line numbers appear once before, too.

Additionally, the person reporting that error says it only happens on Chrome on OS X, not Safari on OS X nor Chrome on Windows. (It works fine for me in Firefox and Chromium on Linux, too.) I can't figure out how it could possibly be happening, so it might be a bug in the HTML export and/or emscripten and/or Chrome.

Surely I'm not the only one having the error report the entirely wrong line number?

The Chrome on OS X error happened to someone else as well, and it seems to be because a particular number is 1.429 instead of 1, even though it's initialized to 1 and only ever changed by having 1 added to it.

I tried resetting it to 1 in _init, and that worked for a few more frames before crashing the same way. No code writes to this value during normal play.

Then they restarted Chrome and it worked.

So, gremlins? I don't know. Playable here, and source that was built from.

Trivial bug, but pressing the DEL key when on the first character of the first line of the code window doesn't behave as expected (it doesn't do anything at all).

time() eventually returns negative result

time() resulting in a negative isn't exactly a bug given that the range of pico-8's number will overflow after 32767+65535/65536
That'll even occur naturally, when time used to be represented using a 32bit number of seconds past 1970, it'd overflow in 2038 and incorrectly say it's now 1901

It still is a 32bit number of seconds past 1970 in a lot of places. time_t overflow is coming.

Documentation bug: type() and assert() are undocumented.

...wow, assert sure would've been nice to know about. Those are both Lua builtins, but given that most Lua builtins are missing (including any facilities that would let you check which ones are available), it might be nice to document which ones still exist.

Which reminds me: is it intentional that setmetatable is available, but getmetatable is not?

x^2 is significantly slower than xx. Ditto x^3 and xx*x. In fact, x^a (raising x to an arbitrary power a) always takes the same amount of time regardless of the magnitude of a.

I'm not sure if this is a bug, but it should be documented at least, i.e. ^ notation is not a convenience provided by the interpreter, but actually an internal pow() function that takes a constant time.

You can verify this for yourself by running the code below (comparing performance of different smooth interpolation methods):

normtable={}
for i=1,32767 do
 normtable[i]=rnd(1)
end

function profile(label,func,tab)
 local t=time()
 local x
 local r
 for q=1,20 do
  for i=1,#tab do
   x=tab[i]
   r=func(x)
  end
 end
 t=time()-t
 print(label..": "..t.." secs")
end

function hermite(a)
 return (3-2*a)*a*a
end

function hermite2(a)
 return (3-2*a)*a^2
end

function hermite15(a)
 return (3-2*a)*a^15
end

function cosine(a)
 return 0.5*(1-cos(0.5*a))
end

profile("hermite",hermite,normtable)
profile("hermite2",hermite2,normtable)
profile("hermite15",hermite15,normtable)
profile("cosine",cosine,normtable)

Re: Audio on raspberry pi

Hi, I don't know if this is a bug, or if anyone else has this issue...but when the audio is directed out of the 3.5 mm Jack there is a high frequency continuous sound when in any pico8 editor, but not on the pico8 boot screen. It stops when switching to the pico8 terminal and resumes as soon as switching to any editor mode.

I'm using a pi 3 with a hdmi screen, and 3.5 mm audio jack into a small amp/speaker. I have no sound issues otherwise.

Hi Zep, I don't know if this is the best way for you to see bugs, we should really have a bug tracker program like Bit Bucket.

Some files randomly will fail to load in SPLORE but load fine with LOAD. Can provide files.

I've now encountered someone who had the same nonsensical Lua error in Chromium on Linux, but the BBS player worked fine for them.

Incidentally, sound has never worked for me on Linux Firefox on the exported player (and not for this person either), but it works fine for both of us with the BBS player. If that's going into the 0.1.7 release, well, hooray. :)

It's really bothersome that "resume" is barely usable anymore in 0.1.16, because something bad happens with the btn controls.

I've found what looks like a bug in the sound export. I have this sound, which plays perfectly in the console:

When exported, it makes a distinct pop at 5.61s, just after the beginning of the third note from the bottom in the third column. I opened it in Audacity and something funny has happened to the waveform:

You can see the transition from the previous note at 5.58s; this problem is happening inside this single note, and I don't understand why.

It's sound effect 31 in this cartridge: https://c.eev.ee/under-construction/under-construction.p8

Re: how to report bugs, I'll gently mention that posting one item per thread in the Support category has the modest advantage that issues can be marked as "resolved." So that's an existing mechanism for users to track issues. These giant bugs lists are great, and I can't speak to what zep would prefer, but the Support forum exists today.

Eevee: I got that same problem, but if you re export it will work.
It seems that there is an issue if you computer is a bit overloaded

Ah, thank you! It took a couple tries, but that did fix it.

I definitely don't mind starting a new thread per issue if that's preferred; it just seemed rude to dump a dozen threads about minor bugs into a forum that's ostensibly for people looking for help. :)

Once you've used Spore's Search feature it seems impossible to clear that text to search for a second phrase?

eevee: "The HTML5 player seems to have a little trouble with line numbers: https://twitter.com/orcaowlart/status/734629808609595392 (I do not have 28k lines of code)

I've seen fractional line numbers appear once before, too."

Hang on, I've encountered fractional line numbers in standalone too. Let's see if I can reproduce...

Here you go: https://www.dropbox.com/s/e1q4x6vvbiodkay/fractionallinenum.p8?dl=0

This game pretty consistently crashes both the web player and the standalone: https://www.lexaloffle.com/bbs/?tid=2950

I didn't write the game so I really don't know what's going on. For all I know, it could be poking system RAM or something.

RE: all the time() reports, I thought time() was deprecated in 0.1.1?

@dynamite_reed Yes so did I!

In other news, I'd like to ask for an option for pico8 to automatically reload if the external code file changes. Perhaps as a command line option?

Cmd+R hardly ever works, Control+R works more frequently. But Esc + cursor up to recall load command, followed by enter to load the file fresh is the only way I can currently get timely and guaranteed reloading of external changes.

I discovered that the pipeline character ("|") renders as a colon (":"). Is this intentional?

Edit: Sounds like I should post this in its own support thread instead.

@matt I think Ctrl-R silently refuses to reload if you've opened the editor at all since the last time you loaded, even if you haven't changed anything. Which is arguably a bug. :)

Interesting.

But if press Cmd+R and it doesn't reload, and then immediately press Control+R it will most often reload. Even bashing Cmd+R a second time will increase my chances of a reload.

I'm adding this bug in this thread: https://www.lexaloffle.com/bbs/?tid=3555
(Saving a file with extra leading space in the name)

Some minor quirks that are fairly trivial but could be worth looking into:

• Built-in functions written immediately after the string concatenation operator are not highlighted in green unless there's a space between them.

(Also using F6 to save screenshots saves the black borders inbetween the window edges and the actual PICO-8 display - is this an intentional design choice? Wouldn't it make more sense and be more convenient to save them with the same dimensions as the .gif videos?)

• None of the API functions for tables are highlighted in green in the editor except for pairs(). Again, not sure if an intentional design choice or just overlooked.

• Clicking in the top right corner of the screen while a cartridge is running (desktop version) will bring up the editor, as noted in this thread. It's an old bug that has been posted about before, but now that people have discovered how to retrieve mouse coordinates and button states it might be worth fixing.

Edit:

• The blank slate you get when typing "reboot" into the console does not have the white X at sprite id 000, instead it's completely black. Reboot also doesn't reset Splore's state; if you navigate the menus and/or type in a search word and then reboot and re-enter Splore you will be in the same menu with the same item selected and the same search phrase entered (meaning the only way to clear search in the current version is to exit the application completely).

ZEP: does the exit bug on the Pi has been solved in 0.1.7?
(It's the one where when running pico8 from a shell script for exemple, calling shutdown will just freeze pico8 (but not the pi, as we can still ssh to it for exemple and do a kill -9 on pico8 to recover)