The Pit

[Dr_Dave]

So I thought to myself, I've learned the absolute basics, why not convert an arcade game? Okay, it's a lofty ambition, but I think I've picked one that is at least possible.

The game is 1982's The Pit. A single screen proto-Boulderdash game by Zileg/Centuri/Taito in which you have to descend into a mine and collect diamonds, avoiding enemy robots, falling rocks and a tank that wants to stop you so much it is prepared to level a mountain. The Pit in the title refers to an acid filled monster room that must be traversed before you can escape with the loot. Here's what it looks like in all it's glory:

https://www.youtube.com/watch?v=mTIjYc-ZH-A

The game received a C64 port https://www.youtube.com/watch?v=VNDOdggdORo, but not a Spectrum one, which I think is a shame. The palette almost looks like a Spectrum game, and the 8x8 tiles seem suited to the Spectrum screen.

So I've made a start on drawing the screen and figuring out how I'm going to fit everything in. I kind of want to make it as faithful to the arcade as possible, with compromises only where I need to. And here's where I run into my first problem:



The arcade has about 29 character lines of playspace, and another 3 for the score at the top and high score at the bottom. I have 24 to play around with. The screenshot above is my attempt to modify the playspace to fit on a single screen, losing some lines here and there. It would probably work, but a lot of the rock layouts have very specific requirements for layout, so it would be a big compromise.

I'm currently thinking about making it a push-scroll instead, only displaying the half+ of the screen the player is in at any one time. Allowing 3 lines for scores, this would leave 21 lines of the 29 visible, which might be a worthwhile compromise to preserve the layout. It's not a particularly fast-moving game, so there's not a lot of need to see all of the screen. The C64 game, for the record, cut it down in a similar way as above. I guess I'll just have to see how it feels.

So, early days. Really, really early days... Other issues I can anticipate right now:

1) Colour - while it looks well constrained in 8x8 blocks, the movement is all pixel based, and dirt can be mined across character cell boundaries. Quite how I'll overcome this with the different coloured rocks/player/dirt, I'm not sure.
2) Movement - the arcade has a very precise movement feel to it, which requires accuracy and can be infuriating at times. Replicating this will be important for retaining the feel of the game.

Of course, I'll probably get distracted by another project and not get that far... but maybe the world will get the Spectrum port of The Pit it has craved so long!

[Juan F. Ramirez]

Never heard of it, seems interesting to play on MAME.

[Lethargeek]

I'm currently thinking about making it a push-scroll instead, only displaying the half+ of the screen the player is in at any one time. Allowing 3 lines for scores, this would leave 21 lines of the 29 visible, which might be a worthwhile compromise to preserve the layout. It's not a particularly fast-moving game, so there's not a lot of need to see all of the screen. The C64 game, for the record, cut it down in a similar way as above. I guess I'll just have to see how it feels.

