261 replies to this topic

[Andrew Davie]

I am planning to post future updates on my Atari 2600 BoulderDash effort in this forum. For those not in the know, Boulder Dash ® is a game released by First Star Software on just about every platform known to mankind -- except the '2600.

Let's get the formalities out of the way. First Star Software owns the copyright to the game, so we can't go around developing our own versions and releasing them to the masses. So the way I've gone about this is to develop an engine capable of BoulderDash functionality (in general, it's a general engine capable of many games) while at the same time using BoulderDash as a basis for the development of various programming techniques in the engine.

While following this process I had occasional correspondence with First Star Software about the possibility of bringing a '2600 version to the masses. In general, our discussions have been encouraging and I am delighted to have received official permission to debut on hardware my current engine running '2600 BoulderDash ® at the Oklahoma show on June 18th.

Whilst I am unable to release binary versions of the game due to the copyright issues and the code pertaining to the BoulderDash mechanics must remain private, too... I do have official permission to regularly release MPGs showing the capability of my engine as it runs BoulderDash scenarios.

In short, I *am* writing BoulderDash for the '2600. First Star Software are aware of this, and have given me their blessing to continue doing so. We both hope that this will turn into a polished '2600 game that can see a release on the market for the '2600 fans. So yes, there is a possibility this may see the light of day after all. Please note, I am not saying that FSS are doing BoulderDash. I am doing it. They have been kind enough to allow me to continue along the current path, using their copyrighted property for my own private use to demo the capabilities of my engine. I think it's fair to say that we both (FSS and I) hope that this can turn into a great '2600 achievement that can bring fame and glory to all. But that's entirely up to me, so any failings are totally mine.

Now, I've previously posted MPGs of the engine as it has progressed from day to day in the other forums. I will continue regularly posting MPGs and maybe even a bit of a development blog in this forum. But for now, here's the most recent MPG (previously posted in the other forum)...

butterfly, firefly, slime, water, boulders, diamonds and two magic walls, all at the same time... with little slowdown. -- 2.2MB.


Currently I am rewriting the systems that control how the boulders and diamonds fall. Due to the complex architecture of the engine, getting the timing right has been difficult, and I'm getting duplicaed boulders and diamonds during the falling stage. I have written the code to fix this -- it just don't work, yet

I think I'll probably get the magic walls working next, so that you can drop boulders and diamonds through them and they change one to the other. That should be fun. After that, I will work on the slime/amoeba and see how to get it detecting when to change to diamonds (when it can't grow, of course... but it's not all that easy).

An overview of the system itself:

The addition of RAM has made a complex display engine possible. Nonetheless, additional RAM does not give you (much) additional processing time for the whole screen. My system doesn't actually draw that much during any frame -- it just looks like it does. But what it does do is efficiently use what time IS avaialble. It does this by using a sort of multitasking timeslice system, where any part of the game is guaranteed (well, supposed ... its not perfect) to use a maximum of a certain amount of time. By detecting if there's enough time left to do another timeslice, the game actually manages to get a hell of a lot done in any one frame, and due to the generic design of the architecture, I don't really care or know what any one timeslice is doing. That is, I don't say "draw the wall", "draw the slime", etc... I just put the wall in memory, and it automatically gets drawn by the timeslice system as a result of the system detecting a change in the data in the area of the board the screen is displaying. I should write this up in more detail sometime, if anyone is really interested.

The bottom line, though, is that I can have VERY complex interactions going on in the game at the same time (say, 10 butterflies, 20 boulders and 20 diamonds falling, with an amoeba expanding, and two magic walls... at the same time as the two players are each independantly scrolling their split-screen windows at a fair clip). Fast enough, anyway, that it seems real-time to the user with little sluggishness or slowdown.

If all goes well, as I said, you can come to the OK show and see it for yourself.

The most recent thing I implemented was a NTSC/PAL switch (right difficulty) so that there is only one cartridge type and it will play on pretty much any Atari in use today.

