Jump to content

Recommended Posts

I noticed in the video it looks like you hesitate before you make any moves with the boulders. Is this intentional while you were making the video, or does the game itself hesitate to make the calculations before you can move?

You mean the delay when Rockford pushes a boulder? That's just not implemented 100% correctly. Should be easy to fix

 

I guess my question is can you move around as fast as you want?

Short anwers: Yes.

 

Long answer: Due to the complexity of the game notBD is probably the first Atari 2600 game, which might lag under certain circumstances. Andrew managed to avoid (obvious) lagging by using several tricks. Some of them are relying on a scrolling speed limit. Therefore the movement speed (which triggers the scrolling) is limited, but only similar to the original.

I've done some more work on this and posted the result on YouTube, also with a much better image. This version shows the "grab" of diamonds in action, though it doesn't show boulder pushing (which works -- you can push a boulder without moving to the boulder's position). This version is still showing some timing glitches, but not too bad.

In answer to the question about the amoeba and turning into diamonds -- no, that is not yet implemented. It's a difficult problem given the architecture of the system, but I will solve it.

 

It was my last day at my job today -- I am moving to a new company next year. I haven't felt able or inclined to program much of anything for the past year, but now I've left... and had a look at this program, I'm feeling a bit of interest returning. I'll try and push this closer to completion.

I like how the screen flashes green now when you get all required diamonds.

I sort of miss the diamond animations though-- I thought those made the game have more of a "this game is alive" sort of feel.

We'll see what happens; will be anxious to see your progress on this. I think it's really cool what you are able to do.

 

-John

In answer to the question about the amoeba and turning into diamonds -- no, that is not yet implemented. It's a difficult problem given the architecture of the system, but I will solve it.

 

http://www.taswegian.com/TwoHeaded/Atari2600/amoeba2.avi

 

This video shows this now working. In this test I let the amoeba grow for a bit, then press my secret programmer key to turn the amoeba into diamonds... and voila. This is on the level with about 20 butterflies and to be honest the system really can't cope with so many butterflies, and an amoeba... it dogs down somewhat... this speed issue can be seen in the following (11MB)

 

http://www.taswegian.com/TwoHeaded/Atari2600/amoeba3.avi

 

And forget diamond animation -- when there's a whole screen of them it kills the scrolling speed. I may switch diamond animation on and off based on the level. The various frame glitches will eventually be fixed. This is just a quick and dirty proof of concept.

 

Cheers

A

You guys seem to have strange problems.

 

First you create a jevel, and then you say it won't be released because of blah blah blah...

 

Is it a BIG problem to release just a .bin file of it as freeware? I think that FSS won't be very angry... ;)

 

btw. Merry X-Mas(s) everyone!:D

Edited by ThomSW
You guys seem to have strange problems.

 

First you create a jevel, and then you say it won't be released because of blah blah blah...

 

Is it a BIG problem to release just a .bin file of it as freeware? I think that FSS won't be very angry... ;)

Not sure about this. IIRC FOX threatened to sue someone just for creating Futurama hack.

 

And this would finally destroy all chances of a cart release. And being a homebrewer myself, I can say, that there is a huge difference between creating a virtual binary and having finally having the thing on cart, with a nice label and manual.

 

So Andrew will probably try and try and try to get a fair deal with FSS. And use the time to further improve his game.

 

Following feedback from Thomas, this version has increased the screen size to an extra row, and removed the bottom scoring line. The system can cope with this extra work -- just. The video above shows a fairly complex screen scrolling reasonably well at good speed. I'm quite happy with this but of course more speed is always needed.

 

One day I hope to release this with FSS's blessing, but for now I'm happy to play with it and make it as perfect as I can. I will not even consider releasing a non-approved version. It's been a long while since I discussed BD with FSS, so any bottlenecks on this are all with me, not them.

 

Cheers

A

 

Recent effort has concentrated on optimising the draw system. Consequently, the scrolling appears much less prone to shear and character draw lag. This video shows level 1 played on difficulty 5 (this is pretty much the fastest the game gets).

Cheers

A

Atarium I

 

1 And on the 8th day... the Lord Sayeth...

 

2 Let the cool be born and roam the earth.

And so it was, & Andrew was born before the Lord sayeth, Earth.

 

3 The Lord looketh down at Andrew and sayeth to him pleased.

"Son... you are one cool cat!" and smiled.

 

4 The earth cracked open & next to Andrew to Lord placed an Atari 2600.

 

5 Andrew looketh at the Atari next to him & asked. Goo Goo Gah Gah?

 

6 The Lord replied... "Boulder Dash"

Recent effort has concentrated on optimising the draw system. Consequently, the scrolling appears much less prone to shear and character draw lag. This video shows level 1 played on difficulty 5 (this is pretty much the fastest the game gets).

 

With 4A50, you might be able to greatly accelerate the drawing by pre-calculating the shapes of all object pairs. Probably not quite fast enough to allow the graphics to be calculated in real time while the beam is drawing them, but very fast nonetheless.

Crap! That's really fast.

 

I think I may have noticed something in an earlier video, so I'll ask about it here.

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.

 

So, 2 questions:

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.

2) In the first video, what is the screen with the hero character running to the right into a wall before each level?

 

-John

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