CDS Games

That would indeed be a good trade...but the logistics are complicated. At least for me. I'll look into it though. Changing into a fireball sprite has the advantage of not requiring any extra RAM addresses.

Yep! We had the DK board game and Frogger as well, and stupidly about 20 years back I told my mom to toss them. <P> If I remember right, Donkey Kong had a rubber-band activated barrel dispenser.

They don't shoot unfortunately. I really wanted to implement shooting for the demons but couldn't come up with an easy solution. That's an interesting thought to use an object...however, I'm not sure though how you can get an object to appear like that, as they are typically placed at level start and you'd need a whole routine to place them during play. I also considered using one of the dedicated enemy sprites, but the movement/speed patterns would be different and I couldn't figure out how to separate them from the regular enemies.

We're almost there actually. Batari made a very nice looking demo with moving elevators, but he didn't get a chance to finish the rest of the level. I finished the level but without any moving elevators. At post #32 of that thread I posted earlier, I started adding his elevator code in to my version. It might be a little tight getting everything in there, but it should be possible.

I did just that a few years back. Still needs polishing but most of the basics are there: http://atariage.com/forums/topic/229931-donkey-kong-2-lost-levels/

Just hacked it, sorry.

1.) I've never felt it was a problem, but ok. 2) The girders are blue in the arcade. Do you mean why are the ramps purple and not red? 3) True, but it's been a while since I've looked at the code so I'm not sure. 4) The Foxfires all use the same sprite. If they moved up and down, they would have to flicker. And yeah, the movement routine would have to be more complex. I don't recall when I worked on it that there was much empty space to add things like a flicker manager and foxfires up and down ladders.

Yes, and this touches on the larger point of how to judge VCS titles now, as an adult who knows its limitations, instead of as a 10 year old upset that there are only 2 screens of Donkey Kong. I can't fault a programmer or company for not doing "the impossible". Ok so people here have been amazingly pushing the envelope of that, but let's expand it to mean impossible either technically or practically given the schedule, knowledge, or manufacturing constraints of the time. You can, though, criticize a game for not meeting even the basic standards of the era. Cruddy graphics are cruddy graphics, and a decent looking sprite doesn't cost you anything extra once the bits are allocated. And I don't find too much to quibble about with Coleco's output here...Zaxxon and DK Jr, yeah, some sprites could have been better. Donkey Kong looks good; and anyone who complains about Gingerbread man up top ought to try hacking something better...I tried and gave up. Mousetrap looks great. Smurfs, Carnival, and Venture all look good.

Right. Garry Kitchen said his intention was to include all the screens in an 8k game but was overruled. Add those two missing screens and there would have not been much to complain about.

I've seen no evidence that this was true. The Colecovision was a more powerful console. You didn't have to "downgrade" games purposefully for Atari because they were already handicapped by running on a 1977 Pong-era unit (2 sprites/128bytes RAM as opposed to 32 sprites/1k RAM). Anyway, Donkey Kong was a solid game for the 2600 that sold very well. Zaxxon had its issues, but it would have been an immense challenge no matter who tried it--again because of the limitations of the 2600. Graphics you can fault to some degree, but even Activision had some clunkers in that regard--notice the massive difference in Double Dragon between the great-looking backgrounds and the sprites. More likely Colecovision's idea was to make a ton of money selling Atari carts that would then be funneled into its own system, which would then take over the market from Atari (or at least grab a chunk of market share).

Playfield pixels are too low resolution for that job unfortunately. If you see that blank space the rocks are in...that's only two playfield pixels wide. Putting a dedicated rock sprite there would really be the best way to get the effect you want--but I'm not sure if that's feasible and there will likely be tradeoffs. It'll make the flicker worse, for sure.

The ball is a bit odd--its width can only be set to 1, 2, 4, or 8 pixels. So you can't have any line at 3 or 5-7 pixels wide, or any lines with gaps between pixels (like 1F42 in your sprite). In other words, you wouldn't be able to recreate your first animation sprite with the ball. The closest you could get is something like this…all the lines are either 1, 2, or 4 pixels: But like Nukey said, you'd definitely have to change CTRLPF on the fly and also HMBL (f you are using this design) to reposition the ball a couple pixels per line. If the kernel cycles are tight, it will be quite a challenge getting it to work. Wavy borders on the strata divisions might be possible. You can get a subtle wave effect by inserting a background-color border between the strata. Like so: Haven't really looked at the code to see if it's feasible though.

Very, very impressive!! I love how smoothly it works. Your half-screen versions would work well with a Bard's Tale style RPG. Your engine could be used to move through a dungeon, and then when you encounter a monster you can switch to a turn-based combat system in another bank. Might be a little less kernel-intensive than a first person shooter. http://bardstale.poverellomedia.com/thebardstale-story.html

I've been experimenting with the Dark Chambers engine--it has a lot of promise for more sophisticated Diablo-style action adventure games. Instead of 2 sets of stats for Player 1 and Player 2, you get rid of player 2 and use those extra stats for mana, gold, and additional items. Here's a sample: Top red bar for health, blue bar under it for mana. White score for XP, yellow score for gold. You also have a few extra bits you can use for additional items. I haven't tried anything with a second controller, but I basically had the same idea you had--keypad in the right port for inventory/spells/etc.

Some of my favorite hacks: Galaxian Arcade Double Dragon arcade style Defender Arcade Venture 3

Nukey is an inspiration. Not just making extremely involved hacks, but making games easier to hack, explaining the code behind his hacks, and taking time out to help much less talented hackers. *cough cough*

Plenty of extra memory carts were made, even back in the day, and memory is basically not much of a limitation anymore. What are we up to now...512k? But all the memory in the world isn't going to change the basic limitations of the console. You still are stuck with 2 sprites, 2 missiles, and a ball--one color per line, very little free cycle time, etc. I'm not going to say Dragon's Lair is impossible, but it would take a pretty amazing programmer to squeeze even a stripped down version of it out of a 1977 glorified Pong console. If you mean can the Atari computer versions of the game be played on the 2600, then no--different hardware, so they would have to be reprogrammed from scratch.

That game always looked terrible to me. Well a couple of months ago, I found it cheap and got it for my daughter. My kids LOVE it. I realize now it's actually a great game for young kids. Firefly and Air Lock I'd definitely consider bad games.

I've started a fix of the Tempest proto that I hope can eventually be made to use the Driving Controller. http://atariage.com/forums/topic/251026-fixing-the-tempest-proto/ That's a ways off though...I'm in the middle of another hack right now and can't even work on that I'm so busy.

If cycles are an issue, how about dropping the PF0 draw completely and getting by with a narrower playfield? You'd only be losing 4 playfield columns per side, and that might free enough room to add color. Would need level redesign and tweaks to the movement code of course.

Heh....*sheepish grin*...sorry! Hacked it the ugly way in Stella....made comments in a separate text file.

Fantastic, thanks Nukey!!

Very nice!!!

It works on the portable? That's good to know. I'm sure there is....I'll have to read through the threads and see if there are any quick code substitutions I can do.

The program blanks all the playfield registers at F0FA to F0FF, which is why there's that gap. Change all those playfield writes at those locations to "NOP" (EA) and it will close the gap. Popeye2closedgap.bin With the extra room you *could* also throw in a color change for the playfield, so on level 1 you can have the grass green and the lower levels brown like the arcade. I set it to F4 because I'm not sure what brown you used in your image above. See here: Popeye2colorplayfield.bin Though the problem with that is, it now sets F4 as the playfield color in all 3 levels and I'm guessing you don't want that. You'd need one extra byte in the code here. Although maybe if we can save a byte or two above where it sets the green...hmmm....