Please creatate Pitfall 3

[supercat]

I haven't decompiled the DPC source or anything, so you may have me at a disadvantage. However, it seems to me that the scrolling playfield, animated water, and several other effects were not really something that could be accomplished inside the 2600's cpu and memory constraints.

 

Vertical scrolling on the 2600 is pretty easy. None of the playfields in Pitfall II are complicated. Compare the screen complexity of Pitfall II with that of Chris Walton's Hunchy II available here at AtariAge. Hunchy II is a standard 4K cart. No DPC, RAM, or even banked ROM, and yet it has IIRC 10 full screens of tiles (there are 16 levels, but some use the same background design). Hunchy II can display a Hunchy, the Guard, a bell, and a shot all on the same scan line as a 32-pixel assymetric playfield, all without flicker.

 

Although the audio on Pitfall II is an impressive technical accomplishment, and although the game is nicely polished, the game aside from the audio is actually quite primitive. There is nothing even remotely resembling a sophisticated monster AI; indeed, all of the game actions have to be kept very simple because the game can't use a RIOT-timed "main loop action handler" the way most games do. The DPC needs to be serviced every scan line, so code has to be subdivided into 66-cycle chunks.

[jbanes]

ITALY 2006 WORLD CUP CHAMPIONS

Whiskey Tango Foxtrot

 

Vertical scrolling on the 2600 is pretty easy.

Individually, easy. I've done it as well. It's together with all the effects that it starts getting tricky. Especially if you need to construct the playfield on the fly rather than pre-cache it in ROM.

 

None of the playfields in Pitfall II are complicated.

I'm looking at the water level at the moment.

• Player 0 - Part of the score, Harry, waterfall, and part of the logo
  
• Player 1 - Part of the score, complex/animated waterfall, eel, part of logo
  
• Missile 1 - Used in water level animation? (Flipping it off + playfield has an effect)
  
• Ball - Part of logo
  
• Playfield - dirt, part of logo, Used in water level animation? (Flipping it off + P1 has an effect)
  
• Background - water, ground, etc.; Used in water level animation?
  

A list of effects:

• The eel is created by shifting Player 1 around with an HMOVE.
  
• The HMOVE lines are hidden inside the playfield using an HMOVE line recoloring trick that I don't understand. It makes the "empty space" caused by the HMOVE the same color as the PF, however. I'm guessing this is handled directly by the DPC?
  
• The Stella debugger doesn't show where the waves are coming from, so are the graphics being created by the DPC directly?
  
• P0 and P1 are alternated in colors to create the waterfall animation.
  
• P0 is recolored every line to create Harry's good looks.
  

That's one heck of a lot to track on the screen! Some of the effects don't even seem possible without the DPC, and the rest are extraordinarily complex!

 

VDub called me crazy the other day for coming up with a pre-computation scheme for sprite handling. This is crazier by far. I wouldn't even want to try without the help of something like the DPC.

 

Compare the screen complexity of Pitfall II with that of Chris Walton's Hunchy II available here at AtariAge.

They're simply not comparable. Hunchy has some nice routines to reuse the sprites and missiles across different scanlines, but everything is otherwise pretty static. The tiles are of a fixed size (for easy computation), the screens are static, and the missiles are forced to fit within particular scanlines. It's excellent work, but nothing anywhere near as crazy as what I just described above.

 

Hunchy II is a standard 4K cart. No DPC, RAM, or even banked ROM, and yet it has IIRC 10 full screens of tiles (there are 16 levels, but some use the same background design). Hunchy II can display a Hunchy, the Guard, a bell, and a shot all on the same scan line as a 32-pixel assymetric playfield, all without flicker.

That's because there's nothing crazy going on. Everything is quite straightforward:

• Player 0 - Hunchy
  
• Player 1 - Guard/Esmerlda
  
• Missile 0 - Bell
  
• Missile 1 - Shot
  
• Playfield - Platforms + hide the unused missile lines
  

I'm sorry, but I just don't buy that Pitfall II can be done easily without the DPC. MAYBE with gobs of extra RAM + precomputations you could produce similar effects through a complex multi-kernal approach, but I just don't see any way to effectively replicate the same work that the DPC is doing.

