Ben_Larson

I actually did this not too long ago playing sonic 2 w/ my wife since we only have 1 genesis controller. works great for whoever is playing as tails. Ben

Here's (i think) the final v1.0 of 'Incoming!', with 4 different binaries for your television format of choice. I can't resist attaching a screenshot of the awesome SECAM version in it's 8 color glory. Ben Incoming1.0.zip

LS: did you ever get a chance to redo the donkey kong demo using the venetian blinds (interlaced sprites) technique? I think this type of flicker might look better on a real TV. Another idea might even be to try venetian blinds without the flicker, i.e. just show one frame of the interlaced sprite all of the time - leaves a lot of 'blank space' but elminates flicker... Ben

But there was one binary posted in this thread, so someone must have written *something*. I think the most likely explanation is that he just got burnt out and gave up...something that happens very easily with atari 2600 development I've found. The system is just so unforgiving and hard to debug. It's verrrry easy to lose motivation. When it stops being fun and starts being tedious, frustrating work, then there's very little personal incentive to continue. The other issue is that a lot of people (including myself) get ideas and then want to start working on them without sitting down and really figuring out an honest level-of-effort estimate and an honest estimate of how many hours per week we'll be able to spend working on it. When you crunch the numbers and then you see yourself looking at a multi-year commitment, it's often a pretty effective deterrent to starting off on a new programming crusade... Ben

ok I'm an idiot. I reintroduced some bug where I wasn't initializing the I/O ports right, and so consequently the joysticks were going haywire on the real hardware. that was probably the cause of the annoying sound (since the game makes a sound when you move the joystick). try this one instead. as far as the glitchy bottom of the screen, I still don't know what's going on there. more photos might help... Ben Incoming1.0RC6.zip

Hi guys, Add me to the list too, I live in Columbus. Ben

Walter, Can you describe the glitches at the bottom of the screen on the PAL50 version? Also, does the problem with the sound disappear when you start a new game, or do just the screen glitches disappear? Thanks, Ben

Ok, new source code and binaries. Nothing really changed from the last version except the new video standards supported (well, hopefully supported ). If someone with a PAL TV could be so kind as to test the PAL binary on real hardware I would appreciate it. Thanks, Ben Incoming1.0RC5.zip

No kidding, I was thinking the same thing. Not many 2-player cooperative Atari 2600 games that come to mind...

The scary thing is that all of their 'screenshots' look doable on actual Atari 2600 hardware. They must have actually done their homework for this prank. Ben

Just a quick update: I began working on the PAL conversion this last weekend and should have something relatively soon. Actually the source code should support 4 compilation modes total when I'm done: NTSC, PAL, PAL60, and SECAM (the SECAM version is comically ugly so far but I'm doing it for the challenge ). Anyway stay tuned... Ben

In 'easier mode' (i.e. when you see the '1' with the bear face next to it), the computer generally won't get one shot kills (I say 'generally' because it still happens occasionally). Did you try that mode yet? Ben

Been busy with other things so I've been a bit neglectful lately...but here's a new version. Bob I implemented your fix to the random number seed bug and used the new sound. I also made 'easy mode' slightly harder. I wasn't so keen on the 4-pixel alignment though because I kinda felt that it limits randomness, particularly when the players are on the same level. So then...I think I am about to call it a game and say this is the last version, barring any bugs. I got some other ideas I'd like to move on to for a new game (that will probably come out in 2015 at the rate I go ). First I suppose I gotta do the PAL version of this one though (and then maybe the SECAM version for laughs? ) Thanks guys, Ben Incoming1.0RC4_NTSC.bin Incoming1.0RC4_NTSC.asm.txt

Here's a new release that 'slows down' the joystick and 'speeds up' the select switch (I did this second part in lieu of debouncing since there's very little free space for that). Also I made the easy-level difficulty easier. The computer will almost always undershoot or overshoot on easy mode diffficulty now. In fact maybe it's too easy now on easy mode...so you're all welcome to test it. K I actually just read a bunch of these new posts for the first time so I'll respond now: But...the tanks actually looked a lot more generic and crappy before though! That's sorta why I redid them and added the clouds, to give it a little more cartoony feel. I actually wanted to redo the font using bubble/balloon numbers too...but I don't think it would work so well given the low resolution. I used to draw cartoons of my professors in my note margins actually, so I think this is an excellent idea... but it WOULD be kinda lame for me to just steal your idea. not to mention the fact that your mockup looks pretty cool, i'd kinda like to see it implemented. plus...I could always help out with the math. It *could* be changed...but I'm pretty much out of rom space again, and sort of reaching a point of diminshing returns on optimization, so maybe not... but...a better question: why do you want the ability to kill yourself anyway?? Ben Incoming1.0RC3_NTSC.bin Incoming1.0RC3_NTSC.asm.txt

Ok new version. I'm just calling this one RC2 since I already went to release candidates (possibly prematurely ) I implemented basically all of Nukey's optimizations (except the illegal opcode ones) and found a few other optimizations on my own. I then proceeded to add an explosion sound and color cycling effect when someone gets hit. After all that there wasn't much space left (again), so I decided to add a (slightly) easier difficulty option (the infamous 'teddy bear mode' ) since I felt that was the most bang for the buck. to get to that just hold down select for a while...you'll see it. So in summary here it is. Woulda been done sooner but I just got back from vacation in Las Vegas. I wasn't doing any programming while I was there I am sorry to report. -Ben Incoming1.0RC2_NTSC.asm.txt Incoming1.0RC2_NTSC.bin

