I made a useful tool to look at what parameters are expected from picotron's api
You can also see in what file it is implemented and inspect the code!
It only works for functions that are implemented in lua, when it's done in c it's not visible, and some lua functions don't have much code in them and redirect a variable amount of parameters toward a c function
I also exported the list of functions with their parameters if I could find them:
I wrote Lua require
function based on the include
function found in /system/lib/head.lua:791
.
This function loads Lua modules similar to standard require found in Lua:
- it loads the file
- executes the file
- returns the module returned by included file
- caches the module, so next call to require will return already loaded module
How to use:
- put the source code of
require
function in yourmain.lua
:
function require(name) if _modules == nil then _modules={} end local already_imported = _modules[name] if already_imported ~= nil then return already_imported end local filename = fullpath(name..'.lua') local src = fetch(filename) if (type(src) ~= "string") then notify("could not include "..filename) stop() return end -- https://www.lua.org/manual/5.4/manual.html#pdf-load -- chunk name (for error reporting), mode ("t" for text only -- no binary chunk loading), _ENV upvalue -- @ is a special character that tells debugger the string is a filename local func,err = load(src, "@"..filename, "t", _ENV) -- syntax error while loading if (not func) then send_message(3, {event="report_error", content = "*syntax error"}) send_message(3, {event="report_error", content = tostr(err)}) stop() return end local module = func() _modules [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=143480#p) |
I wanted to share a few projects that I've been working on to prove out that making low-vision / blind accessible games is possible in PICO-8!
To get to the meat of it, here are the two games that my friend and I were able to put together that we built in prep for, and as a submission to the Games for Blind Gamers game jam:
Tiger & Dragon - https://jrjurman.itch.io/tiger-dragon
Lunch Gambit - https://jrjurman.itch.io/lunch-gambit
The games require a screen reader if you want to hear the text being read aloud, but the long and short of it is that the text on the right will be read out to screen readers. For people who might have trouble reading the text or need especially large fonts, the right side panel respects the font-size of the page, and allows players to zoom in if that would help readability.
The way that we were able to accomplish this is by having a special HTML template that reads the GPIO output from PICO-8 - pico-a11y-template
A limited graphic program for Picotron (stripped-down recreation of Desmos)
Planned features
- ❌ Make the different functions editable within the program
- ✅ Optimize rendering of axis and increments
- ❌ Improved UI (zoom slider, collapsible sidebar)
- ❌ Have the coordinates of a point appear when cursor hovers above a line
- ❌ Preferences menu to change theme, increments etc.
Version 0.2
- Added infinite axis and increments
- Equations are now -∞ < x < ∞, upgraded from -100 < x < 100
- Equation resolution now scales with zoom (higher resolution zoomed in, lower resolution zoomed out)
PREVIOUS UPDATES
I made a handful of commandline utilities for picotron that you might find useful.
https://github.com/Rayquaza01/picotron-utilities
So far, Picotron Utilities has:
cat - print files
touch - create new files
tree - print tree view of a directory
wget - download a file using fetch()
grep - search in a file or recursively search through all files in a folder
frange - print a file or range w/ line numbers
pwd - print the current working directory
Installing as a Yotta Package
You can install the utilities included in this cart with yotta util install #picotron_utilities
Installing as a Bundle Command
You can install this cartridge as a bundle command by saving it to your utility path.
makes locs on desktop
usage: loc path (name)
put code in appdata/system/util/loc.lua
you can change file name to whatever you like, like ln.lua to use as ln
function ext(str) for i=1,#str do if (str:sub(i,i)==".") return i-1 end return #str end local orig=env().argv[1] if (not orig) print("usage: "..env().argv[0].." path (name)") exit(1) if (orig:sub(#orig)=="/") orig=orig:sub(1,#orig-1) if (orig:sub(1,1)!="/") orig=fetch("/ram/system/pwd.pod").."/"..orig if (not fstat(orig)) print("file does not exist ("..orig..")") exit(1) local name=env().argv[2] and #env().argv[2]!=0 and env().argv[2] or orig:basename() name=name:sub(1,ext(name)) local targ="/desktop/"..name..".loc" if (fstat(targ)) print("loc already exists ("..targ..")") exit(1) [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=143431#p) |
While poking around in Picotron, I found myself wanting to view the contents of a file without opening it in the editor (via the edit command), so I wrote a little cat function. In order to implement it I needed to grab the current working directory so I went ahead and implemented a pwd command as well. Both of these are very simple and really just wrap existing Picotron functions for ease of use in the command line.
-=cat=-
local argv = env().argv local foldr = env().path if #argv < 1 or #argv > 1 then print("usage: cat filename") else local f = foldr.."/"..argv[1] print(fetch(f)) end |
-=pwd=-
local foldr = env().path print(foldr) |
To implement these, just save each in it's own project in the /appdata/system/util folder, using the name of each command as the filename- so copy the code for cat into 'main.lua' and cd into /appdata/system/util and type save cat
. Same goes for pwd. Once you do this, you can run them straight from the Picotron command line.
Software Standards
Hello, I'm here to propose some software standards. This post isn't supposed to be all about me, I want the community to come together to make sure we're not stepping on each others toes whenever we make software, games, ect. Currently it's sorta the wild west, so the only thing I can suggest (which I've done with SLATE) is that we put application installs and preferences inside of their own folder within the /appdata/
folder.
I don't want to make standards nobody is going to use, so please comment on this post to talk about any standards for anything that could be useful to everyone.
Personally a new standard I've been thinking of is creating a central libraries folder that software can prompt downloads for libraries it might need, so that no one has to reinvent the wheel every time they make an application (although it is so early I don't think this needs to be a focus yet).
Some Discord servers have been quite busy lately and we've been discovering (less trivial) things here and there than the officially documented things and I thought it was good to have them available in the BBS instead of losing them in a Discord server's chat log. I'll try to update this post as more discoveries are uncovered.
Don't hesitate to write more discoveries in the thread.
Notice
At the moment I'm writing this post, we're running 0.1.0b, stuff might change in the future, nothing is set in stone for now.
POD is data, data is POD
Most of the file one will find on their systems are just POD files with an extension. The extension allows the OS to determine which app to launch but the internal data seems to work the same for all formats: they're PODs.
podtree (your_file)
will pop a tool window containing a tree interface with the guts of your file. So you can determine how those file are formatted.
For instance the default drive.loc
file, once opened, will show that it has only one property: location. So creating a table looking like that my_table = {location="/path/to/a/program.p64"}
and then saving it with store(my_shortcut.loc, my_table)
will efectively crete a new shortcut.
so the new picotron is finally out, and the browser version is no where to be seen! even though pico-8 and voxatron had browser versions! but I think that the reason lexaloffle cant make the browser version is just because they can't figure out what to do with the workstation, and I don't blame them! it would be hard to make it a seamless transition between the full version and the browser version, and the only way I could ever think of is using a default background and limiting use to just the cartridge. I hope lexaloffle will make the browser version one day to open the field to wider audiences!