I will post another MPG as soon as I fix the boulder/diamond falling issues. Shouldn't be too long!

Cheers
A

[Thomas Jentzsch]

Andrew Davie, on Wed May 4, 2005 11:41 AM, said:

I am delighted to have received official permission to debut on hardware my current engine running '2600 BoulderDash ® at the Oklahoma show on June 18th.

Cool.

And due to its complexity, maybe Boulderdash will become the very first 2600 game with (noticable?) slowdowns.

[Andrew Davie]

Thomas Jentzsch, on Wed May 4, 2005 9:59 PM, said:

And due to its complexity, maybe Boulderdash will become the very first 2600 game with (noticable?) slowdowns.

Here's a sample of almost correct boulder/diamond physics showing a fair bit of action on the screen. If there's much slowdown there, it really isn't too noticeable -- and I don't expect that the system is really being pushed anywhere near its limits in this demo.

Any slowdowns in the final game will be pretty much tied to large amounts of visible action, and hopefully you'll be too preoccupied trying to stay alive to really notice slowdown.

Cheers
A

[cd-w]

I will just add my voice to the crowd, and say that this looks awesome, and I hope a full release will be
possible at some point in the future.

Chris

[Thomas Jentzsch]

Andrew Davie, on Wed May 4, 2005 4:03 PM, said:

Any slowdowns in the final game will be pretty much tied to large amounts of visible action, and hopefully you'll be too preoccupied trying to stay alive to really notice slowdown. 

Most likely.

What exactly is using most of the time? Any chances for optimization?

[Nathan Strum]

That's very cool Andrew. It's encouraging that First Star is letting you proceed with this, and share the progress with us. Hopefully they'll be supportive of an actual release should that time come.

Question: with all the graphic goodness going on with your engine, will it be able to handle sounds?

[Rob Mitchell]

Nathan Strum, on Wed May 4, 2005 10:24 PM, said:

Question: with all the graphic goodness going on with your engine, will it be able to handle sounds?

And AtariVox?? Look forward to playing it on my FB2!

Rob Mitchell, Atlanta, GA

[Andrew Davie]

Nathan Strum, on Thu May 5, 2005 3:24 AM, said:

Question: with all the graphic goodness going on with your engine, will it be able to handle sounds?

Yes. I've reserved ample RAM, ROM and processing time for sound. The version at the show *may* have sound installed; we shall all just have to wait and listen!

[Andrew Davie]

Thomas Jentzsch, on Thu May 5, 2005 1:36 AM, said:

What exactly is using most of the time? Any chances for optimization?

The sheer number of objects that have to be processed and drawn. I have a 'board' which is just a massive mxn playfield on which the action occurs. When anything moves or animates, it just changes the board.

Secondly I have a screen bitmap divided into rows, each 10 'characters' wide. A character is 4 pixels, and the rows are in the same format as PF registers. So, 6 bytes per line. Each character is 18 scanlines deep.

Thirdly, I have a 10x9 'screen' which represents what characters are actually already drawn into the screen bitmap. The 10x9 screen may be considered a window onto the larger board.

The screen update process consists of looking at the 'screen' and checking against the bytes on the board. If there is a difference, then the board character has changed, and an update is triggered for that particular character both on the 'screen' and as a consequence of that, in the screen bitmap.

So when, for example, you are scrolling around the board... your 'screen' overlays a new section of the board. The check will determine only those characters that *change* between the old position and the new position (soil is soil is soil, and we don't need to redraw it if it's already drawn). Those characters are placed on a draw stack.

Since the process for checking the screen against the board is time-consuming, it is divided into two parts -- and this is where the two player split screen becomes simple. The first pass does the lefthand 5x9 area. The second pass does the righthand 5x9 area. To get independant scrolling for left/right, I just change the position over the board that the screen is positioned at, one position for left (the 1st player's coordinates) and one position for right (the 2nd player's coordinates).

