Log In  
Page:
1
2

A new year, a new fantasy machine! Picotron Playground is an experimental web version of Picotron's WIP runtime and API, bundled with a terminal and code editor in order to make some toy programs. You can read more about the goals of Picotron and its specifications in the FAQ:

https://www.lexaloffle.com/picotron.php?page=faq

Although I'm still mostly occupied with PICO-8 and Voxatron, I hope this will be a good way to chip away at the project and let future users try out the API in a low-stakes way before it is ready to go into production.

Launch Picotron Playground here:

https://www.lexaloffle.com/picotron.php?page=playground

Note: you'll need a US layout keyboard and there is no permanent storage, although the clipboard does work if you want to store some snippets. Please work on anything larger than toy programs at your own risk!

Running Demos

Demo programs will appear (and probably disappear!) over time to try out various API functionality. At the moment they are mostly simple graphics demos that can be loaded via the terminal:

/$ cd /demos
/demos$ ls
/demos$ load dots

CTRL-R to run it.
ESC ESC to get back into the editor
CTRL-L clears the screen (important!)
The "reset" command can be used to get the default palette back.

Using the API

The most interesting feature of Picotron's runtime is probably the gfx pipeline, which is documented here: https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html

If you'd like a quick way to load sprites, try copying and pasting from PICO-8 gfx editor and pass that as a string to userdata():

my_sprite = userdata"[gfx ... /gfx]"
spr(my_sprite, 100, 100)

There are some more examples of how to manipulate userdata in the FAQ.

Limitations

  • There's no audio yet.
  • There is provisional cpu cycle counting, but it is incomplete and infinite loops will still crash your browser. You can get the cpu with stat(1), but it currently also includes cycles used by system processes.
  • Some of PICO-8's more forgiving behaviors do not not exist [yet?], including being able to divide by zero, and automatically converting floats to ints.
  • The code editor is still a bit janky. Sorry!
  • btn() works but just for a placeholder P1 6-button layout.

I think that's enough to poke around for now. If you have any questions please post them in this thread or ask me on mastodon as there isn't a Picotron sub-forum yet. I hope you enjoy it!

P#123355 2022-12-31 15:33 ( Edited 2022-12-31 16:08)

3

Th😍nks!

P#123362 2022-12-31 16:40 ( Edited 2022-12-31 16:40)
3

This is pretty cool, I'm looking forward to seeing this develop more in the future!

P#123363 2022-12-31 17:30
3

Looks great, @zep. Gold star obviously.

Full instruction page please - like this one ?

https://www.lexaloffle.com/dl/docs/pico-8_manual.html

Also ability and all command sets for loading/saving/importing/exporting files.

. . .


Bug list or at least inconveniences I have discovered so far.

Text does not scroll. You must use your mouse 3rd button (scroller) to scroll the screen, for instance, if you type ls for directory when the cursor is at the bottom of the screen, it will scroll off the edge. Also, please add dir to do the same thing as Pico-8 accepts this and I am more familiar with DOS than Linux.

I am not seeing a Spritesheet, Map editor, SFX editor, or Music editor.

Holding down arrow key does not repeat when in source-code edit. FIXED: 01-01-23

Positive. Arrow keys do work for number keypad. Thanks ! Now if Pico-8 can have this. :)

Should be allowed to delete file if that is the current file. For instance, I saved a file, test as it was loaded I should be able to type delete or kill followed by the filename and provided it is in immediate mode and provided that is the same named file loaded, then the command would be carried out. Useful for maintenance as I didn't want to clutter the virtual directories with test files.

load (filename) immediately jumps to editor. I would make this optional as it is unknown behavior in original Pico-8.

reboot command not recognized.

No opening and audio logo. You deserve it, ZEP. Something nice like you have for Pico-8 and Voxatron. While I have always been against this, programming for years now in Pico-8 I see the use in it. Anyone who exports a game and sells it commercially is certainly allowed, yet your 1-second logo always points the player to whom wrote the system originally and that is very important I believe.

Printing a NIL variable shows two results. One very quickly, then it is overwritten by NIL. You can see this by loading from the demos, fillp Run it. Then type out something like ?aa You will see two values. The first is overwritten quickly by the words NIL. Also works with print(aa)

Just noticing your resolution is only 2-pixels off from the PSP (Pocket Sony Playstation) as theirs is 480x272 and yours is 480x270. Coincidence ? :) Actually these values seem arbitrary. How about 512x256 to match wide-screen telephones and computers today ?

help on commands does not work. Neither just help by itself.

Guys, to see all 32-colors try out this sample code:

function _init()
  cls()
  for i=0,31 do
    rectfill(0,i*7,479,i*7+5,i)
  end
end
function _update()
end

Nice selection of colors there, Zep !

Your command prompt is "/$" whereas in Pico-8 it is, "> "

This program does not run:

cls()
repeat
  pset(rnd(480),rnd(270),rnd(32))
  flip()
until forever

the DEL key on an empty line does not scoot the source-code up one line. (FIXED: 01-01-23)

This code ?0/0 gives a new string value of -nan

Visually in the editor there is no bottom information bar constantly leading me to believe that the screen is getting cut-off somehow as original Pico-8 has both a top and bottom information bar.

Pressing SHIFT L does not give you the equivalent ⬅️. Instead you get an uppercase L

You do not receive a warning that your code is changes when you load another cart. For instance, load any cart. Press ENTER in the source-code. Then load another cart. In original Pico-8 you get the there are unsaved changes - continue with load? In Pictron you currently get no warning whatsoever and it just loads the new cart replacing the edited old one, losing all work.

The cursor in code edit can definitely move off the edge of the screen vertically.

Variable _ is apparently in system use. If you type ?_ you get 27 when you boot. Load a cart, run it, that number changes.

The source-code is numbered. This is unknown behavior in original Pico-8 so I would make it optional.

12-31-22 4:13pm

This program will lock up the system entirely with no way out:

repeat
until forever

Additionally flip() seems to be acting as stop() as the program ends the moment the command is read.

Any chance of getting a parser ? a=parse("1+2*3/4-c") where c is just a normal Picotron variable and a will contain the numeric results.


Will I use Picotron ? Oh yeah, I'm always open to new programming languages, always.

12-31-22 6:31pm

My main interests will be:

  1. See a working FLIP.
  2. Ability to post and read online shared high-scores + data.
  3. More coding space.
  4. More sprite space.
  5. More mapper space.
  6. More SFX definitions. Having the ability to define 4-channel audio in a single SFX.
  7. More overall memory. I am not against bank-switching 4 sets of 64k.
  8. Faster execution for all commands.

  9. Mix resolutions. Current resolution is 480x270 with 64-colors possible per pixel, yielding 6-bits per pixel or 97200-bytes per screen. So you could have 360x270 with 1-byte per pixel giving you r6g6b6 true colors giving a number from 0 to 215 and taking the exact same space of 97200-bytes per screen. Or even more colors if you can set them individually via pal(n,c) or pal(n,r,g,b) r256g256b256.

  10. Supremely simple ways of adding PCM audio and being able to play them at any pitch without distorting their speed in addition to speed control (playback rate and/or repeat set number or infinite and from back to beginning or continue in chosen middle section. Useful for Pan Flute for instance).

  11. Any suggestions deemed good I made for Pico-8 that could not be done earlier for whatever reason can now be considered for Picotron.
P#123368 2022-12-31 18:36 ( Edited 2023-01-02 00:38)
7

exciting !!

edit: okay, I've played around a bit now. it's rough and early, but usable. I'm mainly using an external editor for now (because of crashes), but this is still so exciting! I love the new colors

here's a program to list the available functions/tables, if others are interested: https://gist.github.com/pancelor/0489fc0671cc566db24ee737af4f94c3


The three main pain points for me right now are:

  1. I have to press space every time after pasting, or the editor doesn't seem to realize that the code has changed
  2. two different times while loading and running through the demo programs, p64 froze and the firefox console showed:
    > Uncaught abort("Cannot enlarge memory arrays to size 134238208 bytes. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 134217728, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows increasing the size at runtime, or (3) if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0 "). Build with -s ASSERTIONS=1 for more info. [p64_playground_2.js:1:1106765]
  3. sometimes errors show up in the firefox console instead of the p64 console, e.g. try running this cart:
    function _init()
    print(notdefined.thingy)
    end

    (remember to press space after pasting)

P#123370 2022-12-31 18:38 ( Edited 2022-12-31 21:37)
3

SO. EXCITED.

P#123382 2022-12-31 21:04
1

Quite useful, @pancelor. Thanks !

Check out "draw_text_masked" it's identification is all over the place !

P#123384 2022-12-31 21:55 ( Edited 2022-12-31 21:59)

this looks like a 64-bit sequel to PICO-8

for myself, i don't see the point in this, because i already chose PICO-8 over TIC-80 because i like how PICO-8 has more limitations. it's the same with Picotron

i always want either PICO-8's limitations or the standard game engine's freedom, not this weird middle thing

