Boulder Dash® on YouTube

[Thomas Jentzsch]

When the main character stands idle, does he "blink"? It looks like he does, and I think that's a cool little touch of detail.

Yup. And he also taps with one foot.

 

1) Are there limits to the "bad guys" graphically? I was wondering if you're using placeholders, or if the engine has a limit to how detailed the "enemy" sprites can be. Note that as they stand, they work just fine.

Everything except our little hero is drawn using playfield graphics. The resolution is 4 pixel x 21 lines (or 4 x 7 pixel). The 21 lines consist out of 7 pixel, each row displaying the 3 level colors, which are mixed for each "pixel" to give the desired color.

 

Regarding the bad guys, Andrew and I are still discussing how they should look like.

[+Andrew Davie]

The Atari 2600 Boulder Dash ® engine implements a fairly complex time-sharing system to allow all the various components necessary for the game to operate in the limited time available on a '2600 system. Getting the available time "right" for a lot of the objects is a bit tricky, and overflows in time usage are generally the cause of glitch and flicker in this '2600 version. As the game gets more complex (that is, more objects on screen doing more "stuff"), the available timeslices are still shared between more objects, and so it takes longer to do things. The game lags. I've been trying to balance the allocation of time against the lag, against the flicker and glitching. Right now I'm at a particularly stable version -- and one that even allows 8 lines of characters on the screen (instead of the normal 7). An extra line of characters is a killer for performance as it reduces the timeslice time availabe for object processing. Nonetheless, it's quite possible that 8 lines will make it to the final version.

 

I've placed another video on YouTube which demonstrates this "less glitchy" version, and also demonstrates a magic wall in operation (drop boulders through it, they turn to diamonds). Also shown in this video is the spiffing new explosion graphic, courtesy of Thomas, who has been of great assistance.

 

[r_type2600]

Since this is my first comment here: awesome looking conversion, hope this will make it to cart!

 

Not a big issue, but about the only thing that looks off in the graphics is the diamonds' shape.

Obviously that's due to the 4-pixels horizontal limitation, so I was wondering whether a different approach might work here?

Since the 4 pixels don't seem to allow for a convincing recreation of the original's diamonds, why not try to trick the observer to perceive them as such:

The idea would be to expand the diamonds to 5 pixels, and then animate them back and forth one pixel horizontally (instead or in addition to the current vertical animation).

Not sure, but I think that if done at a decent speed, this animation could convincingly recreate the original diamond's shape in the player's perception.

A 6-line diamond could then look similar to this:

 

- - o - -

- o - o -

o - - - o

o - - - o

- o - o -

- - o - -

 

That may then perhaps also allow to fill the inner parts in a different color, making the diamonds further distinct from the rocks.

Just thinking loud; don't know whether this would make sense (and be doable) in reality...

Edited January 1, 2008 by r_type2600

[Thomas Jentzsch]

Not a big issue, but about the only thing that looks off in the graphics is the diamonds' shape.

Actually the diamonds graphics have been a major problem for us.

 

The idea would be to expand the diamonds to 5 pixels, and then animate them back and forth one pixel horizontally (instead or in addition to the current vertical animation).

The problem is, that we are absolutely limited to 4 pixels horizontally. So no chance for 5 pixels.

 

But I am always open for good suggestions. Within the limitations.

[r_type2600]

The idea would be to expand the diamonds to 5 pixels, and then animate them back and forth one pixel horizontally (instead or in addition to the current vertical animation).

The problem is, that we are absolutely limited to 4 pixels horizontally. So no chance for 5 pixels.

 

But I am always open for good suggestions. Within the limitations.

 

Hm, maybe I expressed myself overcomplicated - what I meant is that any given time the visible diamond would be 4 pixels wide, but since it would animate back and forth horizontally, the first and fifth pixel would both be visible half-time.

That might work to burn the picture of the full 5-pixel wide diamond into the player's mind...

[Thomas Jentzsch]

Hm, maybe I expressed myself overcomplicated - what I meant is that any given time the visible diamond would be 4 pixels wide, but since it would animate back and forth horizontally, the first and fifth pixel would both be visible half-time.

That might work to burn the picture of the full 5-pixel wide diamond into the player's mind...

Ah, got you now.

 

Unfortunately that won't work too. I didn't mention it, but not only are the objects limited to 4 pixel, but those 4 pixel are also at a fixed position.

 

