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.
0 comments
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.
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
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.
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.
Leaving the old version and the old post here. See ya soon!
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!
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 :
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.
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)
View Older Posts
