Jump to content
IGNORED

Why no flicker in Lock 'N' Chase?


Random Terrain

Recommended Posts

After learning a little more about the Atari 2600 than I knew before, it seems like Lock 'N' Chase would have some kind of flicker, but everything is rock solid. Why? Will we ever be able to recreate that with a future version of bB?

920113[/snapback]

 

It looks like how it works is player 0 is your player. Missile 0 is the bonus thing in the middle and the thing at the top.

 

Player 1 and missile 1 both are set to look the same. Missile 1 has its width and position adjusted to assume that particular shape.

 

It looks like Player 1 and missile 1 are displayed twice per frame and are not allowed to overlap eachother vertically. I'd have to play it to know for sure.

 

M-Network was known for abusing the missiles to fool people into thinking they were regular players. Super Challenge Football is a more famous example since it has an animation cycle also.

 

I was always intrigued by this. That's what the technical impetus was behind Death Derby. But it turned out tricky enough that only Thomas J. was about to make it happen without introducing tearing effects in the sprites.

 

M-Network didn't get enough credit for their 2600 work. I'm sure a disassembly would reveal some very clever kernel coding here.

 

To use something like this in bAtari Basic would require a custom kernel.

 

If you didn't need the missiles for projectiles, it's a good way to go.

 

Besides Lock n Chase with its vertical separation limitation, the DD kernel provides full freedom of movement for all 4 objects plus the 32x11 striped playfield bitmap and an independently colored ball that is limited to either a straight line or a dash that has to be inbetween the playfield rows.

 

I'm sure other games could be built with that.

Link to comment
Share on other sites

I was always intrigued by this.  That's what the technical impetus was behind Death Derby.  But it turned out tricky enough that only Thomas J. was about to make it happen without introducing tearing effects in the sprites.

920145[/snapback]

 

Hunchy II by CD-W uses the same approach to draw many bells on the screen. Incidentally, Sky Jinks uses the playfield or THE BALL to display almost all of the on-coming objects. The balloons are 'filled out' slightly using one of the missiles that's the same color as the airplane.

Edited by supercat
Link to comment
Share on other sites

After learning a little more about the Atari 2600 than I knew before, it seems like Lock 'N' Chase would have some kind of flicker, but everything is rock solid. Why? Will we ever be able to recreate that with a future version of bB?

920113[/snapback]

 

It looks like how it works is player 0 is your player. Missile 0 is the bonus thing in the middle and the thing at the top.

 

Player 1 and missile 1 both are set to look the same. Missile 1 has its width and position adjusted to assume that particular shape.

 

It looks like Player 1 and missile 1 are displayed twice per frame and are not allowed to overlap eachother vertically. I'd have to play it to know for sure.

 

M-Network was known for abusing the missiles to fool people into thinking they were regular players. Super Challenge Football is a more famous example since it has an animation cycle also.

920145[/snapback]

 

I'm not sure I'd call that "abusing the missiles"; more like "using the missiles." :) It seems like a pretty obvious (but admittedly still clever) thing to do, when faced with the technical limitations of the 2600. If I'm not mistaken, I believe "Raiders of the Lost Ark" uses the ball to draw the snake, and uses one of the missiles to draw the whip (i.e., when it's lying on the ground).

 

I was always intrigued by this.  That's what the technical impetus was behind Death Derby.  But it turned out tricky enough that only Thomas J. was about to make it happen without introducing tearing effects in the sprites.

920145[/snapback]

 

I used one of the missiles to draw the Sun in an adventure game that I'm (not?) working on, because I wanted to have a strip at the top of the screen that showed sunrise, sunset, moonrise, moonset, plus a few constellations, and I needed the players for the constellations, which left just the missiles for the Sun and Moon. I changed my mind and took it out-- and I never got as far as the constellations, anyway-- but I've been toying with the idea of including it as a selectable view (instead of being there all the time).

 

Anyway, just drawing the Sun (a yellow orb) with a missile was tougher than I'd expected, because at that time I was only just beginning to learn how to use the HMOVE command, and it wasn't working the way I thought it should-- which turned out to be a stupid error on my part. Resizing the missile from one line to the next was easy, but I couldn't get things lined up correctly to form an orb. And even though I tore it all out of the game-- or rather, didn't add the test code into the game-- when I did finally "get it," I was glad I'd experimented with it, because it helped me realize that my understanding of HMOVE had been all wrong! :roll:

 

