Jump to content
IGNORED

Atari 2600 Boulder Dash (R) Announced!


Albert

Recommended Posts

Finally is here on my hands!

 

I received the box at the office, so only opened it and take a photo.

 

In my deparment do the full 'unboxing'. Nice surprise with the extras. Great quality in all the elements. Tomorrow i will play the game on my 2600, because i have all my Atari stuff stored in boxes.

Link to comment
Share on other sites

I wonder is anyone "addicted" yet.

 

Here's a review/unboxing I just spotted... Spanish, but the link translates...

 

http://translate.goo...ved=0CGcQ7gEwAA

 

For those who really wanted to see it, looks like the reviewer has photographed every page of the manual.

 

 

AND...

 

there's another review in the store!

 

http://atariage.com/store/index.php?l=product_detail&p=999

 

 

Cheers

A

  • Like 1
Link to comment
Share on other sites

I got the game, and It's awesome!! It's not only the game, the tune intro, the packaging, everything. Very good work to all involved.

 

At least I don't have any issue with customs, It seems EU don't want abuses from importing (and where goes the neo-liberal commerce now?)

 

But well, asides the game, two things I liked are:

 

- The support from First Star, I think this is the correct way instead other policies like sues

 

- Manual: I like the idea to include how the game was designed and It's evolution. The bubbles with notes from the designer are also a fresh touch.

But when they said they used a new bank-switching scheme, what amount of RAM and ROM uses the game finally?

 

Again, congrats for finish this great journey.

Link to comment
Share on other sites

Ummm. 1K ROM and 10 bytes of RAM.

Thomas is just that awesome ;)

And then Andrew came and used up all the space. :)

 

Seriously, I don't think we ever exactly counted the space. The game is a 32K ROM, but in each RAM and ROM bank (except one) there is often quite some space left.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

Part of the 2600s charm is its simplicity. It was literally only supposed to play pong. One is forced to focus on gameplay and as a side-effect replayability and novelty. On the other hand Atari 2600 has also always represented the infinite capability of programmers minds. It was STILL competing with the 7800, Sega Master System and NES when I grew up. Games like Double Dragon, Ikari Warriors and Commando proved we could strech its reach further.

 

Tile based graphics have been tried before and ALMOST made it. I remember the Homestar Runner demo and other partial examples. Boulderdash is what makes tile based engines real. I hope somehow this becomes a template for other tile based 2600 games. Perhaps someone could write up a tutorial and basic template for those assembly coders. You guys could be the first to enable a new generation of tile based homebrew. That might even be bigger than Boulderdash II :)

Edited by theloon
Link to comment
Share on other sites

You guys could be the first to enable a new generation of tile based homebrew. :)

 

On the other hand, Boulder Dash may end up being the ONLY tile-based game released on the platform.... ever.

 

Is the source too tied into the specifics of Boulderdash? Or, are you saying there's not enough assembly coders out there to carry the torch? Being the first and only sounds like a pretty lonely place.

Edited by theloon
Link to comment
Share on other sites

Is the source too tied into the specifics of Boulderdash?

Currently the code is pretty tied to BD specific stuff. So first we would have to remove all that and then generalize and document the code, so that it could be understood and reused easily.

 

No idea if Andrew or I will ever have the patience to do that.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

Andrew Davie was already kind enough to author a tutorial on the task scheduling. I'm just not sure about the graphic techniques used. It seems reminiscent of "chronocolor" demonstrations in the past. If one wanted to reproduce the tile engine is that a good place to start (by looking at other chonocolor examples)?

Edited by theloon
Link to comment
Share on other sites

Andrew Davie was already kind enough to author a tutorial on the task scheduling.

I am currently helping with Star Castle and there I am using a task scheduling which IMO is even a bit more effective (no central task scheduling routine but direct task jumps based on macros). The source code for that is freely available at http://subversion.assembla.com/svn/starcastle.

 

