Log In  

@Eiyeron

Follow
Follow

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#] | Code | 2019-09-04 | No License | Embed
4

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

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

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 | No License | Embed

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

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

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)

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)

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

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.

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 | License: CC4-BY-NC-SA | Embed
3

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 | License: CC4-BY-NC-SA | Embed
3

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)

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#] | Code | 2018-07-24 | License: CC4-BY-NC-SA | Embed
9

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

Cart [#48271#] | Code | 2018-01-17 | No License | Embed
5

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)

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

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 2017-12-18 19:47)

Cart [#47376#] | Code | 2017-12-14 | License: CC4-BY-NC-SA | Embed
7

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

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#] | Code | 2017-12-12 | License: CC4-BY-NC-SA | Embed
7

Cart [#47322#] | Code | 2017-12-12 | License: CC4-BY-NC-SA | Embed
7

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

Cart [#46544#] | Code | 2017-11-21 | No License | Embed
9

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.

Sorry.

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

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

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)

Cart [#43893#] | Code | 2017-09-03 | License: CC4-BY-NC-SA | Embed
3

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#] | Code | 2017-08-24 | License: CC4-BY-NC-SA | Embed
5

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)
Cart [#43574#] | Code | 2017-08-24 | License: CC4-BY-NC-SA | Embed
5

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

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

Just a small sketch for a moody day.

Alternative version

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

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

Hello everyone, this is just a small thing I did for Pixel Dailes.

Controls :

  • Left/Right : Move cursor.

I didn't do anything else than just this screen, I was mostly interested in throwing the bases. I might touch it up later but that's unprobably (unless people are interested in working on it together...)

Cart [#35338#] | Code | 2017-01-09 | License: CC4-BY-NC-SA | Embed
7

(Older version, music-less)

Cart [#35269#] | Code | 2017-01-08 | License: CC4-BY-NC-SA | Embed
7

Have a nice day!

P#35270 2017-01-08 15:31 ( Edited 2017-01-09 15:32)

Cart [#21775#] | Code | 2016-05-30 | License: CC4-BY-NC-SA | Embed

Hello everyone, been a while I haven't done some PICO so there it is. It's a reboot of a years old dropped calculator project I wanted to do with a friend : an Epic Coaster demake. It's some sort of theme-park themed Canabalt self-proclamed tribute. Let's see how far you (and the developper :p ) will go! o/

Well, for now, I succesfully nailed (for once) physics and I also did some eyecandy, so everything should follow quite smoothly, like the whole game state, more platforms and stuff.

Instructions : Z to jump.

Changelog:
-0.02

  • Added an initial platform
    • Added gameover/replay just after
    • Fade animation
  • 0.01
    • Initial version
      Older versions:
  • 0.01
    Cart [#21393#] | Code | 2016-05-26 | License: CC4-BY-NC-SA | Embed
P#21394 2016-05-26 08:41 ( Edited 2016-05-30 13:08)

Hello everyone, time to show you another project I just made last night : a stack-based Window Manager (WM), cleverfully named StackWM.

A WM is a program or library to manage windows, dispatch events/interactivity to them and draw them. THink of your Windows/Linux/Mac's windows. So yeah, that's totally overkill and eating most of your cart space but it was fun to do and it put me on the tracks for another unrelated project.

Sooo... What does the WM do?

  • Update/render events
  • Window render context :clipping and camera offsetting to limit the renderer to the window's area:
  • Focus or Global events : both aren't exclusive, you can manage both of them on one window.
  • Button/Buttonp events : global or focused (available only if the window is focused)
  • There is always one focused window. THere are helper functions to switch focus to another window.

What do I plan or think of adding to StackWM?

  • Easier customisation? (colors? booleans to set functionnalities like notitle, grabbable, resizable?)
  • Mouse support (emulated with pressing arrow keys and a button for click) and interaction support? (Click+grab on title -> grab window? CLick on close button : Close event?)

And here's a demo to show what I can do with StackWM. That's maybe a simple game but with time, better examples could be done. Have Fun!

Cart [#12218#] | Code | 2015-08-03 | No License | Embed
7

P#12283 2015-08-04 16:05 ( Edited 2015-08-10 12:25)

Cart [#10086#] | Code | 2015-04-21 | No License | Embed
11

Hi everyone! Here goes my first submitted thing : a recreation of the good old rotoscaling effect, quite known in the demoscene... scene... in way less than 1kb of code. I made it fit to a round 1kb by comments in the source code to explain some tricks about the calculation.

Rotoscaling is based on two things : rotation (good old cossin sin-cos) and scaling. I precalculate scaled sine and cosine tables according to the current angle in the update loop to gain some overall speed.

I programmed it on the alpha 0.0.5. I don't know if anything changed around to the speed/cpu usage but this should run quite quickly (don't expect 30 FPS neither, I couldn't make the pixel blit faster) on the 0.1 alpha.

I really liked playing with PICO and I'm not done at all with it! :D

P#10087 2015-04-21 13:14 ( Edited 2015-05-10 15:42)

About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2019-09-20 22:39 | 0.152s | 4194k | Q:271