Possible new DigDug version for the BBC Micro

[tricky]

I've started on a possible new DigDug version for the BBC Micro, I say possible because as some of you may know, I'm easily distracted!

From the what should I write next thread:
Here are the sound tunes played, well, about half the ones in the game, but this is at the limit of my current encoding schemes (about 1.75K)!

combined.ssd

(2.5 KiB) Downloaded 30 times

start_music
in_game_music - played at 1/2 volume as it is apparently 50/50 love/hate and is played at three different speeds in game
last_one_sound
stage_clear
monster_moving
extend_sound - will be used for new high-score
bonus_sound
hurry_up_sound
miss
game_over
game_play
The sound chip in the arcade game doesn't have "noise", so I am planning on replacing some of the "effects" with noise based ones.

Any devs out there, 1.75K seems massive for sound, but does it seem reasonable for the sounds on the .ssd.
They are transcoded from the original chip writes (hacked MAME + custom converter) so have more detail than simple notes.

I was going to make it based on playing the arcade version as I couldn't find anything about the "AI" or anything else.
fizgog pointed to the original 7800 source code by "Namco Limited" https://github.com/videogamepreservation/digdug-7800.
Initially I had been put off by the squashed looking screen and GFX but it looks like it plays quite well, so I might try the logic from there.
I didn't play DigDug it as a kid more than a couple of times so there is a lot for me to learn.

I found a couple of walkthroughs: https://retroist.com/dig-dug-strategy-guide/ and https://strategywiki.org/wiki/Dig_Dug
and fwibbler found a modern one probably running an emulator: https://www.trueachievements.com/game/D ... kthrough/2
It would be great if someone knew the rules so that I can get them right first time

It wasn't until I looked more closely that I realised that the arcade version is 224x288!
I'm planning on combining the status parts and removing the 1/2 row of dirt near the top as I can't see a use for it and it simplifies the logic a little

Memory usage so far:
Pages (256 bytes / 1/4K)

Code: Select all

64 screen, could save 1/2K by shrinking the status line to one char row.
15 sprites
 8 save and restore buffers for sprites, currently last 32 bytes spare per page
 8 tiles, font, dirt etc
 7 tunes
 3 sprite code
 1 main game loop
 3 init level
 1 interrupts and util functions

Total 113 out of 128, so, 3.75K left for the game and tunnel drawing (might be able to claw a bit back from map init once tunnel drawing is done)

The emulator squashed the image a bit, but it should be 256x256 (well, 512,125 as it is 2X)

There is a problem with timing at the moment, I think I have deleted some initial sync code as the sprites shouldn't flicker!

Trickycadegame.ssd

(11.75 KiB) Downloaded 32 times

There are no controls, just the intro tune which then goes into the looping background music at 1/2 volume to hoefully make it less annoying to those who aren't fans.

If you know any "rules" of the "AI" I would be glad to hear them otherwise, it will be play testing time before they get spotted!

All questions welcome as ever, code or anything else, just remember I have no talent for gameplay or graphics and negative talent for sound!

PS Looks like the sound is completely broken on b-em and partially broken on beebjit, but beebjit has no flicker - who knows what I have done!

PPS Beeb has no flicker and sound matches beebjit (as expected )
The demo sound disc works fine, so I have a second issue to look at in what I did in-game!

PPPS flicher changes from run to run, so I do have something wrong with that too

and I can't work out why the green stones are less dense than the red ones!

[tricky]

Found the audio bug, weeks ago I had commented out most of the keyboard code including the line that disabled the keyboard again!
I did think of this and had added code to disable it at the start, but didn't realise that I was even calling the code!
Updated proof of concept, same display, but hopefully working sound, next to look at the flicker!

[Arcadian]

I don't think there's an arcade conversion I could be more excited about you coding! A fine, fine choice - good luck, I'll be downloading and trying every dev version you post for sure!!

[tricky]

Great to hear that, having fans waiting is one thing that often spurs me on
Are you also an expert and can tell me when I have the AI wrong?
I'm not planning on using the exact screen layouts unless I have to use SWRAM, so you will need to learn patterns

[fizgog]

Very nice start