In the case of just one player, for the 2nd pass, I just use the player's position + 5.

The next step of the process is to actually *draw* the characters from the draw stack into the screen bitmap. Since the screen is 10x9 that gives us 90 characters to draw if the screen TOTALLY changes between frames. A single character draw involves removing the character # and position from the draw stack, and then copying the appropriate shape data from the character 'set' into the screen bitmap. This is fairly slow because there is a lot of masking going on to get into the 4-pixel wide PF format, with all the oddities that involves. I can do, say, 5 or so of these per frame. For a full screen update, then, say very rougly half a second.

But you almost never need a full-screen update. And when there are 10 boulders falling, you only really need a few frames for the management (as described above), and two or so for the drawing of the new shapes (if they are all onscreen) and any changes caused by scrolling (which is infrequent anyway). Since the player only really needs to move a few times per second, this is how it all fits into the available time.

So, the most appropriate answer to your question "what takes most of the time" is "most of it". The trick to extra speed is to improve the speed at which character bitmaps can be copied from the character set to the screen bitmap.

One other thing -- there is an INTIM 'throttle'. The timeslicing code is called just before we wait for INTIM to run out (in several places on the screen). It basically says "is INTIM > x", where x is the timeslice maximum requirement. If it is, then the system iterates another round of processing -- typically that would enable another character to be drawn, but the system might be in the screen/board comparison phase, or in one of the other phases. The trick is to get each and every phase so quick that the timeslice amount (x) can be reduced to as small as possible and allow as many timeslices to run while the system is INTIM idle-waiting.

So, that's how it all works!

[Thomas Jentzsch]

Thanks for the info!

Andrew Davie, on Thu May 5, 2005 3:20 AM, said:

So when, for example, you are scrolling around the board... your 'screen' overlays a new section of the board.  The check will determine only those characters that *change* between the old position and the new position (soil is soil is soil, and we don't need to redraw it if it's already drawn).  Those characters are placed on a draw stack.

So, when scrolling a pretty random screen, do you have to redraw (nearly) ALL characters? Or can you reuse the previous screen and just "scroll" the old data?

Quote

Since the process for checking the screen against the board is time-consuming, it is divided into two parts -- and this is where the two player split screen becomes simple.  The first pass does the lefthand 5x9 area.  The second pass does the righthand 5x9 area.

Does that mean, a slowdown might result into a temporary "split "screen? I am mostly wondering about vertical scrolling here.

Quote

The next step of the process is to actually *draw* the characters from the draw stack into the screen bitmap.  Since the screen is 10x9 that gives us 90 characters to draw if the screen TOTALLY changes between frames.

s. above (random screen scrolling)

Quote

A single character draw involves removing the character # and position from the draw stack, and then copying the appropriate shape data from the character 'set' into the screen bitmap.  This is fairly slow because there is a lot of masking going on to get into the 4-pixel wide PF format, with all the oddities that involves.

I understand

Quote

I can do, say, 5 or so of these per frame.  For a full screen update, then, say very rougly half a second.

Ouch, I suppose any double-buffering is completely out of question (RAM)?

Quote

But you almost never need a full-screen update.  And when there are 10 boulders falling, you only really need a few frames for the management (as described above), and two or so for the drawing of the new shapes (if they are all onscreen) and any changes caused by scrolling (which is infrequent anyway).  Since the player only really needs to move a few times per second, this is how it all fits into the available time.

I am sure you have calculated this very carefully, and I suppose you are right. Except maybe for the scrolling, which still looks critical to me. But maybe I am just missing too much informations

Quote

So, the most appropriate answer to your question "what takes most of the time" is "most of it".  

I already suspected that answer. So optimizing (both algorithms and code) must be a hell lot of work. You are on a very complex mission.

BTW: What did Five Star say about support from other coders?

Quote

