Jump to content
IGNORED

Boulder Dash®


Recommended Posts

I think anything you can plug into a stock 2600 that ends up being a fun game is worthwhile pursuing. If you can make the 2600 do backflips by sticking some extra RAM and ROM in a cart, you're still working with the original system, but you're just taking advantage of cheaper chips. You're not "cheating" by modifying the hardware, you're just taking fuller advantage of what it can already do. Broadening its horizon, as it were.

 

Anyway, there were other games that used extra RAM and ROM back in the day. This is taking the same concept up to the next level. Or a maybe a few levels. ;)

Link to comment
Share on other sites

I'm sure different people have different goals, but to my mind part of the fun of 2600 coding is thinking about what would have been possible in 1984.

Been there, done that. I wrote 1K, 4K and 16K games. Now, working with "lots" of RAM and bankswitching is something refreshing and a new challenge (e.g. developing several new tricks which only work with selfmodifying code and/or bankswitching). Yes, it is some kind of "cheating" by 1984 standards, but so did Activision back then and this is 2005.

 

BTW: Why 1984? Why not 1977 (2k!) or 1989? At least in 1989, I am pretty sure 16+16K wouldn't have been a marketing problem.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

I'm sure different people have different goals, but to my mind part of the fun of 2600 coding is thinking about what would have been possible in 1984.

867441[/snapback]

 

I was wondering when someone was going to bring this up. It's an interesting topic, a debate about which is worth its own thread. :)

 

@Andrew. I don't know much about Boulderdash, but I'm certainly impressed by your videos. :) Everyone seems to love BD, so I'll do my homework someday to see what the fuss is about.

Link to comment
Share on other sites

BTW: Why 1984? Why not 1977 (2k!) or 1989? At least in 1989, I am pretty sure 16+16K wouldn't have been a marketing problem.

867645[/snapback]

 

1984 is maybe a bit far back, but I was aiming pre-crash. By 1989, other systems were already starting to take over the market and the Atari was considered 'closeout' material.

 