Code question
Are you using a couple of dirt sprite tiles to generate the backdrop or are you just using some random pixel plots?


Looks like they use the top 2 rows to display flowers small and large - looks like eye candy though and doesn't seem to do anything

[tricky]

I was using two chars to generate the dirt, but I prefer the procedural dirt and without the layers in it, the pattern seemed to dominate.
I'm planning on putting the flowers down the sides of the play area although there would still be room for the smaller ones.
The row that I have removed is the one just below the top two pixels of dirt, just under the flowers.
If you try to dig horizontally just below the surface, you will see what I mean.
To fit all of the soil except the top row leaves four char rows, two for running on and two for the scores.
I might try a couple of mockups, although anyone else is free to try some as well.

[chrisn]

Love Dig Dug! I'm ready as soon as you need it playtesting..

[tricky]

Great to hear than chrisn, the more people who know the game, the smaller the pile of bugs when I think it is finished I hope!

To save memory he always carries his shovel or whatever it is and I was going to let it double up as a pump too!
If I run out of memory and have to require SWRAM (or a ROM like my other games) I'll add the other animation frames in.

I was out most of the day, so only added moving around the grid and animating the main character.

Trickycadegame.ssd

(12 KiB) Downloaded 29 times

I think I copied the gfx correctly, but horizontal movement isn't very nice, so I might tweak the sprites even though I am no good at it!

The colour bars are for restoring the background, capturing the new background and then drawing the sprites in the four quarters of the screen which end where the bar that draws them starts. The minimum height of the bar is checking which of the 14 possible sprites need to be drawn - yep, it takes ages!
The character moves 2 pixels every 4 frames when digging and every 3 frames when not. This may feel a little slow compared to the arcade as we are at 50Hz instead of 60. I was thinking of having a "fast" option where you dig every 3rd frame and move every 2nd with the monsters sped up to match but we will see.

I'm curious what people think of the background music - to quote one of my favourite podcasts "annoy or enjoy?".
It is still in the catchy tune phase

[fwibbler]

I'd say the music is part of Dig Dug. Without it, it just won't be the same.
Also, in the arcade the music only plays when the player is moving (you probably know this but anyway)
Still haven't found the screenshot mockup I did a while back

[tricky]

Thanks, I didn't know that about the music. How does the half volume thing work for you?

[fizgog]

How does the half volume thing work for you?

Definitely prefer the half volume whilst moving the player

[tricky]

I've been poorly, but did get a bit of beeb time tonight.
Added tunneling, although I think I am tunnelling a couple of pixels too far ahead of the player.
3575 bytes free.

[fizgog]

Very nice


One thing I did notice was the point of the shovel seems to be missing going up/down (left / right is fine), unless it was intentional due to sprite size

Screenshot 2023-03-15 at 00.07.10.png (26.11 KiB) Viewed 3537 times

[Rich Talbot-Watkins]

Looks great so far!

I think the music is important and adds to the general vibe of the game, but compared to the arcade I think you have the bassline a bit wrong - I'd try making it an octave higher first of all, but there are some slightly wrong notes there as well from what I can hear.

I think it should be:

C4 G4 C4 G4
B3 G4 B3 G4
Bb3 G4 Bb3 G4
A3 G4 A3 G4
Ab3 F4 Ab3 F4
Ab3 F4 Ab3 F4
G3 F4 G3 F4
A3 F4 B3 F4
(repeat)

where the ascending order of the notes is

(lowest) .................................. (highest)
G3 Ab3 A3 Bb3 B3 C4 Db4 D4 Eb4 E4 F4 Gb4 G4

Does that make sense? Tried to make it as non-musical as possible!

[tricky]

Thanks Rich, I appreciate the dumbing down.
I thought I had compared the frequencies by looking at the waves but I probably misunderstood either the interference between the channels or possibly the effect of the wave tables.
I'll give it another check but I trust your ears.

[tricky]

Great eye fixgog, it is a feature of me drawing all the sprites 14 high because that is what I thought the max size was, just need to centre them.
I have realigned that sprite, fixed the bug that was scribbling on the first part of the first sprite, losing the back of the head, tightened the tunnel face and added static rocks.
Sorry Rich, I have another bad headache, so an hour is about all I'm going to manage today.
3505 bytes free

