It's fake screenshot time

[davidbrit2]

I'd comment more on this now, but I've got an anthropology assignment that needs doing. :-)

 

[NE146]

I dig it!

[ZylonBane]

Fake harder!

 

 

[Nukey Shay]

I thought it was level 3 over here?

 

Here's a modified one using balls as prizes:

[Cupcakus]

Those are very good fakes :-)

 

You should have been hired on by that Airworld guy... :-) He may have lasted longer.

[Room 34]

How about this?

[davidbrit2]

Hey Nukey, good call with the ball objects as prizes. I was thinking of maybe making them used as fireballs, and leaving the springs as player objects, but I decided against fireballs altogether. It seems like they would be very difficult to avoid if they moved like the ones in the second board. In other words, they would need to be a bit slower, and have the capability to climb ladders. I figure it would be easy to have the springs move like the barrels, and just "slide" along the top floor, and drop straight down at a random location. It's not arcade perfect, but it would work, I suppose. I'm sure that would be a hell of a lot easier than hacking in bouncing routines.

 

The elevators seem like the tough part to me. I'm not sure how much the game engine would have to be reworked to support missile objects that Mario can stand on, and actually move with. Those might have to go, or be done in a slightly "Game & Watch" style.

 

I'm really curious to see if this will motivate any expert ROM hackers to give this all a shot. Hint hint... :-)

[Nukey Shay]

Nah...the player used for the two elevators should be possible (possibly by setting missiles to quad width?). Maybe even use the player used for the Mario character (since no objects ever touch them)...since you already "know" Mario's vertical position, you would know where safe points on the elevator are. The other player object can be divided up into as many fireballs as you want vertically.

[Nukey Shay]

...the only disadvantage to using the same player for elevators/Mario is that the elevator platforms would either flicker or disappear whenever they cross the same scanlines that the Mario character is on. It could work though, I think. (techs?)

[+Cafeman]

Too bad the fireballs can't climb ladders in the 2600 version -- your fake DK elevators screen is unbeatable!

[PeeknPoke]

http://peeknpoke.emuunlim.com/spaceharrier.jpg

Posted before,but Space Harrier anyone?

(cut and paste as my site wont allow pic-linking!)

 

 

 

Lee

 

(reedited due to picture missing)

[Inky]

I didn't know space harrier looked like a red x...

 

[RMila75]

Hey, I love Space Harrier. You've got me wishing for a 2600 version again!

Certainly it could be made to look better than that, though.

[Nukey Shay]

Cut and paste, dudes...cut and paste.

 

http://peeknpoke.emuunlim.com/spaceharrier.jpg

[Robert M]

Nah...the player used for the two elevators should be possible (possibly by setting missiles to quad width?).  Maybe even use the player used for the Mario character (since no objects ever touch them)...since you already "know" Mario's vertical position, you would know where safe points on the elevator are.  The other player object can be divided up into as many fireballs as you want vertically.

 

 

The elevators would be best implemented using playfield graphics. The kernal would need to logically 'OR' the platform image into the scan lines of the playfield where it should appear. Then some code would be needed to mathematically check if the player is on the elevator, but that wouldn't be too tough.

 

You could use the missles and ball as fireballs if you are willing to sacrifice on their appearance a bit.

[Nukey Shay]

Your are right! I keep forgetting that the screen pixels are as thin as the scanline.

But 1 player could be used for the fireballs only (like in level2). And I figure that the ball could be used in place of "springs".

I believe that the flicker factor is the only reason that the fireballs do not climb ladders...by careful positioning of them, that could be overcome in level3 (perhaps confining the rightmost fireball to the top two sections and the center fireball to that area). Two fireballs+two springs(one bouncing, 1 falling) should be sufficient

[Godzilla]

that space harrier pic is hilarious.

 

and wouldn't montezumas revenge make an excellent hack candidate for making a 2600 dk/dk jr with all the boards?

[ZylonBane]

The elevators would be best implemented using playfield graphics.

Only if you have most of the 2600's RAM to spare.

[Nukey Shay]

I dunno...it seems like you would only need a pointer for each of the platforms (so the processor "knows" which scanline to draw the pixels on). Then update each of them for the next frame (adc/sbc). Correct?

[Robert M]

The elevators would be best implemented using playfield graphics.

Only if you have most of the 2600's RAM to spare.

 

I disaggree. You don't want to store the whole playfield in RAM. You just need to know which scanlines need elevators. For those lines you logically 'OR' the the elevator image with the playfield image stored in ROM, then write it to the playfield registers. That would take 13 bytes of RAM at the most with the line buffer (6 bytes) and the line counter(s) elevator position registers (7 bytes max for 6 elevatores and the counter with the current scanline.)

 

If the elevators images don't cross the screen boundaries between playfield bytes, a single byte line buffer would work in place of 6. Plus if you space the elevators 16, 32, or 64 lines apart you could use some tricks binary math to reduce the number of bytes needed per column of elevators to 1.

 

If (elevator position + scanline ) && (16|32|64) == 0, then draw elevator.

 

So it could be done as pictured with as few as 2 bytes RAM assuming the elevator columns are moving in sync. If the elevators are out of sync it would take more like 3 or 4 bytes of RAM, but it seems doable to me.

[davidbrit2]

Hmm, interesting stuff. You know, if the missile objects are unused, they could make good springs. It would be possible to have them expand and contract vertically for a reasonable bouncing effect.

 

Perhaps we should consider implementing the conveyor belt scene. That would probably be much easier. The conveyors would just need a simple player height check, and a fireball could be placed on the center set of platforms. The pies/cement would be on different rows exclusively, so it could all be player graphics. I'll probably mock up another screenshot tonight, since I'm neurotic like that. :-)

[Nukey Shay]

You mean that I got it right??

 

Anyway, the only reason that the fireballs do not use ladders (that I can see) is an attempt to keep them from being on the same level as another one. By a bit more use of AI, you could probably avoid them meeting each other...probably make a much better level2, as well.

[ZylonBane]

So it could be done as pictured with as few as 2 bytes RAM assuming the elevator columns are moving in sync.  If the elevators are out of sync it would take more like 3 or 4 bytes of RAM, but it seems doable to me.

Sounds like this would consume far more CPU cycles than are available in a single-line, non-mirrored playfield kernel.

[Nukey Shay]

Nonsense, there was a discussion about how a 2600-Robotron homebrew might be possible (though limited) by using playfield gfx for "Grunts"...so I would think that keeping track of just a few platforms would be easier than doing that.

[Godzilla]

i still think u should just mod montezumas revenge or miner 2049er or something