The trick is to get each and every phase so quick that the timeslice amount (x) can be reduced to as small as possible and allow as many timeslices to run while the system is INTIM idle-waiting.

I have seen some games, which check INTIM and exit calculation when it goes too low, but your timeslice approach is probably new and unique for the 2600.

How many slices fit into Overscan or VBLANK?

Edited by Thomas Jentzsch, Thu May 5, 2005 2:28 AM.

[gambler172]

Hi Andrew
NOTBD looks really great
I hope that there will be a working rom file soon.

greetings Gambler172

[Andrew Davie]

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

So, when scrolling a pretty random screen, do you have to redraw (nearly) ALL characters? Or can you reuse the previous screen and just "scroll" the old data?

You redraw, not re-use. In actuality this is probably reasonably efficient. I can scroll fairly active screens with little sense of slow update. There's some, but it is not dramatically bad. But in practise, MUCH of the screen is the same, even when scrolling.

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

Does that mean, a slowdown might result into a temporary "split "screen? I am mostly wondering about vertical scrolling here.

No, because I double-buffer the screen and the draw stack. It is only after the two parts have been updated that I then proceed to actually do drawing. So there is no apparent 'split' whatsoever.

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

Quote

The next step of the process is to actually *draw* the characters from the draw stack into the screen bitmap.  Since the screen is 10x9 that gives us 90 characters to draw if the screen TOTALLY changes between frames.

s. above (random screen scrolling)

You can see it, if the screens are random and completely different. But in actual usage, they are not, and you don't really notice it. What you do notice... isn't annoying. See the sample MPG files and decide for yourself. And if it were really an issue, don't scroll -- do flip-screen instead.

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

Quote

I can do, say, 5 or so of these per frame.  For a full screen update, then, say very rougly half a second.

Ouch, I suppose any double-buffering is completely out of question (RAM)?

No, it is not out of the question as far as RAM -- my first implementation DID do double-buffering of the screen. But if you think about it, this means that (even with my 'only draw what is changed' system, you end up drawing twice as many characters -- each character has to be drawn once in its correct position in each buffer. So the system was doing twice as much character drawing for exactly the same effect.

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

Quote

So, the most appropriate answer to your question "what takes most of the time" is "most of it".  

I already suspected that answer. So optimizing (both algorithms and code) must be a hell lot of work. You are on a very complex mission.

BTW: What did Five Star say about support from other coders?

Getting itchy fingers?

It's "First Star Software", by the way, and they have been very pleasant to talk to. You must remember that I have been working on this, on and off, for a long time now. My first approach to them was before April 2003. My efforts to ensure that I don't breach their copyright, and respect their wishes has, I hope, established some degree of understanding between us -- trust, shall we say. I want to be very careful to respect that relationship -- after all, the intellectual property is theirs and they don't have to give any permission at all.

So the short answer is that I can't distribute code that is related to BoulderDash implementation. That is, I can't give the algorithms for the movement of boulders, diamonds, or the game logic, etc., etc. What I can share, of course, is my engine.

BUT, my current understanding and agreement with FSS is that no code or binaries will be released. In return, I can release MPG and use their intellectual property as a target for my engine development. So... I would not share code with you until I had sought permission from FSS and clarified exactly what the sharing was going to involve.

On the other hand, I will be quite happy to share small code portions unrelated to BoulderDash, demonstrating the engine technology -- for example, how the timeslice system works. And yeah, I'd love to have your keen coding eyes scan some of my more problematic routines.

Thomas Jentzsch, on Thu May 5, 2005 6:23 PM, said:

I have seen some games, which check INTIM and exit calculation when it goes too low, but your timeslice approach is probably new and unique for the 2600.

How many slices fit into Overscan or VBLANK?

The system is currently non-optimal. I occasionally get screen 'roll' (too many scanlines) when I trim down the limit too much (mainly because some creatures are doing a bit too much in their calculations). And I have a feeling that I can greatly improve the timeslicing -- my first implementation basically worked first time and I haven't played much with it since.

The system is slightly more complex than I indicated earlier. I do a 'general processing' -- that is, board and screen update -- during VBLANk. This is where the BIG routines like the screen compare and draw stack creation is done. And wherever else there is spare time on the screen, I try to draw characters from the draw stack. I have a couple of threshold values for these situations.

Here's a bit of code from the PAL version which has a few extra scanlines available...

                    lda #47
                    sta TIM64T

                    jsr StealCharDraw

PALTiming           lda INTIM
                    bne PALTiming

And the StealCharDraw function...

StealAnother    jsr DrawNewCharacters
StealCharDraw   lda INTIM
                cmp #AUTOCALC
                bcs StealAnother
                rts

...and the AUTOCALC value is currently 13.

The beginning of my screen (ie: VBLANK) looks like this...

         lda #2
         sta WSYNC
         sta VSYNC; Begin vertical sync.

         sta WSYNC; First line of VSYNC
         sta WSYNC; Second line of VSYNC.
         lda	#0
         sta WSYNC; Third line of VSYNC.
         sta VSYNC; (0)

            jsr TimeSlice
            jsr StealCharDraw
          
VblankLoopBD  lda INTIM
            bne VblankLoopBD

So you can see that TimeSlice is called once per frame, and it does the really timeconsuming BIG stuff. And StealCharDraw is called many times per frame -- and it uses all available time to draw characters (which is the main difficult thing to do).

Hope this all makes sense!
Cheers
A

[Andrew Davie]

gambler172, on Thu May 5, 2005 7:37 PM, said:

Hi Andrew
NOTBD looks really great :lust:
I hope that there will be a working rom file soon.
:)
greetings Gambler172

