PICO-8 - have some development fun

[MartyG]

Well we don't get a lot of traffic in this sub-forum, but I've been mucking about with this for a little bit, and it's something I think is worth taking a look at if you've fancied having a go at doing some simple game dev, but thought it might be too intimidating.

Yes, I've got 25 years odd programming, analysis, and design behind me (which admittedly does help), but I've never coded in LUA before looking at this (which is what the system is based on).

It's function-based and sits within three main functions: _init, _update, and _draw - the first of these is called at the start and the others run on a 30 FPS loop. You can keep things tidy by creating your own funcs called from these, and can add code tabs to separate out your different game sections (so, player logic, enemy logic, etc.).

It's all self-contained (although you can use external IDEs with #includes in the main app), and it has a sprite editor, tile mapper, sfx, and music editor all within, along with the code window for doing your logic and game updates.

You have to do everything for yourself (well, apart from basics like screen rendering, and base IO stuff), but you define sprite placement, keyboard input, collision detection etc., and of course an idea. Whilst not exactly original, I was able to knock these two up in a couple of hours each from scratch, referencing the documentation here and there.



PICO-8 is a paid-for engine (it's £15, nothing else after that, and it's sometimes bundled on itch.io). Generally, people just put their games up for fun for free, although there's nothing stopping you from selling P8 carts (and some have been).

I definitely recommend having a tinker.

You can play them both here if you really want, but don't go expecting that much

Both of mine are released under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license, so feel free to tinker underneath.

[MartyG]

Knocked up a breakout clone in a couple of hours this afternoon. I really am quite impressed by PICO-8 - I reckon once you get the hang of how it all fits together (and the basics are pretty easy to pick up), you'll be able to do quite a lot of different 2D sprite-based stuff.



You can do 3D stuff in the engine, but you're going to have to do all the matrices maths on your vectors and work out the occlusions yourself in the game loops. I might have a go at this later, See if I can remember all the stuff from trying to write mini-demos on the PC back in the uni days in C++.

[MartyG]

Okay, I'm nearly ready to write Elite in Pico-8



I have stuff rotating and moving using some geometry mathematics, so really it's just a matter of rotating these in 3D space rather than 2D space - then I have the ability to draw a wireframe 3D image - it's a little bit more complex trying to work out hidden points, especially if you have a free camera, as you need to know which points are occluded, and only draw the lines to the point at which they intersect.

This is why early 3D games used simplified wireframes - it was easier to draw and didn't require a load of maths to work it all out which could get complex and take a lot of CPU to do, but it's fun going back to old skool coding again, rather than relying on the complexities of engines that do everything for you.

Next step here those is to flood fill the shapes and work out Z-order occlusion (if you're flood-filling, it's probably just a matter of draw order, but I could add a DZ component with max/min height, and draw filled shapes based on the z-order value. Pico-8 does have a rect and rectfil command, but this can't be used with rotation (so it's just 2 x/y points of diagonal corners).

Edit - seems a flood-fill is a solved algorithm, basically you just have to work out if a point is inside or outside of the edges of your polygon.

[Brad]

Okay, I'm nearly ready to write Elite in Pico-8

Edit - seems a flood-fill is a solved algorithm, basically you just have to work out if a point is inside or outside of the edges of your polygon.

Literally the first algorithm I had to write as a professional developer! Managed to find a screenshot of it in action. I needed to fit as many shapes as possible into sheet metal:

[Brad]

You're luring me to trying out this Pico 8...

[MartyG]

It has its limitations (which is kind of the appeal of it really).

I don't think you'd be able to do texture maps with it, the pallet is limited to 16-colours, possibly you could map an image to those 16 colours and try and fill based on that, but I don't think it'd be particularly easy to do.

Ok, well it's kind of textured: https://www.lexaloffle.com/bbs/?tid=46037

So kind of possible (there's a link on the last post in that thread, to a Ray Marcher done in PICO-8) - slow, but impressive nonetheless.

If you can do the maths, then is seems that LUA isn't as big a limitation as I anticipated.

[gunrock]

Edit - seems a flood-fill is a solved algorithm, basically you just have to work out if a point is inside or outside of the edges of your polygon.

Yeah, but it gets more problematic once you get concave edges to your polygon - unless your algo covers that?

[Brad]

I'd be interested in how the algorithm works. Mine had no problem with curves but I doubt it was particularly fast, although it was back in the days of 50mhz 486 CPUs so it had to be fairly quick (written in C)

[MartyG]

Yeah, but it gets more problematic once you get concave edges to your polygon - unless your algo covers that?

It does, if I flip the points about so it looks like a bow tie, it fills - it's not my algorithm tho, as I pulled and tweaked it from elsewhere - like I said, solved problem so someone else has done most of the hard work already.



So it should work with any poly, given it's done with point-to-point lines (i've just added a 5th random point here to the array to show it)

There's really not that much to it honestly

function draw_polygon(points, colr)
    local xl,xr,ymin,ymax={},{},129,0xffff
    for k,v in pairs(points) do
        local p2=points[k%#points+1]
        local x1,y1,x2,y2,x_array=v.x,flr(v.y),p2.x,flr(p2.y),xr
        if y1>y2 then
            x_array,y1,y2,x1,x2=xl,y2,y1,x2,x1
        end 
        for y=y1,y2 do
            local d=y2-y1
            x_array[y]=flr(x1+(x2-x1)*(y-y1)/(d==0 and 1 or d))
        end
        ymin,ymax=min(y1,ymin),max(y2,ymax)
    end
    for y=ymin,ymax do
        rectfill(xl[y],y,xr[y],y,colr)
    end
end

You just work out the areas that need filling based on the intersects, and then rectfill the items in the array, (I believe this is based on the odd-even rule). Prior to this I've done the point rotations based on the distance from a pivot point and angular change, then applied the dx,dy change, checked for the boundary hits and multiplied the dx/dy by -1 where needed to reverse direction. The z-order is just down to the order in which I've draw the polys.

You're flooring floats into integers, so there's probably scope here for the fills not being completed in the right place, but the resolution is small enough for it not to be noticeable in the most part.

Seems there are Lua libraries out there for doing a lot of this already: https://www.rockbox.org/wiki/PluginLuaModules (not sure if you can get to the source code, but I'd imagine the algorithm is similar to the above).

You'd probably need to tweak them a bit to get them to work (or fit) within the Pico-8 framework, but it's fun putting this stuff together from scratch, like I mentioned before.

With all the off the shelf engines, you don't really have to think about how it all works under the hood these days, so I think something like Pico-8 gives you a greater understanding of the compexity underneath it all, whist still being relatively friendly coding wise (maths aside, the syntax is easy enough to pick up).