M-Network didn't get enough credit for their 2600 work.  I'm sure a disassembly would reveal some very clever kernel coding here.

920145[/snapback]

 

I totally agree with you about M-Network, at least as far as their bankswitching method is concerned. (I've played only a few of their games, so I can't say how good the other ones were.) When I was reading up on bankswitching for my big adventure game, it was a no-brainer that I should go with the M-Network method, because it offers the most added RAM. And it's simple to implement, too, whereas some of the other methods seemed kind of funky to me-- but I haven't tried using them yet, so they may each have their definite advantages in certain situations. Anyway, with the extra RAM that the M-Network bankswitching adds, you can map the entire screen in RAM, and create player/missile memory that extends for the entire height of the screen, just like it's done on the 800. :cool:

 

For example, my title screens use the playfield pixels to spell out the name of the game (see the screenshots below), which takes up a *lot* of memory! So I've compressed the ROM data for the titles, and then I'm uncompressing the data into RAM when I want to display the titles. For the actual game screens, my goal is to select between different kernels, depending on the situation. For instance, most of the kernels will map player0 to the entire height of the game playing area (which isn't all of the screen, since there are strips above and below the playing area), with each scan line of player0 able to have its own color. For some kernels, I want to do the same thing for player1, and for other kernels, I want to do the same thing for the playfield. I'll have to choose which kernel to use for any given screen, since there's a limit to how much extra RAM there is (not to mention timing issues).

 

post-7456-1125259995_thumb.jpg

 

post-7456-1125260034_thumb.jpg

 

I later found this web site, which seems to imply that M-Network's bankswitching method (or maybe just the version with the additional RAM?) was devised shortly before the big videogame crash, just when it was promising to make it possible to create some fantastic new games for the 2600:

 

http://www.intellivisionlives.com/bluesky/...ts/atari1.shtml

 

(I *think* that's the site; it seems to be down right now, so I can't confirm it.)

 

My only gripe about the M-Network bankswitching is that they didn't provide a way to select the ROM at locations $F800 through $F9FF-- you can select between four banks of 256-byte RAM there, but you can't select the ROM that would otherwise go there! I figured out that you can use the ROM at $F800 through $F8FF anyway-- at least on an emulator-- even though $F800 through $F9FF is set to a RAM bank. But this seems to confuse the emulator so that it can't auto-detect the cartridge type, as it appears to expect all $FFs in that area. This can be worked around by using a command-line switch to specify the bankswitching method when starting up the emulator to play the game, but (1) I would prefer to design the game so the emulators can auto-select the correct bankswitching method for the game, and (2) I don't know if the ROM at $F800 through $F8FF would be available on an actual 2600/7800. I guess that when/if I ever finish the game and get cartridges made, I can just ensure that it works that way; but I'm no engineer, and the prospect of making an actual cartridge is all very daunting to me! :ponder:

 

To use something like this in bAtari Basic would require a custom kernel.

 

If you didn't need the missiles for projectiles, it's a good way to go.

 

Besides Lock n Chase with its vertical separation limitation, the DD kernel provides full freedom of movement for all 4 objects plus the 32x11 striped playfield bitmap and an independently colored ball that is limited to either a straight line or a dash that has to be inbetween the playfield rows.

 

I'm sure other games could be built with that.

920145[/snapback]

 

We're all looking forward to playing Death Derby when it's finished! :D

 

Michael Rideout

Link to comment
Share on other sites

Ot seems like a pretty obvious (but admittedly still clever) thing to do, when faced with the technical limitations of the 2600.

 

Not all that obvious apparently. Al Miller and David Crane repeatedly monologued in Stella at 20 that "the atari really only has 2 8-bit object". I think the quote from Al Miller was "it does have 3 1-bit objects but we can ignore them".

 

So they were of a mindset that they weren't very useful beyond doing projectiles and background elements.

 

Using the missiles in this manner takes a lot of kernel time to pull off. That's why I think it isn't done more often. Instead of just changing the graphics which would be a single load and store, you have to change two registers to draw with the missiles.

 

The way this data is encoded in ROM in Death Derby, the bits for both are on each byte and they need to get masked/shifted into position before they can be used.

 

I do see there is a 2-frame animation on the guys in Lock n Chase. I think the shape chosen is about as good as you are going to get with missiles as far as a front-view of a guy. The side view of the gremlins I did cheat a little in how it does the legs but in a fast animation it works. The football guys look more like blobs but it's okay.

 

I see the barriers are being drawn on lines that no other playfield elements appear on. So the programmer does a color change and then has to only draw the barriers.

 

As simplistic as the game is, it does offer a novel solution to a Pac Man style game on the 2600 than any of the other attempts. It does look like it does some forced vertical separation but it doesn't really feel that way.

 

I'm thinking this game engine might actually allow you to pull off a really stripped down Super Pac Man.

Link to comment
Share on other sites

As simplistic as the game is, it does offer a novel solution to a Pac Man style game on the 2600 than any of the other attempts.  It does look like it does some forced vertical separation but it doesn't really feel that way.

 

If you hack the game so to make the player and missile shapes distinct (see attachment), you'll notice that the game can freely switch between using players or missiles for the enemies. I didn't look into the code to see how the 'zones' are defined, but each enemy does have full use of the screen unlike e.g. Mousetrap.

lock1.bin

Edited by supercat
Link to comment
Share on other sites

If you hack the game so to make the player and missile shapes distinct (see attachment), you'll notice that the game can freely switch between using players or missiles for the enemies.  I didn't look into the code to see how the 'zones' are defined, but each enemy does have full use of the screen. . .

920524[/snapback]

Holy cow does that look complicated. They had to do all of that switching around, plus, the cops had to know how to move, two treasures with points that double if you get them, bars of gold to get, collision with the cops, side 'warp' doors, doors to slam which you can also use to block cops or trap them for 2000 points, and so on.

 

-- Scoring --
Gold Bars          20 points each
Upper Treasure     500, 1000, 2000 then 4000 points
Lower Treasure     250, 500, 1000, 2000, etc., doubling each time
Trap a Cop         2000 points each time (once per screen)

 

There's a lot of stuff going on in this 'simple' game and on top of everything, there's no flicker. The guy or guys that made this game should get a medal.

Link to comment
Share on other sites

My personal favorite example of crazy missile use is Dark Cavern.

 

Player 0 is the user-controlled guy.

Player 1 is one of the enemy robots.

Missile 0 is up to three different onscreen objects! The ammo and the two non-robot enemies (blobs and spiders).

Missile 1 is up to three different enemy robots!

The ball is all the bullets fired by everybody.

 

As far as I can tell they do not reuse any of the players.

 

So at any given time there could be both players, three missile0s, three missile1s, and the ball on the screen.

 

Here's a hacked binary; the modified enemy robot is the player. Notice that the default is to use the missile as the enemy robot; the player is only used for a robot when there are four robots on the screen or when two of the robots overlap vertically.

 

The screenshot shows the maximum of eight objects on screen at once; seven of which can move seemingly freely around the screen. (The extra ammo (the gun) is stationary.)

DarkCavern1.bin

post-6060-1125416766_thumb.png

Edited by vdub_bobby
Link to comment
Share on other sites

But you should qualify "freely move about the screen" because there is no way to get more than 5 objects on any one line without flicker. And since in Lock n Chase only the main character is red, I don't think it's possible to have more than 2 cops on the same line with him (P1 and M1). A 2nd copy of P0 that is colored blue must be used in zones other than the main character.

 

And I've read a million times that playfield is used as bullets in Chopper Command but I haven't looked at the code to verify this. Maybe Defender and Stargate do this too.

 

So in theory you could do a side scrolling shooter with less flicker if you employed missiles as pseudoplayers since you wouldn't need missiles for your player's ship, just for the enemy ships. If course, Stargate seems to use missiles for the hill patterns. Everything is a tradeoff.

 

This is kind of changing the topic, but one technique that Super Football uses is to go back and forth between 3 copies and intelligent flicker. When the players are in the right formation at the line of scrimage, the flicker stops and it converts itself to 3 copies. This is very slick. I would think you could do this with Galaxian type games by having them alternate between flying in formation and then breaking off.

Link to comment
Share on other sites

But you should qualify "freely move about the screen" because there is no way to get more than 5 objects on any one line without flicker.

 

You can get more than 5 on a line with double/triple sprite copies or using the RESPx trick (Galaxian). So that should probably be "no more than 5 independently moving objects on the same line".

 

Chris

Link to comment
Share on other sites

But you should qualify "freely move about the screen" because there is no way to get more than 5 objects on any one line without flicker.

 

You can get more than 5 on a line with double/triple sprite copies or using the RESPx trick (Galaxian). So that should probably be "no more than 5 independently moving objects on the same line".

 

Chris

921732[/snapback]

 

The thing I've learned is that everything the TIA can do is just a grab back of tricks but not because of timing constraints, not all of them can be employed at once on a given scanline.

 

Even though there are 76 machine cycles per scanline, you are limited to less than that because you have to get your changes out of the way before the element in question is scheduled to be displayed. Otherwise you are going to get glitches. This is especially problematic when your sprites need to be able to move all the way to the far left or you need to maintain a dynamic playfield.

 

If the 2600 used a CPU that was 2X or 4X the speed, then it could do quite a bit more work with the existing TIA.

Link to comment
Share on other sites

It's kind of a simple example, but "Deadly Discs" totally had me fooled...I never noticed the enemies didn't line up on the same horizontal line.

 

Loved that game...one of the few where it feels you're on a somewhat equal level with computer controlled opponents.

Link to comment
Share on other sites

Even though there are 76 machine cycles per scanline, you are limited to less than that because you have to get your changes out of the way before the element in question is scheduled to be displayed.

921891[/snapback]

 

Another limitation is that the only way sprites can be displayed on the line where they are positioned is by using multiple sprite copies. Were it not for this restriction, Galaxian might be able to use a wider portion of the screen.

Link to comment
Share on other sites

Wait, wait... so the player sprites can be close vertically as long as they're not on the exact same line? I was under the impression that if they were at all adjacent vertically, there would be flicker. This news makes the upcoming update of Batari BASIC with multiple sprites even more exciting...

 

JR

Link to comment
Share on other sites

Wait, wait... so the player sprites can be close vertically as long as they're not on the exact same line?  I was under the impression that if they were at all adjacent vertically, there would be flicker.  This news makes the upcoming update of Batari BASIC with multiple sprites even more exciting...

If I remember correctly, the separation between the multiple copies of player 1 in the new bB kernel must be at least 2 scanlines. I think. Maybe 3.

Link to comment
Share on other sites

Wait, wait... so the player sprites can be close vertically as long as they're not on the exact same line?  I was under the impression that if they were at all adjacent vertically, there would be flicker.  This news makes the upcoming update of Batari BASIC with multiple sprites even more exciting...

 

JR

922174[/snapback]

 

I think you need at least one blank line to avoid flickering.

 

Suppose you want to use player0 to display two "different" sprites on the screen-- a "top" one and a "bottom" one-- with neither sprite occurring on the same scan line (i.e., no overlap, so you can avoid flickering).

 

After you display the last line of the top sprite, you want a blank line so you can use RESP0 to move the player to a new coarse position without affecting the top sprite. Then you set the horizontal motion value for how much the player should be nudged left or right to get the precise desired position. Then you use HMOVE on the next line to actually nudge the player. You can begin displaying the bottom sprite on the same line as the HMOVE, and maybe also change COLUP0 so the bottom sprite isn't stuck with the same color as the top sprite.

 

If you do the RESP0 on the last line of the top sprite, or on the first line of the bottom sprite, the results will be less than perfect, which is why you really need a minimum of one blank line for doing the RESP0.

 

At least, that's the way I understand it! :)

 

Michael Rideout

Link to comment
Share on other sites

If you do the RESP0 on the last line of the top sprite, or on the first line of the bottom sprite, the results will be less than perfect, which is why you really need a minimum of one blank line for doing the RESP0.

922203[/snapback]

 

If the lower sprite is to the left of the upper sprite by more than 15 pixels, there is no way to avoid requiring a blank scan line between them. Otherwise it is possible to avoid the blank scan line, but different code may be required depending upon the exact object position.

 

It is generally not practical to use the same scan line to reposition multiple objects unless they have a fixed positional relationship.

 

Games which reuse multiple sprites often divide the screen into fixed 'zones'. This provides less versatile placement of objects than would otherwise be possible, but simplifies coding. If only one sprite is being reused, games may make the sprite-relocation line vary with the sprite position.

 

Watching the HMOVE bars at the left side of the screen in various games can be informative. I recommend that aspiring programmers look at how different games handle horizontal motion. Note that some games don't behave as one might at first expect (e.g. Vanguard uses fixed zones even in vertically-scrolling waves).

Link to comment
Share on other sites

Watching the HMOVE bars at the left side of the screen in various games can be informative.  I recommend that aspiring programmers look at how different games handle horizontal motion.  Note that some games don't behave as one might at first expect (e.g. Vanguard uses fixed zones even in vertically-scrolling waves).

That's why I made the background non-black in my multiple-sprite-kernel demo - the HMOVE lines are kinda ugly in a game, but I think they are kinda fun to watch in a demo like that.

Link to comment
Share on other sites

  • 2 months later...
ote]