BTW, 16K+16K would probably have been a bit much even in 1989. 32K+8K would probably have been more reasonable, though even that would have been a stretch (IIRC, an 8Kx8 RAM would have been about $3, which would turn into $12 retail--and that's just for one chip)

 

I will grant, though, that I was probably being a little too much of a killjoy though as a programmer who often programs for tiny processors (e.g. 2K instructions and 128 bytes RAM) I tend to admire 'cute' approaches. Perhaps, though, the right way to view things is that the goal on an Atari is not to pack stuff into 4K (or 16K, or 2K) of code space, but rather to pack stuff into 76 cycles. And that's a constraint that doesn't vanish no matter how much memory you throw in.

Link to comment
Share on other sites

Atari released a few 16K 2600 games in 1984.  Dig Dug, Crystal Castles and Millipede all had extra RAM too.

867935[/snapback]

 

They had 128 bytes each of RAM if I recall. In 1984, an 8Kx8 RAM chip was a rather pricey item; even 2Kx8 chips weren't free. Mask ROM was pretty cheap, but RAM wasn't yet.

Link to comment
Share on other sites

I will grant, though, that I was probably being a little too much of a killjoy though as a programmer who often programs for tiny processors (e.g. 2K instructions and 128 bytes RAM) I tend to admire 'cute' approaches.

867794[/snapback]

Write a 1k minigame :D

Link to comment
Share on other sites

I will grant, though, that I was probably being a little too much of a killjoy though as a programmer who often programs for tiny processors (e.g. 2K instructions and 128 bytes RAM) I tend to admire 'cute' approaches.

867794[/snapback]

Write a 1k minigame :D

867963[/snapback]

 

I'm planning on trying that, actually. My gorgeous title screen idea wouldn't fit in a 1K, though. Maybe I'll have to release my game as a 1K and 8K version. >:*3

Link to comment
Share on other sites

I may have come across as slightly disparaging in earlier posts, but as I view the constraint more as "76 clock cycles" rather than as finite RAM, I see that there's still a lot of challenge left.

 

One thing I was wondering about: do you show the same colors in the same scan lines every frame, or do you change them? One thing that might work well, if it doesn't expand your engine to the point that it goes kaboom, would be to use interlacing so that you could show colors displaced by 1.5 scan lines each frame. This would allow 2:1 flicker instead of 3:1 and might thus allow for improved appearance.

 

I do hope to see Boulderdash when it's finished--that was an awesome game though I still can't imagine how a 2600 could pull it off.

Link to comment
Share on other sites

I may have come across as slightly disparaging in earlier posts, but as I view the constraint more as "76 clock cycles" rather than as finite RAM, I see that there's still a lot of challenge left.

 

One thing I was wondering about: do you show the same colors in the same scan lines every frame, or do you change them?  One thing that might work well, if it doesn't expand your engine to the point that it goes kaboom, would be to use interlacing so that you could show colors displaced by 1.5 scan lines each frame.  This would allow 2:1 flicker instead of 3:1 and might thus allow for improved appearance.

 

I do hope to see Boulderdash when it's finished--that was an awesome game though I still can't imagine how a 2600 could pull it off.

868005[/snapback]

 

I have explored many display techniques. You possibly don't realise that this current version *does not flicker at all*. My previous colour display technologies like Interleaved Chronocolour and Spasticolour used various rolling-colour techniques like you suggest. Check out some of the binaries I released on stella and in the AA forums for examples.

 

And yes, I did do interlacing tests with this current engine. The effect was to *introduce* flicker, because single-depth scanlines now become 1.5 deep scanlines with the edges flickering. Since the majority of the screen is dirt, this had the effect of making the whole thing shimmer like crazy.

 

The display engine is totally chock-a-block using 76 cycles. There are no WSYNCs in the entire bitmap section. It modifies both player shapes, both player colours, the background colour, AND an asymmetrical playfield -- all the time keeping track of which scanline it is at, and bankswitching at the appropriate time. It is a marvel of retro engineering. Having said that, yes I could vary the colours if I wanted to -- but I am happy with the current method, having explored other techniques early on.

 

As to Boulderdash -- I now have 11 or so levels installed, each playable. One or two slow down quite significantly (for example, about 30 butterflies with an amoeba)...but I hope to iprove the speed enough to make even this playable. I have installed a simple selection screen, so at the show people will be able to easily select any level, and any difficulty, and play.

 

I am very pleased to announce that there will be sound in the version demoed at the show. Paul Slocum has been kind enough to allow use of his sound system and data, and hopefully he will have enough time to do some specialised sounds for me.

 

Cheers

A

Link to comment
Share on other sites

The question is, could this be conveniently put to cartridge, now that its requirements have been more or less nailed down? I mean, if the engine is to allow for exceptional capabilities such as yours does, it wouldn't be of quite as much use if there was no simple way to make real hardware out of it.

Link to comment
Share on other sites

The question is, could this be conveniently put to cartridge, now that its requirements have been more or less nailed down?  I mean, if the engine is to allow for exceptional capabilities such as yours does, it wouldn't be of quite as much use if there was no simple way to make real hardware out of it.

868152[/snapback]

 

post-214-1117948154_thumb.jpg

 

post-214-1117948180_thumb.jpg

 

Amazing, no? These from the creator of the Krokodile Cart. In short, yes this has *already* been put onto cartridge and it works just fine.

 

Cheers

A

Link to comment
Share on other sites

I have explored many display techniques.  You possibly don't realise that this current version *does not flicker at all*.  My previous colour display technologies like Interleaved Chronocolour and Spasticolour used various rolling-colour techniques like you suggest.  Check out some of the binaries I released on stella and in the AA forums for examples.

868037[/snapback]

 

I'll have to check those things out. I just wrote a cute little demo of a color technique that's a little different from what you're probably using; the color/BW switch toggles between 'stripes' mode and 'flicker' mode. For this engine, I think flicker mode is better, although given the amount of dirt in Boulderdash having non-flickering stationary colors is probably better.

JPDEM1.ZIP

Link to comment
Share on other sites

I have explored many display techniques.  You possibly don't realise that this current version *does not flicker at all*.  My previous colour display technologies like Interleaved Chronocolour and Spasticolour used various rolling-colour techniques like you suggest.  Check out some of the binaries I released on stella and in the AA forums for examples.

868037[/snapback]

 

I'll have to check those things out. I just wrote a cute little demo of a color technique that's a little different from what you're probably using; the color/BW switch toggles between 'stripes' mode and 'flicker' mode. For this engine, I think flicker mode is better, although given the amount of dirt in Boulderdash having non-flickering stationary colors is probably better.

868189[/snapback]

 

Perhaps it would be better to keep this thread to Boulder Dash, and post demos and discussions of colour display technologies to another forum. Your engine looks nice. But I would advise study of what has already been done. Attached are some small colour-display demos showing Interleaved Chronocolour in action for PAL/NTSC/SECAM, and also some experiments with interlacing. It's probably worth looking through stella and AA archives, because I have posted all my source code and methods with these.

 

If you are using z26, use the -g11 switch for the ohno!colour demo, as it uses 3F bankswitching. The others are all standard ROM images. Some generate incorrect # scanlines (as does your demo), but that's not really the issue. 'fade' demonstrates colour cycling and fading. Enjoy.

 

The Boulder Dash engine is as it is due to various timing and space constraints -- but mostly it is the only technology that I have developed so far that displays colour bitmaps with no 'shimmer' whatsoever.

 

Cheers

A

 

 

 

colourdemos.zip

Link to comment
Share on other sites

Perhaps it would be better to keep this thread to Boulder Dash, and post demos and discussions of colour display technologies to another forum.  Your engine looks nice.  But I would advise study of what has already been done.  Attached are some small colour-display demos showing Interleaved Chronocolour in action for PAL/NTSC/SECAM, and also some experiments with interlacing.

868201[/snapback]

 

Thanks for those. They're kinda cute, though my approach shimmers less (for four of the colors, shimmer is pretty minimal) >:*3. I'll leave this thread to Boulderdash, and look forward to seeing it when it's done. Yeah, I sorta discovered my scan line count was way off after I posted it; I hacked down my code to get it under 1K and sorta oopsed.

Link to comment
Share on other sites

I am very pleased to announce that there will be sound in the version demoed at the show.  Paul Slocum has been kind enough to allow use of his sound system and data, and hopefully he will have enough time to do some specialised sounds for me.

868037[/snapback]

 

Hooray!

 

Moderntimes99

Link to comment
Share on other sites

Looks like I may be able to present all 20 levels of Boulder Dash at the show! Not all of them will be running 100%, as some severely tax the current limits of the system. But it will be close, and I do expect some improvement in speed after the show, when I've had more time to optimise things (what, again?).

 

I have made 11 MPG files showing a short section of gameplay in each of the 11 levels currently installed. You can see occasional colour flashes (diagnostics indicating time overflow) and on some levels screen shake. Basically it's warts and all with no covering the faults. But overall it's reasonably good, and of course most of these problems will be removed by the time of the show. So, here are the 11 implemented levels -- both as single screenshots, and as MPGs...

 

post-214-1118058576_thumb.jpg

Level 1 MPG (9MB)

 

post-214-1118058589_thumb.jpg

Level 2 MPG (17.5MB)

 

post-214-1118058605_thumb.jpg

Level 3 MPG (17MB)

 

post-214-1118058628_thumb.jpg

Level 4 MPG (8MB)

 

post-214-1118058642_thumb.jpg

Level 5 MPG (1.5MB)

 

post-214-1118058654_thumb.jpg

Level 6 MPG (9MB)

 

post-214-1118058668_thumb.jpg

Level 7 (17MB)

 

post-214-1118058680_thumb.jpg

Level 8 MPG (9.5MB)

 

post-214-1118058694_thumb.jpg

Level 9 MPG (4.5MB)

 

post-214-1118058704_thumb.jpg

Level 10 (14.5MB)

 

post-214-1118058716_thumb.jpg

Level 11 MPG (12.5MB)

 

 

These are probably the last images/MPGs that I will post before the show, so if you really want to see more -- come along and play it yourself!

 

Cheers

A

Link to comment
Share on other sites

Looks like I may be able to present all 20 levels of Boulder Dash at the show!  Not all of them will be running 100%, as some severely tax the current limits of the system.  But it will be close, and I do expect some improvement in speed after the show, when I've had more time to optimise things (what, again?).

 

1) Do you ever sleep? ;)

 

