Fort Apocalypse

0.6 minor changes mostly. refactored some code to make it smaller. tried making playfields smaller by using pfvline and pfhline but that didn't work. lander position during select mode raised one pixel. fixed so won't have quake and sound if you land on your base, and fixed player 2 collision sound. falling diamond titan_diamonds_0.6.bas titan_diamonds_0.6.bas.bin titan_diamonds_0.6.bas.asm.txt

We're not saying that (at least I'm not). Were just saying that Target has a supply of new FB2s (that were produced over a year ago) even though they are reporting that they don't have stock on their website. It's either that or they have a supplier they are waiting on. But either way, the "factory" stopped producing new FB2s some time back and they've just been sitting in some warehouse somewhere. Nothing out of the ordinary. Did I mention I can't wait until the next Atari FB console?

The last shipment were the Rev C.'s in the summer of 2006. And those had been manufactured some time before and been sitting for a while. So there has been no production for a good 2 years. Likewise, Atari sold the last of its own personal back stock (via its website) last December/January. Again, these are probably shelf pulls/refurbs that Target would have. There are no new FB2's. Thanks, Marty! Good info. Was wondering when they stopped and that is really interesting about Atari selling the last ones via its website. Guess they were trying to get more bang for the buck on the last ones? I really wish that they were doing this to clear up stock before a release of an FB2 that had a memory stick. Guess I'll have to wait for the next incarnation of Atari for that.

My first 1-player win in 0.5... and yes I died 6 times.

There's always ebay: http://search.ebay.com/search/search.dll?s...o%3D1&fgtp= And a few here and there on google product search (a.k.a. froogle): http://www.google.com/products?q=%22flashb...rch&show=li But I'm imagining that Atari probably didn't continue production so they are probably starting to run out. I agree that it is surprising that Target is going to sell them on Black Friday but they are out of stock currently... Maybe they stopped selling them for now so they'd have enough inventory to spread around for the Black Friday sale.

Michael found that one out here. Was an easter egg that Fred wrote into bB. dim shakescreen = a then shakescreen = shakescreen + 64 can't use any other variable or name. It's magic. You could also scroll the playfield I assume to do similar, but I didn't try.

Awesome! I really like the second one!

Walter, here is 0.5. left and right movement speed doubled. Like it much better! Great suggestion! titan_diamonds_0.5.bas titan_diamonds_0.5.bas.bin titan_diamonds_0.5.bas.asm.txt

Am I being ridiculous by self-imposing a 4k limit on my bB games? What is the limit of size to load games via croc carts, etc. to real 2600s (heavy sixers on up) and (theoretically) FB2s?

Preposed labels

