Caution
This runs poorly in the Web version of 0.1.0f (runs too slow for the streaming to work well). This cart is better experienced in desktop versions.
Long Line Theory
This cart is a quick port of Long Line Theory, a bytebeat track that was and still is impressing me as of today. When I have access to directly audio rendering, this is usually my audio Hello World, especially with the C version I made to port the JS snippet to desktop.
This bytebeat is actually quite heavy, I had to resort to some tricks like a dirty resampling from 8kHz (its original sampling rate) to Picotron's 44.1kHz. It gave me enough spare cycles so I could whip that ugly visualizer. Can't have both your cake and eat it, I guess!
Again, many thanks to @luchak for the PCM streaming proof-of-concept cart and mu6k for that awesome piece of code.
1 comment
Caution
This posts acts also as a kind of documentation for the tool, its usage and the integration of the data. It's not final and might probably change in the future, to improve the writing style, fix mistakes or add more explanations. Please do report any feedback you desire so I can improve the documentation.
Anim Editor
Hello! From starting a project, I ended up going on a tangent for weeks and had been making a frame-based animation editor for the last few weeks with an intent of making my own internal mini animation library to make sprite animations as easy as drawing -or at least, for me-.
Using the tool
The animation editor is trying to follow the philosophy of Picotron's builtin editors. While it can't enjoy the same integration than the tools provided with the OS (like not having its own file open intent), it'll still aiming to feel at home when next to the other tool. Thus it's working at its best when opened while a cart is mounted/loaded to work on the cart's files.
The editor is split in three parts : the view, the timeline and the sidebar, each of which is going to have its own section. There's also going to be one for using the data generated by the animation editor.
The sidebar
The sidebar has buttons to open or save an animation, save as another file, replace the currently loaded GFX file, a button to create animations and undo/redo actions. You can right click the open button to open up a recent file list instead of Picotron's open dialog for a faster access.
Note that saving and opening are disabled in the BBS because there's no persistence nor demo files. This is planned for when I'll the energy to.
Then is presented to you the animation list. Once you created one or more animations, they'll be listed there. Click on one of them to select it and double click an animation to rename it. The X button allows you to delete animations. Don't worry, deleting an animation is undoable.
Following down is the sprite selector. It should work like the GFX editor except that you have an extra button to reload the GFX if you edited it externally. You can click & drag a sprite from the grid to drop it on the view to add it on the current frame in the current animation.
Note that the reload button is going to go away as soon as I'll replicate the map editor's automatic GFX reload mechanism. Another planned "when in the mood for" feature.
The timeline
Once you create and selected an animation, you'll see there its frames in the bottom bar and two buttons crossing over its border. The first button will create more frames at the end of the animation and the other one will play the animation. You can press space to toggle playback too but that doesn't seem to work on the BBS as my browsers tend to scroll the page down instead.
Click on a frame to select it. Drag it to move it in the timeline. More options are hidden a right-click on a frame, like copy & paste or duplicate the frame. The small circle on the top right corner will delete the frame. Again, it's one undo away from you.
Note that most actions are disabled during playback, for your convenience (and to avoid a plethora of bugs). The grid will disappear and you'll be pretty much limited to change the playback speed (left editable for your convenience) and pausing the playback.
The scene view
Finally, the rest of the owl: the scene view. The scene view will display the current animation's current frame by overlaying the sprites from first to last inserted. Drag a sprite from the sprite selector to the view to add it to the frame. Once dropped, you can continue interacting with them by dragging them to reposition them or right-click for more options, like applying the currently selected sprite on the selected sprite. You can drag the view by click and dragging the middle mouse button to pan in the scene.
Note that the two blue and green lines are the main axises of the animations and the point where they meet will be the origin of the animation. You might want to use that point as a reference when integrating your animations, the latter being the main topic of the next section. Nice segue, eh?
Using the animation data
Now that you made your animations, you might want to use them in your game or project, right? This is the section that will explain the inner details to help you getting to it.
Like any POD file, an .anim file is just a serialized Lua table. You can introspect the .anim files by opening them with podtree, that's always a good trick to keep around in case you want to figure something or edit them.
Animation structure
An animation file (.anim), once loaded with fetch or unpod, contains two main elements at its root: a reference to the GFX file used during the creation of the file and a table named anims.
anims contains your animations, indexed by the name you put in the editor. So my_anim will be accessible by getting my_loaded_file.anims["my_anim"] or my_loaded_file.anims.my_anim; the former syntax allows for spaces in the name.
The GFX reference is used by the editor to determine which GFX file to load when loading the .anim, but you can also use it to identify yourself what to load, for situations like having a specific GFX file for a specific animations or anything, really, it's up to you.
Animations
An animation contains a list of frames, a tick member and a loop flag.
ticks: The system currently being based on rendering frames (or game logic ticks) as a measure of time, that member indicates how many ticks should be spent between two frames - so, in other words, a bit like the speed of the animation. Think of SFX'speedloop: This value is currently not used in the editor but you can use it in your code to determine if your animation should stop or not
Each frame contains a list of sprites, which each stores an ID mapped to the loaded GFX file's sprite list(so like spr does too) and a position offset (relative to center of the scene in the editor). Those sprites should be rendered from first to last in the array to reflect what you'll see in the editor
Sample code
This is not fully tested, I just ripped off my project and tried to remove what was speicfic to it, but the general idea is there.
local player_anims = fetch "anim/player.anim"
player = {
...
anims = player_anims.anims
}
function player:set_anim(anim)
self.curanim = anim
local a=self.anims[self.curanim]
self.animticks = a.ticks
self.curframe = 1
end
function player:update_animation()
self.animtick-=1
if self.animtick<=0 then
self.curframe+=1
local a=self.anims[self.curanim]
self.animtick=a.ticks--reset timer
if self.curframe>#a.frames then
if a.loop then
self.curframe=1--loop
else
-- Here I had something else in my code to transition into another animation if needed.
-- Another element I'll probably add in the editor when I'll feel the need for.
self.curframe = #a.frames
end
end
end
end
function player:draw_animation()
local a=self.anims[self.curanim]
local frame=a.frames[self.curframe]
-- Here, the animation's origin will be placed on (cx,cy), so the center of the player object.
-- That's one way to of doing it, you could also use the middle point on the bottom, a corner, etc.
local cx, cy = self.x-(self.w/2), self.y-(self.h/2)
local flp_x = self.flipx and -1 or 1
for sprite in all(frame) do
spr(sprite.gfx_index,
cx + (sprite.x * flp_x),
cy + sprite.y,
self.flipx,
false)
end
end |
About the tool's future
I'm probably going to plug more features as I'll need them in the future, like having a timeline for hitboxes or triggers. I'll probably go back to this tool only when I'll really feel the need for it.
Also, I'd like to be honest and say in advance I don't really plan on making the most versatile tool ever, but I'd like to make it a tool one could remix to their own needs. I made this small tool when building for another project in mind (or two, maybe???) and I'd not want it to take most of my time. I hope you'll understand.
That said, I'll also add the task of trying to improve the source code to make it more open for customization in the "maybe later" task list.
Resources used
- Zep's GUI lib and wrangler utility (forked the latter into a custom version). I also borrowed his save icon I recolorized. I hope you don't mind. :°
- Surt's take on Kenney's Platformer Kit. Licence: CC0
Hello @zep. I had to dig into the bug where text in text editors would overlap for some reasonand I noticed something: on Windows, the following snippet causes the issue 100% when pasted from notepad:
adasd the game |
Of course, I don't think copy-pasting it from here would work. As a matter of fact, there should be two blank lines and there's only one, so there's something altering the text, be it the BBS, the browser or something else.
So, I hacked in gui_ed.lua:insert_multiline_string a way to read the string and its hexdump in the console log in the following snippet. It's ugly but it's functional.
local res = ""
--str = str:gsub("\r", "") -- I'll get to that
for i=1, str:len() do
local c = str:sub(i,i)
local co = ord(c)
local cs = c
if co < 32 then
cs = ("<%02x>"):format(co)
end
res ..= ("[%s][%02x]"):format(cs, co)
end
printh(res) |
I spotted the presence [<0d>][0d][<0a>][0a] in console log, the classical CRLF. In that function, you're splitting by \n and I got a certain suspicion that happens when you mix reading text and Windows. Listing the pasted line's last characters got me on track: \r, a.k.a. the carriage return. That characters stays at the end of the line after the editor's code tries to split the clipboard content by the newlines. And because that character actually does a carriage return like the standard, the text following the character gets moved back to the start of the line and presto, it's overlapping text time!
So, I don't know if you already have resolved that bug or if you have something in your planning, but in case not (and if people feel hacky enough to mod their editor until an official fix appears), one could build a workaround by removing any occurence of \r in the pasted code or strip them from the split lines.
For the first method, the line I commented out in the snippet would do the trick. For the second method, one could add such snippet right after the split
for i, line in ipairs(lines) do
local l = line:len()
if line:sub(l, l) == "\r" then
lines[i] = line:sub(1, l-1)
end
end |
I hope you'll find a more elegant solution than my monkeypatching and I hope that those pesky CRLFs were the only source for this specific bug. Have a nice day!
Hello zep. I was wondering about a specific behavior of Picotron and I couldn't figure if it was a regression or a choice.
Prior to 0.1.0c, if a cart folder with its name ending with .p64 was loaded, saving it would preserve the format, the cart would stay a folder. Now, whatever I try to do, as soon as I save a folder cart from Picotron, it gets turned into a .p64 file, which is a bit more inconvenient as I'm currently using an external editor.
Even cp -o <src> <dest> doesn't save a folder anymore if <dest> is suffixed with .p64. Copying to a normally named folder seems to work and I just realized that as I was writing this blog post. Still my question stands.
Are project folders or files ending in .p64 will always taken as files and going to be converted as such? Was the switch intentional? Should I rename all the folders in my project folder so far?
Good luck squashing all those bugs! Have a nice day!
Hello, the release thread is a bit busy and I'd like to make it a bit more visible as it's both about a possible bug and a feature the community could use for editor or more, it's a bit more interesting than just a crash, I'd say. I think I found a possible issue with wrangle and filenav.
Basically, wrangle that works with the current opened file pwf() and by when creating the wrangle object you have to pass getter/setter to store/load data from the file. Right?
Inspired by the GUI code here and there, I found out that the argument intention was mostly the thing that makes filenav acts as an open/close dialog, or supposedly. Thus, I ended up with code looking like that
sidebar:attach_button{
x=0, y=0,
label="Open",
tap = function()
local segs = split(pwf(),"/",false)
local path = string.sub(pwf(), 1, -#segs[#segs] - 2) -- same folder as current file
create_process("/system/apps/filenav.p64", {path=path, intention="open_file", window_attribs={workspace = "current", autoclose=true}})
end
}
sidebar:attach_button{
x=32, y=0,
label="Save as",
tap = function()
local segs = split(pwf(),"/",false)
local path = string.sub(pwf(), 1, -#segs[#segs] - 2) -- same folder as current file
create_process("/system/apps/filenav.p64", {path=path, intention="save_file_as", window_attribs={workspace = "current", autoclose=true}})
end
} |
And somehow, it works! Or almost.
I believe there's a slight issue with the open_file intention: it doesn't properly override the doubleclick event, as seen in 1/apps/filenav.p64/open.lua, @zep wrote that he didn't any find another intention that didn't needed the same exception thansave_file_as`; the default operation did the same expected result anyway by leaving the default editor to open the file thanks to that hardcoded* extension/editor association mapping.
Thus we end up with the situation where we can't just open a file from a non-system editor by doubleclicking with a custom file or file format. I found a workaround: if you type the file to open in the filename toolbar, it'll properly handle the event, pass the open_file event back to wrangle and your file will properly load!
So, here's my questions:
- Picotron's boundaries about what's user-accesible code or not is a bit blurry, should we allowed to use wrangle?
- Should
filenav'sopen_fileintention get the same exception thansave_file_asif it was called from an external program? - Was the end result intented or is it a bug? Having two contradictory results from the dialog seems like a bit unexpected.
Anyway, have a nice day!
Addendum : I also noticed another potential issue: the opening workflow works only when one types the filename in the text entry. Selecting an icon and then pressing Open won't work and won't change the current file, failing the opening process.
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.
In the same idea, GFX files are just arrays of small tables containing an userdata and some editor properties, map files are in the same vein than GFX files.
Remember that there is a spec documentation available to explain in detail what a POD is or how to manipulate them: here.
.loc files
Loc files are conceptually similar to Windows' .lnk files. They have a property (location) pointing to a file or cart, but they can also store arguments in a table (argv) that will be passed to the launched program. Here a snippet to create a sample .loc launching a program with arguments
store("/desktop/my.loc", {location="/dev/a_program.p64", argv={"some", "arguments", "as", "an", "the", "game"}}) |
Those arguments will be accessible from the launched program through env().argv. Thus, you could make yourself shortcuts to quickly open a tool with a specific file or options or launch a program with a specific mode depending on the flags you launch, you're free to do it the way you want.
I'm working on a tool prototype and here's for instance the current code I'm using to parse the arguments. I'm doing extra logic to handle --gfx or --anim options for absolutely no reason, though. You're free to edit the sample as you wish.
The Tool Tray
The tool tray (also known as desktop2 in some internal places) is the blue region that shows up when you drag the menu bar down. By default it's pretty bare, only a clock and a pair of eyes will welcome you, but it contains a few tricks under its sleeve (or should I dare to say tray?)
Widgets
(Widgets isn't an official term, they just remind me of Windows Vista's widgets)
First, adding more programs in the tray can be done by doing something like what does /system/startup.lua
create_process("/path/to/file.lua", {window_attribs = {workspace = "tooltray", x=widget_x, y=widget_y, width=widget_width, height=widget_height}}) |
More research should be done around those tools, but so far, here's what was found out: Widgets can only draw by default in their region provided in the window_attribs and the drawing coordinates are offset to align (0,0) to the region's top left (basically, clip + camera). As shown by eyes.lua, widgets also can listen to input events. Widgets works like any other process, so they'll be listed by ps and can be killed.
Caution Launching a program as a wallpaper (with the window_attribute wallpaper set to true) doesn't seem to work and it'll blink every other frame, so if you're sensitive to blinking lights, you definitely shouldn't do thqt.
Putting files in the tray
As hinted by some of the OS' code, the tray can act as a second desktop where you can place files in them! Just drag'n'drop from the normal desktop to the tray and you'll can see it can store the file! Actually when you moved the file to the tray, it was moved to /appdata/system/desktop2. So, you could store random shortcuts there, log files, etc. in that tray and show them at will on any other workspace.
Copy data from Pico-8 to Picotron
As Pico-8 and Picotron use the clipboard, you can pass along some data. For instance, copying a sprite from Pico-8's sprite editor to Picotron works. Of course, in Pico-8 you'll be limited to the original 16 colors, so it cannot act as a full replacement for Picotron's drawing tool.
In a pinch, it could help you importing spritesheets to Picotron until other methods are implemented.
POD embedding in code editor
As shown in notebook.p64, Picotron can somewhat support embedded graphics userdata in text file and display them inline with the rest of the file. The way of using that is to pod an userdata into base64 format and concatenating to your file with a comment header like that
--[[pod_type="image"]]unpod("b64:the base64 representation of your image") |
And it'll show up as a picture in both in notebook.p64 and the code editor too! I haven't got to make work with print yet so maybe they're more fit for comments?
The desktop envrionment
Theming your wallpaper
A small tip: the wallpapers provided with the OS are grabbing the theme properties to adapt to the system's theme. For instance "desktop0" and "desktop1" are two of the three colors set for the desktop section of the theme. If you want to write a wallpaper adapting itself automatically to the system, you might want to grab those colors on a regular basis with theme("desktop0") and theme("desktop1") as they'll automatically update when needed. You're not limited to those colors either, but I think that sticking to those colors will help with readability as the selected colors will most often be different from the ones used in other GUI elements.
More desktop workspaces?
Caution This is really not tested yet, this seems to work but here be dragons.
Somehow, a certain combination of window attibutes will allow you to spawn additional desktop workspaces. Surprisingly, most of the behvaior of the desktop is not really a program so the wallpaper will do the job. Here's a minimal snippet to clone your default desktop with comments
-- Those two lines are directly copied from startup.lua, they'll fetch your wallpaper program
local sdat = fetch"/appdata/system/settings.pod"
local wallpaper = (sdat and sdat.wallpaper) or "/system/wallpapers/pattern.p64"
--
create_process(wallpaper, {
window_attribs = {
workspace = "new", -- I don't know yet
desktop_path = "/desktop", -- I suppose that's the folder shown on the desktop
wallpaper=true}, -- RUn the program in background, for wallpaper programs
style="desktop"}) -- Somehow this does the trick and will also make the icons show on the workspace but I don't know why it's not in startup.lua |
That should do the trick. Of course, you don't have to stick to your configured wallpaper, you could perfectly use another. Note that the theme settings are global so you can't really have different UI themes between workspaces yet.
More colors in your icons
So, you've been probably thinking that three color and an alpha channel aren't enough for your icons? Maybe you want your program to stand out on your desktop? Don't fret any more, I have the solution!
Pictron saves metadata for virtually almost every file it can open, icons are part of them. When you've been editing the icon through the icon editor tool, you have been editing those files' metadta, right? What if I told you this icon is just a simple sprite like any other sprite you can create, draw and store? Catch my drift? Here's a magic trick:
source = fetch "/ram/cart/gfx/0.gfx"
meta = fetch_metadata "/untitled.p64"
meta.icon = source[0].bmp
store_metadata("/untitled.p64", meta) |
This will effectively loads the first sprite of your currently loaded cart and set its as the icon of /untitled.p64. There are a few caveats before you get drunk with power:
- Sadly (or not), this won't work if the icon you want to set is not 16*16 pixels. (Note, right now the OS checks only the width so you can go as tall as you wish but it's most likely a bug)
- For desktop theming,
filenav(and thus the desktop too) remaps the colors1, 6, 7, 13to the desktop's theme colors set for the icons and you can't really circumvent that (unless you want to mod your OS). So if you want to get artistic, you might want to skip those colors. Note that those colors are effectively the colors you've been applying to the icon when using the icon editor.
Unsorted general tips or info
- Don't forget to dig in the OS' Lua files, they're currently a good source of info not yet documented, like
blit, which allows copying a 2D region of an userdata to another. A few of the info mentionned were dug from snooping in them, so have look! - Picotron's
/systemfolder is written as read-only but what it means for now is that any user change will be lost as the folder will be recreated at every launch. - In a similar vein, the OS contains some goodies like fonts you can apply on your program by launching a snippet like that one:
poke(0x4000, get(fetch("/system/fonts/lil_mono.font"))). Pico-8's font can be found there, have a look! poke(0x5f36, 0x80)as seen infilenav.p64enables text wrapping using theclip()rect./ram/systemcontains a few neat stuff likeprocesses.podwhich lists all the executing process.- When you launch a cart, it might not close when you exit it and its icon will stick in the menu bar. To effectively close them, you can right-click or middle-click on their icon and hit close. Or use
psandkill. Or use a process manager tool. Or reboot Picotron, etc. - The audio editor can be quite unituitive, you might want to look at the doc in case you missed a feature or another. I mean, I spent some time playing with the tool until I noticed that I could sawp wavetables to get white noise by clicking on an osc.'s waveform window.
- It seems like calling
poke(0x547d,0xff)in a windowed program will make any transparent color marked withpaltor other mechanisms turn transparent, so you can see what's behind your window. Thanks @taxicomics for the report.
So, I fell into the raycasting hole. I'll keep around a small cart with a few routines so I can quickly do more stuff with that technique.
I'm not making a generic routine to display the walls because there are a lot of features one might want to use in their own caster (wall uvs, animations, etc etc), so instead, I made a few scenes to show how to augment a simple caster to do a few more things (like alternating textures on NS/EW sides or having a depth buffer to properly render world sprites)
In the future I might explore ray collision, there is potential to get fun stuff with that. A lead I'm following is using custom collision shapes per tile so hitting a tile will trigger the shape. An example of a possible shape would be a circular column smaller than a tile would be simple to do with a ray-circle hit detection and atan2 to compute the UV.
Addendum: the cart is in WIP because this cart'll never sum up to a finished project and because there is room for improvement. For instance I'm not totally satisfied with rspr.
Version 0: initial release
Version 1: quickly added a sspr map renderer. Costs less CPU than tline for a mostly similar look minus visual jumps in some angles. The renderer might need more work to avoid having the walls and their texture jump as much (experimenting with flooring/ceiling the coordinates might be a lead).
Topic update : moved to GFX samples as it might be a better place than WIP.
The legendary screensaver from Windows 95, recreated in Pico-8. You can now feel like it's 97 all over again, but in 128x128 pixels.
Something is off, I can't put my finger on it. Maybe if I let it run for a while?..
A content note (spoiler) :
A cart a bit different than the usual coming from me. I recently discovered about the hidden PCM channel and I just had to play with.
So I'm experimenting with both sample playback and PSG (Programmable Sound Generators) to both learn and see if we can make the most of the PCM channel and -why not- in the distant future, have a 5-channel tracker?
So here, we've got one cart that shows smooth playback of various samples and at the end a sawtooth PSG.
To generate the samples, I use two steps:
- A pass through SoX to convert a sample into unsigned 8bit 5512Hz raw file (
-e unsigned-integer -r 5512 -b 8). - A quick use of a Python script to convert the sample into a pastable string (I suggest you to convert it into chars once inside Pico-8). I'm sorry I can't post the snippet here yet, it somehow breaks the BBS' upload process.
I commented in the cart a basic low-pass filter inside the sawtooth PSG. It seems pretty costly to generate it on the fly. Maybe it'd be wise to precompute filtered waveforms like LSDj does.
A few notes on my findings
- The playback is way better on Desktop than on a browser. I'm sorry in advance for the noise or the volume.
- I got the best playback results with a packet size of 512 bytes.
- Just playing samples from a string doesn't cost a lot. It'd be even lighter if you would blit the string in the RAM to just memcpy away.
- It seems that a tick of length 8 in a SFX vaguely matches 366 PCM samples. Vaguely because I still have desync issues after a while. I wish I can find the proper packet size balance so we could not have to deal with desyncs.
Update : moved to SFX. I probably won't touch the cart anymore.
Play it also on Itch : https://eiyeron.itch.io/sprintagift
Sprint'a'Gift is a submission to a certain 2020 holidays calendar you can find here.
Santa's in a hurry and forgot to jump on his magical sleigh! Now he's trying to run as fast as he can on the rooftops for an express delivery. Can you help him?
Controls:
- (X) Jump (hold for higher jumps)
Thanks to:
- Gruber for the music
- Somepx for the title font
- Adam Saltsman for Canabalt, which is the main inspiration for this game.
I'm making a small tool to quickly generate fill pattern for making fades. As I'm working on a game using those, I hastily threw together this small program to quickly visualize and tweak a fade based on the base pattern and to export it.
Each case in the grid represents a pixel in the fill pattern. The generator is creating a fill pattern gradient from 0x0000 to 0xFFFF while each pixel can turn off in a different frame. The pixel's value will indicate to the generator how many frames the bit must be kept at 0, with zero meaning that it'll stay down for 1 frame, one for two 2 frames and so on. Up to 17 frames worth of fill pattern can be created this way.
The default setting is the fade with the classic dithering 2x2 Bayer pattern, the one that inspired me to do this tool.
Controls
[Up/Down/Left/Right] : Move the cursor around the grid
[X+Up/Down/Left/Right] : Change the frame at which the bit selected by the cursor is kept at 0.
[O] : Test the pattern
[X+O] : Copy pattern to the clipboard (+ctrl-c on web)
Changelog
Revision 1
- Now generating less frames if the found maximum value is less then 15
- Using up/down when changing the frame value in the grid will increase/decrease by 4
I almost succeeded in making a tline-based tunnel effect in a tweetcart.
Two limitations : poor angle/side management and no perspective scaling.
Close enough.
Post-mortem explanation
Most sites explaining the effect are based on screen-space LUTs. pset-ing 128*128 times being very slow,
I got the idea to use tline to draw on the whole screen by considering that function as the converter between normal and polar coordinates.
To get the "normal coordinates" version, try replacing the for calls to w with w(x,0,x,127,p,o,0,v)
I accidentally made the tunnel circular instead of square, can't help explaining this part, sorry.
I got the voxel itch again after so long. This is a tweetcart version of an effect I'll very probably use in the future. The code is slightly altered from what I posted on Twitter because when running a cart without a scene, the camera is not properly reset.
I also added the zoom transition that'll be used, you can see it working by pressing up/down.
Here's the code
q=0 function _draw() camera() if(btn(3))q-=.5 if(btn(2))q+=.5 q=mid(20,q) clv() for z=48,63 do a=t()/6-z/12 r=63-z+q s=16*(1-q/20) o,p=s*cos(a),s*sin(a) col=z%2+33 set_draw_slice(z-q) rectfill(0,0,127,127,col) circfill(o+64,p+64,r*6,0) end set_draw_slice(0) end |
I can't believe it's been almost 5 years I posted that old rotoscale effect here. It's been roughly 5 years that I discovered and loved Pico8, it's a console that stuck on me and that I love to program little bits and bobs on it.
I also can't believe how far the community have gone with that small computer. Just look back and see how much projects evolved on it and how thriving it is after so long. Y'all are so productive and creative you make the BBS and the community awesome!
So yeah, after a few years, I had to touch up that old cart. It was really poorly optimized. Inspired by a few awesome devs, I used a few new tricks based on peek/poke and damn, it goes way faster than I expected. I jumped on the occasion to add translation and a small effect, just because why the hell not.
See ya!
Update 2020-05-05 (or 2020-05-05 for people reading days before months)
Finally got to make it fit under the 0.2 CPU timing limitations (Post binary operations re-re-balance). Big frame time gain of ~50%.
- Increased the spritesheet to 32x32 to only keep a bitmask instead of calling FLR.
- Precomputed a 128x128 pixel map to make up for the bigger pattern (and to make a neat shifting pattern)
- Precomputed the wave effect to avoid doing the calculation too many times
- Extra color shenanigans because why not?
- Slowed down the scrolling and zooming. Bumping up the wave shift to amplify its visibility.
Hello there, after a positng a sketch variation I did on Twitter earlier today, I was asked how one would do such a similar result.
So instead of a badly written Twitter thread, let me post you a badly written BBS post with a badly written (but well commented) breakdown on how I did it.
The spiral is a cylinder sliced in a few circles I offset on X and Y based on a formula. This formula varies with time and on which circle it'll yield the offset to (here, the index).
So, I progressively iterated from nothing to the spiral. Here's how I broke it down:
First I generate circles made by vertices I'd store aside. Drawing circles this way will allow me to the other steps. Each circle is drawn by drawing a segment between two consecutive vertices in the circle and by linking the same vertex between two consecutives circles. Here, it looks like a colored spider web.
Then, I made the circles' center move based on the time. But it still doesn't look like a spiral. We can do better.
So I make each circle's offset move indenpendtanly. I draw the circle in a for i=1,n
loop, so I can use i to have a different result per circle. Here I just add an offset to the sin formula to make each center different from the others.
By doing the same on the y axis, I'd have a diagonal if I would use the exact same formula. The complement formula to draw a circle based on T with sine is cosine, so for the y offset I used the same formula but with sin turned into cos. Now each center moves into a circle.
I can perfectly tweak both formulas differently. For instance here, I removed the x offset and made the y offset in a way so circles will cross some of their neigbors. It'll be useful to give a better sense of depth in the next step
And, as a last step, I replaced the line drawing by drawing quads with the trifill routine generously made by ElectricGryphon so we have a solid tunnel instead of a wireframe one!
And that's the core basics on how I made the Nuclear Throne inspired vortex sketch a while ago! I'll be leaving the commented code on the bottom of this post, feel free to have a look on how I did it, but here's a fair warning: I clearly didn't optimize the code, there is still a lot that could be done to avoid useless calculations, but it should be clear enough to allow quickly anyone to hack it, it works and in 30 FPS. Have a nice day and happy 32 colors day!
r=rnd function _draw() srand(1) clv() for i=0,32 do ot = r(16)-8 tf = flr((t()+ot)*16) op = r() c = 96+r(7) sh = r(4)+12 z = r(63) yb= r(127) for x=0,48 do h = sin(x/48)*5+6 X = (x + tf)%128 y = sin(X/96 + op) * sh + yb line3d(X, y, z, X, y + h, z, c) end end end |
Alternative version
r=rnd function _draw() srand(1) clv() for i=0,32 do ot = r(16)-8 tf = flr((t()+ot)*16) op = r() sh = r(4)+12 z = r(63) Y= r(127) for x=0,48 do X = (x + tf)%128 y = sin(X/96 + op) * sh + Y line3d(X, y, z, X, y + sin(x/48)*5+6, z, 96+7-(z/9)) end end end |
c=cos s=sin l=sphere v=8 M=2 m=-M function _draw() clv() for X=m,M do for Y=m,M do for Z=m,M do T=t() a=T/8 W=c(a) w=s(a) V=v*(1/T+1)+W+w x,y,z=X*W-Y*w,X*w+Y*W,Z x,y,z=z*w+x*W,y,z*W-x*w x,y,z=x*V+64,y*V+64,z*V+32 l(x,y,z,5,224-16*flr(y/16-2)) l(x,y,z,4,13+X+Y+Z) end end end end |
Hello, I'm trying to port over some libraries to kickstart prototyping on voxatron (such as 30log or cpml) and I got a weird issue with functions not finding an upvalue.
Let's say we have a B.lua file and a A.lua file
B.lua contains this:
B = {}
B_mt = {}
local function new()
return setmetatable({}, B_mt)
end
function B.new()
return new()
end
function B.draw()
print("Called",0,0,7)
end
B_mt.__index = B
function B_mt.__call()
return B.new()
end
B = setmetatable({}, B_mt) |
It's basically a global class-ish definition with a constructor, an alias to the constructor via __index and the private constructor which is called internally.
Let's say we have an A.lua script which does:
local b = B()
function _update()
end
function _draw()
b.draw()
end |
It simply gets a B instance and calls its draw function yet it doesn't work on Voxatron 0.3.5. I don't know what are the private/public global/local stuff available on this platform but this kind of pattern doesn't work well. I get this kind of error.
In vanilla lua, it works pretty well, I can use dofile or require sequentially those files and call _draw() without error.
So I don't know if it's an error or a quirk designed by Voxatron limitations, but I'd like to know if it's intended and what are the extends of using local/global variables between scripts in Voxatron.
Thanks and have a nice day.
Edit : I'm calling those pseudo-modules because as we don't have Lua's module system, there are a few patterns that allows for psuedo modules to happen. They're just loaded during the cart initialization and in a sequential manner.
Edit 2 : For further indication, this is cpml's way of making classes.
I had to recreate my Sphere on Voxatron. I wandted to see how it'd look. I don't have a fillp routine yet, but I feel already happy with how it looks.
I didn't redo the white HUD tidbits for a specific reason : I haven't got to determine the good processes to make good HUD. The "Core status" part looks not as good as I expected.
Hey there. I'll be writing down a few things I'm discovering while taking a bite off the brand new Voxatron update. Scripting API was a long-awaited feature and I'm definitely excited to give a new spin to Vox.
Disclaimer
I'm writing this post while playing with the alpha 0.3.5b. Stuff I'll be writing can and may change over versions.
Script organization
As a script is a component like others, you can perfectly use them in an actor as well as an animation or an emitter. update and draw are called when an actor is updated or drawn.
A script has a basic encapsulation system. Local "top"[^1] variables are indeed locals to the script and globals are shared over scripts. Yeah, you read that perfectly. You can perfectly have "library" script pieces that are just there to hold your functions akin to a Pico8 code tab as long as the desired functions or variables are global.
Note that if the script has _draw and _update, they take precedence over Voxatron's routines, even if they're not placed in a room. I'm linking a cart that stores two script pieces, a few circle drawing routines and a script having _update and _draw. Feel free to download it to see how it goes. As you can see, the room is totally blank and isn't actually rendered at all.
I don't know if there are "rules" for loading or executing or ordering the scripts pieces yet, but it looks quite promising. You can have behavior code for an actor, an advanced particle emitter to add tidbits to a creature or even take over voxatron's rules temporarily to implement some logic over it (for instance a battle engine to intrrupt your RPG players with some slimes? :D )
Colors
Colors are actually spaced over the [0-255] range sparsely. I'm linking a demo so you see them. Press up or down to change the bottom layer to see which colors are transparent. The 0-15 colors are the good old Pico-8 palette where the 16 and 32 color row looks like complementary colors. There are two nice gray gradients at 80-85 and 86-91.
The (interesting) transparent colors are at 160-168, 192-200 and 224-255.
Properly making global/local functions
In 0.3.5 there is a scoping issue as seen there that raises when trying to use a local function through a function set to a variable.
For instance trying to make a globally accessible class named B where one of the class (or object)' members in a script like this:
B = {}
local function new()
return {draw = B.draw}
end
function B.new()
return new()
end
function B.draw()
print("Called",0,0,7)
end |
will not properly find the local function new for unknown yet reasons. I suggest to create the global variable as-is and wrap the rest of the code in a do ... end block. It'll properly set the upvalues scoping and will fix the issue.
Making libraries
As there are a few quirks around how Voxatron loads code, there might be the need to make a few conventions to make easily shareable code.
- As mentioned in the previous point, there is a current scoping issue, so the best route would be wrapping as much code in a do/end scope, if not the whole script object.
- Currently, when exporting objects or folders, the resulting cart uses as label the BBS label of the currently loaded cartridge (the object seen in the Metadata tab). That could be a fancy way to give an identity to your library
- An idea for organization is having a README script only to contain your licence. You can do comment blocks by wrapping your comment in
--[[ <your code> ]]. - You can directly export folders. That can be quite useful to export multiples scripts easily.
Random API bits
- set_draw_slice also takes an additional boolean argument to determine if you want to draw the Pico8's slice on a XY plane (flat) or XZ plane (vertically in front of the player). If it's true, it'll use XZ and will draw the top 64 rows of Pico8's buffer, else (false or nil) it'll draw on a layer like before.
- From what I tested, stat seems to work here and there. Looks like the CPU and memory usage functions seem to work. I have yet to test the rest
Footnotes
[^1]: I can't find a better way or word to explain, but any kind of variable that's not already in a scope like a do/end, a function, a condition, a while loop or a repeat.
View Older Posts