Edited July 29, 2006 by jbanes

[Thomas Jentzsch]

I'm looking at the water level at the moment.

• Player 0 - Part of the score, Harry, waterfall, and part of the logo

Nope, the waterfall is only done with player 1.

Player 1 - Part of the score, complex/animated waterfall, eel, part of logo

Correct.

Missile 1 - Used in water level animation? (Flipping it off + playfield has an effect)

Nope, Missile 1 is stationary at the left border and used to blank the screen where no HMOVES occure.

Ball - Part of logo

Correct.

Playfield - dirt, part of logo, Used in water level animation? (Flipping it off + P1 has an effect)

The animation is solely done by the playfield.

Background - water, ground, etc.; Used in water level animation?

The background changes color from light blue (sky) to black, blue (water) and black (logo) again. It's not used for any animation.
 

A list of effects:

[*]The eel is created by shifting Player 1 around with an HMOVE.

Nope, its just a simple player 1 (exactly 8 pixels wide).

[*]The HMOVE lines are hidden inside the playfield using an HMOVE line recoloring trick that I don't understand. It makes the "empty space" caused by the HMOVE the same color as the PF, however. I'm guessing this is handled directly by the DPC?

Nope, the HMOVE lines show on the left border. But like many Activision games HMOVE is either used every line of the missing HMOVE lines are made black (here by using missile 1).

[*]The Stella debugger doesn't show where the waves are coming from, so are the graphics being created by the DPC directly?

I have to look at the code for that. Everything else can be revealed by using the special emulator keys I described above.

[*]P0 and P1 are alternated in colors to create the waterfall animation.

Nope, just P1.

[*]P0 is recolored every line to create Harry's good looks.

Right.

 

So, with the corrected information, it looks much easier now, doesn't it?

[+atari2600land]

ITALY 2006 WORLD CUP CHAMPIONS

 

 

 

GO ITALY GO DEFEATED THE GERMANS 2-0

 

HAHAHAHAHAHAHAHAHAHAHAHAH

 

 

PROUD TO BE AN ITALIAN

What does this have to do with Pitfall?

[mos6507]

When judging Pitfall II, remember that the DPC was not created to enable just that game. It was created as a kind of platform on a platform like the SuperFX chip on the SNES. So it may not exploit the chip to the fullest.

 

I have no doubt that a game designed to exploit it completely could do things that would be next to impossible through other means.

 

As great as the DPC was, it didn't offer any extra general purpose RAM, so even the DPC puts some constraints on games that other formats like the Supercharger don't have. This wouldn't be a factor for a game like Pitfall II, but more RPG-like games that have more persistent game-state would be difficult to do on it.

 

If we ever finish the Chimera cartridge, it would not only be feasibe to homebrew a Pitfall III sort of game using its DPC-like functionality, but even more due to the added benefit of the extra RAM and multiloading.

[supercat]

I have no doubt that a game designed to exploit it completely could do things that would be next to impossible through other means.

 

The audio in Pitfall II would be impossible by other means (at least in the context of a playable game).

 

As great as the DPC was, it didn't offer any extra general purpose RAM, so even the DPC puts some constraints on games that other formats like the Supercharger don't have. This wouldn't be a factor for a game like Pitfall II, but more RPG-like games that have more persistent game-state would be difficult to do on it.

 

If the game code keeps Y as a scan-line counter (pretty common), and if there's enough ROM to have a mask table (really not too hard), then the DPC allows MaskDraw

 lda (shape0ptr),y
 and (mask0ptr),y
 sta GRP0
 lda (color0ptr),y
 sta COLUP0
 lda (shape1ptr),y
 and (mask1ptr),y
 sta GRP1
 lda (color1ptr),y
 sta COLUP1

to be replaced by

 lda DPCsomething
 sta GRP0
 lda DPCsomething
 sta COLUP0
 lda DPCsomething
 sta GRP1
 lda DPCsomething
 sta COLUP1

A potential useful time saver in a kernel (42 cycles down to 28), but 10 of those original cycles could have been shaved off by padding out shape data. Considering that doing music with the DPC requires 7 cycles per scan line, the net savings is 7 cycles compared with maskdraw, and -3 cycles if masking wouldn't be needed.

 

