Moving the mouse on a cart that:

1. has non-default palette values set (pal(c0, rgba, 2)), and
2. has been throttled down to 20fps

results in rapid flashing. It looks like the palette is constantly getting reset to the default, then restored to my new palette.

Some effects (like the edit button of the about menu changing color) still activate through other windows

@farvardin

> there is no scancodes.pod file on my system after the update (linux).
> I've create an empty file called scancodes.pod, I can open it but don't know how to add a value.

have you tried the code that you quoted in your message?

store("/appdata/system/scancodes.pod", {lctrl=57})

this is an example of calling the store function with a path and data (here remapping left Ctrl to key 57)

Alt-Tab from fullscreen mode seems to be quite slow - there's about 2second delay between switching windows.

Also there's a visible gap on the right side of the screen in fullscreen mode (my desktop resolution is 2560x1600).

save mycart crashes the application for me.

Hello! I can finally try making some programs with 0.1.0b!
However it seems to crash after a few minutes of the program being opened. (Macbook Air M2)
Following is the end of the log after it crashes. There are bunch of "PH_HOST file not found" messages before this.

[809478 058] PF_HOST file not found: /Users/jida/code/Picotron/drive/code/particle_physics_temp.p64
[809478 058] PF_HOST file not found: /Users/jida/code/Picotron/drive/code/particle_physics_temp.p64
[809478 058] PF_HOST file not found: /Users/jida/code/Picotron/drive/code/particle_physics_temp.p64
[834327 001] run_process_slice() for process 1 error: 2 :136: stack overflow
[834328 001] --------
traceback:
stack traceback:
    :136: in main chunk
---------
[834328 001] SYSTEM ERROR: *runtime error
[834328 001] SYSTEM ERROR: :136: stack overflow
[834328 001] SYSTEM ERROR: stack traceback:
    :136: in main chunk
[834328 001] ** RUNTIME ERROR IN KERNEL **
[834328 001] :136: stack overflow

Thank you for your effort!

Typo in readme.txt:

f/v flip selection horizontall or vertically

@bsm I don't really thing it is a bug because sticks are analogue and they are supposed to give all possible angles. It's difficult to press stick strictly horizontally or vertically if your stick is a good one. The app shows diagonal when it detects even a slight diagonal input and it is OK.
The question here is: can picotron return stick angles?

@maleficmax When dealing with analogue inputs, it is customary to make use of a deadzone in order to combat unintentional directional inputs.

If the user is intending to move the stick straight up/down and has the Y axis maxed out (±1.0), but is just slightly off-axis and has the X axis at (±0.01), the expectation would not be to see both max Y AND X reflected in the output.

A deadzone of between 10 and 15% is commonly seen with modern game controller joysticks to prevent exactly such accidental inputs.
It seems to me that that is what they are getting at and ESPECIALLY in the case of analogue-to-digital conversion for directional input (in the event that Picotron is not intended to support full-range analogue stick angles) a larger deadzone than that can be desired.

On linux, 1.0.0b2 fixes the Control key issue (woohoo!) but the right Alt still doesn't work for some hotkeys like Alt+Left and Alt+Right to swtich between workspaces. The left Alt works for this, but the right alt is a lot easier to hit on my laptop, so that's a bummer.

I've remapped my RAlt to LAlt to fix this temporarily.

@Decidetto I absolutely agree, it's an obvious thing to do in game but it's wrong for testing software (assuming full range of motion is supported).
I hope full-range will be supported so much :)

Enabling zoom on alt or shift in settings causes a crash on windows. I also toggled squishy windows and a few other settings before it happen. However, once it did, it would crash all the time when I would start picotron. Had to remove picotron save folder in appdata to regenerate it.

Also no way to link picotron from humble to here.

System: macOS Sonoma 14.4 (Intel)
Issue: Picotron closes on its own with no error after 14 minutes.
Version: Picotron 0.1.0B

The following is the Terminal output when running Picotron:

2024-03-15 14:59:52.354 picotron[1662:115750] WARNING: Secure coding us automatically
enabled for restorable state! However, not on all supported macOS versions of this
application. Opt-in to secure coding explicitly by implementing
NSApplicationDelegate.applicationSupportsSecureRestorableState:.

The output is produced upon running Picotron, however, there is no output when Picotron closes on its own.

Random crashes in 0.1b. Just letting it sit with the Screen Saver choices up, with one chosen, waiting for each one to start crashed it 2-3 times.

Instruments don't sound the same in the synth editor as the patterns. Seems like it works fine until they are not being played, and the release is not processed real time but per step. changing speed affects the sound

bug:
paste this code into a fresh cart and run it; picotron hangs for a second and then crashes to desktop:
local x=1+vec(1,1)

obviously this code is wrong but it should show an error ("cannot add float to userdata" or something) instead of crashing, took a bit to track down
(running on linux, picotron_0.1.0b2_amd64)

