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

Mac OS

CMD+H puts Picotron in backgorund (is this a bug?)

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

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