Ben_Larson

I can remember in 89 going to Kay Bee toys in the mall and they still had a wall with Atari games on it. I distinctly remember seeing Rampage for the 2600 and thinking 'this has to be a joke'. Toys R' Us, as I remember, also carried Atari games well into the late 80s and maybe early 90s. I got an NES in 89 I think, though, so after that I wasn't into Atari as much anymore...

Here: http://www.pouet.net/prodlist.php?platform...p;x=27&y=12

Using all 3 PF registers for the asymmetrical playfield, even if you're only displaying stuff on half the screen, isn't much faster than just displaying stuff on the whole screen because you still have to write zeroes to all 3 registers every scanline - it's 35-36 cycles (half screen) vs. 42 (full screen). So really you should try to use only 2 of the PF registers for the asymmetrical PF parts. Then you don't have to worry about writing a zero to the unused register. This method would cost 28 cycles per line... Ben

Actually I think you'll need to do 2 players + ball + checkerboard...because you have to display the game ball too, right? There's a trick you can use with the stack pointer to display the ball which doesn't take many cycles though, although the one constraint is that the ball is a constant height. Here's an example which assumes that Y is being used as a line counter: ; before kernel LDX #$1F TXS ... ; in kernel CPY BallYPosition PHP PLA ... ; after kernel LDX #$FF TXS I used this in 'Incoming' after someone on the stella list (don't remember who) pointed it out to me. Ben

The goals are always going to be above the checkerboard when you're looking straight at them, though. So if you just don't display them when looking sideways, then can't you just use separate '2 player + 2 missile' and '2 player + checkerboard' kernels?

As I see it, the only drawback to including the 90° movement is that the guy on defense wouldn't be able to see where the goal is that he's defending, at least while he's travelling laterally. But I think I could accept that tradeoff... Also, roland: very nice job so far. The use of color changes to make the grid is very innovative, although I'm still trying to figure out in my head how you'll have time to do the sprite(s). If nothing else, I think the scrolling grid alone is going to make a lot of demoscene scenesters jealous. I know I'm jealous at least. Ben

Yeah unfortunately asymmetrical playfields are sort of a killer in terms of CPU usage. A full-screen asymmetrical playfield will take at least 42 cycles per line by itself (out of 76). Comprimises could be made though: could just do a 32-pixel wide asymmetrical playfield in the center, which would only take 28 cycles. Also you could draw the playfield every other line (blanking it out on the odd lines) and use double-height sprites. I haven't done all the calculations, but this might be the only way to get the color sprites and the asymmetrical playfield, as well as a ball or missile...

I think there's one other option - player graphics will wrap at the edge of the screen, so you could use a border-color solid player graphic stretched x 4 so that it's 32 pixels wide, and position it off the right edge of the screen so that it wraps back around to the left side. Although if you were planning on using both player graphics for other things, then that obviously won't work. Ben

I assume you're using reflected mode for the playfield, but yes this is valid. A number of games use this method. I'm actually using it on some new super secret project I'm working on. The timing where you overwrite PF2 has to be done at exactly cycle 48 as you say though - neither 47 nor 49 will work AFAIK. So you would start the STA PF2 at cycle 45 and it would finish at cycle 48. As far as colors go I don't know what the exact delay is since I've never had a need to change colors in the middle of a scanline... Ben

Devin - I'm glad you enjoy it. I also think it plays at a better pace than Artillery Duel. With regards to the suggestion, though, unfortunately I think I'm done with development, as I haven't worked on it since I got done with v1.0 in April and I really don't want to lug it back out except for bugfixes. There is an 'easier' mode though, if you keep select held down until the teddy bear face shows up...did you try that yet? Ben

Hi, I was wondering if anyone has had a chance to test this on an Atari 7800. All I have is a Supercharger so I don't think I can do it. The reason I bring this up is that a while back on the Stellalist it was mentioned that the playfield graphic timings may be ever so slightly different on at least some 7800s. Since 'Incoming!' uses some pretty tight playfield timing I thought it might be good to check and see... Thanks, Ben

gotta love those google translations. i *think* a more accurate translation though is: '8.8cm flak at the brandenburg gate! that'll definitely give it away!' ...although my german is far from perfect. Ben

