I'm loving messing around picotron and the sounds I'm discovering~
But I think I stumbled into a bug!

The sfx data, most specifically the notes in the individual patterns as well as the spd and loop data, are getting jumbled up as I insert new notes, and behave in strange ways...

Undo (ctrl+z) is not working to undo these glitches either, unfortunately :<

'load' bug

Issue: load fails to properly load cartridges from the BBS after the first one.

Reproduce:

1. boot picotron
2. > load #nights
3. ctrl+r: #nights plays. stop.
4. > load #util_new (or any other cart)
5. ctrl+r: #nights plays again
6. repeat as many times as you'd like to keep seeing nights instead of what you want to see.

Fix: whenever you load a BBS cart it seems you have to manually delete the temporary bbs cart (rm /ram/bbs_cart.p64.png) before issuing another load command. Doing so will have your desired second cart load and run properly.

Anyone else having this issue?

This one's doesn't reproduce after a bit but when you load up the sprite editor after a clean boot, the brush tool doesn't work at first until you change the brush size.

Yep @ahrotahn, I am having the same issue.

Pretty niche one, but: Touchpad taps don't seem to register as more than selection clicks. Can't execute on tap, only with clicks,

@The V Man - i can also reproduce this issue and find it quite annoying, though i found that very well timed (kind of longer than you'd expect) double taps will do it. i have been resorting to loud touchpad manual clicks to double click stuff as well on my laptop.

(PS: how do i properly @ someone who has a space in their name?)

Dragging a file into a folder on the desktop, where it opens a new window, and then dropping the file over the window as soon as it opens causes picotron to freeze. It can still be closed via the close button on the title bar normally.

Glad to find that we've got a bug reporting thread going! I keep running code with mget (guessing that this has been retired, but I'm not 100% sure), and each time I absent-mindedly do, Picotron crashes. Code like this:

print(mget(p.x,p.y),10,10,8)

Running a Mac M1, if it helps.

Ooh, but if I define it in a variable then run the code ->

test=mget(p.x,p.y)
print(test,10,10,8)

I get a proper runtime error. 'attempt to call a nil value'. Love the error reporting popup, by the way!

Escape sequences like this are marking the colors of what is a string and what is code in a weird way but only the colors the rest works right:

Using a non-default video mode (e.g. vid(4)) and falling back to rendering at lower than 60fps results in truly horrible flashing.

calling assert(false,vec(0)) crashes picotron, as well any userdata as far as I can tell. I get around it by calling :__tostring() on whatever userdata variable I'm checking

I closed all the workspaces from boot just for curiosity sake. I got stuck in the console with nothing on the alt toolbar besides the current terminal. Desperate for a way to get a desktop UI again, I found system/startup.lua, running this at first seems to restore/restart the UI.

But if I run the "ps" command to check running software, there are now duplicates of all the operating system programs, like multiple copies of eyes, wm, etc. This can be repeated indefinitely to eat ever more memory and make the UI basically super confusing to use.

I don't see a way to get back out of this state without closing and restarting the program.

I realize this is probably just the emulated consequence of the OS boot sequence and being silly enough to go run startup.lua instead of restarting the whole OS.

Still, maybe there should be a "safe mode" or "newbie mode" safety feature to keep us from doing super dumb things out of the box.

I think such a feature would need to toggle off, since the whole point is to let us hack the system too.

But I would love if the system broke character and helped a bit with situations like this, instead of leaving the user stranded. This could be very rough for someone without pico8, lua, or even computer console command knowledge. I got here in like 5 minutes just poking it, lol.

Oh, there was also a full freeze on the first time I typed "save testcart" into the console after installing. I haven't been able to recreate yet.

I believe it was caused by my backup software running and checking the hard drive while Picotron tried to save a new file?

If I can find the steps to recreate, I will report more. Unfortunately, since the picotron boots up full screen, I couldn't get to the rest of windows to see anything else without terminating the application. And of course, now that I set it to windowed mode my scanner is done and saving works fine.