There will not be any releases of ROM files. Sorry, but that's an absolute. Hopefully one day it will come out on cartridge and the masses will buy a copy or two.
Cheers
A

[Thomas Jentzsch]

Andrew Davie, on Thu May 5, 2005 11:42 AM, said:

But in practise, MUCH of the screen is he same, even when scrolling.

In theory I am not convinced yet, but in practice your are most likely right.

Quote

See the sample MPG files and decide for yourself.

Those are looking absolutely great.

Quote

And if it were really an issue, don't scroll -- do flip-screen instead.

Please don't, I love scrolling.

Quote

No, it is not out of the question as far as RAM -- my first implementation DID do double-buffering of the screen.

How much RAM do you need NOW?

Quote

Getting itchy fingers?

Who? Me? |style_emoticons/atariage/icon_innocent.gif

Quote

It's "First Star Software", by the way...

OMG! How could I...?!?

Quote

You must remember that I have been working on this, on and off, for a long time now.  My first approach to them was before April 2003.

I do remember and I admire your stamina.

Quote

So the short answer is that I can't distribute code that is related to BoulderDash implementation.  That is, I can't give the algorithms for the movement of boulders, diamonds, or the game logic, etc., etc.  What I can share, of course, is my engine.

I am not very interested into the algorithms (which could be reverse engineered quite easily anyway), but your engine sounds very cool.

Quote

On the other hand, I will be quite happy to share small code portions unrelated to BoulderDash, demonstrating the engine technology -- for example, how the timeslice system works.  And yeah, I'd love to have your keen coding eyes scan some of my more problematic routines.

You know my address.

Quote

Here's a bit of code from the PAL version which has a few extra scanlines available...
<snip>
Hope this all makes sense!

It sure does! Thanks a lot!

[Andrew Davie]

Thomas Jentzsch, on Thu May 5, 2005 8:38 PM, said:

Quote

No, it is not out of the question as far as RAM -- my first implementation DID do double-buffering of the screen.

How much RAM do you need NOW?