2) After all the work you're putting into this, I really hope First Star is appropriately impressed and allows the game to be sold. This is a pretty phenomenal project.

Link to comment
Share on other sites

holy shit! awesome...

 

just my 2 cents regarding the "is it cheating?"...

 

no... it isnt... look... we @ taquart released Numen demo for atari800 with 320kb of ram... well... not a common configuration back in the 80s but who cares...we are 2006...

 

and... to be very honest... all of us use modern dev tools...pc, cross assembler, emulators other debugg & dev tools... most of them would not be available back in 80s...except main frame machines for assembling and serial interfaces for data input... so what? i would say with all these new tools, PCs and modern programming knowledge make BD possible... in 80s nearly impossible.... thats my 2 cents...

 

so in short... NO it's not cheating using a RAM cart + special self modifing code...

consumers will buy a cart which actually works in a plain 2600... so what?

Link to comment
Share on other sites

Amazing videos.

 

Not-Rockford seems to move really, really fast though, compared to Boulder Dash. Will this change?

870064[/snapback]

 

The game attempts to maintain a frame rate of 10 fps. This seems to give a reasonable falling-speed for boulders and diamonds. And since Rockford® can move down at the same speed as boulders, that's the speed he needs to move at, too. So depending on which video you're looking at, the answer is no.

 

