Loderunner 2600 mockup

[happymonster]

Based on posts in the Jumpman 2600 thread, I decided to make a mockup for Loderunner on the 2600. The original Apple/Atari/C64 versions used 10 x 10 tiles, so I've used the Spectrum and Vic 20 versions as inspiration, which use 8 x 8 tiles with a smaller screen size.

 

The level is constructed from the playfield, using alternate colours to show the differences between wall bricks, ladders, poles and gold. The score and life indicator are also using the playfield, although a good 2600 coder might be able to come up with something better here.

 

This is the cool idea I had though: The two reddish enemies visible here are taken from the Atari version, shrunk by 2 pixels vertically and recoloured halfway down as in the Atari. The player though is actually made from the ball sprite. If you look closely you will see there are no gaps, just the X and width changed between 1, 2, and 4 clocks wide. Although not looking quite as good this can be got away with if we use clever images for the player. So, now we can then use the 2 missiles in the same way to make 2 slightly worse looking enemies.

 

With this technique we can have one player and 4 fully animated enemies on the same row of blocks without any flickering.

 

I think the mockup looks pretty good, and I think it would be doable on the 2600. Hope it inspires people!

[+SpiceWare]

Leprechaun

[happymonster]

Er.. ok. I still think the mockup I did looks better though.

[+SpiceWare]

The mockup looks nice, but it's not playable - Leprechaun is.

[vdub_bobby]

I like the mockup, and I'd like to see Lode Runner on the 2600, especially since Leprechaun seems to be mostly dead at this point - but an asymmetrical playfield plus drawing sprites with particles plus regular sprites is almost certainly just too much for one poor little kernel to handle.

 

And before I get too excited, I want to see the missile-men animated. Can you make them run using just the missile?

[+SpiceWare]

I suspect you don't understand some of the limits of the 2600. One of those is the color of objects is linked - the color of Player0 = the color of Missile0, Player1=Missile1 and Playfield=Ball. Assuming the player is Sprite 0, then the 4 enemy characters you're proposing to draw w/out flicker use Sprite 1, Missile 0, Missile 1 and the Ball.

 

The enemy drawn by Missile 0 would be the exact same color as the player. It might be a tad difficult to tell them apart.

 

The enemies drawn by Sprite 1 and Missile 1 also share colors.

 

The Ball shares color with the playfield, so any enemy drawn with the ball would be striped blue/gold/blue/gold/...

 

 

The other limit is there's only 76 cycles per scanline. You can use less, but not more.

 

The timing to draw "sprites" using the ball or missiles is extremely expensive. As an example, the routine here takes 18 cycles to update just missile 0. Missile 1 and Ball would take the same, or 18*3 = 54 cycles to draw 3 enemy, and this routine doesn't include the logic to determine if the enemy should be drawn or not.

 

Using SkipDraw to draw the sprites will take 15 cycles for a single color sprite or 21 for a multi-color sprite. Opting for single color would yield 30 cycles to draw the player and the last enemy. In other words, we need 84 cycles to draw the player and the 4 enemy - but we only have 76. To top it off, we haven't even added the CPU time to draw the playfield or to update colors.

 

Sure, your mock-up is nicer looking than leprechaun; but it's a mute point as your mock-up can't even be done.

[supercat]

The timing to draw "sprites" using the ball or missiles is extremely expensive.

 

