Lode Runner

[CPUWIZ]

It's amazing that you both agree on the various facts yet still manage to argue....

 

No, it's not.

[Tempest]

joeybastard wrote:  

It's amazing that you both agree on the various facts yet still manage to argue....  

 

 

No, it's not.

 

Yes it is!

 

Tempest

[NE146]

And don't forget the latest.. The GBA version!

[Godzilla]

I think I'm naming my next band "Cosmic Jehosaphat"

 

LOL Im glad you like my parody pir8 brazillian cart name.

 

i bet someone could have fun making a random brazillian cart name generator...

 

no they couldn't

 

yes they could.

[Nukey Shay]

Cosmic Jehosaphat is a good band name...

much better than King F*cker Chicken

[joeybastard]

Cosmic Jehosaphat is a good band name...

much better than King F*cker Chicken

 

Dave Barry?

[Godzilla]

Cosmic Jehosaphat is a good band name...

much better than King F*cker Chicken

 

Just make sure I get my credit, and 1 point. :-)

[EricBall]

Check out my website.

 

[Nukey Shay]

Cool! It's Bload Brunner!*

 

*see lynx thread

 

BTW the gold on that screen would require 34 bytes of Ram minimum (17@ 2 bytes each...you could set them to a low number when being held by a character). And it might be better to use the missiles for enemies (like Lock N Chase did). That way you could get 6 enemies on the screen with minimal flicker.

[ZylonBane]

It's amazing that you both agree on the various facts yet still manage to argue....

We're not arguing, we're debating. Perhaps even quibbling. But back on topic...

 

Okay, did some research. The Lode Runner playfield is a 28 x 16 grid. Each grid block is 10 pixels wide by 11 pixels tall. This is full-screen on the Apple II, and slightly narrower on the Atari and C64, due to their higher horizontal resolution. It's going to be a LOT narrower on the 2600, since we only have 40 horizontal playfield pixels to work with. The advantage of this is that all the blank space on the sides will allow more cycles for register stuffing.

 

Grid objects are: brick, concrete, ladder, overhead line, and gold. All of the objects can be arbitrarily positioned anywhere on the screen. Since gold can theoretically be in a solid line across the screen, that rules out using the ball or missiles for it. So we have five objects that must be represented uniquely with a 1x11-pixel block. Actually, make that 1x10, so we can have evenly-spaced ladder steps (and save some RAM & cycles!). No wait, that should be 1x8 so we'll have two blank lines for sprite repositining. We can try a little color-switching, a la Mountain King:

 

1: blue

2: white

3: blue

4: blue

5: blue

6: blue

7: white

8: blue

 

So let's see how that looks:

 

Apple II original

 

Atari 2600 mockup

 

Yes, I realize this could be jazzed up significantly with a little gradient action on the bricks and score. Since I dropped a line from the block height, and made two of the remainder blank, I had to crush the sprites vertically by three pixels. Fortunately they're still mostly recognizable.

 

The big challenge with this layout is RAM. We're essentially emulating a tile-based display, and there's not nearly enough time in the kernel to decode each line of object data into 8 lines of playfield data. We'll have to do it offscreen into a buffer, which I estimate would consume 960 bytes (6 bytes/line * 10 lines/block * 16 blocks). The second-largest RAM consumer would be the object buffer itself. We have more than 4 unique objects, but less than 16, so a nybble (4 bits) per block will suffice. That gives 224 bytes for the object buffer (28 * 16 / 2). Since 4 bits allows 16 unique objects per block, we can use the object buffer to encode additional info like "gold dropped in front of ladder", "hole 1/4 filled", "hole 1/2 filled", etc. RAM will also be required for sprites, the sprite multiplexing routine, hole tracking, status display buffer, game state,and other miscellaneous overhead. Overall I'd say the whole thing couldn't be done with less than 1.5K of RAM.

 

Now, if someone were to do a Lode Runner derivative tailor-made for the 2600, they could impose certain level design restrictions that would cut this amount tremendously.

 

EDIT: Geeze, I took so long putting this together that 12 more posts snuck in ahead of me. Impressive work, Eric!

[Goochman]

Wow, that looks sweet for a 2600 game - would it fly like that though?

[Godzilla]

nice mock up zylon, really has the flavor of the original. and since the apple 2 was so color imparied, you could arguably not have to worry about gradients (though the 2600 version looking better than the apple 2 version does have an appeal all it's own!)

 

Eric: wow, thats a pretty detailed platforming screen on your load-runner clone. really monochromatic though. It could definately benefit from some grandients :-)

[EricBall]

Eric: wow, thats a pretty detailed platforming screen on your load-runner clone. really monochromatic though. It could definately benefit from some grandients :-)

 

The problem is there's only 76 cycles per line to draw the screen. At a minimum I need:

16 cycles to load the playfield from ROM