0.4 released! * can now explode by hitting playfield (can sometimes hit it safely, sometimes you can't- some chance involved!) * self-destruct sequence before killed (length depends on "random damage" caused by hitting playfield or getting shot) It's basically pretty close to being done now. Can't think of anything else to do with it currently titan_diamonds_0.4.bas titan_diamonds_0.4.bas.bin titan_diamonds_0.4.bas.asm.txt

Let me know if you guys like the game and what you'd like to see different to make it more playable. Also, try it with a friend if you can. The two player aspect of it is still much better than 1 player since there is currently no way to die except to be shot. I forgot that I still haven't implemented the UFO running across the top... I don't think that would be very challenging anyway. I think the best could maybe just be to say you can't hit the playfield at all unless it is to the far left or right. I'll try that next for 0.4.

Screenshots. Third screenshot shows the exposed diamond to lower left.

Curtis, The player scores minikernel proves totally awesome again and am using it in Titan Diamonds (keep hitting select until you get one of the two-player games, then hit reset to start). Two things I noticed though are that: * When I use it it keeps wanting to flicker the 2nd score red (see attached 0.3). titan_diamonds_0.3.bas.bintitan_diamonds_0.3.bas * I can't use pfscore when I'm using the minikernel or it totally hoses everything up. It starts to ignore COLUBK and use COLUP0/COLUP1 instead (just by having using both playerscores minikernel and enabling pfscores at same time) and when I set the pfscores it changes the playerscores to player sprites that have been rolled down 2 rows instead of digits (see attached 0.3-pfscorebug). titan_diamonds_0.3_pfscorebug.bas.bintitan_diamonds_0.3_pfscorebug.bas

During the title screen code, are you seetin COLUP0 and COLUP1 every time you call drawscreen? These are TIA registers and get overwritten by the Score routine, so that your players will end up being the same as the color of the last score. It looks like this doesn't happen with your cars because you redefine each player and it's color every frame. Curtis, To answer your previous question, I pretty much gave up on that, but I think the answer to my issue is that I would have just needed to set the player1scorecolor, player2scorecolor, player3scorecolor, player4scorecolor before each drawscreen.

Here is 0.3. Basically the game is almost done as I described it with the exception of a life counter because I ran out of memory (4k top). Has sound, lander collisions, lander explosions and dropdowns after dying, game ends at 10 points. Get points by killing other player or finding diamond. I also added large falling meteorites (which you can see coming as they wait for their turn to fall... a sort of radar I guess). There is a slight bug in the 2 player scorecolor. Posted it to playerscores thread. Unfortunately I can't use pfscore to have the life counter either because of the use of playerscores. Would be great if that could be fixed because I think that having a life counter would really help the game. titan_diamonds_0.3.bas titan_diamonds_0.3.bas.bin

0.2 released 2 player lander duel! dynamics for lander are more lander-like now and has thrust effect and ability to shoot and keep score as well as the 2nd player lander. For now bullets can go through rock. This makes it a bit more challenging and is not where the game is headed, unless you want me to just drop the 1 player aspect of it and make it a 2 player lander duel, which turns out to be pretty fun in and of itself. No sound yet. Let me know what you think titan_diamonds_0.2.bastitan_diamonds_0.2.bas.bin

I had another idea on this yesterday. Maybe you could just register the running average of x and y coordinates (each move you recalculate the average by also keeping track of the number of dots drawn) and also keep track of the starting and ending x,y coordinates. With that information you may be able to figure out the "centerpoint" to determine area. An easier way would be to just assume that the greatest x-1 and least y-1 is a fill point and fill by drawing each line left until you run into something. The latter wouldn't work well though. Just guessing. No answer yet.

Looks good. I can't think of an easy way to fill in the areas unfortunately. If you had to rate the difficulty of getting something similar enough to Qix to call it Qix implemented in bB, I'd give it a 12 out of 10. The right way to fill in the blocks is to have the application smart enough to determine what the smallest area is to fill the blocks in is after you complete a line. A possible way of filling the blocks if it wasn't that smart is to use the variables to store the last direction the player moved since starting a line. Then as soon as the player hits the playfield, it uses those directions to determine how to retrace the line but move it over +1 x/y coordinate at a time (depending on the last move) and then do pfread to "stop" painting the shape when it hits a line. Another way is to register the starting point of the line (as x,y variables) and then paint straight across when you complete the line, starting with those coordinates and doing pfpixel across (+1 x if x>16 or -1 x if x<=16 for example) until you hit a block then start at the same starting x again and paint across. Or you could track the x coordinate of every dot in the line and draw over from that. But neither of those ways will probably do it. It will be tough, and probably is not what you want to take on (hard games to write can sometimes be demotivating).

SEE LAST POST FOR LATEST VERSION! The story: In the year 2574 a lot of things have changed. Humans have colonized our solar system and the O81b "flying saucer"is the primary means of getting around town. However, some things don't change, specifically the need for diamonds. In 2574, the largest known diamond in the solar system was found in the moon, Titan. But in the process of trying to mine it, the 2 petaton atomic bomb used was overkill and scattered diamonds across the planet and across the solar system. You are one of the many that have equipped their O81b's with rock blasters and set off to mine for the diamonds. But watch out, the explosion also caused a lot of meteorites! Good luck diamond hunter, and get rich! Features: * shoot rock in attempt to find diamond that is same color as playfield (also ball) except it flickers (the diamond) * 2 players * can shoot opposing player * get points by collecting diamonds ("win" game at 10 diamonds?) * may/may not die by hitting playfield * can select different levels * can bump into other player * falling meteorites * ground quakes when playfield is shot * player resting position landing strip is "safe" to land on * self-destruct sequence when lander is damaged (colors of red) Original Plans not implemented/won't be implemented: * landing pad where you refuel (ball) - pfscore not working * ufo runs across top and shoots down at you - ditched ufo * lose fuel by hitting playfield - pfscore not working * run out of fuel and you crash - pfscore not working * playfield only crumbles when ufo's shots hit ground - ditched ufo titan_diamonds_0.1.bastitan_diamonds_0.1.bas.bin

Now it removes the top playfield pixel so it won't leave blocks sitting in midair. Made it fall faster so you don't have to wait and changed the playfield a little. test_fall2.bas.bintest_fall2.bas

Here is a demo I put together of a mountain that comes apart over time and falls down. Thinking about using it in my next game. test_fall.bastest_fall.bas.bin

Hey... resurrecting this thread because I'm looking for the most efficient way of storing 4 2-bit "pseudovariables" in a single variable (byte) to hold velocity for the 4 cars in the indy game. I'll use the timer variable to delay incrementing/decrementing of each of the 4 velocities (so it can jump in speed like you're changing gears). So the plan is to have a carvelocitybits variable such that: tempcar0velocity = carvelocitybits & %11000000 tempcar1velocity = carvelocitybits & %00110000 tempcar2velocity = carvelocitybits & %00001100 tempcar3velocity = carvelocitybits & %00000011 so if I wanted to: add "1" to car0 velocity: if tempcar0velocity < 255 then carvelocitybits = carvelocitybits + 64 add "1" to car1 velocity: if tempcar1velocity < 64 then carvelocitybits = carvelocitybits + 16 add "1" to car2 velocity: if tempcar2velocity < 16 then carvelocitybits = carvelocitybits + 4 add "1" to car3 velocity: if tempcar3velocity < 4 then carvelocitybits = carvelocitybits + 1 subtract "1" from car0 velocity: if tempcar0velocity > 0 then carvelocitybits = carvelocitybits - 64 subtract "1" from car1 velocity: if tempcar1velocity > 0 then carvelocitybits = carvelocitybits - 16 subtract "1" from car2 velocity: if tempcar2velocity > 0 then carvelocitybits = carvelocitybits - 4 subtract "1" from car3 velocity: if tempcar3velocity > 0 then carvelocitybits = carvelocitybits - 1 and if I need to have 0-3 based numbers I use: tempcar0vel0to3 = (carvelocitybits & %11000000) / 64 tempcar1vel0to3 = (carvelocitybits & %00110000) / 16 tempcar2vel0to3 = (carvelocitybits & %00001100) / 8 tempcar3vel0to3 = carvelocitybits & %00000011 Is that the most efficient way (program space-wise) to do those things?

Doh! That was it. Thanks, Michael! (BTW- it is so out of control now when it does compile. )

P.S. Thanks for the info on how you figured it out. I need to start looking at the partially compiled code to help myself... I just see stuff like: ---------- Capture Output ---------- 2600 Basic compilation complete. DASM V2.20.07, Macro Assembler (C)1988-2003 bytes of ROM space left 83 bytes of ROM space left Possible duplicate label: L0278 fb78 > Terminated with exit code 0. then try commenting code or putting stuff like: if asfd = fdas then asfd = 4 : asff = 5 into the code and recompiling (because putting bad code in sometimes help expose other bad code). And if that doesn't work I usually have started just commenting out parts of the code, until I find the offending piece. Your way is much better! BTW- sorry I haven't done much stuff in bB side of wiki. I kind of froze up when I started into it and have been wondering since how to get batari/Random Terrain's great single html page (which is easy to search, etc) into a lot of different pages easily and so it looks good. The only way I can think to start it is by copying the whole html into the wiki page and converting to wiki (the body without the right nav/link bar) but then I freeze up thinking about how to start copying those functions and creating their own pages, and I somehow think I'm going to run into problems converting it into just a straight list of functions... I just need to do it though.