Mine your way to fame and fortune in a continuously generated 3D voxel world. But keep an eye on your energy level and make sure you can find your way back through the deep and twisted caves.
s,f: turn left and right
e,d: move forward and backwards
lshift or z: jump (hold to jump higher if upgraded)
The mouse is required for mining and building.
Click on shop computer to enter store menu. Ore and gems will auto-sell.
With laser selected, click and hold on a block to mine it. Circular progress bar will indicate how long is left. Precious ores will take longer to mine.
With a placeable block selected, click on the side of an existing block to place a new block.
Energy will deplete when moving, jumping or mining. The battery can be recharged by standing on the glowing yellow charge squares near the shop. When your energy goes to zero, you will lose most of your money and be teleported back to the starting point.
- The GPS or Far View are good investments early on because it's easy to get lost.
- Be very careful about falling into caves. They may go very deep and getting back home before energy runs out could prove a challenge.
This game uses a modified ray-casting engine based on tutorials from (https://lodev.org/cgtutor/raycasting.html). This was extended to work with voxels, reading in a local 3-dimensional map array.
The map is generated dynamically as the player moves around. However, it is set up such that the same block will always exist at the same x,y,z coordinates. In addition, there is a user map that is used to store the locations of blocks that the user added or removed. These are essentially stored in a sparse matrix.
There is currently no way to save your constructions. It might be possible to save some aspects of the world with the persistent cart data, but I don't know that 256 bytes will be sufficient. Clipboard import and export might be a better way to allow folks to share creations.
The code is a dog's breakfast. Token count wasn't really a problem for me on this one, but it was a struggle to keep frame rate acceptable with the world rendering code. I'd love to be able to increase the view depth without dropping to 15 FPS.
Take a stroll through the swirly bits of my imagination.
--Image size: 1536X128, 2 bit
--Scanned from a drawing and imported into Pico8.
--Utilizes RLE encoding as well as storage in both strings and sprite page
Here's a Pico-8 ray tracer with the amazing ability to render both spheres AND planes.
Let it run all the way through even though the colors will be funky at first. After it renders the image, it will switch to high-color mode.
-NEW High Color Mode
-Diffuse and Specular Shading
These things always get stuck in my socks when I go hiking.
I've been playing with a z-buffer 3D rendering implementation, which lends itself to recursive additive fractal structures.
My ultimate plan was a static landscape renderer, but this was an interesting (if sluggish) detour.
Pilot your state-of-the-art RAH-66 Comanche helicopter over once-peaceful tropical shores. Take on an endless barrage of enemies and leave their wreckage littering the voxel landscape.
The engine and overall game is inspired by the Comanche series from NovaLogic.
--Voxel landscape engine (as seen in Tera Firma tech demo)
--Shaded 3D polygon enemies
--Awful self-made music and sound effects
z: Fire Missiles
x: Fire Mini Gun
tab: Enable Mouse Control (left button fires gun)
Here's a landscape / flight simulation engine that I have been playing with. I'm still figuring out how to turn this into a game, but at least it's functional now and runs at 30 fps.
It takes a few seconds to generate the map using simplex noise mapped onto a sphere.
Arrow keys to turn and pitch up and down.
Z-key to accelerate
There's a 3D shaded polygon engine built into this as well, but I'm not using it yet.
Thanks Anthony DiGirolamo for the simplex noise:
Playing around for the text jam using Signed Distance Functions. It's not really fast enough for anything other than a proof of concept for textifying grayscale images.
I've become unhealthily interested in image compression on Pico8.
Hit the "z" key to see the next image.
What we have here is something that might resemble the JPEG compression scheme if you squint.
Compression goes like this:
--Discrete Cosine Transform + Quantatization
--Zigzag encoding of blocks
--Run Length Encoding
--Conversion to a base 64 character set
--Overall compresses to around 1/5 of original 8-bit grayscale size.
What didn't work well:
Image quality is kinda low. There are only about 16 levels of gray that are discernible on pico8 with dithering. Not sure that it makes a lot of sense to encode 256 shades of gray in that case. Not to mention that the image quality at 64x64 is pretty lame to begin with.
This path may be a dead-end because I can only get about 12 64X64 images in here before hitting compressed code limit. If I drop the base 64 coding, I could fit maybe 10 images into the sprite area... Because Pico8 compresses data as well (definitely with better algorithms), my compression may be working at cross purposes to Zep's compression. I still need to do an experiment to see whether the base 64 encoding is any better than the base 16 coding.
I've got some glitching in the bottom right blocks.
Here's the compression script: https://github.com/electricgryphon/pico_8_jpg
Perhaps this will inspire someone to greater image compression heights :-D.
Step into cyberspace with cutting-edge 3D vector graphics. Battle tanks with your triangular pew-pew cannon. Explode into a number of polygons.
This is an homage to Specter VR, which came packaged with my Macintosh Performa back in the day.
-Motion blur effects
-Blue/Red 3D glasses mode (it actually works)
-Multiple camera modes
-An attempt at writing title music
Gameplay is a bit, well, simple. Basically drive around shooting and being shot at.
Take aim, fire and score! It's Desert Lead 3D!
Spread the desert with the dented and shattered remains of bottles and cans. It's like recycling, but more destructive.
For use with the Pico Light Gun, Desert Lead 3D is also compatible with the Pico Mouse.
(Pico Light Gun is only available in selected dimensions.)
Click at the bottom of the screen to reload.
Sound effects could use some love. Anyone have a good shot and "plink" sound?
Affine texture mapped 3D isn't perfect, but it does create the appropriate effect.
Scoring system may be a bit glitched right now.
Thanks Felice for the sound and cross hair improvements.
Here's a demo effect kludged together from some doodles I had been playing with.
I'm quite fond of my new and improved 3D shading. (It's not quite as speedy as the line shading I was using previously, but it gives smoother gradients.)
I've been hacking at a ray-marching 3D rendering app.
playing with the dithering patterns a bit more.
Here's a stab at some lossy compression of the Bad Apple animation-- clocking in at 25 seconds long without even touching the sprite sheet.
The compression algorithm finds the best possible dictionary of 32 different 8x8 tiles with which to represent all of the frames of the animation. Then for each 8x8 chunk of each frame that is being compressed, I find the closest possible match out of this dictionary and record the index of this chunk. Finally, I use run length encoding to compress the string of dictionary indexes for each frame. (That's the idea at least...)
That gets things down to around 54 bytes per frame while still being recognizable.
Inspired by old-school demo-scene effects, here is a new and improved grayscale bump map render, which takes 8 bit height map input and generates real-time shading effects.
Please see GitHub for Python image conversion script and sample files. (https://github.com/electricgryphon/pico-9-height-map-converter)
I found the skull height map in the following forum:
Why settle for single renderings of a Mandelbrot when we can smoothly zoom in?
--Dithered Palette Animation
--Smooth Bilinear Zoom from sprite buffer
--Background Rendering of Mandelbrot into a (third?) buffer
The way this works is that we graphically zoom into initially rendered view of the Mandelbrot from the sprite buffer. While doing this, we are drawing the next level of Mandelbrot zoom into a second background buffer. When it's done, this gets copied into the zoom/sprite buffer. Lather, rinse, repeat.
Overall, a neat effect I think. Though, I wonder if I should trade the (more or less) smooth frame rate and dithering for less chunky pixels.
Also, I realize that I am awful at spelling "Mandelbrot".
This is an attempt to create a faster falling sand simulation (60fps) by reading and writing directly to screen memory. All pixels / sand particles are active at all times.
I'm writing 1X2 pixel blocks in order to work directly with bytes and avoid bit-masking to address individual pixels. Then, I am using the display mode hack ( poke(0x5f2c, 2) ) to stretch the vertical scale of the display by 2X without requiring me to write any more data to screen memory.
Here's a toy I have been playing around with. Perhaps somebody can use these functions for fancy shaded 3D rendering or something like that.
I have a few functions that draw "RGB" pixels to the screen using pattern dither that are approximated using the rgb values of the pico8 palette.
color_bayer_plot_8(x,y,r,g,b) -- writes a given r,g,b at the x,y (r,g,b are from 0 to 1) fast_rgb_create() -- pre-renders patterns using a 4X4 bayer dither representing 8 levels of R and B and 16 levels of G. fast_rgb(x,y,r,g,b) -- writes a given r,g,b at the x,y (r,g,b are from 0 to 1) function solid_trifill( x1,y1,x2,y2,x3,y3, r0,g0,b0,r1,g1,b1,r2,g2,b2) Renders a triangle with the three corners colored at rgb and shades smoothly between them. Right now this uses the slower color_bayer_plot_8.
If you move the cursor around with the arrow keys you can see the triangles. The vertices can be grabbed with the "z" key and the color of the vertices can be changed with the "x" key.
Originally I had been thinking about making a gradient image compression algorithm, but it seemed less interesting after getting half-way through.
Here's a spinning R G B triangle for fun.
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.
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
Please feel free to use this in your projects as well as to update it and make it work better.
New features for version 2:
--Significant speed increase (2X!)
--Load models from strings to save token space
--Python script to translate from ".obj" files to compressed string
Run the script in the folder with the files that you are converting.
python low_poly_compress-01.py filename.obj
Detailed instructions and script found on GitHub.
View Older Posts