On fullscreen, sometimes this happens, other times not.
(I'm talking about the red bars)

I'm going crazy trying to understand why but what I noticed is that it always happens when I test this at boot.

Here's a screen of 20 minutes ago when it didn't have red bars:

This is a bug I had with other beta stage software on my MacOS 12.5 intel

In my case it is not pixel-perfect on a MacBook with retina screen.

related to last issue i reported: when i press mod4+F to tell my wm to fullscreen, picotron also responds to that and brings up the search input

besides that, if i press mod4+A (which isn't bound for my wm), it interprets it as both an A key press and a ctrl+A key press at the same time

and ctrl+1 also inputs a 1, but ctrl+A doesn't input an A

On safari (on MacOS 14.4.1) , the embedded web player doesn't lock the arrow keys, so when you're playing a game with the arrow keys the window keeps scrolling up and down

CMD + W picotron closed unexpectedly...
Also I lost 4 hours of work today... It was all fine when I left it.
Then I came back and my cart's content was empty! I would've lost everything if I didn't have a backup elsewhere... so this is kind of a huge bug I guess, I hope we can bypass this issues with backups in 0.1.0f

EDIT: Again, picotron casually crashed after hitting "right shift"

Just got picotron. I was experiencing with the picotron_config.txt file on linux. I wanted to see what would happen if I mount an empty directory to the system directory.

And it looks like it copied the system directory into that empty directory and in the picotron console it shows two system directories exist:

That seems wrong :D...

MacOS 14.4.1 (arm), Picotron 0.1.0e

Option-Left/Right to switch the Picotron workspace doesn't do anything in 0.1.0e. It used to work in an earlier version.

Also the documentation for the mount config is wrong. The arguments are swapped and ~ doesn't expand to the home dir

Windows 11. Picotron 0.1.0f closes at launch.

Edit: I managed to launch it removing the picotoron_config file, Looks like it has problems with my previous version mounts

0.1.0f boots to an empty workspace rather than the desktop. Reboot does the same.

Windows 11

Thanks for the update @zep! F is finally out!
Screen width is fixed with HIGH dpi on Mac OS 12.5! but fullscreen still has those strange red bars at the top and bottom of the screen...

Another thing worth noticing is the same Empty Workstation everyone is getting at boot. On the toolbar there's 2 desktop icons, and if I click on the deselected one I see the normal desktop with no bugs whatsoever:

And once I double click on Picotron's window bar (the one on top where it says Picotron) to have the program in a big window, doubleclicking again to get back to a small windowon doesn't work! I have to close and reopen Picotron to have that nice small window.

But they're not big bugs doe, and the new features I tested seem to work nice! Great work Zep.

0.1.0f Windows 10
PNG import leaves a bit to be desired when you're not using something with lots of flat colours. I know there's probably a squillion ways to palletize an image but the current results are quite dodgy.
I'm not asking for auto dithering or anything but something's definitely up here. I'm getting flashbacks to that one horrible time I wrote a BMP parser.

For example...

Input:

Result:

(Ps. Unless I'm wrong, the BBS doesn't like POD GFX)

0.1.0f running on Windows 10:
The RSHIFT Magnify feature renders black pixels as transparent:

Happy 0.1.0f Day to all those who celebrate.
At any resolution, the top control bar obscures the very first line of the terminal screen. Tried playing with all video settings but same behavior. Fairly certain I wasn't seeing this in prior releases.
Running the Linux build on Arch x64.

Quick update: seems very intermittent. Switched between desktop environments and having trouble reproducing now.

In the 0.1.0f docs, the mouse_y is present twice at different places (2 and 5):

mouse() Returns mouse_x, mouse_y, mouse_b, wheel_x, mouse_y

Not a bug but annoyingly in the latest update (v0.1.0f) changing the number dialog boxes with the mouse makes it difficult to see the number as it's covered by the cursor and it moves so slow.

Running 0.1.0f under Windows (10) with a dual monitor setup.

When you full-screen on the non-primary monitor (both monitors are 1920x1080 but primary monitor is 125% windows scaling), it truncates the right and bottom parts of the screen (no icons in top-right demonstrates this).

Was fine under 0.1.0e

this became unresolved again as of 0.1.0f: https://www.lexaloffle.com/bbs/?pid=144623#p

edit 2024-07-22: resolved in 0.1.0h

0.1.0f Win 11
I checked my game foxrun and pressing cursor up or down seems to register twice whereas pressing "w" or "s" does not. This is using keyp().

Not sure if this is the right place, but in the picotron manual, there's a typo in section 5.5 (input).

Button 4 is skipped, and button 12 is listed as both "Buttons (not named yet!)" and "Secondary Stick". Seems to be the case in both the .txt and .html manuals. The buttons are correct if you start from 0 and count them as listed :)

not sure if this is considered a bug, but i am having problems with the view being extremely off centered in the sprite editor, and it is a pain to try and scroll back to the center. what i think might be a bug is that it's different from sprite to sprite... if one sprite is selected and centered the next one is way off center, and if i then scroll back on that one, it is off center in the first.
this happened I think after dragging in a large png.

macOS 14.4.1 (apple chip)

I discovered what caused the bug in my game in 0.1.0f

My game was written in 0.1.0e and at first only had keyboard code like this

if keyp("up") then move_fox(-1) end
if keyp("down") then move_fox(1) end

Then I added controller support like this

if keyp("up") or btnp(2) then move_fox(-1) end
if keyp("down") or btnp(3) then move_fox(1) end

this is called in _update() every frame. Now btnp(2) will return true if a controller is pressing up or the "up" key on the keyboard is pressed so I was checking everything twice but in 0.1.0e on the next frame both would return false

if we look at the changelog for 0.1.0f

Fixed: key() / keyp() returns false when received keyup and keydown messages in same frame (should be true for 1 frame)
Fixed: keyboard btn() responds to keypress one frame late

Now the keypress event recorded with keyp() and the keypress event recorded with btnp() are returning true on different frames and it caused my code to receive the event twice.

I fixed it by removing the redundant keyp("up/down") code.

Found a bug in 0.1.0f:

mouse clicks in vid(3) don't seem to work as intended. They only register on the top left part of the screen (in a space that's half of the resolution) I wrote the following snippet to demonstrate this. Additionally the cursor is missing. If the option/alt key is held you can see the cursor disappear into the rect I drew in real-time.