There is a reason M Network games that use that technique all run at 2-line resolution. Given enough expanded memory, Lode Runner could work with missilemen and 2LK resolution. I did some experiments that would suggest BurgerTime could as well (I wonder if that's what was planned?)

[happymonster]

Ok, you are correct that I am not a 2600 programmer or aware of all the limitations. After seeing NotBD I thought this would be possible without such a dynamically changing playfield. Some points:

 

1. I forgot that the ball shared the same playfield colour, but in this case it wouldn't look too bad.

 

2. I know that the missiles share the same colour as the sprites. Since the sprites run on tile boundaries the colouring split from red-white would work in most cases, only when a sprite/missile man falls or climbs down a ladder for a few frames would that colouring go wrong. But still it would look better than flickering.

 

3. The level is only 256 pixels wide, so would it not be possible to skip drawing to playfield 0, and just update 1 & 2, with reflection on? The level data would be reversed in the rom for the 2nd part of the screen?

 

So, if the sprites were 2 double line thickness to enable a 2LK resolution with the playfield update I decribed being correct, would it be doable?

[Cybergoth]

So, if the sprites were 2 double line thickness to enable a 2LK resolution with the playfield update I decribed being correct, would it be doable?

 

Possibly yes. To know for sure you'd have to programm it though

[+SpiceWare]

not using PF0 and using reflection works - that's what I had to do for Stay Frosty for the holiday cart. It does introduce a new constraint - you have to update the 2nd PF2 value at exactly the right CPU cycle, even 1 cycle off will cause the graphics to be messed up in the middle of the display. It has 2 major benefits - less CPU time is required for each scanline, and less RAM is required to store the display. I did update PF0 for the horizon(the hills at the top). The score divider line was done using the background color.

 

Nathan's Mock-Up:

 

Final:

 

 

Also had to drop the carrot nose, the original plan was to use the fireball's missile to draw the nose and the first few versions did so. We were also going to use 2x and 3x on the sprites for extra fireballs, but that was dropped right away as it conflicted with the nose - the missile will 2x or 3x exactly the same as the sprite will. Ended up using flicker to get a max of 2 fireballs in each zone. Flicker works well for the fireballs since fire flickers anyway. Probably could have added back the 2x or 3x for the fireballs, but by that point the RAM was all used up. I think I ended up with 1 byte free.

 

Using a 2LK will definitely help on the timing, that's how I did the shields and fireballs in Medieval Mayhem. The dragon in the middle is done with a 1LK. The PF has to be updated as a 1LK though if the left & right side don't repeat or reflect.

 

In rereading this thread, I see I came off a bit harsh - I apologize for that. We tend to get a number of "look how great this screen is" when it's not even possible, and then others get disappointed when they see what is possible.

Edited February 17, 2008 by SpiceWare

[vdub_bobby]

The main problem with 2600 Lode Runner is that you need a bunch of RAM to hold the screen display.

 

Or...if you use the Ball to display the holes filling in and closing, it might work. The filling/emptying dirt would flicker if more than 1 hole was emptying or filling at the same time, but...it just might work.

 

Need to go to a 2LK, probably need to redesign levels so that the dirt is asymmetrical but the ladders are symmetrical.

 

And using the ball for dirt would mean you can't use it for a sprite nor the gold, so you're down to 3 enemies without flicker.

[happymonster]

It did seem a bit harsh at first, but I can understand why you might get disappointed here with things like this.. Peace.

[supercat]

The main problem with 2600 Lode Runner is that you need a bunch of RAM to hold the screen display.

 

Lode Runner might almost be workable with the 2600 RAM capacity if the levels were stored in ROM in some Kernel-accessible format. If Magic Zeepy banking is workable, that might be possible, but otherwise it would be hard (if each level is 20 rows x 32 columns, that would probably require 320 bytes per level. The trick would be to recognize that every square that isn't blank on the map will either hold what's on the map or nothing; every square that's blank on the map will either hold treasure or nothing. So the game only needs enough RAM to blank out selected areas of the map. A 20-row screen would require 80 bytes, which should be entirely workable.

 

Holes wouldn't fill in nicely, but 30Hz flicker for holes should be fine. Everything but the player and monsters would be drawn using the playfield. Multiplexing the sprites for players and monsters might be a bit tough, but probably not impossible. Certainly 3 monsters plus player using 30Hz flicker would be easy. With Magic Zeepy banking, maybe even four monsters plus player (flickering monsters only) or five plus player (flickering player as well) would be achievable without midscreen positioning.

 

Edit Thinking about this some more, RAM is going to be extremely tight since the player can dig multiple holes and they have to self-fill. But let's see what RAM would be required.

 

80 bytes for playfield. Cutting this to 64 (for a 16-row playfield) might be acceptable I guess.

 

10 bytes to keep track of the last 8 holes drilled. Figure a minimum of one second between holes, and 7-8 seconds for holes to refill, so at most 8 holes outstanding at ten bits each. Refill times would get rounded to the nearest second, but such is life. Adding an extra byte would smooth that to half-second resolution.

 

3 bytes for the last hole drilled and the last hole filled, combined.

 

3 bytes for 3 monster states

 

(96 bytes so far)

6 bytes for 3 monster XY

 

2 bytes for player XY

 

4 bytes for sprite pointers (may be a little tricky to get it this low)

 

4 bytes for playfield pointers

 

4 bytes for playfield temps

 

Still need stuff like score, level, frame counters, etc. but the RAM constraints seem almost survivable, amazingly enough, especially if the height is cut to 16 (saving 16 bytes)

 

As for CPU cycles, in each group of four scan lines one would need to do:

• Eight load (ind),y for playfield (40 cycles)
  Eight load (ind),y for sprites (40 cycles)
  Four load zp,x (or PLA) (16 cycles)
  Sixteen store PFx (48 cycles)
  Eight store GRPx (24 cycles)
  Four store temps (12 cycles)
  Eight load temps (24 cycles)
  

So not counting loop overhead of extra temp variables, that's 204 cycles out of 304. Seems like it might be workable, even for 1LK resolution, though some parts would be tricky. Going to 2LK would simplify things a bit and might allow for missilemen. If each enemy state has two frames of animation, one of which can be drawn with a missile, it should be possible to swap the two states so two enemies per frame (four with 30Hz flicker) look well animated.

Edited February 2, 2008 by supercat

[+Random Terrain]

Sure, your mock-up is nicer looking than leprechaun; but it's a mute point as your mock-up can't even be done.

A mute point is much better than a noisy one.

[ZylonBane]

Er.. ok. I still think the mockup I did looks better though.

And my mockup looked better than yours over four years ago--

 

http://www.atariage.com/forums/index.php?s...mp;#entry255982

[happymonster]

Yes it is.. But you come over as a bit of an ass for saying it like that.

[ZylonBane]

And thus, my victory is complete.

[Shawn]

And thus, my victory is complete.

 

And you still have not programmed a lick into a 2600 game sense that mock up 4 years ago so I would have to say it's a pretty lame victory on your part.

[Cybergoth]

...

 

Your avatar, that is the title page from "The Killing Joke", no? Good story

[vdub_bobby]

All this talk about LR mockups makes me think that Eric B's Leprechaun is the best way to go. Sure, it uses the supercharger. But still. He's got a 32x20 play area, 4 intelliflickered enemies, and every LR element except that enemies don't drop gold.

 

What's the point of re-doing this exact same thing?

[ZylonBane]

And you still have not programmed a lick into a 2600 game sense that mock up 4 years ago so I would have to say it's a pretty lame victory on your part.

I'm quite certain people don't want their 2600 games to sense and lick them.

[vdub_bobby]

Seriously, take your slap fight somewhere else, you two.

[haroldoop]

And you still have not programmed a lick into a 2600 game sense that mock up 4 years ago so I would have to say it's a pretty lame victory on your part.

I'm quite certain people don't want their 2600 games to sense and lick them.

 

Dog simulator for the Atari 2600!

[Cybergoth]

What's the point of re-doing this exact same thing?

 

Well, Leprechaun is just some clone for the supercharger, not a "Lode Runner" VCS cartridge

[vdub_bobby]

What's the point of re-doing this exact same thing?

 

Well, Leprechaun is just some clone for the supercharger, not a "Lode Runner" VCS cartridge

Yeah, but it's exactly the same, or anyway as close as you're going to get on the 2600, except for the name and the level layouts.

 

I mean, by that logic someone should write BurgerTime for the 7800 since Beef Drop is just a clone...

 

Ok, maybe that's stretching it, but I'm sure I have a good point in there somewhere.