UPDATE: Part II Thread https://www.lexaloffle.com/bbs/?tid=52692
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!
This is pretty cool, I'm looking forward to seeing this develop more in the future!
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:
- See a working FLIP.
- Ability to post and read online shared high-scores + data.
- More coding space.
- More sprite space.
- More mapper space.
- More SFX definitions. Having the ability to define 4-channel audio in a single SFX.
- More overall memory. I am not against bank-switching 4 sets of 64k.
-
Faster execution for all commands.
-
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.
-
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).
- Any suggestions deemed good I made for Pico-8 that could not be done earlier for whatever reason can now be considered for Picotron.
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:
- I have to press space every time after pasting, or the editor doesn't seem to realize that the code has changed
- 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] - 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)
Quite useful, @pancelor. Thanks !
Check out "draw_text_masked" it's identification is all over the place !
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
So glad to see this. What are the plans for the PCM sample rate?
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
I already gushed on socials about this, but somehow forgot here.
Thanks @zep for giving us an early build to play with - ❤️ it already! 😊
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.
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.
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.
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.
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. |
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
No worries, @Ummmm_ok.
Try this code out in Picotron:
function _update() cls() ?"-- I \135 Picotron --",192,120 end |
@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!
I threw together an aseprite-to-picotron sprite exporter: https://gist.github.com/pancelor/43512028087bf34e5d9773a61a03f93a
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?
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).
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.
@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
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.
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.
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.
So it turns out we can just look at any of the .lua files even from within the playground. Thanks 
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 atapi.luafor 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, thennot a>0, so wereturn -1. PICO-8 returns1instead, and most other implementations ofsgnreturn0in 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 returning1or join the masses in returning0, but I think we can safely rule out this behavior as the 'intentional' one.- On a similar note,
absreturns negative zero ifa==0. While you might not think this matters at all - and if you use integers it doesn't - if you input0.0it uses floating-point, a system which - unlike its fixed-point precursors - includes-0.0. Considering the point ofabsis 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 asstring.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!
For the effort and record, the bottom pink line is not appearing at all for me, @zep. This is at 01-05-23.
@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)
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 :)
Is there a way to have consistent fps? Using a high refresh rate monitor seems to result in faster rendering in the skull demo.
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.
@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.
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.
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.
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.
@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 :-).
@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!
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
Upgrading hexopus.p64
Other thoughts on Picotron
Will picotron support other language （display, not programming language） by loading font?
I see SDL has font module.It seems feasible for picotron.
@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
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).
[Please log in to post a comment]