[tricky]

Still not feeling great, so wanted a quick win.
I've initialised the pookas and fygars and added the into anim.
3483 bytes free

[tricky]

Feeling better, but have to go out so another minor update, a new BCD add score and draw with leading 0s skipped.
The adding and drawing the score is a little larger than the previous ones I have used, but it may need less code to use for rounds. Maybe more useful in future games.

Code: Select all

.add_scoreAA ; AA=bcd add : A=?? Y=&FF X=?F HI(score_pos)=HI(score_pos) LO(score_pos)=LO(score_pos)+&60 (wraps)
{
	ldx #0
.*add_scoreXXAA ; XXAA=bcd add : A=?? Y=&FF X=?F
	SED
	clc : adc score : sta score
	txa : adc score+1 : sta score+1
	lda #0 : adc score+2 : sta score+2
	CLD
	ldy #LO(SCORE_ADDR) : sty dst : ldy #HI(SCORE_ADDR) : sty dst + 1
	lda score+0 : PHA
	lda score+1 : PHA
	lda score+2 : PHA
.*draw_number ; 3 bytes on stack lsB pushed first : A=?? Y=&FF X=?F ; draws to (dst)
	lda #opcode_LDA_IND_Y : sta write_sm + sm_op
	PLA : jsr digits
	PLA : jsr digits
	PLA
.digits
	pha : and #&F0 : jsr digit
	pla : asl A : asl A : asl A : asl A
.digit
	beq ok : ldx #opcode_STA_IND_Y : stx write_sm + sm_op : .ok
	ora #&0F : tax : ldy #15
.lp
	lda tiles,x : .write_sm : sta (dst),y : dex : dey : bpl lp
	clc : lda dst : adc #16 : sta dst
	RTS
}

add_scoreAA is called to add the BCD contents of A to the score.
add_scoreXXAA add BCD XXAA to the score
draw_number writes the three byte BCD number on the stack to (dst) skipping leading 0s.

If anyone has better routines, I'd love to know as 91 bytes feels a little high.
Previous versions have only drawn the number in a single place or not skipped leading 0s but were < 80 bytes.

3386 bytes free

[TobyLobster]

If anyone has better routines, I'd love to know as 91 bytes feels a little high.

A small improvement if I am seeing it correctly: Do you need the ora #&0f ? If you omit that then the lower 4 bits are zero here, and you can use 'lda tiles+15,x' a few instructions later to access rather than 'lda tiles, x'
Only saves 2 bytes though.
EDIT: But that doesn't quite work if X=0 and we decrement around the loop though. Oops. It would need the tiles memory carefully arranged to make it work, which is probably inconvenient.
EDIT: But, could remove the ora #&0f and maybe the loop could be made to count upwards in both X and Y instead of down? Have Y start at 256-15?

[tricky]

Good point TobyLobster, but then it would add 96 cycles, 3/4 of a scan line but I could save nearly all of that by making the sta absolute,y but then that would cost more bytes. I'll keep it in the bag for when things get desperate

Actually, I had thought about storing the bytes for each digit backwards so that X could count up to save the ora #&F.
I could also save the anf #&F0 if I wasn't skipping leading zeros.

[TobyLobster]

I was thinking something like this (untested) changes commented with *****:

Code: Select all

.add_scoreAA ; AA=bcd add : A=?? Y=&FF X=?F HI(score_pos)=HI(score_pos) LO(score_pos)=LO(score_pos)+&60 (wraps)
{
	ldx #0
.*add_scoreXXAA ; XXAA=bcd add : A=?? Y=&FF X=?F
	SED
	clc : adc score : sta score
	txa : adc score+1 : sta score+1
	lda #0 : adc score+2 : sta score+2
	CLD
	; ***** offset address by -240 *****
	ldy #LO(SCORE_ADDR-240) : sty dst : ldy #HI(SCORE_ADDR-240) : sty dst + 1
	lda score+0 : PHA
	lda score+1 : PHA
	lda score+2 : PHA
.*draw_number ; 3 bytes on stack lsB pushed first : A=?? Y=&FF X=?F ; draws to (dst)
	lda #opcode_LDA_IND_Y : sta write_sm + sm_op
	PLA : jsr digits
	PLA : jsr digits
	PLA
.digits
	pha : and #&F0 : jsr digit
	pla : asl A : asl A : asl A : asl A
.digit
	beq ok : ldx #opcode_STA_IND_Y : stx write_sm + sm_op : .ok
	; ***** no need for 'ora #&0f', start Y at 240 ******
	tax : ldy #240
.lp
	lda tiles,x : .write_sm : sta (dst),y : inx : iny : bmi lp   ; ***** increment both X and Y and loop back *****
	clc : lda dst : adc #16 : sta dst
	RTS
}