The earlier videos did not have the frame rate tied, so he moved as quickly as was possible. Later videos (within the last week, say) have had the system limited to a maximum rate and should reflect the correct movement speed.

 

For all those interested, I now have a working sound engine playing music. Thanks very much to Paul Slocum for the original (and catchy!) composition. Also thanks to Thomas who has helped with the data for 20 levels (16 game levels, 4 intermission levels) thus giving the demo all the screens of the original Boulder Dash®!

 

I have a rudimentary selection screen allowing any level to be played. I may leave this in for the show -- I'm a bit burned out. All I really need to install now is player death, a few lives, and try my hand at optimising the systems a bit more (what, again again?). Basically it's pretty much ready to demo now, give or take a few bugs.

 

Cheers

A

Link to comment
Share on other sites

1) Do you ever sleep? ;)

 

Not nearly enough. I have a full-time job and two young children. So all my programming is done late at night and weekends. I typically get 5-6 hours of sleep. I acutally *need* more like 8 or 9 -- so I get pretty burned out when doing these sorts of projects.

 

Cheers

A

Link to comment
Share on other sites

For all those interested, I now have a working sound engine playing music.  Thanks very much to Paul Slocum for the original (and catchy!) composition. 

870372[/snapback]

Could we possibly have a sample of the title music as an mp3 file? (for us poor souls who can't attend the show...)

 

As for all remaining fine tuning (snapping a diamond? pushing boulders?) title screen etc etc I suggest a long break first! The effort that has been put into this project is really impressive - you definitely deserve some rest!

 

Regards,

Moderntimes99

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