maybe it's even better to use just 2 fixed viewpoints switching as the player is sufficiently close to the top/bottom
(trying several distances to determine when it's not too close and switching not too frequent)

[Dr_Dave]

maybe it's even better to use just 2 fixed viewpoints switching as the player is sufficiently close to the top/bottom
(trying several distances to determine when it's not too close and switching not too frequent)

Yes, that's what I'm thinking. The way the game plays, you don't move between the top and bottom that much, so having it flip would be fine. The only downside of that is that it hides the "timer" mechanic at the top (as you play, the tank shoots through the mountain, eventually blowing up your spaceship). On later levels, where time is tight, it would be easy to lose track.

[Lethargeek]

The only downside of that is that it hides the "timer" mechanic at the top (as you play, the tank shoots through the mountain, eventually blowing up your spaceship). On later levels, where time is tight, it would be easy to lose track.

well then, it just adds to the angst also maybe slide firing sound a bit?

[Pobulous]

Would it be possible to use a multicolour engine such as Bifrost? That would allow the graphics to be only 6 pixels high without leading to excessive colour clash.
The original layout could then be used, as there would be 32 possible positions.

[Einar Saukas]

Would it be possible to use a multicolour engine such as Bifrost? That would allow the graphics to be only 6 pixels high without leading to excessive colour clash.
The original layout could then be used, as there would be 32 possible positions.

Exactly! Although NIRVANA would be more appropriate. You would have 32 rows x 30 columns of 6x8 multicolor chars each, except no multicolor at the top and lower rows.

I can easily modify NIRVANA to print 6x8 chars for you, if you decide to use it.

[Dr_Dave]

Would it be possible to use a multicolour engine such as Bifrost? That would allow the graphics to be only 6 pixels high without leading to excessive colour clash.
The original layout could then be used, as there would be 32 possible positions.

Exactly! Although NIRVANA would be more appropriate. You would have 32 rows x 30 columns of 6x8 multicolor chars each, except no multicolor at the top and lower rows.

I can easily modify NIRVANA to print 6x8 chars for you, if you decide to use it.

That's tempting... I'll probably revisit that option later down the line when I feel a bit more confident with assembly language.

[Dr_Dave]

A nice stormy weekend, so the perfect time to catch up on 35 years of missed Spectrum coding time.

Here's where I'm currently at:

https://www.youtube.com/watch?v=Hr2zpaiQkvU

I decided to go with the push screen scrolling, which I think works quite well. Of course, this needed me to figure out about screen buffers and what not, and fast copying between the buffer and the screen. Honestly, I thought the layout of the Spectrum screen would melt my brain, but I figured it out eventually. Spent most of yesterday afternoon trying to figure out why a little line of corruption was sneaking onto my restored screen, only to remember I was using a stack manipulation technique to do the copy and I'd forgotten to disable interupts. Doh.

I spent today making the man move around and doing a first pass at collision detection, which is a little complicated because he can move into two cells at any one move. I've got it working and it seems to work well, but I feel as though I wrote a LOT of code to do it. Definitely a place I'll revisit for efficiency later.

I also added the title screen, a reasonably faithful version of the arcade. It's so dumb, I couldn't resist.

[Dr_Dave]

More progress. A spaceship and a "zonker" appear.

https://www.youtube.com/watch?v=bgaukjNnqs8

I've also added in all the rocks from the first level. Which now means I'll need to implement the digging mechanism to be able to get around the whole level. It'll be enouragement to face it, I suppose.

Had an interesting bug over the last few days, where a single line of my sprite's graphic would render one character space above his head, but only when stradling two particular columns. This seemed to just appear as I added some unrelated code (actually, it was always there, just hidden by the background. For some reason, it moved to a different column and became far more visible). I spent a lot of time debugging that, until I realised I was inc'ing l, but not h. And in a particular circumstance where l was FF, this was causing that the memory pointer to write one line up.

Thank goodness for the Z80 Debugger is all I can say!

Got a list of tasks I need to tackle now. It's nice to be able to treat this like a project and plan out what I'm going to work on next. I like how it's all breaking down into manageable modules - implement the ship, implement the tank, implement digging, etc. It makes it feel achievable.

[Lethargeek]

I decided to go with the push screen scrolling, which I think works quite well.

No, i see here flip happening at the same point when moving up and down, this is wrong. There must be a gap, so when you take a step back after the flip, the screen doesn't revert back immediately. Right now, when moving down, the point is 5 rows above the edge of the playfield, and when moving up, it is at 9 rows below the top edge, almost twice farther. Put it at the same distance from it's edge as the low point.

[Dr_Dave]

I decided to go with the push screen scrolling, which I think works quite well.

No, i see here flip happening at the same point when moving up and down, this is wrong. There must be a gap, so when you take a step back after the flip, the screen doesn't revert back immediately. Right now, when moving down, the point is 5 rows above the edge of the playfield, and when moving up, it is at 9 rows below the top edge, almost twice farther. Put it at the same distance from it's edge as the low point.

Yep, I think you're right here. It feels more natural with a gap. I'll play around with the numbers more when I have an end to end level in place, but just moving the up-scroll point back 32 pixels feels less flippy.

[Dr_Dave]

Ha, that's mad

I just suggested a port of The Pit late last year, and even mocked up a slightly adjusted screen layout to account for the missing lines:

viewtopic.php?p=27734#p27734

Yours looks fabulous. Not sure about the snap-scroll but it's early days The good thing is you don't ever really need to see the bottom of the screen while you're at the top or vice versa. Very excited to see how it develops.

Oh my god! I can't believe how much your concept looked like my first concept... I guess there's not a lot of ways you can vary it with the limitations of the Spectrum screen, but they're eerily familiar!

I've long thought The Pit would make a good Spectrum conversion... in a lot of ways, it LOOKS like a Spectrum game, so I'm amazed nobody attempted it before now.

[DouglasReynholm]

Has anyone ever seen [mention]Dr_Dave[/mention] and [mention]Rev_Stuart_Campbell[/mention] in the same room?

Ever?

Because I haven't.

[Dr_Dave]

This time, I ran into my first head scratcher - how to reproduce the digging mechanic. Initially, I toyed with the idea of doing the movement and the digging as character-based. This would have made things so much easier, especially with colour clash, with figuring out what you can dig, what you can't, where you can move etc. etc.

However, part of the uniqueness of the arcade game is the pixel movement, which allows you to end up with rocks perched on single pixels, or get hung up on a narrow entrance while a robot chases you. So sticking to character movement would have lost a lot of the charm of the game... and I decided to go with pixel movement.

First problem was that I was using attrs to do collision detection. If I wanted to avoid too much colour clash, I needed to make the player yellow-on-black, like the dirt, instead of white-on-black. Which meant that collision detection no longer worked. So first thing was to re-write collision detection with a routine that looked at the pixels the player is moving into. This allowed me to coopt this to detect a case where the destination space had dirt in it and whether the player could "dig it". At this point, my brain melted, as I realised how many different permutations there could possibly be in a well dug board.

Then I stumbled on something useful - in the arcade, pixel movement only applies to up/down movement. For left right movement, the game moves 8 pixels at a time. Which means that dirt can't be halved across columns, and it cuts the number of possibilities right down.

After that, it became a lot clearer. A couple of edge cases needed for digging up or down into dirt on top of or under rocks, a bit of animation and a flash effect (embiggen the video to see), and here we are...

https://youtu.be/1TFfulC12IU

I'm happy with it! Needs some tweaking and bug fixing here and there, but its the first real game mechanic done.

[Dr_Dave]

Looks great! (though we might have to remove "16k" from the list of supported models before we send it to the printers!)

[Dr_Dave]

Latest developments:

- Added high score table underneath play area (per arcade)
- Added alternate title screen with instructions (per arcade)
- Added rock falling
- Added gems, and made diamond and gems twinkle

https://www.youtube.com/watch?v=25QxbigCTM4

I'm starting to run into places where I need to make compromises or decide to live with consequences. The falling rocks were relatively easy to implement, as it turned out, but they made me face my first real brush with colour clash. Like the digging, this wouldn't be a problem if we worked with characters, but the rocks can land on partially dug block, so fall in between the yellow ink dirt block and the red ink rock block. You can see one in the middle at the bottom of the video.

How to deal with this. Well, here are some options:

1) Apply attributes cleverly to minimise it (if a dirt is more than half empty, make it red, otherwise keep it yellow)
2) Deviate from arcade and have the rock "flatten" dirt down to full character
3) Live with it, it's a spectrum!