How long is a piece of string? I'm currently using roughly 9K of RAM, and that includes a 32x32 board. The bankswitch format handles up to 32K RAM. Available RAM is not an issue with this game, nor available ROM. The main limits to further development are available space in the sole fixed-bank (which is incredibly tight), and available processing time (which seems adequate at the moment).

Cheers
A

[moderntimes99]

Cool! Is there any chance that there will be a PAL version also?

Regards,
Moderntimes99

[Kroko]

moderntimes99, on Fri May 6, 2005 9:13 PM, said:

Cool! Is there any chance that there will be a PAL version also?

Andrew Davie said:

The most recent thing I implemented was a NTSC/PAL switch (right difficulty) so that there is only one cartridge type and it will play on pretty much any Atari in use today.

This should answer your question

[Andrew Davie]

Thomas Jentzsch has suggested an improvement in the draw algorithm that has made a speedup possible, and every little bit counts. Here is a short MPG showing scrolling in X and Y directions under conditions of high entropy -- 3MB.
I continue to tweak the code, looking for improvements in speed mostly. I have another avenue to explore -- using self modifying code, which is a bit tricky to implement (due to bankswitching considerations) but if it works out I should gain a fair chunk of my fixed bank back, and get a 20% speed increase in the draw.
Cheers
A

[Big Player]

Amazing. I hope I can one day purchase this game.

Is there any idea what a cart with this type of bankswitching would cost?

[Andrew Davie]

Big Player, on Sat May 7, 2005 1:21 PM, said:

Amazing.  I hope I can one day purchase this game.

Is there any idea what a cart with this type of bankswitching would cost?

Not really. Armin Vogl (Kroko) has designed a board already, and I think a rough estimate of production cost would be $20 per populated board. But that's a real guess at this stage.

[gambler172]

Hi Andrew
equal how much a NOTBD cartridge will cost,i will buy one.
greetings Gambler172

[Andrew Davie]

I have been experimenting with some
diamond animation. Not sure if I'll go with this, or something similar... but it does show the engine keeping up with all I throw at it.
Cheers
A

[Thomas Jentzsch]

Andrew Davie, on Sun May 8, 2005 7:36 AM, said:

Not sure if I'll go with this, or something similar...

How about some vertical moving black stripes?

Quote

...but it does show the engine keeping up with all I throw at it

It might get interesting in those levels where almost the whole screen is filled with diamonds (or slime).

[moderntimes99]

Kroko, on Fri May 6, 2005 9:08 PM, said:

moderntimes99, on Fri May 6, 2005 9:13 PM, said:

Cool! Is there any chance that there will be a PAL version also?

Andrew Davie said:

The most recent thing I implemented was a NTSC/PAL switch (right difficulty) so that there is only one cartridge type and it will play on pretty much any Atari in use today.

This should answer your question

Great news indeed! Using the right difficulty switch for NTSC/PAL is the best solution. Just let me know if you're starting to take pre-orders! I've spent hundreds of hours in front of Boulder Dash on the C64...

Andrew Davie, on Sun May 8, 2005 6:36 AM, said:

I have been experimenting with some
diamond animation.  Not sure if I'll go with this, or something similar... but it does show the engine keeping up with all I throw at it.
Cheers
A

I think the unanimated diamonds are fine... I miss the original Rockford look though...

Regards,
Moderntimes99

[Andrew Davie]

moderntimes99, on Sun May 8, 2005 5:11 PM, said:

Just let me know if you're starting to take pre-orders! I've spent hundreds of hours in front of Boulder Dash on the C64...

Please remember, there are no current plans to release this game! It is a proof of concept, showing my engine in action, running BoulderDash® -- a copyrighted property of First Star Software. I am not at liberty to either release it, nor make promises about its availability.

Having said that, it would be nice to finish it and have it published. But let's cross that bridge when we come to it. So, no preorders, no prices, no delivery dates. If you want to see it in action, get to where I'm going to be... in the States over June/July.

Cheers
A