i can see why other people are excited for Picotron.
i am not in the target audience, and that's okay

P#123389 2022-12-31 23:23
2

So glad to see this. What are the plans for the PCM sample rate?

P#123391 2022-12-31 23:31
5

After a lot of data mining from Picotron's code, I managed to extract the internal playground.p64 cartridge! https://cdn.discordapp.com/attachments/854747514044809266/1059005058227908639/playground.p64

Very interesting format, it seems that Picotron will store everything as hex dumps, including Lua code.

After I figured out the format (and converted a ton of hex dumps), I managed to make a copy of Picotron's filesystem as a zip file: https://cdn.discordapp.com/attachments/854747514044809266/1059012784370757653/picotron-playground.zip

The demo .p64 carts were converted to folders as well. Hope these come in handy for anyone wanting to get a look at Picotron's internals and learn more about the API!

UPDATE: Made a script that automates the extraction of a .P64 file! https://gist.github.com/HTV04/4b61339441a02c9aea31ccecee24e064

P#123421 2023-01-01 07:52 ( Edited 2023-01-02 06:12)
3

I already gushed on socials about this, but somehow forgot here.
Thanks @zep for giving us an early build to play with - ❤️ it already! 😊

P#123423 2023-01-01 09:53
5

Thanks everyone!

I'm traveling rn, so can't respond to everything but just a quick note that v4 is up now and fixes some of the more annoying editor jank + @pancelor's first 2 pain points.

P#123438 2023-01-01 17:09

Serious error, @zep. RESOLVED

Start up Picotron. Press ENTER once or many times. Imagine these lines above are code you typed. Now press CTRL+Z. The editor will completely hang. You will lose all the work you've done to this point.

I lost my work a few times pressing CTRL+Z on a blank while working on new code in it.

P#123445 2023-01-01 18:55 ( Edited 2023-01-02 01:47)
1

I just wanted to say thank you so much for this. If picotron manages to keep the lovely developer community of pico-8 I'll be glad to switch.

Thank you again. Hope you have a great new year.

P#123447 2023-01-01 19:01
1

Thanks @dw817 -- this was happening when undo caused the cursor position to go out of range. I've fixed it in v5 (which also stores the cursor position with undo points)

One random thing -- I also don't like the feeling of not having a bottom bar for that reason! It is going to be there as a standard wm component (for showing system messages, drag up to see history etc), but for now I've put in a visual placeholder.

P#123461 2023-01-01 23:42

Hi @zep !

How are ya ? :D

I also found that if you do too big a number, it also hangs completely.

Try ?2^32

Functions seem to be working now.

The classic, "static" test code gives weird results in Picotron.

function _update()
  for i=0,269 do
    for j=0,479 do
      pset(j,i,rnd(32))
    end
  end
end

The screen sorta flips around but not a nice smooth static scene.

You must press ESC twice instead of just once after running code to return to source-code view.
This is true even if your code ended normally in command mode.

Another problem, pasting source-code from any editor truncates blank CRs, try this:

-- Doesn't do much,

-- but does have a blank line between. Or it did.

Copy, now paste that in Picotron. It will truncate every blank line. Not good ZEP as I use that for separators for information usually.

-- author
-- date written

-- explain what code does

-- describe each line giving a blank cr after the programming line.

-- describe and detail each function using a blank line prior to information.
P#123462 2023-01-01 23:49 ( Edited 2023-01-02 01:53)