Maybe some kinda split-screen 2-player game w/ scrolling. Seems like your engine might be able to do that with some modifications. Maybe a split-screen 2-player racing game with scrolling?... or a split-screen sequel to combat (err...combat 3)? The scrolling platformer idea might be cool too... Ben

I actually thought of the exact same idea the other day after posting about this. I think that's what I will try to do. I forgot to comment on this earlier. The 'gravity defying tanks' is a result of using the hardware collision detection. I agree it would look better to make them fall under those circumstances...but it would take some extra logic, and rom space is in short supply if I'm gonna stay under the 4k mark... so we'll see. Ben

Actually I'm planning to do a 'real PAL' (i.e. PAL-50) version. Not sure if it will be a 'cheap conversion' (i.e. just add blank lines) or a 'real conversion' (try to stretch the picture) right now though. You should at least avoid any color loss with the current version if your equipment supports PAL-60 (although the colors will be wrong). Ben

Wow thanks for all the feedback guys. I was beginning to sorta think nobody really cared... Nukey I feel embarassed that you actually read though my crappy source code. But anyway, I built your binary and it appears to work fine except for a small player-graphics graphical glitch right before the scores are displayed (in z26 at least). Maybe that's because I had to replace your LAXs with LDA and LDX since my version of DASM doesn't seem to recognize the illegal opcodes. I'll definitely try to merge your optimizations into the baseline though. Also, I'm aware of the scanline count going off a bit after a tank gets hit - that happens when the playfield is being generated (takes a while to do), so the timing to keep a stable picture isn't perfect there...but it's only 1 scanline and it appears to work fine on a real TV. I agree with all of you that it needs some sort of tank exposion sound effect, I just didn't put it in cause ROM space was so low. Actually...I sorta knew as I was posting the RC1 binary that I was gonna 'get it' for this. With regards to an actual explosion on screen...I don't think that's gonna happen unfortunately. See the way I'm displaying the player graphics on-screen is very ROM-inefficient but very fast speed-wise (classic computer science speed-vs.-memory tradeoff). I did it that way in order to have time to display the full width asymmetrical playfield, 2 single-line resolution players, the double-line resolution ball, and also have time to do the playfield and background color changes. The only way I think having an explosion on-screen would work would be to write another kernel to use during the explosion sequence which doesn't display the ball and I don't think there's ROM space for that. Although I suppose there's the possibility of illegal opcodes in the kernel to shave off more time...that I have not looked into. At any rate I will put in an explosion sound at the very least. I could also add some randomization to the computer shot calculations...the thing is, is that I seem to beat him fairly regularly so I was concerned that it might be too easy if I do that. Maybe you guys could post some of your scores in games vs. the computer to convince me otherwise?... Thanks again, Ben

New version everybody. I think this *might* be the 'official' v1.0 release version barring any new bugs found... There's a change list at the top of the source code if you want to see exactly what changed. But in summary: spent a long time optimizing stuff to squeeze out more ROM space, fixed some math bugs, improved the AI some, added a new 'random terrain roughness' mode, and made a small graphical change to the clouds. Enjoy!...and feel free to comment/criticize/scathingly denounce... Ben Incoming1.0RC1_NTSC.asm.txt Incoming1.0RC1_NTSC.bin

in my (perpetually in development ) game 'incoming!', computing the X and Y shot vectors takes forever (in computer timespans at least) because I'm doing "poor man's multiplication" (i.e. just adding over and over). originally when I was doing this it was destabilizing the kernel for higher power shots because it was taking too long, so I had to modify things so that it did the computation in pieces. with power = 99, it takes 10 frames total to compute. i could probably do it in fewer, just haven't messed with it since it's working as-is...and i have a tendency to break things that are already working. -Ben

well if you're using fixed point notation, then 8.8 is the same as 16.0, right? I mean, it's just a matter of how you interpret it. with that said I think you could use this method (scroll down to 'Binary Multiplication'): http://www.atariarchives.org/roots/chapter_10.php Basically the algorithm is long multiplication like you'd do by hand, except in binary form.

I updated the Atari 2600 section to mention Batari Basic as well as to mention how Atari 2600 programming could be considered a form of hard realtime computing due to the timing constraints... Ben

It seems relatively doable except the walls I think would have to be constrained to 40x20 or 32x25 resolution (or something like that). Unless you used superchip ram in which case you could have double the wall resolution. Also I thought more about this...and I think there would definitely need to be distortion correction (i.e stretching wall columns vertically as you get closer to the edges of the screen) or things would not look right when you turned left and right. I think maybe this could be precalculated and hardcoded though since the number of columns is relatively few, thus avoiding any multiplication there... Turning the TV sideways would not be needed. The only reason Merlin's Walls was done like that (I think) is so he could use multiple colors for the walls. Ben

sorry accidentally posted twice...deleting!