function _init()
	vid(3)
end

function _draw()
	cls()
	rect(0,0,119,67,1)
	print("\n"..mx.." \n"..my.." \n"..mb,mx,my,7)
	line(mx,my,mx,my,7)
end

function _update()
	mx, my, mb = mouse()
end

EDIT: Good news! Zep said a fix will be in 0.1.0g. Also thanks to nephilim for finding this!

After installing 0.1.0f on Windows 11 I get this:

clicking the second of the two desktops does seem to fix it until relaunch, but very odd!

I tried uninstalling and reinstalling a couple of times, rebooting, deleting the appdata, but can't get it to stop.
I'll go back to 0.1.0e for the time being.

Macbook air MacOS 12.5 intel
Picotron 0.1.0f

Crashed suddently after hitting "CMD+Q" even if I have it turned off in settings (I have this issue since the first picotron release). Also crashed after hitting right shift earlier today.

idk if this is a bug, exactly, but file paths can have any number of /'s in between directories

when we do i.e.

clip(120,0,240,270)

without specify(add) vid(0) first, #picotron crash and close. Anyway it is important to specify the vid(0) or (3) or (4) at starts of code when do fullscreen.

I've also just started getting the dual desktop icons and the cursed pointer (Windows 10) when I start Picotron, clicking any of the icons fixes the problem until reboot

Also (not sure if this is a bug)
I saved my cart as a .p64.png with edited icon and description/info then edited the code and saved again, the icon and info did not save to the cart on the second save.

I've hit upon a bug in gui_ed.lua (version 0.1.0f).

Setting up key_callback for "generic keys" causes a runtime error. This code snippet

gui:attach_text_editor {
	width = 100, height = 100,
	key_callback = {
		enter = function()
			t:set_text("enter was pressed")
		end,
		a = function()
			t:set_text("A was pressed")
		end
	}
}

causes the error below when pressing the 'a' key:

Line 1070 in gui_ed.lua is:

1069:	if (type(content.key_callback[k]) == "function") then
1070:		content.key_callback(k)
1071:	else

Hitting enter works as expected. I guess the fix is quite easy, something along the lines of

- content.key_callback(k)
+ content.key_callback[k](k, text)

https://www.lexaloffle.com/bbs/?pid=147549#p I uploaded a cart here (as a reply, not as the start of a thread), but it isn't being played by the BBS web player. it shows the right preview but it's playing a different cart from the same thread instead

I am not able to select any layers greater than 7 in the map editor. I looked in the code for map.p64 and see no hotkeys to change the selected layer. This is problematic because you cannot scroll in the layer select window in the map editor. Additionally, you cannot even select layer 8 as it resides under the GUI buttons.

I was able to add these hotkeys to map.p64, but my way was very clumsy. Is it possible to get this issue rectified? This is on 0.1.0g on MacOS.

-- in map.p64::update.lua

	if keyp("l") then

		if current_item <= 32 then
			set_current_item(current_item+1)
		end
		refresh_gui = true
	end

	if keyp("k") then

		if current_item >= 1 then
			set_current_item(current_item-1)
		end
		refresh_gui = true
	end

stop(txt) doesn't print out the text when called during _update(), only in _draw(). It will still stop the program, but without printing out any text that might have been passed in as a parameter. Inside _draw(), it works as expected.

010g on linux:

• notify(123) freezes the workstation
• pressing alt-tab is inserting tab characters into my code; I fixed it by editing /system/lib/events.lua, changing if (msg.scancode == name_to_scancodes["enter"][1]) accept = false to if (msg.scancode == name_to_scancodes["enter"][1] or msg.scancode == name_to_scancodes["tab"][1]) accept = false
• pressing enter when editing a value using podtree crashes b/c of some variable name shadowing (/system/apps/podtree.p64/main.lua -> if(key("shift")) return true (key has been overidden))
• mget(-1,-1) returns nil; I think it should return 0 instead. This would mirror mymap[1].bmp:get(-1,-1) and would also match pico8 behavior
• save /folder/does/not/exist.p64 is misleading -- it looks like it succeeds
• print(true,0,0,7) doesn't work? odd. print(true) works, and print(tostr(true),0,0,7) works too
• hitting a runtime error doesn't stop music playback
• when calling ord with 3 params (ord(str,index,num_results)), num_results is ignored and index is used instead. for example, foreach({ord("123456789a",5,2)},print) prints 5 entries starting at index 5, instead of 2 entries starting at index 5

Soak test fail: 0.1.0g crashed after launching, sitting on the desktop, and waiting like 30-40 minutes. Was on separate desktop when it crashed.

MacStudio M1,Sonoma 14.4.1 (23E224)

MacOs 12.5 intel - Picotron 0.1.0g

Sometimes keyboard input doesn't work in music editor.
It has been like this since a couple updates ago but I was waiting to have a hint for better bug reporting. But still I can't understand why.

If I quit Picotron for 20 minutes or so then everything is fixed, but later, it randomly gets broken again

Picotron becomes bugged out everytime I paste-in more than one (big) pod sprite inside the code editor!

I was working on a dinamic wallpaper (which had to be 480x270)
I copyed it from the sprite editor, pasted it in the code editor and everything all right, then I do the same with a second one and everything gets bugged out as soon as i move around a bit.

Strange bug I found with the split function

print(split("123","")[1])

prints 65536.0 instead of the expected 1
This happens whenever the separator is an empty string and convert_numbers is true.

Windows, 0.1.0g:

btnp(4)/btnp(5) return true in the first update if they have been used to select the "Reset Cartridge" option in the cart pause menu.

Not a huge issue but I've got to hack around it so the default item on a game's main menu isn't selected after resetting the cartridge.

MacOS 12.5

Picotron 0.1.0g crashes when trying to open a ".png" file with the code editor... I know this isn't something you should do, but instead of crashing I think it should print an error message

This is a lot to read through. Is there any place to read a list of reported bugs so I don't make a duplicate report?

Windows, 0.1.0g:

multiline strings don't get special characters inserted properly.

print([[line a \135
line b \133]]..
"\nline c \140")

will print:

line a \135
line b \133
line c 😀

@SophieHoulden It's like that in PICO-8 too, I'm not sure if it's intentional.

@TBMcQueen Eh, you could probably just read the last page or two, the thread is moving slowly enough that anything beyond that was posted months ago and so is either fixed or could use a reminder that the bug is still there.

picotron 0.1.0g mac (arm)

The picotron screensaver activates if I'm actively using the gamepad but don't use keyboard or mouse

Picotron 0.1.0g
I don't know if this can be considered a bug, but I just found out that the load #bbscart command doesn't immediately work on startup.

If I run it as soon as I open PT, it takes more than 60 seconds to load the cart into ram.
After that minute running the load # command loads the bbs cart immediately

I did save /desktop/#cart.p64 in the terminal and instead of telling me that I cannot use symbols in filenames (because of #), it just saved that file but it cannot be managed by picotron's filenav.
I cannot rename nor delete it.
If I try moving it in another path I get attempt to index a nil value (file 'fullpath') and it glitches the filenav. Everything good if I delete it from OS doe!

Picotron 0.1.0g
As pancelor noted "fget(x,num) -- the num arg doesn't do anything, unlike pico8"

The manual states "fget(n, [f])" yet it currently always returns a bitfield even when a flag is supplied.

This seems to be a common issue that people are running into on discord. We can currently work around it with something like fget(spriteNum) & 0b1<<flag!=0. However parity with pico8 would be ideal.

Not exactly a bug but you might want to note in the manual that if your multiline comment includes embedded POD stuff it should be formatted as

--[=[
COMMENT AND POD DATA HERE
]=]

Another "not really a bug but..." post.
I understand why the default music pattern is set up that way but it might be better to only use half (or 3/4 of) the channels by default so that newbies don't get confused why their sound-effects (using note()) keep interrupting the music, especially if they're only using 1 or 2 channels on the left.

@TickedOffJosh I believe that Picotron actually has 16 channels available, so I don't think the 8 that the music channels use will really be that much of an issue.

In 0.1.0h:
When I tried to add nil to a vector, I got a crash (Picotron hangs for a just a second or two, then closes).

I can consistently get it to happen by running this:

crash = nil + vec(1) -- crashes

It doesn't happen if I try to run the statement without assigning it to anything:

nil + vec(1) -- syntax error

Or if it's a normal Lua datatype:

crash = nil + 1 -- syntax error

I'm on Linux.

When running from the shell and getting this crash, I see this message:

Picotron Workstation OS 0.1.0h (c) Lexaloffle Games
https://www.picotron.net  //  build: 240720-033214
fish: Job 1, './picotron' terminated by signal SIGSEGV (Address boundary error)