The games you mentioned (HR runner RPG demo, pitfall 2) use pretty advanced 2600 programming techniques, and in any case I don't think they wouldn't be of much use in creating a tower toppler type game anyway. the reason is because the display code in most 2600 games is usually too specialized to be of much value in terms of reuse. knowing 6502 is a good start, but the hard part is really learning the architecture of the system and the basic display kernel stuff. i recommend you start here if you're serious (this is where i started at least): http://www.io.com/~nickb/atari/ ...and read through stella.txt and the 'how to draw a playfield demo'. those will give you a good foundation on the basics of the system. another site with some good programming techniques is: http://www.qotile.net/minidig/ another alternative if you want to jump into programming right away and avoid some of the hardware details would be to download the batari basic compiler and start hacking around with that... Good luck! Ben

Hey John, Can't give an in-depth answer right now since I'm at work , but in a nutshell: yes you cannot use the X register to do indirect addressing the way you'd like to. The 6502 doesn't support it. If you want to use indirect addressing with an offset (i.e. LDA (Address),Offset), you have to use the Y register for the offset. Which means that if you're doing two player graphics, you have to save the Y register and reuse it. As to the zero-padding method, yes that is bar-none the fastest way to draw two players on the screen, but as you mentioned it is extremely wasteful ROM-wise. Other methods like skipdraw are much more ROM-efficient but obviously use more CPU cycles... Later, Ben

Ye of little faith. I have it on good word that evil versions of ourselves with mustaches in a parallel universe are actually playing Knight Rider 2600 at this very moment...

I tend to agree. If you're new to programming, and you want to specifically do game programming, Java or C# is probably the place to start. You can learn all of the same fundamentals of object-oriented programming that you would learn in C++ without having to worry as much about low-level stuff. If you do insist on using C++, though, the Allegro game programming library is pretty good package to use to give you some basic graphics capabilities to play around with... Ben

I think most people implement the different TV types using preprocessor logic in their code (that way you only have one .asm file to maintain). So if you do that, then it's pretty easy to add-in support to do a SECAM build too - it's just a matter of using the PAL kernel timing with some different colors. I just did it because I like the cheesiness (and challenge) of the 8-color palette... Whether anyone will use it is doubtful, but it's kinda fun to do for completeness' sake...

I think the short answer is that when you kill someone in a video game, it's usually just a generic person, or else a 'bad guy', so it's not really very personal and therefore not very taboo. But a game involving killing people *can* be taboo, though, if it gets too personal. For example: Super Columbine Massacre RPG, or JFK Reloaded.

GTA is kind of gimmicky. That's my main problem with it. Also I'm not sure the sandbox play really works in a game like this either. In an RPG it works because character advancement is an end in-and-of-itself. But in GTA, the sandbox play seems like just sort of a distraction from the real game...

graphics certainly does not always equal fun. how can it? the only thing graphics can possibly give you is a greater immersion and suspension of disbelief. that *can* make for fun because it can create an almost intoxicating sense of escapism when done right...if you've ever played half-life 2, i think the beginning of that game was a great example of this (when you're fleeing for your life from the jackboots through the apartment building and then through the canals). but good graphics are effectively worthless if the core game mechanics or story are boring. conversely there are many graphically primitive games which are extremely fun and addicting - not because they contain any sense of escapism, but just because the game mechanics are fun and addictive...

montezuma's revenge! I just played this for the first time the other day actually...it's pretty impressive for the 2600... Ben

I can't believe nobody has mentioned Enduro yet...

It's just a header file you'd need in order to assemble the .asm file using DASM. People tend to use slightly different naming conventions for various things that appear in vcs.h, so I figured it would be a good idea to include the vcs.h that I used. I was talking to Al via email a while back about doing an atariage cart release, but I don't know if he's still interested. We'll see... Ben

bob, Could you explain the general restrictions on the tiled background and on the foreground sprites for the 320 modes you've chosen, in terms of number of colors. It looks like monochrome background and 3-color foreground sprites (plus transparency?), from what I can tell... Also, any plans to experiment with NTSC color artifacting at all, sort of like how Tower Toppler does? Ben

Thanks! For those of you unfamiliar with the full story of the game, I originally started on it like 6 1/2 years ago, worked on it sporadically, then basically lost motivation and shelved it for a number of years. A lot of personal problems helped derail things too, but that's a different story. Anyway...then sometime late last year I got the urge to finally finish the long lost project... So it's been a long time in the making, although not beating the all time record of 'longest-in-development-homebrew-that-was-actually-finished' which AFAIK is still held by 'INV+', which was 7 years in development. That's just part of the strategy! Happens to the computer sometimes as well. Just gotta lower your elevation and blast through the terrain or hope that the wind changes before the other guy hits you... oh that's probably because your emulator is autodetecting it as NTSC, hence the wrong colors. I know there's a setting in Z26 to force a certain palette... Ben