Fort Apocalypse

Man I really messed that up. Here's the source. Sorry about that. That part changed in 0.9. I tried commenting it out though (in all 4 places - I wish I could refactor it but it doesn't make sense to) and it still complained. ultindy500_0.9.bas

Compiles. Won't run. Have tried commenting out various new sections of code, but haven't found the issue. Any ideas? Thanks in advance! Code: ultindy500_0.9.bas.bin Minikernel that code uses: 4 player scores minikernel

Thought some of this was a kind of fun read (many may have already read, but this is the first I'd seen it): http://www.atarimuseum.com/ahs_archives/ar...0_Standards.pdf Found that on Curt's atarimuseum site here: http://archives.atarimuseum.com/archives/archives.html

Thought some of this was a kind of fun read (many may have already read, but this is the first I'd seen it): http://www.atarimuseum.com/ahs_archives/ar...0_Standards.pdf Found that on Curt's atarimuseum site here: http://archives.atarimuseum.com/archives/archives.html

0.8. REAL INDY CARS! (Thanks to batari!) Much better driving dynamics. ultindy500_0.8.bas.binultindy500_0.8.bas

larger versions

I wrote this a few weeks ago and was going to spend more time on it before posting, but someone might find it fun. The story is that you are a schoolbus driver and there is a storm that took a lot of powerlines down and you have to drive to school without running off the road or into downed powerlines. It is basically currently just a side-scrolling driving game where you get more points by driving faster and longer. Have fun! Plans were to have some kind of kids getting off/on the bus and maybe having to avoid other things besides downed power lines, but I'm not sure when I'll get to it. schoolbus0.1.bas.binschoolbus0.1.bas

0.7 contains radical changes and is a major step backwards in smoothness and gameplay, but radically different for steering (and saved some space). Direction is tied 1:1 to paddle (so you have to rotate it all the way back around after turning right too far) - this is just temporary to make it easier to drive and figure out the x, y deltas. Changed the way I was doing deltas. Unfortunately, it is pretty jumpy. ultindy500_0.7.bas.binultindy500_0.7.bas One kind of neat trick I used (not sure yet whether it is a good trick or not) is that since I didn't need the persistance of player0x, player0y, player1x, player1y (since I was storing those in car0x, car0y, etc.) I could use them as temp variables. I don't know whether it is affecting collision detection, but that is not a concern for now (until I get driving dynamics figured out).

0.6 just had the small changes I mentioned previously (steering more accurate and is less sluggish). ultindy500_0.6.bas.binultindy500_0.6.bas

Actually, I think I know what may be wrong with it if it is about car movement and not the actual direction of the car. (If it is about direction of the car though I think the previous fix is the first thing to do probably.) Here is the part of the code that does 0-15 direction to x,y coordinate delta: setdeltas if tempvel >= 0 then temp100percentdelta = 0 : temp92percentdelta = 0 : temp71percentdelta = 0 : temp38percentdelta = 0 if tempvel > 1 then temp100percentdelta = 1 : temp92percentdelta = 1 : temp71percentdelta = 1 : temp38percentdelta = 1 if tempvel > 20 then temp100percentdelta = 2 : temp92percentdelta = 2 : temp71percentdelta = 1 : temp38percentdelta = 1 if tempvel > 40 then temp100percentdelta = 3 : temp92percentdelta = 3 : temp71percentdelta = 2 : temp38percentdelta = 1 rem if tempvel > 50 then temp100percentdelta = 5 : temp92percentdelta = 5 : temp71percentdelta = 4 : temp38percentdelta = 2 rem if tempvel > 60 then temp100percentdelta = 6 : temp92percentdelta = 6 : temp71percentdelta = 4 : temp38percentdelta = 2 return changepos if tempdir16max = 1 then tempy = tempy - temp100percentdelta if tempdir16max = 2 then tempx = tempx + temp38percentdelta : tempy = tempy - temp92percentdelta if tempdir16max = 3 then tempx = tempx + temp71percentdelta : tempy = tempy - temp71percentdelta if tempdir16max = 4 then tempx = tempx + temp92percentdelta : tempy = tempy - temp38percentdelta if tempdir16max = 5 then tempx = tempx + temp100percentdelta if tempdir16max = 6 then tempx = tempx + temp92percentdelta : tempy = tempy + temp38percentdelta if tempdir16max = 7 then tempx = tempx + temp71percentdelta : tempy = tempy + temp71percentdelta if tempdir16max = 8 then tempx = tempx + temp38percentdelta : tempy = tempy + temp92percentdelta if tempdir16max = 9 then tempy = tempy + temp100percentdelta if tempdir16max = 10 then tempx = tempx - temp38percentdelta : tempy = tempy + temp92percentdelta if tempdir16max = 11 then tempx = tempx - temp71percentdelta : tempy = tempy + temp71percentdelta if tempdir16max = 12 then tempx = tempx - temp92percentdelta : tempy = tempy + temp38percentdelta if tempdir16max = 13 then tempx = tempx - temp100percentdelta if tempdir16max = 14 then tempx = tempx - temp92percentdelta : tempy = tempy - temp38percentdelta if tempdir16max = 15 then tempx = tempx - temp71percentdelta : tempy = tempy - temp71percentdelta if tempdir16max = 16 then tempx = tempx - temp38percentdelta : tempy = tempy - temp92percentdelta return If you look at that you can see that at slow speed, the x,y deltas are REALLY rough. That is the best I could come up with at the time, because I just didn't have enough variables (and/or space) available to have 2 byte floats. When you're only using 2 cars you can do stuff like store the first byte in the player x coord and only need one variable, but you can't do that with 4 cars without using multisprite kernel, but you can't use paddles with multisprite, so... If I had more variables, the x,y coord changes would definitely be smoother. For now, you have to drive fast as heck to get more realistic movement.

Right. That would be awesome. It is really hard getting the right feel for it without having actually paddles. I think the problem may be this: if paddle > 40 then tempdir255maxdelta = (paddle - 38) / 8 : gosub incrdir : return if paddle < 36 then tempdir255maxdelta = (38 - paddle) / 8 : gosub decrdir I was trying to have a way to keep it "steady" in the middle, but maybe I should make it like this (lowering from 8 to might it turn faster and changed the middle value to not have a "center" range: if paddle > 38 then tempdir255maxdelta = (paddle - 38) / 6 : gosub incrdir : return if paddle < 38 then tempdir255maxdelta = (38 - paddle) / 6 : gosub decrdir

I'm thinking once I'm done with the 4k game, it might also be cool to have a version that has a lot of tracks and better physics. Or maybe someone else could take that on if interested.

0.5 released * Has lap count and working lap detection * Has fuel gauges (lines to left and right of playfield). When fuel runs out, car is slower. * Got rid of title sequence to save space * Got rid of flag to use missile for fuel gauge ultindy500_0.5.bas.binultindy500_0.5.bas

Unfortunately, since there are four players, there is no way to show 4 bars without writing a minikernel (and I'm not quite up to that level yet ). I had originally thought that maybe you would still be able to move but just really, really slow at this point. That way, even though you will probably lose the game, at least you still have a chance and can play. I almost have to code done for the fuel (to use car color) but am having to take chance using temp vars 2 and 3 and lose title sequence. Hopefully playfield collision detection won't screw up again.

0.4 released. Steering less sensitive (went from diving paddle difference from center by 5 to dividing by 8 for the 255-based direction delta- don't ask me what percentage difference that is- it is too late today for me to do math), accel/decel more sensitive (2x sensitivity). Changed code to not use temp1-3 (so had to use up 3 more regular vars). It now sets sound and checks for playfield collision 2x as quickly and maybe more accurately (I didn't test to see if it fixed the pf bug yet- let me know if it does). Let me know what you think. You may have to turn up the default paddle delta in Stella to get it to turn quickly enough via keyboard. ultindy500_0.4.bas.binultindy500_0.4.bas

Steve, Thanks for the code from batari. I looked at it and unfortunately it uses 16 variables per player (since I can't reuse player1 and 2 x and y coords since I share player0 and 1 with players 2 and 3), which would mean 64 variables for all 4 cars. If there is some part of it that you think I could reuse or if you think that it is going to suck too bad without bank switching let me know and I'll do what I can. I'll definitely look at it to see what I can use though. I was really hoping to keep it under 4k to try to make it more accessible (isn't 4k the lowest common denominator?).

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them). Also, note you can't use pfread with multisprite kernel.

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

I was wondering about what need a pit stop for. How about a fuel gauge that runs out when the players are driving, when a player hits something, like a wall, the fuel gauge loses a bit of fuel. The pit stop is the place to refuel. I do have a question about the track designs. Are you planning more tracks? Decrementing fuel would be good. I'm not sure about how I would indicate fuel and damage (was thinking changing color of car to show that). One of the problems with having more than one track unfortunately is that if I have to worry about where the pit stop or finish line/halfway point are (if they are different for different tracks) it will require more space (and probably at least one more variable or so and some additional code in the selection part of the game that doesn't even exist yet - I might need to drop the title sequence to fit that in). I think I need to get the mechanics of the game figured out before I worry about that, but if I have space I'll definitely try for at least 2 tracks in the beginning. Maybe different tracks could just be released as different games if space were really tight.

A number of functions use temp variables internally. At some point I hope to document them all. If you stick to TEMP4 through TEMP6 you should be fine. Thanks! Will try limiting to those 3!

Thanks, Mike! Will do!

Steve, Thanks a lot! Will definitely take a look at it and do what I can! Glad to hear you think it is cool! I kind of thought no one was really interested in it. Batari had some/all of the indy physics in the game that comes with bB (zombie chase). I tried not to look at it in the beginning because I wanted to see what I could do on my own, and later found out that I couldn't really use much of what he had for 4 players in a 4k game because there weren't enough variables. So the physics take a serious hit because of that. If I changed it to a larger bank-switched game maybe it would be more fun. I will do that if people think that is the best direction to get this jump started again. My goal has been previously not to write any game that couldn't be played on a future Atari product that may not support superchargers, so I thought 4k was the best I could do to be safe. Is that right? Also, I don't want to limit who can play them on regular 2600s (for those with croc cart/etc but no supercharger). In other news- I tried to duplicate the playfield bug last week in separate code and determined that the thing that is causing 2 cars to have playfield collision detection issues is my use of temp variables. I don't know what bit(s) it is nor the exact condition that makes this happen, so I'm hesitant to list it as a bug. But it definitely seems to either make it look like player sprite is always colliding or never colliding with playfield. Wish I had more time to look into it. I wish I didn't have to use temp vars but I ran out of regular ones.

Yes, I saw that too in Stella 2.3.5. I think it is either a bug in bB or a bug in Stella. Can anyone figure out why it would be doing this? Figured that flickering out. Had too many sprites on the y=100 coordinate. Here is the latest (interim version with fix and diff maps) 2padv0.5.bas.bin2padv0.5.bas

Yes, I saw that too in Stella 2.3.5. I think it is either a bug in bB or a bug in Stella. Can anyone figure out why it would be doing this?