[caspian]

Pengo, Mr. Do and DigDug are 3 of my favourite games (though I've seen a walk-through give kind of a boring but effective strategy for dig-dug)
After I saw a detailed description of Pac-Man enemy AI I looked for similar explanations for them but didn't find it. I've figured out a lot of it for Dig Dug though, here's my observations:

The monsters can be normal or in ghost mode.

1: In ghost mode they head for you, kind of ignoring tile-based movement. But I think it's in one of either the 4 tile-aligned directions or the 4 diagonals.

2: In normal mode, they don't turn backward unless they have to, so they will follow a tunnel, including around corners, even if it moves them away from you.

3: In normal mode at a T junction if they have a choice of moving away from you or towards you (while following rule 2) they move towards you.

4: In normal mode at a T junction, if they can move both horiontally or vertically towards you, they may do either (I tested this where 2 different monsters followed me different ways while I stayed in the same location, so I don't know how they decide but maybe it's pseudorandom)

5: I think in a 4 way junction the rules are the same - they avoid turning back and they avoid moving away from you.

I haven't tested rules 3-5 if you're either exactly lined up with them in the X or Y direction - to know if they treat moving away from you on an axis where they were lined up, the same as moving further away when there's already a difference.

6: If there's a rock above them going to fall on them, they'll run away from it. Including turning back, so this overrides rule 2. I've never seen them run away vertically down a tunnel and get to a dead end, so I don't know if they'd just keep turning back over and over again. I did try making a very shallow tunnel downward (less than half a tile) and they didn't bother going into it at all (see rule 13)

7: After all but one monster are killed, the last remaining monster soon starts running away to the top left corner of the screen, turning into ghost mode when its path is blocked. This is an exception to rule 1, it doesn't chase you now. In this situation I have seen non-ghost monsters turn backwards instead of turning a corner that moves them away from their target, an exception to rule 2. Also, I think I read in one of your links they don't always run away on higher levels.

8: In normal mode, they sometimes change to ghost mode - not sure if this is time-based or pseudorandom and different for each game. It happens more quickyl on the later levels.

9: In normal mode, the fire-breathing one sometimes stops briefly then breathes fire. It can do this regardless of whether the player is in front of it.

10: In ghost mode while they are in walls they stay in ghost mode.

11: In ghost mode if they move into empty space they change back to normal mode.

12: If you stay on the level long enough the enemies get faster.

13: The monsters can't go into a tile square through if the tunnel only goes half way in.

14: The monsters can can't travel between two tiles next to each other, if both tiles have a thin layer of wiggly dirt in between.

15: If the thin layer of dirt between two empty-ish squares was wiggly on both sides, but is then dug flat on one side to be even thinner, I'm not sure if monsters can go through, but I think sometimes they can. Not sure if this is important, but it's something I think I noticed while trying to test their behaviour.

I think I've covered most of what I know about the monster AI. There were a couple of observations about inflation that came to mind though.

16: You can walk through monsters while they're inflated.

17: Monsters if you let them deflate, they're facing the same direction as they were before.

And a non-monster thing I've noticed - if you walk all the way around the point between four tiles, dirt is cleared from that point.

[tricky]

I was thinking something like this (untested) changes commented with *****:

The thing is that every read will then cross a page boundary and add a cycle.

[TobyLobster]

I was thinking something like this (untested) changes commented with *****:

The thing is that every read will then cross a page boundary and add a cycle.

Yep, good point.

[tricky]

Pengo, Mr. Do and DigDug are 3 of my favourite games (though I've seen a walk-through give kind of a boring but effective strategy for dig-dug)
After I saw a detailed description of Pac-Man enemy AI I looked for similar explanations for them but didn't find it. I've figured out a lot of it for Dig Dug though, here's my observations:
...

Thanks, this was exactly what I was hoping someone would have excavated from the code.

I had assumed that when the reached a junction that they would pick the direction that would head closer to you, like pacman, "measuring" from the first square in each direction. I hadn't noticed that they couldn't reverse unless they had to.

I was wondering about how far into the last tile of a dead end they would go.

Sould 14 be can't not can?

I read somewhere that both you and the fygars can "shoot" through walls.

I had also noticed that slightly odd rules about when dirt is removed and when not. At first I was trying to make the game tile based, but even with 8x8 tiles, the number of combinations required for partially dug tiles is in the several hundred. I suspect that where they have parts of tiles disappearing that it is because they ran out of tile memory! I'm doing it as a bitmap game restoring the background (my first game like this) so it is easier to do what I think they would have liked to have done.

The dead ends are a pain too as it means storing a bitmask or reading the screen to see if the way ahead is clear. Currently I have a two byte mask per tile (16x16) where 8 bits are the horizontal slices remaining and the same for the vertical. I haven't implemented this yet, but the idea is when one becomes 0, clear the middle 6 bits in the other and score the 10 points.

[tricky]

I was thinking something like this (untested) changes commented with *****:

The thing is that every read will then cross a page boundary and add a cycle.

Yep, good point.

If I'm worrying about spending 96 cycles, shouldn't I just reverse the byte order and save 192 vyvles and 2 bytes>

Yes, I wasn't because of the other numbers that need to be drawn, but since I swapped to PHA for which number to draw, doing the smaller numbers using the same routine should be fine.

PS I was also thinking of reversing the order of the bytes in the digits to allow Y to count up and numbers to cross a page boundary without adding 16 bit addition. This would require X to count down or use a CMP.

[tricky]

I swapped the (dest),y for dest,y allowing the low byte to be modded for a different start pos as well as allowing Y to start at an offset from there!
OK, numbers are a little harder to read in the "texture":

_digits.png (311 Bytes) Viewed 3075 times

but it does mean that the add and draw code total shrinks to 78 bytes and we save more cycles:

Code: Select all

.add_scoreAA ; AA=bcd add : A=?? Y=&FF X=?F HI(score_pos)=HI(score_pos) LO(score_pos)=LO(score_pos)+&60 (wraps)
{
	ldx #0
.*add_scoreXXAA ; XXAA=bcd add : A=?? Y=&FF X=?F
	SED
	clc : adc score : sta score
	txa : adc score+1 : sta score+1
	lda #0 : tay : adc score+2 : sta score+2 ; Y offset for score
	CLD
	lda score+0 : PHA
	lda score+1 : PHA
	lda score+2 : PHA
.*draw_number ; 3 bytes on stack lsB pushed first Y=offset from SCORE_ADDR (may be self modded) : A=?? Y=&FF X=?F ; draws to (dst)
	lda #opcode_LDA_ABS_Y : sta draw_number_sm + sm_op
	PLA : jsr digits
	PLA : jsr digits
	PLA
.digits
	pha : and #&F0 : jsr digit
	pla : asl A : asl A : asl A : asl A
.digit
	beq ok : ldx #opcode_STA_ABS_Y : stx draw_number_sm + sm_op : .ok
	sta lp_sm + sm_lo : ldx #15
.lp_sm
	lda tiles,x : .*draw_number_sm : sta SCORE_ADDR,y : iny : dex : bpl lp_sm
	RTS
}
PRINT "add_scoreAA",P%-add_scoreAA

Originally I had a small player sprite to show the number of lives, which I changed to be a digit as it would be easy to copy from the tiles. I may swap this back, I'll see.

[caspian]

Pengo, Mr. Do and DigDug are 3 of my favourite games (though I've seen a walk-through give kind of a boring but effective strategy for dig-dug)
After I saw a detailed description of Pac-Man enemy AI I looked for similar explanations for them but didn't find it. I've figured out a lot of it for Dig Dug though, here's my observations:
...

Thanks, this was exactly what I was hoping someone would have excavated from the code.

I had assumed that when the reached a junction that they would pick the direction that would head closer to you, like pacman, "measuring" from the first square in each direction. I hadn't noticed that they couldn't reverse unless they had to.

I was wondering about how far into the last tile of a dead end they would go.

Sould 14 be can't not can?

I read somewhere that both you and the fygars can "shoot" through walls.

I had also noticed that slightly odd rules about when dirt is removed and when not. At first I was trying to make the game tile based, but even with 8x8 tiles, the number of combinations required for partially dug tiles is in the several hundred. I suspect that where they have parts of tiles disappearing that it is because they ran out of tile memory! I'm doing it as a bitmap game restoring the background (my first game like this) so it is easier to do what I think they would have liked to have done.

The dead ends are a pain too as it means storing a bitmask or reading the screen to see if the way ahead is clear. Currently I have a two byte mask per tile (16x16) where 8 bits are the horizontal slices remaining and the same for the vertical. I haven't implemented this yet, but the idea is when one becomes 0, clear the middle 6 bits in the other and score the 10 points.

I don't think ghosts can normally reverse in pacman either, at any junction they're only evaluating the non-reverse directions, and they don't have dead-ends in that game (there's other triggers to reverse in pacman though). I just realised that in pacman the ghosts obey different rules from each other. If it's the same in dig dug, that could be why the monsters didn't take the same path towards me. It could still be randomness though.

Yes 14 should be "can't", thanks, fixed.

I've only glanced at the code so far, it will be interesting to see how much it matches what I've worked out from playing the MAME arcade version, which is where my observations are from.

Testing shooting through walls - I can shoot through thin walls but only if I'm close, and my pump only goes slightly past the wall. fygars can only shoot through thin walls, not thick walls, but thin walls don't lessen their range, so they can get me through two thin walls with a tile in between.

I found what looks like the arcade version's tiles and sprites here:
https://www.spriters-resource.com/arcad ... et/125268/
https://www.spriters-resource.com/arcad ... eet/64409/

It looks like there aren't as many 8x8 tiles as you'd expect, and the apparent smoothness of the digging motion is because there's a black area in front of the digging guy that moves smoothly - if you turn around at the wrong point while digging the tunnel has to change length as you leave - something I noticed when trying to make shallow tunnels. The sprite sheet doesn't seem to have the convex dirt corners I've seen in the game, so it may not be complete or reflect the actual implementation. It does seem like it would have to be pretty complicated.

[caspian]

Pengo, Mr. Do and DigDug are 3 of my favourite games (though I've seen a walk-through give kind of a boring but effective strategy for dig-dug)
After I saw a detailed description of Pac-Man enemy AI I looked for similar explanations for them but didn't find it. I've figured out a lot of it for Dig Dug though, here's my observations:
...

Thanks, this was exactly what I was hoping someone would have excavated from the code.

I had assumed that when the reached a junction that they would pick the direction that would head closer to you, like pacman, "measuring" from the first square in each direction. I hadn't noticed that they couldn't reverse unless they had to.

I don't think ghosts can normally reverse in pacman either, at any junction they're only evaluating the non-reverse directions, and they don't have dead-ends in that game (there's other triggers to reverse in pacman though). I just realised that in pacman the ghosts obey different rules from each other. If it's the same in dig dug, that could be why the monsters didn't take the same path towards me. It could still be randomness though.

With further testing it seems like they (dig dug monsters) can sometimes turn backwards at a corner, if I'm following close behind, but they often don't. So I'm not sure about that rule - it doesn't seem 100% right.

[TobyLobster]

the add and draw code total shrinks to 78 bytes and we save more cycles:

Nice. Instead of:

Code: Select all

    lda score+0
    PHA
    lda score+1
    PHA
    lda score+2
    PHA

just do the PHA's as you go in the addition above it:

Code: Select all

.*add_score ; XXAA ; XXAA=bcd add : A=?? Y=&FF X=?F
	SED
	clc
	adc score
	sta score
	PHA
	txa
	adc score+1
	sta score+1
	PHA
	lda #0
	tay
	adc score+2
	sta score+2 ; Y offset for score
	PHA
	CLD