Also, by moving the diamond horizontally, it would interfere with the adjacent objects.

[+Andrew Davie]

 

Prototype title screen graphic. It's actually extremely tricky getting the moving pattern in the background like in the original. Not sure if this is the way I'll do it... but thought I'd show the prototype.

 

Also, a "stress test" video is available at

which shows the system performing under extremely heavy load.

 

Cheers

A

[Rom Hunter]

Also, a "stress test" video is available at

which shows the system performing under extremely heavy load.

Very impressive indeed!

 

[+Propane13]

That's pretty sweet! I thought it was extremely fast, considering the calculations that must be going through the system.

 

On the control front-- I assume that tapping the button causes a boulder push, but holding it down for X amount of time kills off the character? If so, how big is X?

 

-John

[+Andrew Davie]

Player coming to life.

[Godzilla]

i can't wait for this game to come to life

[+Andrew Davie]

i can't wait for this game to come to life

 

Mmmh, never say "never ever", eh?

[lapetino]

i can't wait for this game to come to life

 

Mmmh, never say "never ever", eh?

 

Is that a hint?

[mos6507]

Nothing new to say here but wanted to agree with the others that it is an impressive game engine.

[+Andrew Davie]

On the control front-- I assume that tapping the button causes a boulder push, but holding it down for X amount of time kills off the character? If so, how big is X?

 

-John

 

No. Holding button + direction "grabs" the object in that direction (or clears dirt). Pushing in the direction of a boulder tries to push the boulder. Hitting the select button suicides.

 

Cheesr

A

[Rom Hunter]

Andrew,

 

Why can't you be hired by First Star and let them supervise the release of (say) 100 BD carts?

 

[+Andrew Davie]

Andrew,

 

Why can't you be hired by First Star and let them supervise the release of (say) 100 BD carts?

 

 

Oh, I'm way too expensive by far, I'm sure

[+Andrew Davie]

I've had a bit of a brainflash and been able to organise things so that the engine is running "even faster still ". It's hard to quantify, but the most "busy" levels (eg: level 9 with the cascading falling diamonds/boulders or level 13 with the 20 or so butterflies and the amoeba) are now becoming almost-playable.

 

 

I thought I'd throw this video up, because it shows the faster screen updating AND Thomas's experimental amoeba graphics operating together. The whole screen at the end is full of animating amoeba, yet you don't really see each individual amoeba character being 'drawn'. This also shows nicely the multiple playfield colours in action -- green amoeba with brown dirt/boulders, and no flicker.

[Rom Hunter]

I've had a bit of a brainflash and been able to organise things so that the engine is running "even faster still ". It's hard to quantify, but the most "busy" levels (eg: level 9 with the cascading falling diamonds/boulders or level 13 with the 20 or so butterflies and the amoeba) are now becoming almost-playable.

 

 

I thought I'd throw this video up, because it shows the faster screen updating AND Thomas's experimental amoeba graphics operating together. The whole screen at the end is full of animating amoeba, yet you don't really see each individual amoeba character being 'drawn'. This also shows nicely the multiple playfield colours in action -- green amoeba with brown dirt/boulders, and no flicker.

Incredible.

 

It's almost like watching the C64 version.

 

Well done, Andrew.

 

[Thomas Jentzsch]

It's almost like watching the C64 version.

Thanks. We tried our best to make the colors and graphics match the C64 version as close as possible.

 

The 8 Bit version has some levels with different colors, not sure which one we should go for. Personally I prefer C64, since that's the one I know from the past. Others may think different.

[panamajoe]

this HAS to be released!

[Godzilla]

just amazing what you are pulling off with ol stella. AWESOME.

[Inky]

Wow! This is looking very impressive!

 

I cant wait to play it!

[lapetino]

I never played this game either, but it looks great! Can't wait to see it actually get released.

 

Also Andrew, I posted this in another thread but it didn't get answered:

 

I read on the FSS site that they had released a limited edition 5200 edition of Boulder Dash. If someone got permission to use the rights for that, why has it been difficult to do so for a 2600 version? I feel like I'm missing part of the story...

[Kroko]

I feel like I'm missing part of the story...

This part ?

 

It's been a long while since I discussed BD with FSS, so any bottlenecks on this are all with me, not them.