I am on windows 10 64 bit, my backup software is idrive, it was scanning files for changes.

Absolutely loving the support of copy and paste between code editor and notepads/etc. within the OS itself, by the way! I can make cheat sheets with all my functions ready to paste into new apps without leaving Picotron, it's awesome!

I've got way broken key mapping on a PC on Windows 11 (with the standalone version):

• up maps to a small value on the left and down axis
• down maps to a full down + slight left nudge
• left maps to full left + slight down nudge
• right maps to a small down value
• up + left maps to full left
• up + right maps to full right
• down + left maps to down-left diagonal
• down + right maps to down-right diagonal
• Opposite directions cancel each other

EDIT: Damnit, I didn't notice I had a gamepad on. If you have an active controller, using the keyboard might skip the controller's deadzone (or it's just merging both inputs methods into something unpredictable).

The layer order looks reversed the layer below in the list is showing the object above. At moment is not possible to drag or change layer order too

Since it sounds like some folks are not experiencing constant crashing: I'm seeing constant crashes, even when not really doing much (like reading code for a minute or two) on my M1 Mac running MacOS 14.3.1. Starting to sound like this might be an issue specific to the Mac build?

@luchak I'm also on a Mac M1 and experiencing a lot of crashes, often when running small programs. Excited for future updates with patches. For the time being it's exciting using Picotron in its buggy state, feels like the wild west!

@luchak Maybe running the x86 build through rosetta would solve it? I'll try it to see, it could just be related to the architecture not macOS in general

The M series chips have stricter security and a stricter obj-c method calling convention, and probably more subtle differences

update:
Sadly still crashes, but it was worth a try

@TeamPuzel Oh, interesting, that seems plausible. I'd be curious to know if that works!

/system is valid as a mount point in picotron_config.txt

Doing some stuff like

mount /system c:/tmp/picotron_system

Makes that folder persist across Picotron reboots and gets a full copy of the system's folder the first time you launch Picotron after setting up this mountpoint, leaving you free reign to mod the OS the way you want with little restriction.

I have an inkling that this is a way to allow custom runtime setups and/or persistent specific configurations (like a kiosk mode) but the way it is right now allows for customization in an unpredictible way in multiple forms:

• The OS state, now permanent, can be broken across reboots more easily than just a configuration or a startup daisy chain error.
• The OS state probably won't change across updates, so you might end up easily in unsupported situations where you're getting an outdated OS running on a newer runtime.

The plus? You can tune the default apps the way you want, like adding features like jump-to-top/bottom in the code editor, making fix patches or basically "rice" your system up to the way the window frame is drawn.

Is that a planned feature, an accidental feature? This sounds pretty wild, given that by default Picotron's OS is supposed to be "read-only".

• Some when save card first time (win10) with save **** on console, it crash!
• We need Mget and Mset and any pico-8's map function back. So I can continue working on my game in #picotron.
• As long as Map functions and pget not works properly, I suspend my platformer game dev and use of #picotron, for now, this new fantasy workstation it's a joke. :P

Trying to delete a folder does nothing, additionally trying to move a folder creates a duplicate in the target directory, but fails to remove the original copy, essentially copying the folder (these functions work as intended on files, just not folders)

I am using windows 11

@TetraPengwin I have had something similar happen with files and not folders, perhaps it is related and we can figure out how to fix this. In my case, I was trying to move a lua file from name1.lua to name2.lua, but while name2.lua would appear, name1.lua kept remaining - or rather, coming back almost instantaneously. It turns out I had name1.lua open in the code editor, and the editor would automatically and immediately re-save the file. Once I closed name1.lua I was able to just rm it. Is there something that might be trying to use /desktop/test that would be recreating it on access if it's missing, do you think?
Worst-case, I suppose you could folder to open your OS file browser and navigate in to delete it... does that work, or does it reappear if you do that?

• Changing video mode via vid() function in a terminal window on the desktop switches the whole desktop to a fullscreen terminal that, as far as I can tell, can't be exited.

• In 'Battery Saver' mode, in the instrument creator, if I add an oscillator, mod or fx to the first carrier the background will flicker rapidly. In the regular mode, it just dims the background a bit.

• Also, on my 2015 macbook pro, it takes several clicks of the trackpad to register a single left click. It's definitely not an issue with the computer as Picotron is the only app that does this.

It's impossible to include a file that includes other files because it does not preserve the relative path within each

@TeamPuzel I might be misunderstanding what you're saying, but it works fine for me! I have a lib folder in my 3d renderer thingy and a few of the lua files in there include other files from the same path, but in the include statement, they all start from the base cartridge path (so all the files in the lib folder would still say "lib/example.lua" if that makes sense)

@Maeve Yeah I understand how it works, it just forces the library to be aware of it's absolute path ahead of time — not very convenient, if I wanted to then move it somewhere I'd not only have to correct the path to it but also all the paths within it :(

And once the library also contains a library it gets too confusing to even be worth trying anymore

@Legno I also didn't get a redeemable key with my purchase. I already contacted Lexaloffle but didn’t get an answer so far.

@eggnog but there are no built in mget() in picotron...

Does the web player builds count as candidates for bug reports? The task bar can be triggered and clicking on Files in its menu crashes the console.

Also looks like having multiple versions of the cart in a thread doesn't work? Luchak's rain wallpaper has two different behaviors in both versions but only the most recent is loaded even though Luchak tried to show both carts.\

EDIT: Task Monitor just crashes on load because theme is nil. Is there plans for different types of carts like Vox had?

EDIT2 : Valden's Mode7 demo seems stuck, the performance might look fine my my desktop but the sound is definitely broken.

@maleficmax You are correct! A runtime error like "attempt to call a nil value" would be the proper result of a typed mistake like this, not a crash.

When i add a modulator in the instrument editor (when i click the +mod button), the background of the editor starts flickering. This makes the instrument editor unusable for me because flickering graphics trigger my migraine and make me sick to the point of vomiting. I would love to see this fixed! :)

@Sorm - have you got Battery Saver disabled?
See: https://github.com/ace-dent/picotracker/issues/13

@Eiyeron I can fix that, I'm slowly moving Task Monitor and Minesweeper to my own ui library, so I could use a theme wrapper class that just returns defaults if a theme isn't in /ram/shared for some reason

But it would be nicer if the web version was just compatible with the desktop and had a basic theme selection, the blue background will make playing windowed games like minesweeper visually unpleasant for me anyway :/

edit:
Sound is really messed up in the browser for me, sounds somewhat distorted (using Safari 17.4)

Website not picotron issue, and more subjective, but the font seems to have changed, and I find it very hard to read :(
Could there be an option to use a normal sans serif font like before?

@aced When i enable the battery save mode the flickering is just slower. ^^

Regarding the GUI lib, The GUI's field element doesn't let me delete the first character of its field.

Picotron carts are currently using the PICO-8 icon on the BBS:

The web player's frame rate appears to be tied to the refresh rate of your monitor. My laptop's screen runs at 144hz, so games run much faster than they're supposed to.

> The web player's frame rate appears to be tied to the refresh rate of your monitor.

@bluswimmer It doesn't seem to be tied to the refresh rate, but it's definitely too fast. I posted a cart in another thread that shows it's going way too fast:

time_check

Cart File | Forum Post |

	More cartridges by MBoffin

More Cartridges [View All]

 

time_check

by MBoffin

Cart #time_check-0 | 2024-03-19 | Embed ▽ | License: CC4-BY-NC-SA

Even on my monitor running at 60hz, it's going at way above 60fps.

@MBoffin What browser are you using? I'm on a 120hz MacBook, using Safari, and it appears to run at 59fps instead (and it messes up sound too).

If you are running the web player of Picotron on a 120hz monitor, it will run twice as fast as intended (144hz will run 2.4 times as fast, etc.). This also happened in the playground.

EDIT: Looks like other people already said this, oops

If you're running a slow cart, there are at least two big issues:

1. Framerate convergence. If you're close to a framerate boundary, Picotron is really indecisive about picking one, and this sometimes seems to lead to settling on a lower framerate than you would get if the cart ran just a little bit slower.
2. There's tons of palette flickering, where the palette gets reset to the default quite often. This seems to happen more when the framerate changes.

Also, possibly related to the above: I have some carts that run at a solid 0.71-0.73 CPU at 60fps when all the code is in _draw(). But if I partition some of the code out into _update(), the cart then drops to ~20fps and reports CPU usage in the ~1.5 range.

If the code couldn't run at 60fps I'd get why bad things might happen, but as-is I'm not sure what's going on.

There's a couple bugs with fetch (M1 Mac, Picotron 0.1.0b & 0.1.0c):

1. I can reliably crash Picotron when calling fetch() containing a remote URL with a query string that is 60+ characters long:

-- Works
local c = cocreate(function()
  print(fetch("https://example.com?ThisQueryIs59CharactersLongThisQueryIs59CharactersLongThisQ"))
end)
while (costatus(c) != "dead") do coresume(c) end

-- Crashes Picotron 0.1.0b & 0.1.0c
local c = cocreate(function()
  print(fetch("https://example.com?ThisQueryIs60CharactersLongThisQueryIs60CharactersLongThisQu"))
end)
while (costatus(c) != "dead") do coresume(c) end

But, if there's a / immediately before the ?, it works again:

-- Works now with the /
local c = cocreate(function()
  print(fetch("https://example.com/?ThisQueryIs60CharactersLongThisQueryIs60CharactersLongThisQu"))
end)
while (costatus(c) != "dead") do coresume(c) end

2. fetch() forces remote URLs to lowercase / is case insensitive, which breaks requests to some sites (like Fandom; its URLs are case sensitive)

Can confirm it yourself with this testing API that just echos back the requested URL:

local c = cocreate(function()
  print(fetch("https://echo.free.beeceptor.com/UPPER_case"))
end)
while (costatus(c) != "dead") do coresume(c) end

Another macOS issue: on top of not remembering the last window position and size (which is annoying but not too bad) the window's behavior breaks in multi-monitor macOS.
A window should open on the last display it was on, which doesn't work, but it gets even more annoying;
When the active display already has something in fullscreen, and there is another monitor currently on a desktop space, that takes precedence and the new window ignores its last position and opens on the desktop monitor, to avoid shuffling the user's tiled/fullscreen spaces around.
Picotron is hardcoded to just appear centered on the primary display and will just move my fullscreen space out of the way, even when there's an empty desktop on my other monitor :(
Please consider using NSWindow correctly (something SDL is apparently incapable of)

Is the map editor currently not capable of selecting different sprite sheets or am I missing a menu or something? I expected "open file" within the map editor to differentiate between map and gfx files but it doesn't, it runs the graphics editor instead which is confusing.

Hello,

I have a couple of small bugs.
One is that the command ls (with the space) causes an error:

/system/util/ls.lua:25 attempt to concatenate a nil value (local 'path')
stack traceback:

The other one is that somehow, while using the terminal it started always scrolling up/only printing on the top line, even when space was available. I would cd system and then use ls on various subdirectories of system (wallpapers, util, wm) when it happened both times, though I haven't figured out how to consistently cause this. (E: This seems like it might just be a scroll feature, so nevermind.)

Adding to the other mentions of right modifier keys failing, the right Alt key does not work for me (testing with Alt+Enter, it works with the left one and not the right one)

This was on version picotron_0.1.0b2_amd64.zip on Linux (Debian 12).

This software looks very cool. Looking forward to seeing it develop :)

Thanks for all the hard work zep! Not sure if this is a bug but I get the attached error message when I try to save a cart with a dash ("-") in the filename.