I've been playing around with Floyd–Steinberg dithering in order to achieve more continuous color gradients.
This is slow as molasses of course, and even with optimization I don't think it could be used in a game. But perhaps it could be used in a ray tracer or other, more temporally relaxed image generation applications.
So... one of the things in my tinkering cart that I'm playing with is sprite complexity. The idea here is to associate the player position with the body, then draw the head relative to the player position, and finally, layer the expression on top of the head (unless it's facing up/away), and recolor as appropriate. It's not just the player that'll be using the build, but many enemies and NPCs as well, of course, so I'm trying to plan a "DRAWBODY(..)" function to draw the whole thing in one swoop.
So far, I'm thinking important factors are:
-x and y positions
-body frame
-colors of body
-relative head x/y
-head color/sprite
-eye expression/color
-facial expression/color
...but I get the feeling I might be forgetting something here?
old version:
Here is a cleaned up version of the 3D library that I put together for the Pico Fox game.
The demo code is commented in more detail, but here is the basic gist.
Copy the code between Begin Cut and End Cut. (It's a big chunk.) In _init() function include: --init_3d() --Need to call init_3d() to set up player, camera and lights --use load_object(object_vertices,object_faces,x,y,z,ax,ay,az,obstacle,color_mode,color) to load 3D models into the world --use read_vector_string and read_face_string to generate vertex list and face list from string data In _update() function include: --handle_buttons() -- handle default buttons for player-- this can be overwritten obviously. --update_player() -- update the player with default movement, stopping at obstacles --update_camera() -- update the camera based on player location and direction --update_particles() --update 3D particles if used. (I didn't add any for this demo.) --... --update_3d() -- call update_3d() at the end of the _update() function to transform etc. in _draw() function include: --draw_3d() --render objects into triangles, sort the triangles and draw them onto the screen |

This is the procedural constellation generator from WIZRND, amped up a bit. It's a little fun to flip through some of them, so I've released this standalone as a bonus for #PROCJAM for people who aren't good at being a slippery wizard. ;)
More of a curiosity than a game.
You can play this here: https://topphysicist.itch.io/starrnd
You can play WIZRND here: https://topphysicist.itch.io/wizrnd
Source code is here: https://github.com/mattleblanc/STARRND
Cheers!
(This may sound convoluted)
Is it possible to invoke an embedded ("export html") pico-8 program's functions from an external javascript file?
In this particular case, I wrote a .js app that fetches remote data asynchronously (via ajax). I then want to map that data to a sequence of pico-8 program function names, invoking each one in turn at regular intervals.

Ok. So you can finally update pico8 on pocket chip without having to flash by typing the following in terminal:
sudo apt update && sudo apt install chip-pico-8
Also thought some of you may be interested in the following link regarding a 'console' version of pico8 that is being released for $29.
https://getchip.com/pages/chip

