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.
The Pit
-
Lethargeek
- Manic Miner
- Posts: 743
- Joined: Wed Dec 11, 2019 6:47 am
Re: The Pit
Re: The Pit
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.Lethargeek wrote: ↑Wed Feb 12, 2020 1:00 amNo, 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.
Re: The Pit
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!Rev_Stuart_Campbell wrote: ↑Wed Feb 12, 2020 2:37 am 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 daysThe 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.
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.
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
- Manic Miner
- Posts: 349
- Joined: Wed Feb 20, 2019 8:38 pm
Re: The Pit
Has anyone ever seen [mention]Dr_Dave[/mention] and [mention]Rev_Stuart_Campbell[/mention] in the same room?
Ever?
Because I haven't.
Ever?
Because I haven't.
Re: The Pit
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.
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.
Re: The Pit
Looks great! (though we might have to remove "16k" from the list of supported models before we send it to the printers!) 
Re: The Pit
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.
- 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
- Manic Miner
- Posts: 743
- Joined: Wed Dec 11, 2019 6:47 am
Re: The Pit
also try altering the rock gfx having less ink pixels in the bottom half (heavy shadow)
unless you insist keeping the exact original look
if most of the screen area doesn't change, it is faster to copy the 'dirty' tiles only (those marked drawing into the buffer)
Re: The Pit
Yeah, that's a good idea. Will have a think about doing it like that instead.Lethargeek wrote: ↑Sun Feb 16, 2020 7:20 pm If most of the screen area doesn't change, it is faster to copy the 'dirty' tiles only (those marked drawing into the buffer)
-
PROSM
- Manic Miner
- Posts: 476
- Joined: Fri Nov 17, 2017 7:18 pm
- Location: Sunderland, England
- Contact:
Re: The Pit
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.
All software to-date
Working on something, as always.
Working on something, as always.
Re: The Pit
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
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
Re: The Pit
I wish I'd known about this a few weeks agoIvanzx wrote: ↑Thu Feb 20, 2020 7:47 pm 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
Re: The Pit
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!
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!
Re: The Pit
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!
Re: The Pit
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.
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.
Re: The Pit
https://youtu.be/3IpPztRz470
Progress...
- Added scoring
- Added high score table
- Added level completion
- Added tank shooting
- Also fixed a load of bugs
Phew!
The tank shooting turned out to be not as awful as I thought it would be. Once I had some functions sorted out to check if chars were empty, to copy characters down, it all came together. Interestingly, having the timer in place really adds something to navigating the bottom half of the screen. Knowing that it's ticking away up there and you can't see it really adds to the tension of trying to get out of the diamond room.
Only got a few functional tasks left now:
- Robots
- The Pit room
- Falling missiles
- Shooting
Then it's just making sure two player works, increasing the difficulty, different level layouts etc.
Then I can finally play around with my Next
Progress...
- Added scoring
- Added high score table
- Added level completion
- Added tank shooting
- Also fixed a load of bugs
Phew!
The tank shooting turned out to be not as awful as I thought it would be. Once I had some functions sorted out to check if chars were empty, to copy characters down, it all came together. Interestingly, having the timer in place really adds something to navigating the bottom half of the screen. Knowing that it's ticking away up there and you can't see it really adds to the tension of trying to get out of the diamond room.
Only got a few functional tasks left now:
- Robots
- The Pit room
- Falling missiles
- Shooting
Then it's just making sure two player works, increasing the difficulty, different level layouts etc.
Then I can finally play around with my Next
-
Firefox
Re: The Pit
That's looking very nice!
I notice there's a tunnel that leads up behind the Zonker. Is there some way you can disable it or slow it down?
I notice there's a tunnel that leads up behind the Zonker. Is there some way you can disable it or slow it down?
Re: The Pit
In the arcade, that tunnel is where the enemy robots deploy. They kind of pile in behind the zonker and drop down. I've never tried getting up there, funnily enough! Maybe in The Pit 2, you'll escape up this tunnel into a sprawling open world MMO
Re: The Pit
How about a decent squish animation when he gets crushed by a falling rock?
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
Re: The Pit
https://youtu.be/bGaTIW9EbIc
Progress:
- Added falling missiles
- Added pit monster
- Added pit trap
- Added robots
- Added shooting
- Added options screen
- Added joystick support
- Added some placeholder (and awful) sound effects
- Performance improvements
Busy week! Actually, most of this week was spent rebuilding stuff from the ground up for performance. I redid my buffering routine after adding in the monster and finding the framerate tanked... shifting sprites is real expensive! Next time, I'd probably consider using pre-shifted sprites for the time it would save. I don't seem to be coming close to the memory limit, on this game at least.
Everything else was relatively trouble free. The code is at the stage where adding in new stuff is really just adding in variations on existing themes, so a lot of code can be repurposed. Not that I'm doing too much of that... I seem to be mostly content to copy and paste routines, rather than make them generic. The shame of doing that is offset by the lack of mental anguish trying to shoehorn register states into other scenarios. Maybe one day I'll refactor it... ho ho!
One great thing this week was the release of zesarux 8.1, which fixed the issues I was having with the Z80 debugger and made problem diagnosis 100x easier. It's so nice to be able to step back and forward through code as it runs...
Okay, the game is mostly complete now! Certaintly, all of the game elements are there. It all hangs together reasonably well. So what's left to do?
1) Make sure the 1/2 player transition is working properly. I've been kind of coding with this in mind all along, but haven't tied it all together. I'm sure it'll be fine
2) Figure out the difficulty progression. At the moment, things are just pretty much drawing as I coded them, so I need to put in a level based difficulty structure. Looking at videos of the arcade, this seems fairly simple: tank speed, robot speed, dig speed, pit speed and missile drop rate. So I just need to parameterise those, and tie them into the level transition. It also has a kill screen on level 12, where the speed becomes too fast to complete. So I'll be aiming to reproduce that.
3) The arcade also has a second rock layout on alternate levels.
4) Sound effects.
And that's it. Oh, and I want to make the font a little more arcadey.
A cheat mode might help as well, since I'm too rubbish to get very far in the game!
Progress:
- Added falling missiles
- Added pit monster
- Added pit trap
- Added robots
- Added shooting
- Added options screen
- Added joystick support
- Added some placeholder (and awful) sound effects
- Performance improvements
Busy week! Actually, most of this week was spent rebuilding stuff from the ground up for performance. I redid my buffering routine after adding in the monster and finding the framerate tanked... shifting sprites is real expensive! Next time, I'd probably consider using pre-shifted sprites for the time it would save. I don't seem to be coming close to the memory limit, on this game at least.
Everything else was relatively trouble free. The code is at the stage where adding in new stuff is really just adding in variations on existing themes, so a lot of code can be repurposed. Not that I'm doing too much of that... I seem to be mostly content to copy and paste routines, rather than make them generic. The shame of doing that is offset by the lack of mental anguish trying to shoehorn register states into other scenarios. Maybe one day I'll refactor it... ho ho!
One great thing this week was the release of zesarux 8.1, which fixed the issues I was having with the Z80 debugger and made problem diagnosis 100x easier. It's so nice to be able to step back and forward through code as it runs...
Okay, the game is mostly complete now! Certaintly, all of the game elements are there. It all hangs together reasonably well. So what's left to do?
1) Make sure the 1/2 player transition is working properly. I've been kind of coding with this in mind all along, but haven't tied it all together. I'm sure it'll be fine
2) Figure out the difficulty progression. At the moment, things are just pretty much drawing as I coded them, so I need to put in a level based difficulty structure. Looking at videos of the arcade, this seems fairly simple: tank speed, robot speed, dig speed, pit speed and missile drop rate. So I just need to parameterise those, and tie them into the level transition. It also has a kill screen on level 12, where the speed becomes too fast to complete. So I'll be aiming to reproduce that.
3) The arcade also has a second rock layout on alternate levels.
4) Sound effects.
And that's it. Oh, and I want to make the font a little more arcadey.
A cheat mode might help as well, since I'm too rubbish to get very far in the game!
Re: The Pit
Well, I think I'm pretty much done!
https://youtu.be/YQeyKqAeEaY?t=127
If you scoot back to the beginning of the video, you can see the loading screen in all it's colour clashing glory.
Progress:
- Added difficulty curve, which hopefully tops out at level 12 (I don't know, I can't get past level 5!)
- Added two players
- Added arcade font
- Added sound effect
- Added loading screen
- Bug fixed!
If you want to give it a go, grab it from my github: https://github.com/davetansley/thepitspectrum (link in the readme). Warning, it will probably have bugs
So, first venture in assembly and game development in general... Overall, it was a load of fun! I got quite obsessed with it for a while there, and loved seeing the thing come together.
Coding for the Spectrum feels finite, you know? Like you could one day master it. This is totally different to modern languages and systems, the mastery of which seems a folorn hope at best. And the process gave me a newfound respect for 80s coders, especially those who were involved in arcade conversions. I can't even begin to imagine how frustrating it must have been to debug code without modern tools, and I do wonder just how they managed to replicate coinop mechanisms so well without MAME running in a window beside them!
Biggest frustrations? Once I got over the conceptual difficulty of assembly language coding, I think the sound was the thing that annoyed me the most. Realising just how limited the 48k beeper is and how creative you need to be to get it to something interesting (not to mention the effect on game speed!)
Finally, porting The Pit made me realise just how much of an annoying game The Pit actually is! So many peculiar design decisions (most of which I've tried to replicate faithfully!) and frustrating little control quirks... I guess what I'm trying to say is, "don't blame me!"
https://youtu.be/YQeyKqAeEaY?t=127
If you scoot back to the beginning of the video, you can see the loading screen in all it's colour clashing glory.
Progress:
- Added difficulty curve, which hopefully tops out at level 12 (I don't know, I can't get past level 5!)
- Added two players
- Added arcade font
- Added sound effect
- Added loading screen
- Bug fixed!
If you want to give it a go, grab it from my github: https://github.com/davetansley/thepitspectrum (link in the readme). Warning, it will probably have bugs
So, first venture in assembly and game development in general... Overall, it was a load of fun! I got quite obsessed with it for a while there, and loved seeing the thing come together.
Coding for the Spectrum feels finite, you know? Like you could one day master it. This is totally different to modern languages and systems, the mastery of which seems a folorn hope at best. And the process gave me a newfound respect for 80s coders, especially those who were involved in arcade conversions. I can't even begin to imagine how frustrating it must have been to debug code without modern tools, and I do wonder just how they managed to replicate coinop mechanisms so well without MAME running in a window beside them!
Biggest frustrations? Once I got over the conceptual difficulty of assembly language coding, I think the sound was the thing that annoyed me the most. Realising just how limited the 48k beeper is and how creative you need to be to get it to something interesting (not to mention the effect on game speed!)
Finally, porting The Pit made me realise just how much of an annoying game The Pit actually is!
So many peculiar design decisions (most of which I've tried to replicate faithfully!) and frustrating little control quirks... I guess what I'm trying to say is, "don't blame me!" -
andydansby
- Microbot
- Posts: 147
- Joined: Fri Nov 24, 2017 5:09 pm
- Location: Syracuse, NY, USA
- Contact:
Re: The Pit
Congratulations on your game release. Looking good.
Re: The Pit
Yeah, the difficulties are things that can be tweaked. To be honest, I've played through the same level so many times, I'm almost blind to what's hard and what's not now. Going to step back from it, let a few people play it, then adjust in coming weeks. Luckily it's all just numbers I can fiddle with that control the missile drop rate or the trap withdraw speed.Rev_Stuart_Campbell wrote: ↑Sat Mar 07, 2020 2:50 pm OM actual G he's only gone and done it. Wowsers.
Would love to see it get polished up a bit in time by yourself or someone else (the diamond cave is much too easy and the monster pool is extremely hard to escape from), but that's just a phenomenal feat for a first game, from scratch to release in a single month. My dream of a Speccy Pit has finally come true. All kudos to you, sir
Re: The Pit
Hah! Now, I can't even do the arcade trap room repeatedly, so it felt perfectly accurate to meRev_Stuart_Campbell wrote: ↑Sat Mar 07, 2020 3:20 pm The actual trap withdraw speed is fine, it's just that the player movement is a little twitchy/gluey so it's hard to get it right with the required precision. (Maybe partly down to having 48K sound rather than 128?) I can do the coin-op blindfold but it took me about 100 lives to escape the first level.
I think I could probably do with toning down the left-right motion, which, as you say, is too twitchy. Will have a look at it.