That's why I made the background non-black in my multiple-sprite-kernel demo - the HMOVE lines are kinda ugly in a game, but I think they are kinda fun to watch in a demo like that.

922343[/snapback]

 

Hadn't seen that demo before. Sorta cute. BTW, it's possible to eliminate the 'zone bars' (as I used to call them) by performing the HMOVE on cycle 74 of a scan line. This will cause all objects to move to a position eight pixels to the left of where they otherwise would (so to make an object stay still, you would program it to might right eight). This technique also makes it possible to move an object left eight pixels (actually up to 15) in one scan line.

 

Technical explanation: the Atari 2600 object positions are handled using counters that repeat every 160 pulses. Normally, these counters are driven by the display pixel clock which gets hit 160 times per scan line. When an HMOVE is performed, two things happen: (1) the display counters receive 0 to 15 extra pulses, and (2) the start of the next scan line is delayed by eight pixels. If an object's HMx value is set to zero, the object will receive eight extra pulses, which will precisely offset the fact that it doesn't get eight pulses at the start of the next scan line. If the HMx value is greater than zero, it gets more than eight extra pulses. If it's "less than zero", it will get less than eight extra pulses.

 

If an HMOVE is performed just a little early, the extra pulses will be generated as expected, but the start of the next scan line will not be delayed. Thus, objects will appear eight pixels left of where they would otherwise be.