As great as the DPC was, it didn't offer any extra general purpose RAM, so even the DPC puts some constraints on games that other formats like the Supercharger don't have. This wouldn't be a factor for a game like Pitfall II, but more RPG-like games that have more persistent game-state would be difficult to do on it.

 

For anything but music, RAM is probably more useful than the DPC. Saving a few cycles in a kernel is a big deal, but self-modifying code can do a lot. In Pitfall II, I think the music was more of a hindrance than the DPC was a help.

[mos6507]

==

For anything but music, RAM is probably more useful than the DPC. Saving a few cycles in a kernel is a big deal, but self-modifying code can do a lot. In Pitfall II, I think the music was more of a hindrance than the DPC was a help.

==

 

Remember that you have to reserve time during VBLANK to modify the self-modifying code. It doesn't just happen for free. If you read up on the Leprechaun blog you'll see how Eric is really strapped for time during VBlank to do all those RAM writes. RAM writing on the Supercharger (or Superchip) is kind of slow. Even the Atari 8-bit has trouble sometimes updating graphics between frames despite the fact that it doesn't have to work as hard as the 2600 during the actual drawing. So you have to look at the big picture. You can't just look at VBLANK as this unlimited block of time.

 

Not only that, but in the end you have to keep in mind that the cart address-space is only 4K at a time. If you want a lot of graphical changes on a scanline-by-scanline basis, and you reserve arrays of ROM or RAM for that, it's going to really add up and force a lot of awkward bank juggling. Queues allow you to separate the data off and access them through individual hotspots. Data that tends to be written once and read sequentially are best presented to the VCS via queues.

 

In cases where a given effect is coded using queues and then recoded not using queues, I think you'd find that the non-queue version winds up bloated and hard to read vs. the queue version. For instance, given the work that we've done so far with text kernels, the Stellar Track kernel winds up getting heavily simplified when converted to use queues because it no longer has to JIT render each line of text between lines. That also means text no longer even requires any blank lines beween rows, yielding almost a perfect fullscreen bitmap (aside from the mandatory gaps between the sprites).

[supercat]

Remember that you have to reserve time during VBLANK to modify the self-modifying code. It doesn't just happen for free. If you read up on the Leprechaun blog you'll see how Eric is really strapped for time during VBlank to do all those RAM writes. RAM writing on the Supercharger (or Superchip) is kind of slow. Even the Atari 8-bit has trouble sometimes updating graphics between frames despite the fact that it doesn't have to work as hard as the 2600 during the actual drawing. So you have to look at the big picture. You can't just look at VBLANK as this unlimited block of time.

 

Writes to the SuperCharger are indeed slow. Except for the inability to use read/modify/write, SuperChip writing is no slower than absolute-mode writes on any other platform. The 4A50 banking chip even allows read-modify-write operations.

 

Not only that, but in the end you have to keep in mind that the cart address-space is only 4K at a time. If you want a lot of graphical changes on a scanline-by-scanline basis, and you reserve arrays of ROM or RAM for that, it's going to really add up and force a lot of awkward bank juggling. Queues allow you to separate the data off and access them through individual hotspots. Data that tends to be written once and read sequentially are best presented to the VCS via queues.

 

The $xE00 bank of 4A50 is very handy. Only 256 bytes at a time can be accessed there, but it can access any part of RAM (or any part of the top 64K of flash) with 256-byte granularity and without regard for any intermediate-sized (e.g. 2K) chunk boundaries; further, one can switch among four different 'presets' with nothing more than a 3-cycle NOP.

 

In most cases, self-modifying code will only need a small amount of tweaking each frame. Ruby Runner

 

In cases where a given effect is coded using queues and then recoded not using queues, I think you'd find that the non-queue version winds up bloated and hard to read vs. the queue version. For instance, given the work that we've done so far with text kernels, the Stellar Track kernel winds up getting heavily simplified when converted to use queues because it no longer has to JIT render each line of text between lines. That also means text no longer even requires any blank lines beween rows, yielding almost a perfect fullscreen bitmap (aside from the mandatory gaps between the sprites).

 