I'm just not sure about the graphic techniques used. It seems reminiscent of "chronocolor" demonstrations in the past. If one wanted to reproduce the tile engine is that a good place to start (by looking at other chonocolor examples)?

It is a slightly different approach, because only the human eye mixes the color here (no flicker).

 

For each cave we have a set of three colors (+ black) which can be used alone (for darker colors) or mixed (for brighter colors). Each color gets his own line. So for a tile which is e.g. 21 pixel high, we have each color 7 times, always at the same line.

Link to comment
Share on other sites

Is the source too tied into the specifics of Boulderdash?

Currently the code is pretty tied to BD specific stuff. So first we would have to remove all that and then generalize and document the code, so that it could be understood and reused easily.

 

No idea if Andrew or I will ever have the patience to do that.

 

 

I don't exactly agree with Thomas's statement. I think what he is really trying to say is that it is the bankswitching scheme (3E) that restricts use of the engine as it is ow. This restricts the number of tiles, and where they must live i the banks. That has further consequences for the rest of the code. I disagree totally with Thomas's opinion that the code for the tile engine is "pretty tied to BD speciic stuff". IMHO it's already a very generic engine and I don't see any problem at all with re-using it for other games. However, it is a very very complex system in terms of what the code is actually doing, and how it's doing it. The real limitation at the moment is that there's only room in the banks for (say) a dozen different tiles. A new bankswitch scheme would probably be required to make the engine truly generic and usable for other games.

 

As to explaining it, I already have a document which gives the basic concept. I'd be quite happy to build up details and answer questions so that others could implement their own, or alternatively some day -- one day -- I hope to revisit the code, remove all the Boulder Dash specific stuff, and then release it for everyone to play with.

 

Cheers

A

  • Like 2
Link to comment
Share on other sites

I don't exactly agree with Thomas's statement. I think what he is really trying to say is that it is the bankswitching scheme (3E) that restricts use of the engine as it is ow. This restricts the number of tiles, and where they must live i the banks. That has further consequences for the rest of the code.

Yea, first we should move to a more flexible bankswitching. That would make using the engine much easier.

 

I disagree totally with Thomas's opinion that the code for the tile engine is "pretty tied to BD speciic stuff".

Absolutely true, I confused that with the tile logic, which of course is very BD specific. The tile "rendering" is mostly generic, except maybe a few BD specific optimizations, which could be removed quite easily.

Link to comment
Share on other sites

Not just the human eye, I think. The old CRT televisions ALSO do actual mixing of colours, too.

I have to check on my CRT, but since the Atari creates double height scan lines anyway, I think the TV color mixing effect is rather small. Also the color mixing works on an emulator with a sharp LCD display pretty well too.

Link to comment
Share on other sites

Looks very doable at first glance.

 

BTW: Even though Andrew and I are very proud of our work, that doesn't mean it is perfect (I still have some ideas here and Andrew probably too) or can't be done by anyone else.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

Looks very doable at first glance.

 

BTW: Even though Andrew and I are very proud of our work, that doesn't mean it is perfect (I still have some ideas here and Andrew probably too) or can't be done by anyone else.

 

Do-able, but tiles are only 4 pixels wide, so if those square blocks were next to each other, they would be indistinguishable. Unless you had right and bottom edges as a border colour. That might look OK, but the borders would be very thick.

I don't see any real issues with this, really, other than it would be lower resolution and perhaps less colourful.

 

Thomas and I are very happy to share the code and techniques. We just can't share anything specific to Boulder Dash, per our agreement with FSS. The tiling engine was specifically reserved as our property so that's available to share. I think the "magical" things about our tile engine are the internal architecture that makes it all possible, and the tri-colour tiling display idea which gives a full-screen colour tile capability with no flicker. When we eventually get around to explaining how it all works, I expect the reaction might be a) wow, that's incredibly complex and b) well, of course, that's the obvious way to do it. The other magical thing is that we actually did it :)

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