Link to comment
Share on other sites

ote]

That's why I made the background non-black in my multiple-sprite-kernel demo - the HMOVE lines are kinda ugly in a game, but I think they are kinda fun to watch in a demo like that.

922343[/snapback]

BTW, it's possible to eliminate the 'zone bars' (as I used to call them) by performing the HMOVE on cycle 74 of a scan line.

 

...

 

If an HMOVE is performed just a little early, the extra pulses will be generated as expected, but the start of the next scan line will not be delayed. Thus, objects will appear eight pixels left of where they would otherwise be.

968351[/snapback]

I tried it... and it seems to work - I bumped the HMOVE to up to cycle 74 instead of cycle 3 (was right after the WSYNC.) If this actually works right, I will probably use this version instead.

 

I did discover something unexpected. Using HMCLR does NOT prevent movement!

 

It makes sense now, though... Since the regs would all contain zero, it actually sets the movement at -8 pixels every time HMOVE is called! So you have to replace all HMCLR with something like lda #$80...sta HMM0 to actually disable movement when doing cycle 74 HMOVEs.

bBk2.bin

Link to comment
Share on other sites

ote]

That's why I made the background non-black in my multiple-sprite-kernel demo - the HMOVE lines are kinda ugly in a game, but I think they are kinda fun to watch in a demo like that.

922343[/snapback]

 

Hadn't seen that demo before. Sorta cute. BTW, it's possible to eliminate the 'zone bars' (as I used to call them) by performing the HMOVE on cycle 74 of a scan line. This will cause all objects to move to a position eight pixels to the left of where they otherwise would (so to make an object stay still, you would program it to might right eight). This technique also makes it possible to move an object left eight pixels (actually up to 15) in one scan line.

Yup. I use that technique in Running Man, the unfinished demo I wrote almost a year ago (look in my blog or in the homebrew forum if you're interested).

 

Also, for a nice, giant full chart of HMOVE behavior when hit at all kinds of weird times, check this out: http://www.qotile.net/minidig/docs/2600_ad..._prog_guide.txt (it's at the very bottom)

 

Also, I think there was some discussion on [stella] about HMOVE behavior, when hit at weird times, not being consistent on some versions of the TIA!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...