Log In  
Follow
Eiyeron

I don't post everything I did on Pico-8 here.

You can also check out my gallery too.

[ :: Read More :: ]

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!

P#144462 2024-03-25 20:58 ( Edited 2024-03-26 19:44)

[ :: Read More :: ]

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's open_file intention get the same exception than save_file_as if 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.

P#143779 2024-03-18 23:02 ( Edited 2024-03-19 11:55)

[ :: Read More :: ]

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.

local default_anim_path = "/desktop/untitled.anim"
--local default_gfx_path = "/ram/cart/gfx/0.gfx"
local default_gfx_path = "/dev/platformer.p64/gfx/0.gfx" -- My current project

function get_or(tbl, key, fallback)
    return tbl[key] or fallback
end

function extract_args(argv)
    local anim, gfx = default_anim_path, default_gfx_path
    if not argv then
        return anim, gfx
    end

    local index = 1
    while index < #argv do
        if index == "--gfx" then
            local gfx_arg = get_or(argv, index + 1)
            if gfx_arg ~= nil then
                gfx = gfx_arg
                index += 2
            else
                index += 1
            end
        elseif index == "--anim" then
            local gfx_arg = get_or(argv, index + 1)
            if gfx_arg ~= nil then
                gfx = gfx_arg
                index += 2
            else
                index += 1
            end
        else
            -- Guessing from extension
            local arg = argv[index]
            local parts = arg:split(".")
            local ext = parts[#parts]
            if ext == "gfx" then
                gfx = arg
            elseif ext == "anim" then
                anim = arg
            end
            index += 1
        end
    end
    return anim, gfx
end

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 colors 1, 6, 7, 13 to 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 /system folder 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 in filenav.p64 enables text wrapping using the clip() rect.
  • /ram/system contains a few neat stuff like processes.pod which 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 ps and kill. 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 with palt or other mechanisms turn transparent, so you can see what's behind your window. Thanks @taxicomics for the report.
P#143405 2024-03-17 00:22 ( Edited 2024-03-23 10:35)

[ :: Read More :: ]

Cart #eyn_raybase-1 | 2021-05-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
2

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.

P#92849 2021-05-31 18:21 ( Edited 2021-09-13 11:50)

[ :: Read More :: ]

Cart #eyn_3dmaze-4 | 2021-05-29 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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) :

Contains mild horror stuff (eyes, bloddy mouth). No screamer though.

P#92767 2021-05-29 09:05 ( Edited 2021-05-29 10:40)

[ :: Read More :: ]

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.

Cart #eyn_smplsndbx-0 | 2021-05-07 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
10

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.

P#91665 2021-05-07 22:36 ( Edited 2021-09-13 11:49)

[ :: Read More :: ]

Cart #eyn_sprintagift-2 | 2020-12-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
8

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.
P#85186 2020-12-09 07:41 ( Edited 2020-12-12 18:06)

[ :: Read More :: ]

Cart #eyn_fade_gen-1 | 2020-08-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
9

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
P#81392 2020-08-31 11:43 ( Edited 2020-08-31 21:48)

[ :: Read More :: ]

Cart #quasi_tunnel-0 | 2020-08-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
6

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.

P#80961 2020-08-19 19:01 ( Edited 2020-09-03 21:46)

[ :: Read More :: ]

Cart #tc_vortex-0 | 2020-04-08 | Embed ▽ | License: CC4-BY-NC-SA
5

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
P#74558 2020-04-08 10:15

[ :: Read More :: ]

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!

Cart #new_roto-2 | 2021-05-05 | Code ▽ | Embed ▽ | No License
10

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.
P#73789 2020-03-09 20:12 ( Edited 2021-05-05 17:15)

[ :: Read More :: ]

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!

Cart #colored_spiral-0 | 2019-09-04 | Code ▽ | Embed ▽ | No License
7

P#67245 2019-09-04 18:50 ( Edited 2019-09-04 18:56)

[ :: Read More :: ]

Cart #fishes-1 | 2019-05-11 | Embed ▽ | License: CC4-BY-NC-SA
1

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

Cart #fishes_alt-1 | 2019-05-11 | Embed ▽ | No License
1

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
P#64332 2019-05-11 20:33

[ :: Read More :: ]

Cart #sphere_cube-1 | 2019-01-08 | Embed ▽ | License: CC4-BY-NC-SA

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
P#60688 2019-01-08 19:47 ( Edited 2019-01-08 19:49)

[ :: Read More :: ]

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.

P#60532 2019-01-03 16:28 ( Edited 2019-01-03 16:40)

[ :: Read More :: ]

Cart #sphere_vox-1 | 2019-01-02 | Embed ▽ | License: CC4-BY-NC-SA
3

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.

P#60455 2018-12-31 10:31 ( Edited 2019-01-02 22:49)

[ :: Read More :: ]

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.

Cart #doyumogeka-0 | 2018-12-31 | Embed ▽ | License: CC4-BY-NC-SA
5

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.

Cart #sinihojoni-0 | 2018-12-31 | Embed ▽ | License: CC4-BY-NC-SA
5

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.

P#60452 2018-12-31 10:10 ( Edited 2019-03-13 14:01)

[ :: Read More :: ]

Update : I don't think my cart is very usable. Possily math issues and globally unoptimized process won't make it a decent base for games or sketches. I'll hold further dev of it for now. Check instead freds' version istead, it seems pretty more promising Here be dragons.

Hello everyone, I'll be posting my 3d (+extra) toolkit here. Been a while I haven't touched it until a few days ago. I could even optimize it further than before (at the expense of a few things).

The cart is a basic demo of what it can do, I'll be writing a few more explanations (and a link to a Blender export tool) later, if you don't mind.

What's supported (or inside the pipeline):

  • wireframe/flat/light shading (ambiant+light power+light direction)
  • backface culling
  • zsorting (thanking a few people for offering good heapsorts)
  • Translate/Rotate/Scale per object
  • basic vector/matrix library

What's not supported

  • Proper frustrum culling (put a mesh behind the camera and see the disaster)
  • Texturing

What's maybe planned

  • Mesh compression (not yet planned)
  • Vertex keyframing (still wondering how to make it the quickiest)

Extra features

  • The water/reflecton effect you all loved in my demos (with palette indirection)
  • record utility to quickly record a number of frames

Cart #54374 | 2018-07-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
10

P#54375 2018-07-24 02:23 ( Edited 2018-07-25 05:12)

[ :: Read More :: ]

Cart #48271 | 2018-01-17 | Code ▽ | Embed ▽ | No License
7

Hello everyone, after a Twitter thread of WIPs and half posted routines, I'm releasing this cartridge containing a few routines to allow making basic split-screen scenes relatively cheaply (around 20% of CPU used at max and 8KB of RAM used as back_buffer.

This isn't a pretty scene or sketch, it's at most minimal, but it shows that you can have two scenes drawn and draw them with a non-axis-aligned delimitation. Is anyone remembered of the DBZ SNES/Genesis fighting games? :D

-- Available functions:
- cpy_to_buffer : saves the current state of the VRAM to the back-buffer
- drw_horiz_half : draws the back-buffer on the top part to the screen, with the limit being a line located on ([0;y1],[127,y2])
- drw_vert_half : draws the back-buffer on the left part to the screen, with the limit being a line located on ([x1;0],[x2,127)

Have a nice day!

Addendum : two more things

  • It doesn't do bound check, so beware if you go out of [0;127]
  • There probably is space for optimization, sorry for the ugly code.

Update :
I did an update fixing the horizontal split code, cleaning a bit here and there and applying Felice's array indexing idea (thanks!) And I did a small demo to show a bit better what it could like than just two plain screens.

P#48239 2018-01-16 10:13 ( Edited 2018-01-17 16:48)

[ :: Read More :: ]

2020 Update : Hello there.

After looking at people making stuff with subpixel lines, I challenged myself to improve that old favorite cart of mine to replace most of its drawing with those sleek lines.

I threw away a lot of things, namely the "math library" I used to have. Turns out that most of the CPU was caused by this and a less optimal management of variables and memory. Cutting down the useless code and the slower practices, I could shave off 10k chars, ~45% of CPU and leave enough CPU time to let the front lines be drawn with subpixel rendering and still take less CPU than the original version. Wow.

Cart #eyn_sphere-1 | 2022-04-04 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
13

Leaving the old version and the old post here. See ya soon!

Cart #47484 | 2017-12-17 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
13

Hey there, here's another sketch I did a few days ago. After playing a bit with it, I don't have any ideas for it right now. (Also first cart from me with a perspective projection, I took the occasion to fix a bit my vec/mat library.)

Have a nice day!

P#47487 2017-12-17 17:17 ( Edited 2022-04-04 12:18)

View Older Posts
Follow Lexaloffle:          
Generated 2024-03-28 12:51:47 | 0.111s | Q:87