I'm leaning towards 3, with some of 1. I'd rather keep the gameplay intact.

I also ran into my first performance hurdle. I figured out that my debugger can show me the t-states I'm currently using. I ran it on a single frame and found, to my surprise, that I was using about 137,000 t-states! This is about twice what would be needed for 50fps, and barely under the 25fps limit.

Further inspection revealed this was due to my buffer-to-screen routine that was using a massive 132,000 t-states. So, on the one hand, I was happy that my game code was using only about 5000. On the other, I was dangerously close to falling below 25fps.

So I dived into the code for the buffer copy. The main culprit was about some stack manipulation with 32 pop/pushes per pixel row, which use 10-15 t-states each... I soon realised I could lose some big chunks of screen off the side that is empty and I hadn't bothered trimming, which got down to 28 pop/pushes per line. I also lost a character row at the bottom that contains the high score table. When I was done, I was down to about 120,000 t-states. Which gives me some breathing room to keep at 25fps.

Anyone have any tips for writing fast buffer copy routines?

All in all. Good progress. Getting to the fun stuff now. Next time - DEATH.

[Lethargeek]

1) Apply attributes cleverly to minimise it (if a dirt is more than half empty, make it red, otherwise keep it yellow)
2) Deviate from arcade and have the rock "flatten" dirt down to full character
3) Live with it, it's a spectrum!