AHH i'm so excited :) love it so far
but whenever i paste it pastes zxc instead of literally anything i copy might be my fault :\
(ok fixed that it's chrome clipboard permissions issue according to @TracyDMcGrath )
also there're caps!? which means i can't do heart emoticons :(
(thanks dw817)
|
V

P#123472 2023-01-02 02:16 ( Edited 2023-01-08 19:51)
2

No worries, @Ummmm_ok.

Try this code out in Picotron:

function _update()
  cls()
  ?"-- I \135 Picotron --",192,120
end
P#123474 2023-01-02 02:21

@bikibird I'm also wondering about this. It appears a lot of the specs are 2x-ish Pico-8's, so hopefully it's at least 11.025KHz!

P#123480 2023-01-02 04:11
5

I threw together an aseprite-to-picotron sprite exporter: https://gist.github.com/pancelor/43512028087bf34e5d9773a61a03f93a

P#123482 2023-01-02 04:24

The new cartridge format looks like it'll be harder to use with an external text editor. Will there be a way to expose the "unbundled" version of a cartridge to the host OS?

P#123493 2023-01-02 05:46

Are we not supposed to have access to this at the moment? I had to boot the terminal from the terminal and it opened as a window in the desktop. Doesn't seem to allow anything new, just makes it a window you can drag around (and delete).

P#123492 2023-01-02 05:49

Another serious error, @zep.

Start up Picotron.

Copy this code including the asterisks.

-- ****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
--

Paste that at the top of the source-code editor for Picotron. Press ENTER. Now press the LEFT arrow until you are viewing the far right of the asterisks in the long remark. The cursor does not appear. Try clicking in the * field to make it appear.

Whole system hangs completely.

This apparently occurs for any programming line that is at or exceeding 6640 characters.

P#123495 2023-01-02 07:01 ( Edited 2023-01-02 07:10)

Hi @pancelor.

How do I run your LUA file ? Can it be done in CMD.EXE ?

P#123496 2023-01-02 07:10

@dw817 you'll need aseprite; I updated the readme to be clearer. aseprite can run scripts from the commandline I think (see their docs) but you should probably wait until picotron matures some more to make anything large with it

edit: the file is an extension/plugin that only works in Aseprite -- you can't run it on its own

P#123520 2023-01-02 18:27 ( Edited 2023-01-03 02:37)

Ohno, @pancelor. I apologize. I wasn't clear. I mean how do I run files that have the *.LUA extension in them for my Windows 10 ?

Asesprite appears to be a sprite editor, not a programming language.

https://www.aseprite.org/download/?itch

P#123521 2023-01-02 18:30 ( Edited 2023-01-02 18:31)

Adding a seeming error, @zep.

In immediate mode type:

a=0
b=ord(chr(0))

if you PRINT A you will get zero as you expect.

Yet if you print B you will get 0.0 (zero point zero). Which is entirely different.

I'm understanding you are wanting to have a separation of integer values from floating point yet ORD will never return a fractional number - so this is something that could be corrected.

Additionally you have other commands that immediately go to floating point that are not needed. Suggest you do not make number floating point unless 0.0 or any other number with a fraction attached to it is added, subtracted, or in any way modifies a variable that is already keyed for integer. In fact I would key all variables as integer unless otherwise specified - for speed and memory savings.

flr(a) is another example. While 1.5 does get converted to 1.0 it is still fractional whereas flr() truly is for integer results.

Likely there are other places too where floating point is not desired.

I WILL tell you now I like the scope of numbers ! :)

Much larger than Pico-8, yet even here you can crash the system.

Try in immediate mode, a=2^31

Well that's it. You crashed the system.

Reboot and restart. Now try this. a=2^31-1

That works. You can print a and see it has the right value. So what happens when you add one ? a=a+1

It doesn't crash. In fact it accepts it. If you did it again, a=a+1 that is also accepted, so apparently 2^31 is not the upper limit, yet something is causing it to crash in calculating near where that limit may be.

. . .

printh() does not seem to work. Also when you post a glyph from original Pico-8 thus typed in immediate mode:

printh(chr(130),"@clip")

[8x8]

Which is the cat you remember. If you press CTRL+V in Picotron you get a mess, 4-unrelated characters.

So this, too, I think needs to be remedied so Pico-8 can communicate its code to Picotron and back again.

P#123527 2023-01-02 19:31 ( Edited 2023-01-02 20:02)

Congratulations.
Picotron has become a command prompt, but I am grateful that I can execute commands like pico 8"? stat(1)".
I'm looking forward to the completion.

P#123584 2023-01-03 05:40
4

So it turns out we can just look at any of the .lua files even from within the playground. Thanks @pancelor for finding that list of functions. It's great seeing @zep's comments and ideas in here. I can't wait to see more of Picotron!!!

P#123669 2023-01-04 19:30

so exciting , also thanks zep love u <3

P#123683 2023-01-04 21:41

Excellent job on getting a demo of Picotron up and running, zep! And what better time than the new year! I've been playing around with it for a little bit, and while it's been fun, I have noticed a few things that bug me about it.

  • sgn(0) == -1. Oops! After looking at api.lua for a bit, I discovered why. (Actually, I looked at the file first, THEN realized that this problem existed, but it sounds better in writing the other way around.)
    function sgn(a)
    return a > 0 and 1 or -1
    end

    Do you see it? If a==0, then not a>0, so we return -1. PICO-8 returns 1 instead, and most other implementations of sgn return 0 in this specific case. As Picotron is intended to be more 'modern', it's impossible to tell whether it will continue PICO-8's conventions of returning 1 or join the masses in returning 0, but I think we can safely rule out this behavior as the 'intentional' one.

  • On a similar note, abs returns negative zero if a==0. While you might not think this matters at all - and if you use integers it doesn't - if you input 0.0 it uses floating-point, a system which - unlike its fixed-point precursors - includes -0.0. Considering the point of abs is to get rid of negative numbers, having it create negative numbers - even if it's only in situations like this - is undesirable. For reference, here is the code responsible:
    function abs(a)
    return a > 0 and a or -a
    end

    The solution to both of these problems is to either use >=, or to use < and swap the two possible results.

  • Unlike PICO-8 with its (mostly) idiot-proof API functions, Picotrons API currently lacks that, so - for example - max("Blah",nil) will result in a runtime error. This will probably be ironed out later, but I wanted to mention it here anyways. (Also, string-based functions like sub have the decency to do this which makes situations like this a little bit bizarre and inconsistent.)
  • Also unlike PICO-8, whose official documentation was comprehensive and unofficial documentation even more so, Picotron currently does not have such rigorous documentation, and as such it's difficult to determine, for instance, that string.format("%.4f",stat(1)) can be used to display a set amount of decimal digits of a given floating-point value outside of looking through the demos and doing a little bit of guesswork based on the usage of them there. Again, it's safe to assume this will be remedied, but until then it will be hard to utilize the full extent of functions such as string.format.
  • This last one's a weird one but...

    the bottom of the viewport is cut off at the bottom. But then when I opened the developer tools in Google Chrome to see if I could temporarily fix it...

    The developer tool window eating up the space left to show the page resolved the issue before I could even do some basic looking around. Messing around with the size of the window also seems to resolve the issue, but making it shorter will result in it showing up just right, then too large for the window size, then it realizes it need to shrink it and does just that, making it go back to being a good size for the window. Making it thinner (like what the dev tools were doing) has no similar issue with the width of Picotron, with it always shrinking it just in time.

That was about all the issues I could think of that I ran into (minus the ones I only noticed after I saw other people running into them and decided to test them out myself). I can harly wait until more progress is made on this. Thanks again for releasing a playable demo, zep!

P#123782 2023-01-06 03:16 ( Edited 2023-01-16 16:32)
2

For the effort and record, the bottom pink line is not appearing at all for me, @zep. This is at 01-05-23.

P#123797 2023-01-06 03:52

My god.. this is amazing! Thank you zep!

P#123815 2023-01-06 10:22 ( Edited 2023-01-06 10:22)

@Ummmm_ok how did you fix that pasting issue because I'm getting the same thing, any time I paste it's always zxc

(Edit: ahh it's a clipboard permissions issue in chrome if anyone else sees that happening)

P#123897 2023-01-07 17:38 ( Edited 2023-01-07 17:44)

Can confirm what others are saying about the bottom of the screen being cut off by default. If I change my browser scale to 90% (and seemingly ONLY 90%) the website's sizing allows to see the full screen. Drawing a rectangle to the screen to outline the exact width and height was the only way I figured out that 90% truly showed the full window

Edit: Did some more testing. Seems like the Picotron web player is being cut off at the bottom by a buffer zone. As I change the size of my window, it will scale Picotron up to the next integer level when it is able to, but doesn't seem to take into account the forced gray buffer area of the website, which increases in size based on how tall the window is. Because of this, it looks like more and more of the screen gets cut off the higher the resolution the website is being rendered at. I haven't touched web dev too much though, so I can only speak for what it effectively looks like from a user perspective. I'm using Firefox, if that makes a difference

This image shows the "inspect element" highlight for the program, which should help to show how it's getting cut off :)

P#123914 2023-01-07 23:16 ( Edited 2023-01-07 23:32)

Is there a way to have consistent fps? Using a high refresh rate monitor seems to result in faster rendering in the skull demo.

P#123977 2023-01-08 22:20 ( Edited 2023-01-08 22:22)
5

Great feedback, thanks everyone! I'm out of office until the 15th, but will do another round of fixes soon after I get back. I also hope to settle a few more fundamental questions soon, including deciding on 32bit vs 64bit numbers, and precise memory mapping rules.

I've uploaded some changes to the html shell just now -- there's a prompt before leaving the page with an open Picotron session running, and also the cut-off problem should be gone.

P#124087 2023-01-11 10:40 ( Edited 2023-01-11 10:42)
2

@jamesgecko the .p64 format will eventually store .lua files as plain text (to be git friendly) but in any case I hope to offer a workflow for editing the individual .lua files with external editors. This would also help avoid conflicts when making changes to the same .p64 using multiple (internal or external) editors. One solution might be to simply allow using /cproj instead of /ram/cproj for working files so that they are exposed on the host filesystem.

@Shoozza Thanks for mentioning this -- that sounds like a bug. The real-world speed of time() should not be effected by monitor refresh rate. Currently the framerate is fixed at 60fps (I forgot to rename _update to _update60!), but I plan to use variable _draw() call frequency similar to PICO-8 in order to adapt to performance differences across host machines.

P#124088 2023-01-11 11:02 ( Edited 2023-01-11 11:03)

I think palt() (and possibly pal(), haven't extensively tested it) might be bugged. It seems that after calling palt(col, true/false) for any value of col other than 0, the color will be permanently unusable until pal() is called. I don't know if I'm using it wrong, but I managed to get the behavior I'm trying to achieve with the following implementation:

function palt(col, t)
    if col then
        if t then
            for i = 0, 63 do
                poke(0x8000 + (col * 64) + i, i)
            end
        else
            memset(0x8000 + (col * 64), col, 64)
        end
    else
        for i = 0, 63 do
            for j = 0, 63 do
                poke(0x8000 + (i * 64) + j, i)
            end
        end
    end
end

However, it's VERY slow when called multiple times a frame compared to the performance the native palt() seems to provide.

P#124207 2023-01-13 07:14

I tried to find the minimum and maximum values in the table, but I'm sending you a report because I got a strange result.

nums=split("-10,-5,-1,1,5,15",",")
n1,n2=nums[1],nums[1]
for i=1,#nums do n1,n2=min(n1,nums[i]),max(n2,nums[i]) end
print(n1.."~"..n2)
  • Pico-8:"-10~15"
  • Picotron: "-1~5" <- ???

There was no problem creating a table without using split()

n1,n2=min(n1+1,nums[i]+1)-1,max(n2+1,nums[i]+1)-1

In the game I was making, I solved it like this.

P#124282 2023-01-14 09:34 ( Edited 2023-01-14 09:42)

As @dw817 noted the 480x270 is just two line below the 480x272 of the PSP.
That 480x272 is also the resolution of the Pocket CHIP and that would be great hardware to run Picotron.

I investigated those values, and 480x270 is just 1920/4 x 1080/4.
So basically you can upscale that to FullHD with integer upscale, pixel perfect.

The 480x272 of the PSP and PocketCHIP is likely to have multiple of 16 both in x and y. That can help for video encoding/decoding. But it could also be a hardware availability.

I don't think it is a problem to just display Picotron on a screen with two additional lines of pixels that you can turn black and ignore.

And if you want to run Pico8 content on Picotron, you can double, your would have 256 lines in use out of 270, so just not using 14 (or 16 if on 272 hardware), no big deal... just two black boarder on the side.

P#124288 2023-01-14 12:30

@moon to explain what you saw ... "-1" and "5" being min and max makes sense if the values are compared as strings and not numbers. String comparison is typically a lexicographic comparison, with the strings compared character by character, and shorter strings being "less" than longer strings.

Here's an enlightening snippet:

x = min("-1", "1")
print(x .. " " .. type(x))
x = min("@", "2")
print(x .." ".. type(x))
x = min("@", 2)
print(x .." ".. type(x))

With Pico-8:

-1 number
0 number
0 number

The strings arguments are converted to numbers, with "@" being converted to zero.

With Picotron:

-1 string
2 string
Runtime error
:47: Attempt to compare string with number

The strings arguments remain strings, and in fact there is an internal error if you use mixed argument types.

You get similar results if you try that snippet on a pure Lua playground like https://www.lua.org/cgi-bin/demo (min is math.min)

This is likely one of those compatibility issues Zep has yet to fix, in the interest of making Pico-8 code mostly "just work".

Your fix of adding/subtracting one effectively forces a conversion of the string to number. For your workaround, you could just add zero to the arguments instead, and then you wouldn't need to subtract one from the returned value.

Sidenote - in Javascript, you can force a similar conversion with a unary '+', but that doesn't work in Lua. I tried it hoping to save you a token :-).

P#124301 2023-01-14 18:34

@passionsocks Thank you for the detailed explanation.
"ust add zero to the arguments instead, and then you wouldn't need to subtract one from the returned value" <- I didn't think of this!

P#124335 2023-01-15 06:09
1

I see v.6 has been uploaded now, so I might as well make another comment here to talk about it, along with some other stuff.

Thoughts on v.6


The first thing about v6 is that you can drag the top bar down in the code editor to see a gray backdrop.

A few things to note about this:

  • A silhouette of the Picotron logo has also appeared and can be clicked to cause the screen to scroll down in a similar manner, which was what was used in the above image. Clicking it while the top bar is already scrolled down will fix the scrolling, as will pressing escape.
  • I said you can do it in the editor, and while that's true, you can actually do it anywhere, whether you're in the terminal, on the desktop, or even when running a program. The same goes for clicking the logo, even though it isn't visible.
  • Nothing ever seems to be rendered behind the screen.
  • The top bar is the only object that takes into account how far the screen is scrolled when you click. Everything else still thinks the screen isn't scrolled. For example, in the image above, I had just clicked prior to taking the screenshot and I hadn't moved my mouse at all, yet the cursor is approximately six lines below where it should be.

Given the weird behavior of this, it's hard to tell exactly why it's here, so I can only assume that it is a test for a part of the desktop environment that is incomplete at the moment.

Another part of v.6 is the two new demos available. chonky.p64 is a basic test of the drawing capacity of Picotron, but hexopus.p64 is a lot more interesting. So much so that I went and overhauled it.

Upgrading hexopus.p64


This version of hexopus.p64 (dubbed 'polypus') has several new features, including polypuses with a variable number of 'arms' (accessible with L/R click) and an 'omega' variant of each polypus (togglable with middle click). Just copy/paste the following snippet into a blank program.

-- any flexing polypus
-- by kai (modified from hexopus by zep)
s=1
lastb=0
maxs=16
function polygon(s,x,y,r,a,c)

    line()
    for i=0,s do
        local x = x + cos(a+i/s*(omega and 2 or 1)) * r
        local y = y + sin(a+i/s*(omega and 2 or 1)) * r
        line(x,y,c)
    end

end
local da = 0
function _draw()
    da += 0.002
    cls(1)
    clip(10,10,460, 250)
    camera()
    rectfill(0,0,480,270,32)
    pal(15,16)
    camera(0,0)

--   to do: clipping / coordinates outside i16 range
--  q=100000
--  line(240-q,135-q/2,240+q,135+q/2,10)

    local _,_,b=get_mouse()
    local bp=b&~lastb
    if (bp&1>0) s=s==maxs and 1 or s+1
    if (bp&4>0) s=s==1 and maxs or s-1
    if (bp&2>0) omega=not omega
    lastb=b

--  s=time()\40+1

    for j = 0,s-1 do
    local x,y = 240, 135
    local r   = 22
    local a   = j/s + time()/8

    da = cos(time()/5)/12
    for i = 1,20 do
        polygon(s, x, y, r*.9, a, 8 + ((i+time())%8))
        x += cos(a) * r
        y += sin(a) * r
        a += da
        r *= i < 10 and 0.8 or 0.9
        x += cos(a) * r
        y += sin(a) * r
    end
    end
    clip()
    print("CPU: "..string.format("%.3f", stat(1)*100).."% at 60 FPS ("..string.format("%.3f",stat(1)*50).."% at 30 FPS)", 12,2,17)
    local names=split("Unopus,Duopus,Trittopus,Quadrupus,Pentapus,Hexapus,Septapus,Octopus,Nonopus,Decapus,Undecapus,Duodecapus",",")
    print("Segments: "..string.format("%.0f",s).."/"..maxs.." ("..(omega and "\^:000e1111110a1b00" or "")..(names[s] or "Multipolypus-"..s)..")",12,261,17)
end

Other thoughts on Picotron


One thing that is weird is that the button output for get_mouse() assigns right click to bit 2 and middle click to bit 1, the opposite of what PICO-8 uses.

The FAQ expresses uncertainty regarding the fate of Picotron Playground after launch. My personal opinion is that it should continue to exist as the Picotron equivalent of PICO-8 Education Edition; a watered-down version of the main product to allow non-paying users to experience the software before purchasing it, as well as for use in a classroom setting.

The second argument for split is now required, and omitting it causes the entire string to be put into index 1.

With regards to @mooon's issues with strings vs. number values, remember that tonum exists. it probably won't save you tokens - although it's hard to tell what Picotron's limits will be - but it does look nicer overall.

When pasting into code, Picotron seems to add a carriage return character just before every newline, meaning that if you copy/paste a snippet of code (like the one above) and then try to append new letters at the end of a line, the new letters will overlap the old ones. Yuck.

P#124476 2023-01-17 23:35

Will picotron support other language (display, not programming language) by loading font?
I see SDL has font module.It seems feasible for picotron.

P#124489 2023-01-18 05:51 ( Edited 2023-01-18 05:54)

VERSION 7


Here we go again! Though I didn't notice anything new right off the bat... anything like new API features or functions aren't going to be easy to find, so I encourage others to look around for anything like that. The only thing I noticed was that the gray background 'behind the screen' now has something written on it!

I actually really like this. (Or at least I like where it's going.) It has the potential to be a combination of the blue bunny from P8EE and PICO-8's HELP [topic] command in one convenient area. Here's a mockup of what I'm thinking:

A basic mouse-based interface with the main topics and a 'recent' list allowing you to jump back and forth between various topics. You don't have to do this, but I think it would be pretty useful for people learning how to program in Picotron (both for those who have never programmed, and those who have only done so in PICO-8).

Getting back to v.7, this help text also shows up on the desktop. (You know, the one accessible by typing in terminal on the terminal screen.) BUT, if then close all windows on the desktop, the desktop will show a blue background with -- empty workspace -- displayed... and as long as the desktop is selected, so will the screen behind the screen.

(Side note: we need a better name for this... thing.)

Bugs (Past and present)


I already mentioned the empty-desktop-affecting-the-ZEP-HELP-WHAT-DO-WE-CALL-THIS bug above, so there's no need to reiterate that one.

The bug where sgn(0) and abs(0.0) return negative values has been fixed!

When pressing middle-click, the browser's scrolling mode will activate, causing the next click to be ignored and until then making the page move up and down when you move your mouse.

The carriage-return-character bug and the single-argument-split bug both have not been fixed yet. I don't know about other bugs that have been reported, however, so there may be others that have been fixed so I can't say this is all of them.

P#124526 2023-01-19 03:25
1

@Ahai-8 pico-8 has a system to define a custom font (240 possible characters, people have used it for cyrillic for example) and it seems that picotron has the same or a similar system! it’s not based on ttf files and SDL_font; see https://www.lexaloffle.com/bbs/?tid=41544 for details

P#124530 2023-01-19 03:50
8

Hi All
Version 7 is up, and you can view a changelog with the newly included :

$ edit /system/playground.txt

> What are the plans for the PCM sample rate?

@bikibird @ridgekuhn

The audio out is going to be regular 44100 stereo, but the mixer might drop down to 22050 if needed (e.g. if it can't keep up under web). To get raw audio playback, it can be fed into a single synth node, or two for stereo. There is a wavetable node type, and the audio data for that can be modified while it is playing, so to stream it is possible to alternate memcpy'ing into the front or back half of a single wavetable entry at the right moments.

@dw817
Fixed flr & ord returning floats instead of integers, thanks. Large i64's conversions are more stable in v7 too. I'm still getting a hang of the extra complexity of large (and dual) number types, but I'm really digging the potential here.

On glyphs: The PICO-8 character set will likely return as the default font -- I just haven't drawn it yet! The data is preserved though, so it's at least possible to paste in binary strings from PICO-8 and read the same data from them.

On the absence of boot screen/sound & editors etc -- this will all arrive (as binaries) in Picotron 0.1, which I think needs to be released as a cohesive whole to give the full Fantasy Workstation effect. Playground is mostly focused on getting the api / runtime right.

@Kaius
Thanks, I've fixed some of these for v7 and hope to improve PICO-8 behavior compatibility in v8. The standard Lua libraries are available to Picotron, so authors can choose if they want the more forgiving behavior or not!

@HTV04
I fixed the palt() bug for v.8. There is still a difference with PICO-8 though: once a colour has been made transparent with palt(col, true), any remapping for that colour is lost and so palt(col, false) will revert to mapping to itself (i.e. palt(col, false) is the same as pal(col, col)).

@mooon @passionsocks I'll fix this for v.8 -- split() should indeed (by default) return numbers for items that are formed as such.

@Kaius
That area is eventually going to be the main "Picotron Menu" (settings, favorite apps, project file navigation etc.). Having a help / documentation tab there certainly wouldn't be out of place.

Nice catch about mouse buttons -- will fix that. There are still a bunch of annoying problems with the code editor that I'll fix a bit later on (including cursor placement after paste etc).

Modified hexopus.p64 is beautiful!

@Ahai-8 @merwok I'm hoping standard P8SCII fonts will solve most latin font needs, but for larger unicode code I think it will be possible to roll custom solutions using sprite fonts + Lua's utf8 library support (although performance there might be questionable -- I haven't looked into that much yet).

P#124553 2023-01-19 17:21 ( Edited 2023-01-20 08:28)
1

@zep yesssssss

P#124559 2023-01-19 17:54

Great news on the audio. Can't wait to make Speakotron.

P#124560 2023-01-19 18:02
Page:

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-02-03 14:10:17 | 0.311s | Q:104