@pancelor: You can add a float to userdata, though! Scalars are broadcast across the array. That works fine if you flip the operands, so I assume this is an issue with how operator overloading is handled ... or perhaps arithmetic ops are intended to be non-commutative when userdata is involved and the error should be shown after all.

When i use load in the picotron terminal to load a cart from bbs, and after that use load again to load another cart, it won't change to the second cart i loaded, it seems that the cart in ram wasn't replaced when i load a new cart.Wonder is it a bug or just i didn't know how to use it correctly. After i move the previous cart in the ram i can load another successfully, but that seems not to be the best way.

@merwok

>this is an example of calling the store function with a path and data >(here remapping left Ctrl to key 57)

I thought it did the opposite, in fact it's remapping left Ctrl to key 57 and doesn't give lctrl the feature of key 57...

Anyway, it looks like the CTRL+Q (which I trigger when I type CTRL+A in reality on my azerty keyboard) is hardcoded and can't be intercepted elsewhere. If I remap lctrl to key 57, I can no longer copy with CTRL+C but it will quit picotron anyway if I type CTRL+A on my keyboard.

This hard exit (be it with CTRL+Q or by clicking on the X on a window) really should have a warning before quitting... I think I'll go back to the previous picotron release because I'm used to type CTRL+A on a terminal for going back to the begining of the line, and CTRL+A in a text editor for selecting everything... and the fact picotron understand this as CTRL+Q and exits immediately is getting on my nerves :(

My keyboard inputs are still not working properly.

0,1,2,3 is still L,R,U,D?

I'm getting weird diagonals. Sometimes my WASD keys work, sometimes they don't. Arrow keys are given different results every time I boot up.

create_process can result in code not working when mounted — it can run .p64 and .lua but it can't run /ram/cart as it's missing the extension. This allows using create_process with "." as the argument to let a program run a new instance of itself, but only when running from the gui, otherwise it rejects the valid folder based on extension alone.

edit:
I currently get around it by always having my program copy itself into ram with the full file extension

hey there! super excited for this project, I bought it immediately lol. Anyway, I've been having an interesting issue where anytime I load 2 carts from the bbs in one session, it will only ever actually load the first one.

for example:
1: I load #example-0, run it, it's fine
(I also usually save carts so that may have something to do with something?)
2: then I'll load #something-1, run it, and it's the #example-0 cart I just loaded. When I check the code, it is also the same.

I got around it by simply restarting picotron anytime i want to load a new cart from bbs.

sorry if someone already posted this issue, i only skimmed the bug reports up to this point

I just got Picotron today, managed to get it working on my laptop just fine, but when trying to get it to work on my desktop I get this error.

This is after a fresh installation too so I cant figure out what is wrong, Im using windows 10, and have windows defender turned off, and Avast has it added as a safe program. I have also tried using both the installer and the zip downloads to get it to work but no luck :(

Instrument editor, Documentation mentions three parameters for LFO: frequency, phase, and function (wave form). The LFO envelope only has inputs for frequency and phase.

I can reproduce this consistently (in Windows) by:

1. Copy some text to the clipboard (e.g. from notepad or the Pico-8 editor)
2. Run Picotron
3. Load a cart
4. Switch to the code editor
5. Select a block of text
6. Press Ctrl+V

If you delete the selected block of text before pasting it works fine.

Quite cool that you can view the editor source code btw.
I tried inserting a delete_selected() into insert_multiline_string(), but I'm not sure how to make picotron use the updated editor code.

@Mot The documentation mentions a startup script — not sure if that's implemented already, but if so you could probably use it to kill the default editor and run your modified version automatically
https://www.lexaloffle.com/dl/docs/picotron_filesystem.html#Startup

The ceil function is missing.
The editor highlights it in green, like flr and other built-in functions, so I assume it's intended to be there.

isn’t it in the math table?

The map editor draws sprite zero along the right and bottom edges, just past the bounds.

While we're here, a button to "return to centre" would be nice, for jumping back to the map if we get lost.
Middle mouse should pan the map+sprite editors like in PICO-8, it seems that is missing here?

@merwok I see. That makes sense.
(I was thrown off by the syntax highlighting, and that flr is a built-in global function :-) )

Clicking the mouse outside of the top-left quadrant of the screen in video mode 3 exits the user's running program. Something similar seems to happen in video mode 4.

Screenshots taken in video mode 3 also don't look right - they only occupy the top-left corner of the image.

Hi! The whole localization thing seems to be an issue-my german keyboard is not much use, opening a curly bracket captures the label image(lol). A fix would probably be easy-ish, "just" get the host systems keyboard setting and that should be it. My undo and redo options are also qwerty rather than qwertz.

Flip does not work for Spr when sprite is clipped:

function _draw()
  spr(1, -8, -8, 1.0, 1.0, true, true) -- flip x and flip y
end

Instead of flipping and then clipping, it is the other way around.

Sprite 16x16:

Actual screen:

When a program creates another window or just runs any different program, focus is not given to the new window (at least visually)

When typing accented letters (such as in French), instead of typing for example é, picotron will display 2 square boxes, like ▤▤

Something when writing some code, we can accidentally trigger such letters, but the fact there are 2 characters makes it tedious to erase them: the cursor then will place itself between the 2 boxes and you have to backspace the first one and erase the second one.

Expected behavior

picotron should display utf-8 characters, or if it's not possible, display a "degraded" letters (é->e, ù->u), or if it's not complicated, not trigger anything when typing such a letter.

https://github.com/ace-dent/picotracker/issues/9

I have been messing around with this on my laptop now and love it so far! There are some things it isn't doing as I would like but I saw that I can edit the scripts for all the tools and OS and so can make little tweaks. I was messing around with adding something to the tooltray and added it to the startup script, but for some reason when restarting, the code I wrote was now gone from the tooltrays folder, nowhere to be found, and the startup script had reset. I saved both but I'm not sure if I did something wrong.

I and others have noticed that Picotron (0.1.0b) will crash silently, frequently, for no apparent reason on MacOS Big Sur (11.7.10 in my case). Is there a log or something to check?

I am getting lots of silent crashes on macOS Monterey on a 2015 15" Macbook Pro.

@dmorris
There is a log now but it's not very helpful

• You will crash after a while due to a stack overflow, every time, this one shows up in the log
• You will crash when trying to index or call nil values basically 90% of the time, this doesn't seem to appear in the log

Don't save and immediately run the program, if it happens to crash picotron at the exact time it seems to be able to corrupt the cart, happened to me once
If you feel like you've been using picotron for a while probably just restart it before it inevitably crashes in the middle of writing something

System is read-only at the moment, correct?
Changing the background to a custom cart saved in "system/wallpapers" and shutting down Picotron causes the window manager to crash on start, can be resolved by opening System Settings and changing back to a built-in background, then rebooting.

I saved a cart to a folder on the desktop, and that seems not to have saved even though the folders I created afterward persisted.

Use of bxor(a, b) for any a,b immediately crashes Picotron. (0.1.0b, OS X 13.6.4, Intel)

Love where this is going though -- looking forward to getting back into the Pico world.

A few I've found in 0.1b running on Linux Mint 21.3:

• Using the terminal to move a file to a path that doesn't exist deletes the file
• Creating the themes, screenshot and wallpapers folders for custom content hides the default content in system settings
• Delete key doesn't delete on the desktop or in filenav

Instrument editor: For fields that refer to frequency, I'd like to see the data displayed in Hz. For fields that refer to duration, I'd like to data displayed in milliseconds. I don't care so much about about the values of the underlying byte data. I want the data displayed in units I understand.

I know there is the "load #cart-1" command from within picrotron, but is it possible to just save a cart from the forum, copy it inside the picotron folder, and run it from there, like we did with pico-8? When I load such a cart I get errors.
(EDIT: ok just found out: when uploading through submit, the displayed png is not containing the code, or there is a bug. If people attach their own .p64.png in addition, this png can be loaded into picotron)

I had an issue with a project that had a really big file size

I managed to make an orthogonal projection 3d renderer (my first time attempting anything resembling this, so it probably wasn't very efficient at all). I programmed an obj file parser to test it out. My model of choice was the utah teapot which I saved inside the cart data (206 kb, you can probably see where this is going). each time it took a very long time to run the parsing function, which was inside the init function. first suspicious thing was that while init was slowly chugging along, I could still interact with the code editor. I don't know if this is intended behavior but there ya go

It ran fine for the most part, for the first 5 or 6 times I ran it (I was iterating on some changes, but it worked!) But eventually, I either ran it, tried to save it, or maybe did nothing at all, and it gave me an error that I didn't have time to read properly (it had the words "out of memory" I think, but that's all I remember), and crashed. Next time I opened it and tried to load the cartridge with the data of the project I had been working on, I found that the cartridge was completely empty. Maybe this is intended behavior, but I have a suspicion it's not lol
;^;

(incidentally if anyone can think of a way to recover the file, that would help me a lot lol, but I assume it's beyond recovery at this point)

there are some bitwise operations such as bnot etc which were available in pico-8, but not in picotron, maybe there are other way to use them?

When using the map editor, if we have a 16x16 sprite, it will adapt correctly to the map, but with a 8x8 sprite, there will be gap between the tiles, and I can't find a way to change this (ideally, it should change the pen size to the size of the sprite)

the map editor seems also to have problem to correctly zoom to a dedicated area. If I point to arrow to an area and zoom in with the mouse, it will zoom to the top left of the map no matter what I do (we can navigate with arrows though).

Another fun one I found is that when changing sprite sizes in the GFX editor on Linux, you can't use num pad enter.

More linux fun bugs:

• Adding an FX node causes the background to darken
• Adding a second FX node causes the background to flicker