Are you using a full-screen bitmap for your "text" kernel? That seems to be more a function of RAM than of queues.

 

Ruby Runner implements a 10-column four-color text kernel quite nicely; each row of text is 16 scan lines, and there are no blank lines between rows. Incidentally, it's a text kernel rather than a bitmap kernel--that's why it's able to animate and scroll so nicely.

 

I can certainly imagine that queues might be useful in a complicated shoot-em-up with lots of independent object motion. Having an adequate supply of RAM is also very useful.

[jbanes]

So, with the corrected information, it looks much easier now, doesn't it?

That does help. Now that I know what to look for, it looks like Stella's debugger is glitching out. It doesn't update the playfield data and many of the registers even when it's explicitly fed updates. I guess that explains why the waves go flat after a few frames in the debugger. Even flipping on and off the playfield outside the debugger doesn't seem to have the expected effect.

 

Nope, the waterfall is only done with player 1.

There is some sort of weird cycling of colors through player0. That's what I was looking at. Perhaps just a side effect of what the DPC is doing?

 

Nope, Missile 1 is stationary at the left border and used to blank the screen where no HMOVES occure.

...

Nope, the HMOVE lines show on the left border. But like many Activision games HMOVE is either used every line of the missing HMOVE lines are made black (here by using missile 1).

I'm not quite sure I understand the effect. If it's used to cover over black HMOVE lines, then why is the missile only visible on the same scanlines as the character? By turning off the playfield, the missiles can be quite clearly seen to the left of the screen with the same color as the playfield. Is that just another glitch in Stella, or is there more complex logic at work here?

[supercat]

I'm not quite sure I understand the effect. If it's used to cover over black HMOVE lines, then why is the missile only visible on the same scanlines as the character? By turning off the playfield, the missiles can be quite clearly seen to the left of the screen with the same color as the playfield. Is that just another glitch in Stella, or is there more complex logic at work here?

 

Nothing will be visible in the first 8 pixels of an HMOVE line. A missile has the same color as the corresponding player sprite. Often, games will hit HMOVE on every line during any part of the screen where a particular player isn't black, but in other parts of the screen where the player isn't used will set the player to black so the missile will blend in with the HMOVE lines.

[jbanes]

Nothing will be visible in the first 8 pixels of an HMOVE line. A missile has the same color as the corresponding player sprite. Often, games will hit HMOVE on every line during any part of the screen where a particular player isn't black, but in other parts of the screen where the player isn't used will set the player to black so the missile will blend in with the HMOVE lines.

I think I generally understand what you're saying. What I don't follow is how this is used in Pitfall II?

 

As far as I can see, there is no left border in the game. It's all active gameplay area. Which means that the missiles are not being used to blank out the area. Instead, if you turn off the playfield in Stella, you find some lines colored the same as the playfield following the players around. Now if this was done to hide the existence of the missiles, I would understand. But I don't see any reason to do that. There's a perfectly good enable/disable bit for making these missiles go away. In addition, they don't appear to be visible anywhere expect on the lines where players are used.

 

Any insight?

[Thomas Jentzsch]

As far as I can see, there is no left border in the game. It's all active gameplay area.

Nope, the left side of the screen is clearly cut. You can easily see when you look at the reflected playfield (trees, dirt).

 

Which means that the missiles are not being used to blank out the area.

Believe me, they ARE.

 

Instead, if you turn off the playfield in Stella, you find some lines colored the same as the playfield following the players around.

Maybe you are using the original properties of Stella. Then the displayed screen starts at pixel 8, so you cant't see the HMOVE blank. Or try z26.

[jbanes]

Maybe you are using the original properties of Stella. Then the displayed screen starts at pixel 8, so you cant't see the HMOVE blank. Or try z26.