Fly your Arwing to victory in this demake of a certain, iconic SNES game.
Controls:
Arrow Keys: Move ship, Select level in title screen
z/o: Fire
Features:
Filled 3D polygon graphics-- reminiscent of SuperFX chip
3 levels -- select with left or right on the title screen
2 enemy types
Music
Special thanks:
Star Fox Cornerea music sequenced by PJBarnes.com (http://www.khinsider.com/midi/snes/starfox) and imported using kittenm4ster's midi to pico-8 tracker translator (https://github.com/andmatand/midi-to-pico8)

Today i fixed a keyboard issue for PICO-8 running on a rpi3 B + raspbian(2016-05-27).
I use a German keyboard and the "<>" keys weren't displayed neither in console nor in code editor.
This occured with the static linked pico8 binary. ( pico8_dyn seems to work with the sdl version installed here, but runs to slow to be usable in my setup.)
As far as i understand it, it has to do with the keyboard handling of SDL. SDL seems to drop unknown keycodes.
I could observe an error message like:
INFO: The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <[email protected]> EVDEV KeyCode 86 |
Creating a custom xmodmap file did not work. My custom keyboard mappings weren't recognised. So i tried to handle it a level closer to the keyboard and created a custom xkb mapping.
I copied the current used layout
cp /usr/share/X11/xkb/symbols/de /usr/share/X11/xkb/symbols/de_pi |

I feel like it hasn't been said out loud that _init() seems like it breaks the normal rules of scope.
The below code works fine, printing out the string stored in a:
function _draw() cls() print(a,10,10) end function _init() a="yo" end |
edit: Technically, no rules are broken, as _init is called first, and since the variable assignment isn't local, it refers to the variable in the global scope, so it all works out.
But it still feels weird.

That was a requirement, for me, to have splore working as it is intended to, the problem is, there is no internet connexion, and I can't use my phone tethering as it wasn't in a location where I can use it.
The problem is, we can use splore for exploring folder, but you will have all the other part to be not working because, of course, no internet access.
After some quick test while using PICO-8, I finally found how it get data from lexaloffle servers, at least I found something, but there were missing informations.
The way ZEP have made that is in fact quite clever, as he used something similar as the way we save carts, all the data are transferred in the form of pictures, when PICO-8 request a new cart set from the BBS it receive a PNG file. The clever part is, it's not done the same way, but data about the cart is also stored in the picture in a similar way as it is done on the cart, it took me a couple of minute to figure how it is working.
As all my Pi (I manage to get 4 of them running during the convention) were to be connecter on the same network + a pocket chip on wifi, I took some standard network hub & wifi ap for that, nothing really fancy, but the tricky part was to make sure that everyone speak the same thing and especially that any device can connect without the need to spend hours in network configuration, especially because PICO-8 use hardcoded values to search for lexaloffle servers, so I had to trick it for that.
After some time spent on searching for a solution, I was going to use all the big tools for DNS/DHCP because haven't found a proper and simple tool, it was just when I read about dnsmasq which was the exact tool I needed for the job.
dnsmasq is a simple tool that provide:
- DHCP
- DNS cache and server
all of that using simple text file for the configuration (for those who have to install and configure a Bind server, you know how easy is it to configure this beast! :D)
So the next step was to install this tool on the Raspberry Pi that was to be used as the main server, and copy configure it to at least give proper name to my device that I was going to connect so I was able to remote connect on them without any hassle.
The last step was to make the offline BBS itself, it took me a couple of hour to have something that was looking like it's working, but hand't a PICO-8 to test, so I had to wait a little bit, and it worked on the first try.. :D
Where I was really impressed is my search is way more faster than the one the official BBS, but as my search is only done on cart name, I suppose that the official one, is going that on the full content of the BBS, including posts, that may explain the slight different in generating the answer.
My offline server also honour the "Featured" category, but with a really different algorithm. My server know how many times a cart has been requested by a PICO-8 and will use that metric for the featured list. Maybe not the best, but as there is no real BBS with the favorite star button, I can't use that.. ;-)
The other part of my offline BBS was to make a tool to dump the BBS, there are already some tools that you can find, but they way they get the cart is a bit clumsy and it does not work well, the one I've made was using my knowledge on how the BBS is working and use the same mechanism as what PICO use to get data from the BBS.
As a proof it is working here is a dump, in form of an HTML page, of the dump I've made just before the convention that has been used during the weekend:
http://box.godzil.net/~godzil/pico8/

WIZRND, a pico-8 contribution to #ProcJam 2016 (https://itch.io/jam/procjam).
arrow keys to move
up to jump
down while standing to channel a shield
z to shoot lightning, x to shoot a magic missle
You can play it on itch.io here: https://topphysicist.itch.io/wizrnd
... or on github here: https://mattleblanc.github.io/WIZRND/
The main idea behind this project was to learn about developing for the PICO-8 platform -- although I have some programming experience, I've never made a game before. My goals were to simply make anything that was remotely playable, which actually didn't take that long.
Since I'm interested in procedural generation anyway and didn't have a lot of spare time to make a game in, contributing to #ProcJam was the perfect excuse for me to actually learn how PICO-8 works. Turns out, it's super fun and very straightforward.
The source code is freely available here: https://github.com/mattleblanc/WIZRND
This is my entry to ProcJam 2016!
Feel free to have a read on the code of this thing. The voxel drawing part should be very easy to extract from the rest.
The first quarter (first spritesheet tab in the editor) serves as a map for the voxel drawing, using layers of 16x16 pixels.
The island is generated using custom cellular automata, each layer being a new step based on the previous one.
The seasons are all about reading the voxel map and replacing the colors.
The name generation is [b]super rudimentary






4 comments





















