Hey, long time no see!
I've had this sitting on my hard drive for quite some time, but I don't have the time to work on it right now due to university work... Wasn't doing any good just sitting there (and other people are posting 3d stuff not), so here it is in its current state.
Z to drive, arrows to turn. Unfortunately that's it! No AI, ghosts or even checkpoints/laps at this stage. I got stuck on some integer overflow bugs, which you can still experience a little too easily... It might be finished one day, who knows! Just not soon. :(
This is pretty dang awesome! I didn't even know the Pico-8 could do this! Nice job, seriously! :D
Good job! Nice shortcuts, working indoor/outdoor spaces, interesting map terrain...! It's all pretty great when it's working correctly. :D
Great game. It's impressive you did collisions and even near plane clipping !
One thing that could help with overflow issues is to keep everything around the camera. So you move the ground around instead of the car and if bugs happen, it's far away from the view.
Cool, but I've driven into a tunnel (or what seemed to be a tunnel) and ended up in a void (classic fall through world glitch). Please try to work on it when you have time, please.
Also it'd be cool if this car engine would be used in "we missed you 3D). Ground could be a flat plane with roads laid in and occasional hill and buildings could be cubes, where objects like trees would be just sprites (like in Wolf3D).
Teleport glitches are overflows which generally occur around large triangles. Generally it "detects" that you collided with an edge or vertice, and snaps you to it immediately. The render and collision steps take up more than half of the token space, so gameplay options are unfortunately limited. I don't think we missed you could be ported to 3d without major cutbacks, and looking terrible because it wasn't designed with flat shaded 3d in mind.
If I stripped near-z clipping I could save some space, but then you wouldn't be able to have large grass planes which you can intersect with the camera like in this model.
Wait a minute, the car is looking pretty funky on the web player... Did anything important (graphics, math) change between 1.1 and 1.3?
Probably. Zep's got this wacky fixed point math thing going, as you are well aware, and it's got a lot wrong with it.
I'm getting a Chrome "Aw Snap" crash just after Pico-8 startup in the web player for this cart. It sounds like others are getting it to work so that's a bit odd. Chrome 46.0.2490.80 on Mac OS X 10.11.1. Anyone else?
-- Oh wait, not just this cart. I'll try some more things. Carry on...
Here's a comparison (v1.2/v1.3 web vs v1.3/v1.1). Looks like something is going horribly wrong on just the web player and messing up my triangle fill.
Great job, Rhys! The vibe is awesome and the technical side of it is mesmerizing. Everything looks awesome to me, even the buggy parts!
I didn't realize the car had wrong triangle filling, but you might take a look at inverting the order of the fill. Try filling counter-clockwise for every triangle, I think the problem might be backface filling.
I hope you keep making this one!
Wow, so it's possible to make a 3d racing game, that controls very nicely, it just needs to get more gameplay :)
Heads up that this cart had a hidden bug that seems to be exposed in the latest web player, and it makes some of the polygons misshapen. Here's a corrected version I came up with while debugging it:
The problem is that you were dividing by 63356, which isn't a legal number in PICO-8, where numbers range from -32768 to 32767.9999. Not sure why it worked in the original web player, but it doesn't now.
The fix, if you want to update your OP, is to change the place where you divide by 63356, which I'm assuming was a typo for 65536 and meant to shift right 16, to multiply by 0x.0001 instead. This accomplishes the same thing, but uses a number that's inside the valid range.
Wow, that's some in-depth analysis there - good catch! I haven't messed with pico in a long time, but if I were to continue this project I'd probably rewrite the collision entirely due to a ridiculous number over/underflow errors like this. (that and swept sphere collisions being honestly a bit much for the cpu budget)
Also, is it me or does your version run a lot slower in the starting area? Doesn't seem like a small change to rendering should do something like that.
Hmm, you're right. It's possible the bug was allowing some stuff not to be drawn at all, maybe stuff that's either offscreen or not immediately obvious in the fixed version.
Literally all I did was change the divide by 63356 to a multiply by 0x.0001.
How do the two versions here compare to the one you have at your end?
Huh. If I type LOAD #16350 (your version) in my local 0.1.11g executable, it runs about the same speed as my version here on the BBS.
Yet, here on the BBS, 16350 is running easily twice as fast, and, while a few polygons are mangled, overall it looks like you're filling roughly the same number of pixels.
I wonder what's being done in the working version that's not being done in the mangled version. Given that the output isn't much different, I wonder if this exposes something that wasn't working correctly in the version that looks correct. Like maybe backface culling isn't working right, or something, and for whatever reason, the thing that broke polygon positions made backface culling work right. Something like that.
If you were still actively working on it, I'd call this a silver lining, something that shows you it could possibly be sped up. But you're not, so instead I'll just call it a curiosity-attractor. ;)
FYI I made this interactive calculator cart to debug exactly this, because I wanted to see what was new in 0.1.12.
You can see that while 63356 is bizarrely clamped to -32768 in PICO-8 0.1.11g:
it is now wrapped-around to -2180 in 0.1.12 (the version on the website):
The new behaviour seems preferable to me, even if it may break some carts.
I agree, I would prefer that out-of-range numbers wrap, not clamp.
By the way, the 63356 -> -32768 thing might have been because zep clamped to (-32768..+32768) rather than (-32768..32767.9999). I suspect this because +32768 is just outside the valid range and would have wrapped to -32768 once encoded in PICO-8 format.
Side note: 0x8000 is often displayed as -32768, but it's also +32768, because 2's complement math behaves as oddly with 0x8000 as it does with 0. Technically, it doesn't have a sign, like 0, and its only given one for the sake of convention. I have several names for it in my head, but I basically think of it as "the outpost value" because it's the farthest value from the origin (0). I haven't yet seen a perfect word for it, but it's good to give it some name so you'll remember that it's special and doesn't work like all the other numbers.
This is nothing short of genius. Reminds me greatly of Hard Drivin' bothin the arcade and on Sega Genesis.
https://www.youtube.com/watch?v=g6JC-HCNcio
https://youtu.be/pfe2Ze_yDk4
Definitely gets my star and favorited. I'll play it as is. Love these 3D accurate physics games.
Wow this is super fun!!! Lots of potential here, I'm super excited to see where this goes!!
.jpg)
No Matter What I Do I Fall Out The Map.This Game Is The Best Ive Ever Played And i Cant Wait To Play It When Its Not WIP Also I BReak Everything
I enjoyed trying it out. It's great to see people pushing what limited hardware can do. I'd be curious to see any updates.
Also, I fell into the void. :)
I'm seeing the same error as mentioned above, using the web browser player.
[Please log in to post a comment]