Hmmm... could be. If I get a chance tonight (might not happen since I'm leaving for vacation tomorrow) I'll try popping the actual cartridge into my 7800 and see if I spot the border.

[Inky]

This project is going to need (snicker) a lot of (guffaw) HARD WORK (pause for big laffs)

 

Dern.. Nobody got my little joke.

[vdub_bobby]

For many many games, Stella has the properties set to hide the TIA's "glitches" - for example: in Jr. Pac-Man, the HMOVE lines are completely suppressed, in Dark Cavern, Pitfall!, Pitfall II, etc. etc., the left border of the screen is at pixel 8...

 

This makes for a pretty picture, but it isn't an accurate emulation. Just gotta remember that the default properties for a lot of games are like that.

 

Or use z26.

[Pac Munchkin]

I know everyone is talking of making Pitfall 3 but have you seen the hack Bottomless Pitfall? That I think is pretty darn close to what could be called Pitfall 3.

 

Wade

[yuppicide]

Pitfall III would be awesome. You don't need to rip out some DPC or find any information on it. Just make use of some other chip that might be readily available.

[rjchamp3]

Again somone should just give me a course on home brewing, so i can just make one, jezz everones ideas suck out here my god all talk no action, so somone coach me and ill create a game.

[kirin jensen]

Again somone should just give me a course on home brewing, so i can just make one, jezz everones ideas suck out here my god all talk no action, so somone coach me and ill create a game.

If you look on this very site, you will find tons of info about coding for the 2600.

 

You will find batari Basic, and support for using it.

 

The Programming forum logically contains helps and tips for new and not-so-new programmers.

 

Mind you, machines are not as forgiving of typing/spelling/grammar errors and general stupidity as people.

 

Now cut it out.

Edited August 7, 2006 by kirin jensen

[D.Yancey]

Rudy, When are you going to make your triumphant return on Twin Galaxies??

[Shannon]

Again somone should just give me a course on home brewing, so i can just make one, jezz everones ideas suck out here my god all talk no action, so somone coach me and ill create a game.

All that talk alone was enough info to get anyone with half a brain going...

[rjchamp3]

I dont feel i said anything wrong just the truth

[BrianC]

I dont feel i said anything wrong just the truth

 

First off, hacks and homebrews are not the same thing. Hacks are rewrites of existing games. Homebrews are new games made from scratch. This search can be used to find homebrews. Just set region to all, rarity to H, leave everything else as is, and then click "Begin Search". There are download links for the homebrews at AtariAge. I highly recommend trying each and every one of them, especially Marble Craze, Qb, Oystron, Skeleton+, Gunfight, Seawolf, Crazy Balloon, Conquest of Mars, Fall Down, Thrust+ Platinum, and Star Fire.

 

Hacks are avaliable at the AtariAge site too. They can be found here and at the pages for the games at www.atariage.com that they are hacks of. These are edits of existing games and IMO should not be referred to as "homebrews".

 

Please try to give other homebrews and hacks a chance and respect ideas instead of claiming that yours are better. Also, throwing out random stuff like Pitfall 3, Three Stooges, etc without any indication of how you want the ideas to be used will not make more hacks or homebrews. You can't just force random ideas on people and expect them to be done.

Edited August 8, 2006 by BrianC

[Pac Munchkin]

I dont feel i said anything wrong just the truth

 

First off, hacks are homebrews are not the same thing. Hacks are rewrites of existing games. Homebrews are new games made from scratch. This search can be used to find homebrews. Just set region to all, rarity to H, leave everything else as is, and then click "Begin Search". There are download links for the homebrews at AtariAge. I highly recommend trying each and every one of them, especially Marble Craze, Qb, Oystron, Skeleton+, Gunfight, Seawolf, Crazy Balloon, Conquest of Mars, Fall Down, Thrust+ Platinum, and Star Fire.

 

Hacks are avaliable at the AtariAge site too. They can be found here and at the pages for the games at www.atariage.com that they are hacks of. These are edits of existing games and IMO should not be referred to as "homebrews".

 

Please try to give other homebrews and hacks a chance and respect ideas instead of claiming that yours are better. Also, throwing out random stuff like Pitfall 3, Three Stooges, etc without any indication of how you want the ideas to be used will not make more hacks or homebrews. You can't just force random ideas on people and expect them to be done.

 

 

WOW Brian thanks for the info on the searches, I found a lot of Homebrews I don't have!

 

Wade

[Shannon]

I dont feel i said anything wrong just the truth

I was stating what you incorrectly perceived as the truth.