Log In  

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

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?


  • (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)

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

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.


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


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)

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

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)

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

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

function _draw()
for z=48,63 do
P#74558 2020-04-08 10:15

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-0 | 2020-03-09 | Code ▽ | Embed ▽ | No License

P#73789 2020-03-09 20:12 ( Edited 2020-03-09 20:14)

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

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

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

function _draw()
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)

Alternative version

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

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

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

c=cos s=sin l=sphere
function _draw()
for X=m,M do
for Y=m,M do
for Z=m,M do
P#60688 2019-01-08 19:47 ( Edited 2019-01-08 19:49)

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)

function B.new()
    return new()

function B.draw()

B_mt.__index = B
function B_mt.__call()
    return B.new()

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

function _draw()

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)

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

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)

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.


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

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

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}
function B.new()
        return new()
function B.draw()

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


[^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)

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

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

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

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)

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-0 | 2020-12-01 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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

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

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 2020-12-01 22:22)

Cart #47368 | 2017-12-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I started playing Wipeout HD (Fury) again. I like this series. I had to try to make 3D stuff so here we go, a brand new custom model inspired from HD Fury's Feisar ship.

Once again, thanks to Eletricgryphon for the triangle routine and Rez for the tips

Edit : crammed shading in the cart!
Edit v3 : I got to optimize the mesh, remove a lot of internal faces, allowing me to add way more eyecandy. Wow.
Edit v3b : Added a gridless version.

Previous versions :

Cart #47316 | 2017-12-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #47322 | 2017-12-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#47317 2017-12-12 12:23 ( Edited 2017-12-14 15:23)

Cart #46544 | 2017-11-21 | Code ▽ | Embed ▽ | No License

Hello there. This is a silly cart I did as a result of a inside joke. It started with one of my current avatars being a tracing of a "I REGRET NOTHING" gif with a rotating chicken and it ended up somehow on Pico-8.

Some technical stuff:
So we have 12 frame gif exported into spritesheet/map data with a tool I wrote on the fly to make it possible and took most of the programming time. The tool loads the frames from a gif and split each frame in 8*8 sprites, indexes them to avoid repetition in sprites and gives me the map data of each frame (or better, the map values to be changed from a frame to another, making a frame's data negligible).

I wanted to use the vector tool to vectorize the frames by hand but the lack of overlaying a model image and the amount of frames made me prefer automatically chunking the frames instead...

The end result? Probably my silliest cart yet.


P#46545 2017-11-21 09:50 ( Edited 2017-11-21 14:50)

Cart #44091 | 2017-09-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Another small sketch. This one was inspired by one of Trasevol Dog's projects.

(Note : should I do a thread per sketch or a big thread for storing all of them?)

(Thanks to electricgryphon for their trifill routine)

P#44092 2017-09-11 09:45 ( Edited 2017-09-11 13:48)

Hey there, I did a few weeks ago a mini cart showing how Earthbound or Mother 3 would do most of the background effects.

I redid the whole routine and made two versions, vertical and horiztontal, which should cover a big part of the basics behind those games' technique (the rest being layer blending, scaling, palette cycling, or alternating backgrounds per line).

There are two implementations, sspr-based and map-based. The sspr based uses the data of a sprite at given coords and size to tile it on the screen whereas the map-based routines uses the map routine to directly draw a line of pixels on the screen. The map-based routines uses part of the map data but it makes up for allowing more than one sprite to be used, as you can see with the sample's colored corner areas.

Notes about the implementation:

  • I used time, amplitude, frequency and scale as global variables to make the implementation a bit less repetitive but you can pass them as arguments to the functions to have different settings
  • The map-based routines (map_<routine name>) assume that you're using at least a 16*16 map, but can be bigger. I haven't programmed an iteration allowing to use smaller maps to make it faster (as it'd use more than two map calls per line)
  • The map routines overrides camera and clip settings. Make sure to save their context before using.
P#43894 2017-09-03 10:54 ( Edited 2017-09-03 14:54)

After a few days of making a few sketches around some in-the-books tricks, I got an idea during a dream and decided to make it.

Cart #43572 | 2017-08-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Here's the alternative version. I may use it (or a tweaked version) as a album cover if I will ever do synthwave (or vaporwave, RIP)

P#43573 2017-08-24 03:20 ( Edited 2017-08-25 10:12)

Cart #40544 | 2017-05-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Just a small sketch for a moody day.

Alternative version

Cart #40546 | 2017-05-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#40545 2017-05-13 15:47 ( Edited 2017-05-13 19:49)

View Older Posts
Follow Lexaloffle:        
Generated 2021-04-19 21:47 | 0.170s | 4194k | Q:311