Fort Apocalypse

Dang it. Did you get a picture?

Ok, now I'm really interested. What kind of shenanigans? This is the meaty stuff!

Isn't there anyone out there that has some clue what Atari is doing with this new console or can at least say they saw Curt in the parking lot eating a candy bar?

I think there is a good chance that the new flashback console will support the 2600, and even if there is a glimmer of hope that it might, and if the cartridge format that they choose is actually just an encased memory stick, or even in the very remote chance it supports USB, then there will be a lot of people that will be interested in new homebrew games for the 2600. That said, for those that aren't aware (there may be a few) Batari Basic is a really great way to get into Atari game development, and you can create some pretty neat games with it (it's not just a stepping stone to asm anymore). If you are interested, please check out the Batari Basic (bB) forum in AtariAge: http://www.atariage.com/forums/index.php?showforum=65 There is a really great tutorial to get you started and a really great page for reference when you start writing code. Folks like SeaGtGruff (Michael), batari (Fred), and Curtis on the bB forum are always helping people out. It has been really fun hanging out with those guys and learning how stuff works. Maybe you might like it too.

Curt mentioned that something was in the pipeline: "what was being developed for 08' as an advanced follow-up system has been moved up to the front burner and is being worked on now in place of the original FBP design" I am still pro-Atari and definitely pro-Curt, but it was a seriously bad decision to not give anyone any insight into what is coming. One of the absolute best ways to generate revenue is to create buzz. No talk = no buzz = lower revenue for Atari. If there is a competitor that Atari is afraid will steal whatever secret they have is, then don't say anything meaningful, but least say something and acknowledge the fanbase. It doesn't even have to be good. Just give us an empty statement every two months like "the greatest thing since sliced bread" and at least we can sit here and try to pick apart the statement for some hidden meaning of "sliced bread".

What's stopping you from buying a FB2? Or did you mean FB2 portable? Odds are the next flashback (or whatever it is called) will be more expensive (but not much more though). Not like anyone cares about my theories but here's the latest: * atari 2600 console with cartridges that contain about 40 games each (a few best sellers, lots of "average" ones, a few homebrews, several prototypes/new games) OR * atari 2600 + atari 800 console with cartridges that contain about 40 games each (fewer homebrews/new games than it would be if it was 2600-only console) (this is more likely considering what Curt has said previously) And would be: * packaged with 2 joysticks again * have no paddle/racing games (no unlockable games like the FB2, but there would still be easter eggs) * keyboard connection can be easily hacked on if supports 800 This model makes the most business sense, and Atari/Infogrames cannot take chances at this point. Reasons: (1) only having an atari 800-based console would sink like a rock (2) portable is too expensive to make (3) USB load is too prone to legal and support issues (4) emulator-based console is too expensive and there are legal concerns

Sure thing, but it won't be tonight. Michael No problem! It might make more sense to just wait until the game is closer to completion anyway. I'm sure that it could get more noticeable as I'm adding more logic to it.

That would totally rock! I wouldn't mind at all that the 6-digit score get turned off. If there is anyway to also fit colors into it, that would be best, but even a single hardcoded color would be fine!

Sorry to bump, but any chance for an AtariAge wiki? TIA!

That's totally awesome! This definitely help out a ton of games! Any chance you might be able to do a 4 player version (4 2-digit scores)? If so, I could really use it.

Do you mind checking this out on a real 2600 to see if it flickers? I switched to reuse missile 1 for the flag (both flagpole and flag) and dropped the pit since you set up a nice looking pit that I can just check x and y to determine if it is in the pit. Here is the one with the latest changes (no more compile error): ultindy500_0.1.basultindy500_0.1.bin

Man, that would be totally awesome! I think a symmetrical playfield would be totally fine, and getting a higher vertical resolution would be really great for for better looking turns and for an oval track! Let me know if you think you might have time to help with that or if you could give me some pointers to how it could be done. I wish I had your asm programming ability! (Unfortunately between college and years of raising children, my mind is even less of a steel trap than it used to be. Even before that it was just small mouse trap.) And thanks for helping me figure out the paddle issue! (that was an artifact of me trying to get it to work with multisprite, which of course never would work!)

Could anyone help me figure this out? TIA! I know that value mismatch usually means that I'm trying to set something with a value type it doesn't accept, but I can't see in the program where it is happening. Program is (note- this is different than the other file I posted previously in diff topics with same name): ultindy500_0.1.bas

Awesome! Thanks, Michael! I saw Batari had posted about my bug in the player 3 y coordinate setting that was causing it to "disappear" (go off the screen) also.

Are you sure you mean vertical? There should be no flicker in a verticle line: X | X | X | X But in a horizontal line you would have lots X-X-X-X Just checking... I'm not really sure why it is flickering so much actually. I changed the sprites to not be on the same vertical or horizontal (at least as far as I can tell - maybe there is some overlap - don't know. Posted the code and bin here Edit: Actually Michael figured it out in the other topic!

Oh yeah. They rock!

Would use the internals of the paddles to handle the x and y axis, like a gun turret. I would bet that this idea came up in the 80s and was shot down because it was too hard to do. Or maybe someone else already thought of it. But I came up with it a few days ago and thought I'd share it. Feel free to use this idea and build one yourself. By doing this. I'm releasing the idea for full public, private, and commercial use. But I'm probably not going to actually create one.

Could anyone provide some sample asm code that I could include within a subroutine of batari basic to do this? Unfortunately my eyes still glaze over with asm. If not, if anyone could point me in the right direction that would help. In addition, it would be super awesome if it were added as the first (and only?) kernel option for multisprite in a bB 1.1 release, as not only would it allow people to more easily write 4 player racing games, but 4 player pong games with 2 balls (ball and missle), a warlords-like game (without the bricks, since there is no pfread or pfpixel in multisprite kernel), 4 player planetary defense, and you could build a new paddle-based turret controller and shoot at 6 sprites at once (by using a blinking ball and missle for the targets).

This is my very sad Friday night handiwork. Thought someone might find this funny because it's so bad.

D'oh, I think I see your problem! "readpaddles" is a kernel option, but you're using the multisprite kernel, and the kernel options don't work with the multisprite kernel, just with the standard kernel. Michael Does that mean I can't use paddles with the multisprite kernel? That would suck.

Yikes! Scared me for a while there, hoping there wasn't a bug in the flickering routine (that is, other than the known bugs that are already there ) I think the problem lies here: if paddle < 38 then p3x =p3x - 1 : if p3x < 28 then p3y = 140 I'm pretty sure you want p3x = 140 at the end of that line. p3y=140 would move the third car off of the visible screen. Doh! Thanks for catching that. Man I suck. Thanks, Batari!

Better?

Here's a proposed label. I'd much rather have a drawing of some guy with a paint brush running from something (away from the observer) with a wierd robot and nuclear vial over his head. But I can't draw that well.

Unfortunately I still can't get it working. I tried what Michael said and what Stephen said and all paddles always equal 0. I even tried mapping keys to the paddles, which I'd rather use since it is a 4 player game and I'd like to emulate more than one paddle at once if possible, but that didn't work either. I made sure controllers were both set to paddle in the Stella green screens and reloaded the rom also. Tried starting with -bc paddles and saw that it was set to paddles in green screen which was good, didn't work, I tried reload and didn't work. Attached is the source and bin I'm having trouble with. Stella 2.3.5 and bB 1.0. (note: this is the same that I just posted in the other thread about the player 3 sprite issue) Thanks in advance! ultindy500_0.1.basultindy500_0.1.bin

Note I'm using Stella 2.3.5 on Win XP and bB 1.0 (at least that is what bB README.txt says).