Adventure programming questions

[+Cafeman]

Nukester was mentioning the disassembly of the 2600 Adventure game.

 

First of all, could you post where this is located at?

 

Secondly, maybe you could just answer a question of mine without my having to look -- the candlelight effect in the invisible/dark parts of the maze. How is this done?

 

After some thought, this is how I would do it in the Atari 5200 context:

 

1. the maze, which would be redefined character sets acting as tiles, would use the same color as the background register. Hence, collision would work but you would not see the maze.

 

2. I'd have a tile/character that would be bright to emulate the 'light' color. I'd program a routine that would:

 

(a) Deduce at what X,Y coordinate the player was at. Since players occupy different memory locations than bg graphics, I'd have to have my own counters and keep it in sync, I suppose.

 

(b) Calculate about 2-5 character rows above the Player's X-Y location as it would correspond to the bg screen. I'd then check in screen RAM -- I'd draw a box around my player over top any empty character slots, but if I detected a tile of maze graphics, I would not draw overtop that.

 

© Each frame as the player moves, I'd erase the Light tile and redraw the whole box around the player, remembering only to fill in the empty slots.

 

-----

 

Now, this is probably a bit different from the Adventure way because that's in a pixel mode -- 2600 has no character mode,correct? In fact, I'm more familiar with graphical FX using pixel modes and not character modes, since Koffi is in Antic E, a high res pixel mode.

 

Comments?

[NE146]

quote:

---

Nukester was mentioning the disassembly of the 2600 Adventure game.

First of all, could you post where this is located at?

---

 

Geeze Louize Cafeman you mean after all this time you've never been to The Dig? It's an old cool page

 

http://www.neonghost.com/the-dig/rev_eng.html

[Nukey Shay]

http://www.io.com/~nickb/atari/doc/adventur.txt

 

Joel Park is currently making a much better one that breaks down the variables and jump points.

 

The "candlelight effect" in the dark mazes is done simply by making a large block as a sprite and setting it to quad width. Give the playfield priority, and the "light" will be blocked where ever color registers 0 and 1 are found on the screen. You may have noticed that dark rooms flash with only two objects present...that's because the light IS an object as well. Therefore, step 1 is ok, and step 2 is not necessary. To figure the positioning of the "light", you would just subtract a given number from the player-controlled character. That should be much easier than having to "draw" the light whenever you move.

And nope, the 2600 has no character set (only pixels that operate in a few modes).

[+Cafeman]

Wow, that's much simpler and elegant of a solution than what I was trying to figure out. Too bad you gotta burn a sprite, but oh well. 5200's got 4 players!

 

The problem with that method springs up with our new 5200 Adventure II -- if we have detail that the player can move over top, then messing around with priority will cause the player to walk 'behind' the cobblestones, etc. However, I think that in the dark rooms we just will omit any floor detail to prevent that problem.

 

 

Nope, I've never been to The Dig. I'll check it out soon though. There's only so much time and I don't need excessive 2600 knowledge in my brain while trying to code 5200 stuff.

 

Speaking of bg priority tricks, on Koffi I found that I was able to change the bg-to-player priority in a DLI on a per-scanline basis. That can cause some nifty FX.

[Nukey Shay]

The priority can be set to players 0 and 1 only or all of them. The screen color priority funtions the same way. So, the floor tiles and light sprite can be made to have low priority, while the walls and player character have high priority. My advise is to experiment with all of them using a sample program that puts one of each type on the screen...to give you some idea of which players/colors to assign to particualr objects/graphics. That might be a good idea so you won't end up having to change everything if the wrong combo was picked by accident.

Here's another thing that had me stumped about the game for a while until I ran across that disassembly.

The way that the ball-object collisions work is by using a table that contains all the 15 objects in the game (except the message...which is hard-coded in place). Each one is given a room number variable, table addresses, and states (open/closed, biting/running/dead, etc)...and addresses to the bitmaps for those states. The dragons and bat are given a few extras (x&y directions, x&y old direction), and the bat is given a couple more (object carried, carrying/fedup).

Anyway, the program runs through the sprites two at a time. Looks at the next object's room number. If it's a match, it grabs the variables of the object position and state graphic, and dumps that into temp variables and jumps to a generic display routine. it does the second object the same way. As these two objects are on the screen, the program checks it's collision registers to see if anything hit. If something did, the program transfers the object number currently in the object counter so it knows which one it was, before looping back and testing the next two objects. In this manner on the 5200, you are only limited by the number of objects you can bear to look at at any given time. You could have 256 objects using the 2600 routines, if it were not for the insane flashing. The same thing goes for the number of rooms. The 2600 draws its playfield in a bizzare method, but the underlying routines that gather the room number and map directions would be completely useable on any 6502 platform...and offer as many as 256 unique screens without modification to the code (which is why my interest in 8k of address space).

In short, this disassembly is definately worth your time to look at (even though some spots will have you laughing to yourself).

 

[ 06-06-2002: Message edited by: Nukey Shay ]

[Nukey Shay]

Another quick note while I'm thinking about it.

Haunted House did the candle effect pretty much the same way, except that instead of an unchanging block, alternating bitmaps of larger/smaller circles was used. By setting the colors of objects in the room to be the same as the background (black), these would only be visable as the colored "light" falls over their location. Very simple, and quite effective.

[+Cafeman]

Also, the light blew out when a creature entered the room, eliminating flicker.

[Nukey Shay]

Ha ha... yeah, Too much flicker in your game? Easy, just make everything dark. Problem solved.

[Joel D. Park]

Sorry Guys, I will get the Disassembly for your guys very soon... I have it at home ready to go.