20 cycles to update the playfield registers

16 cycles to load/store the two sprites

5 cycles to increment the line counter & loop

20 cycles for top/bottom tests for the sprites

 

Which comes to 77 cycles. Ooops, too many. As I blather on about on the webpage, I will have to create a complex kernel to do what I want. But I do like ZylonBane's idea of making some lines white to highlight the ladders and ropes. And I may have to put in blank lines for sprite repositioning, as he described.

[moycon]

Wow thanks for all the input. For once Zylon posted something that didn't make me think he was a total picklehead.

Very awesome screen shots both Zylon and EricBall. I swear those look like a real 2600 game.

 

If Zylon ever wanted to pull a "Found AirWorld Proto" He might be able to pull it off.

 

I only wish I had got this kind of response when I asked if Archon could be done on the 2600.

I used to love that game and think it would make a great 2 player 2600 game.

 

If anyone has the time a mock screen of that would be great:

 

Old Archon Thread

 

Also if someone did make a Load Runner game for the 2600, do you think they would get grief over copyrights? I guess you could always change the name to Load Runner.

[Nukey Shay]

That's why the Lynx thread came up earlier, as there are concerns about producing a Lode Runner game for it. Some people just don't care to take chances (* also see Pesco)

[ZylonBane]

Wow thanks for all the input. For once Zylon posted something that didn't make me think he was a total picklehead.

Memory can be a selective thing, can't it?

 

For example, I used to be convinced that every single mock screenshot you post has a sandwich in it somewhere. A cruel and unfair assumption on my part, I now realize.

[Nukey Shay]

I think that the holy sandwich is reserved for games that have little chance of becoming anything other than a pipe dream...but there might have been a couple other SSDFF (screenshots done for fun)

[EricBall]

Very awesome screen shots both Zylon and EricBall. I swear those look like a real 2600 game.

 

Mine is a screen shot from a work in progress. But Zylon has given me some items I will try to incorporate into the actual game.

 

Also if someone did make a Load Runner game for the 2600, do you think they would get grief over copyrights? I guess you could always change the name to Load Runner.

 

The big problem with attempting to make a Lode Runner clone would be duplicating the game mechanics (e.g. relative movement speeds, enemy movement logic). Some of the levels were very dependent on the player's ability to affect enemy movement. Unfortunately, a simple name change wouldn't hold back the lawyers.

[Nukey Shay]

The enemy logic isn't really all that complicated, I think. When standing on a "ground" surface, they make a beeline right for you or to the nearest ladder (if the ground is not at their height). When climbing a ladder, they move in a direction based on your vertical position.

[Witchfynde]

EDIT: Oh god... anyone who really wants to feel depressed, go visit the Broderbund web site.

 

http://www.broderbund.com/

 

How the mighty have fallen...

 

Yech, no kidding...that IS depressing. I thought I had clicked on a wrong link or something...

[Nukey Shay]

Aw...established names can be worth quite a bit. In today's uncertian times, that must be the explaination.

[Witchfynde]

Or excuse

[rasty]

BTW the gold on that screen would require 34 bytes of Ram minimum (17@ 2 bytes each...you could set them to a low number when being held by a character).

Just an idea: if you limit the amount of gold to 1 per row and the number of rows to 16, you could use 2 bytes as a bitmap to flag whether the row has gold on it, therefore limiting the amount of RAM needed to 16+2 = 18 bytes

 

Rasty.-

[Nukey Shay]

Yeah, but you can't limit the gold to 1 per row (since the enemies can move them around too). Of course, you could force the game into not letting them drop the gold at some points...but that would be drifting farther away from the concept.

[mos6507]

Lode Runner is tailor-made for the Starpath Supercharger.

 

I think it's doable by using an interleaved playfield where some rows are blue and others are gold, and use the gold rows for ladders and the gold bars.

 

Not only does the Supercharger give you the ability to have a larger bitmap, but it saves CPU cycles in other ways because you can store strips of sprites in RAM also. By not having to know which scanline a sprite starts or stops, all you really have to do inbetween frames is update your RAM. The kernel just feeds the registers line by line out of RAM in a very simple, CPU-efficient way.

 

You can do quite a bit this way.

 

It should be possible to use all 5 sprite objects to their fullest with a playfield bitmap this way.

 

If you used the two missiles and the ball for gold you could have up to 3 gold bars on one scanline and then do intelligent flicker on the players if they bunch up on the same scanline. But you could use the missiles and ball for enemies instead.

 

Then you can get by with storing even just one level per multiload so you can use tons of RAM if you want for the level data. You'd then only be limited by the time it takes during VBLANK/OVERSCAN to modify the RAM.

 

I believe that storing to Starpath RAM involves more CPU overhead than a regular write, so that might be a limitation, but changes to RAM for this game should be minor on a frame by frame basis.