also try altering the rock gfx having less ink pixels in the bottom half (heavy shadow)
unless you insist keeping the exact original look

Anyone have any tips for writing fast buffer copy routines?

if most of the screen area doesn't change, it is faster to copy the 'dirty' tiles only (those marked drawing into the buffer)

[Dr_Dave]

If most of the screen area doesn't change, it is faster to copy the 'dirty' tiles only (those marked drawing into the buffer)

Yeah, that's a good idea. Will have a think about doing it like that instead.

[PROSM]

If it's possible, the fastest way to copy the graphics would be to draw them directly to the screen. You'd need to reorganise your game code somewhat, but it would probably let you get up to 50fps if you wanted, and 25fps very comfortably.

[Ivanzx]

Following closely this project, sounds like an interesting game to convert

By the way, I foun out that there was a conversion for the Spectrum, as a type-in!!

https://spectrumcomputing.co.uk/index.p ... 6&id=15150

[Dr_Dave]

Following closely this project, sounds like an interesting game to convert

By the way, I foun out that there was a conversion for the Spectrum, as a type-in!!

https://spectrumcomputing.co.uk/index.p ... 6&id=15150

I wish I'd known about this a few weeks ago

[Dr_Dave]

Meanwhile...

https://youtu.be/SMa1pU0skS8

Latest developments:

- Added collision between rocks and player
- Added lives, a life summary screen, game over screen
- Added collection of gems

Best of all, I revisited my buffer to screen code. Based on an idea up thread, I rewrote my buffer copy to only copy character lines that had undergone changes. The idea being that only a few things are actually moving on the screen at any one time, so even redrawing a couple of lines for every moving thing results in the number of lines being drawn decreasing from 20 to under ten for most frames. This had the effect of reducing my t-states for a frame from 120,000 to around 40,000. Now I've got the idea, I could probably do it by just doing individual character cells, but that's one for another update.

I'm starting to run into more interesting bugs now that the game is getting more complex. I had one that stumped me for a while where starting a new life caused the game to crash. Just couldn't figure out what was going on. I ended up commenting out pretty much everything and adding it back line by line to track down the issue. Turns out I was writing a 16 bit number to a place where I'd only defined one byte, so it was overwriting something crucial that only became apparent on the next life loop. Satisfying to solve, but really difficult to figure out... I notice in the video above there some weird sprite corruption on the final death. Looking forward to figuring that one out!

Anyway, it's starting to feel like a game now. I think I'll tackle scoring next. Anything to avoid writing the code to make the tank shoot through the mountain!

[Dr_Dave]

Mercifully, it runs on a Next... so if I get it finished in time, I might be able to get a piece of that Christmas Spectrum sales pie!

[Hedge1970]

Looks really nice, never played the game but it looks fun. I think your screen flip is perfect and does not detract from the game, in many ways it enhances it and give a feeling of being deeper.

I am in awe at how quickly you have picked up machine code. The tiny projects I am working on have me scratching my head for days and yet in a few short weeks you’ve got a (good looking) playable game screen. Looking forward to the end result.