Jump to content
IGNORED

Boulder Dash® on YouTube


Recommended Posts

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. :)

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by r_type2600
Link to comment
Share on other sites

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. ;)

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

8)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

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...