Old version:
Clean the skies of sector Q97-C with your trusty mining laser.
Keep an eye out for debris, not to mention Turrets and Tormentors.
Controls:
Arrow keys control roll and yaw.
X-key accelerates.
Z-key fires laser.
Tips:
Full 3D navigation can be tricky, so keep an eye on your radar at the bottom.
It can be easier to sweep the laser up over targets than to try to hit them dead on.
Watch out because the laser uses your ship's power, which only refills slowly over time.
Version Notes:
Added music by Robby Duguay
-www.robbyduguay.com
Added sound effects
Do you realize what you did there? You now have to port Elite to Pico-8.
I love the colors (scanline dithering FTW!) and how silky smooth this is. Beautiful.
Oh man I am in love with your dithering. It's great how a coherent aesthetic emerges from what is efficient to render.
How much does the reduced viewport help with the framerate? Does the game have trouble hitting 30fps without it?
This blows my mind. F-ing well done, the game is great and plus it's beautiful!!!
Is Pico-8 VR in your plans?
Man, all your carts are amazing! Your work in 3D stuff on P8 is really awe-inspiring, and the game is great!
Hi Viggles,
I've mostly been able to keep this to 30fps, though it does occasionally drop when there are a lot of objects on the screen. (The engine does a pretty good job of limiting the effort put into translating and rendering items that are out of view.) The viewport size helps a little, but not as much as it does in a raycast engine.
I'm very happy with the way the colors work--I think this might have to do more with the P8 palate being genuinely pleasing than any special consideration on my part.
Updated to 1.1 with music by Robby Duguay
https://www.lexaloffle.com/bbs/?tid=2619
and sound effects.
This marks the first time that I have hit the token limit, which probably means its about time to check this one off as complete and start on another game.
If you're in need, I may provide you my WIP-toolkit to store data within the sprite/map data from a python script. This saves the need to store them in code and you gain some tokens? Works until the sound effect section, which I still need to decode/encode properly.
Next 3D game, I'll probably borrow your method for storing vertex data in the map section. What scheme did you use? 2 bytes per fixed point number--i.e. one pixel?
I could also compress the vertices into strings, which has worked well enough in the past, though tends to push into compressed code limit space while it helps with token count.
The other area that I need to figure out better is the z-clipping. For discrete objects like the asteroids, it's not really necessary because they render as smaller than the view port, and you don't want to hit them anyway. But for something with ground or internal scenes z clipping is critical.
There was a cool z-buffer demo here a little while ago, but I believe the z buffer was only calculated when the camera moved--great for fixed camera scenes like alone in the dark, but perhaps not fast enough for real time camera movement. (Just filling a 128 x 128 table takes a good chunk of a frame.)
I simply place the bytes there, although the system cares for the specialities of each section, including the music section. I compress the data with a naive approch to the huffman encoding, which saves a good third on text data. I hope to get the sfx-section available very soon, too, although it is a bit harder to use.
To save the data itself, I serialize a tree of dictionaries and arrays within python, which creates a table-tree within pico-8. Within my game, I can check for certain key elements to even add game logic from this approach, like adding conditions to elements and the ability to execute parts of the tree as very simple scripts, making it a very primitive VM.
Hi,
Nice game. I like your line dithering to get a smart cheap lighting.
Storing meshes in the map data works well as there s plenty of room there. I used that on my game Hyperspace to store positions, normals, uvs and triangle indices. Basically using one byte for each value. This gives me a 256 sampling and I then multiply positions by a scale depending on the model. I didnt look into compressing more as I had more than enough memory there, I cared more about optimizing the decoding method to limit token usage.
I also have implemented a zbuffer in my terrain demo. I stored depth linearly in 8 bits per pixel. This still consume quite a lot of data and was not used for 30fps target.
But you dont need z buffer to perform z clipping, just split the triangles that intersects near plane. I havent used that in pico8 because it can be heavy (I just discarded triangles that intersect or didnt care at all for objects that I know will not intersect) but for some scene, you may have no choice if you dont want holes (like ground planes...)
I just got z-clipping working this weekend. Agreed that it's a bit heavy--I'll probably just use it on polygons with a "landscape" flag or something like that.
I'm going to try a more complete implementation of painter's algorithm. I've just been sorting by the z value of the centroid, but that often draws the large ground triangles above smaller object triangles. If I test some more cases, I can exchange speed for additional sort accuracy.
SunSailor, your data compression method sounds strange and wonderful and will likely make my head explode. I will have to check it out.
looks very fun but navigating is a nightmare :) the aesthetic is great though, would love to see a descent-like using this sort of rendering.
Roll and yaw? I wish I could control the yaw on this thing. @_@ With only roll and pitch, aiming is such a pain in the butt...
It works wonderfully though and I has shot many aliums and rocks. Truly the epitome of 3D gaming on the Pico-8.
I debated a bit about controls on this one-- with the idea that roll and pitch added extra challenge and maybe added a degree of disorienting realism. I wonder if adding a more simple control option would improve things, however, and let people blow more stuff up with reckless abandon.
I love it!! It looks awesome and feels almost like no man's sky ship flight!!!
Oh my god,, ilove the way this looks. I'm not a programmer, so reading the comments about z buffers and what not goes way over my head. but i've been playing games since i was plonked on the planet in '81, and to see graphics go from what they were then, to what they are now, and then tto see now techniques applied to things that look like they could be from then, blows my mind. I only found this site after lookng for a version of star wars tie fighter to play, and its great. but if it had your aesthetics, with the dithering and smoothness, and whatnot, i think it would look even better. So i'd love to see you try your hand at a tie fighter replica. Your game is cool too, and once you get used the controls, its kinda satisfying clearing asteroids away. cant wait to try out some more of your games. this one really felt like i was back in the day on my dads ZX spectrum or C64.
That’s really awesome! Can you add in the title screen a picture of the starship we pilot? So to know what’s the vehicle we fly
This is impressive. I just recently made a 3D Space Shooter myself but it does not have filled polygons. I am assuming you used the line function to fill each triangle. I have attempted to make a textured polygon game and the large amount of pset() calls slowed the game down to 5fps. lol I was afraid if I used the line tool to raster triangles it would have slowed my game down significantly so I chose to do a hybrid of 3D and 2D or pseudo 3D in my game. This game is inspiring me to attempt to do shaded polygons with the line function.
[Please log in to post a comment]
