Possible new DigDug version for the BBC Micro

[tricky]

I did wonder about pookas and fygars having different "AI" but haven't played the game enough to be able to test it easily.

The arcade machine has three z80s (at least one is probably sound) but as I haven't looked at z80 since the 70s, I don't think I would get on very well, but maybe some debugging in MAME might help.

Those sprite sheets suggest that maybe it does have a bitmapped screen, I will try to remember to check in MAME.

Here is my tile sheet before reversing the byte order of the digits, which I thought I had posted, but can't find!

tiles.png (2.05 KiB) Viewed 3414 times

The tunnel sections are used in 4x4 blocks to reduce duplication. Blue is colour 3, so they are ANDed with the screen after the backgrounds have been restored, but before the new ones are captured and sprites drawn. This means checking in the four parts of the code that deal with the four rows of the screen, roughly matching the dirt colours. The restore, store and draw ranges are offset for each stage to prevent one operation interfering with the next when being applied to the next quarter.

I will probably have to do something similar for the "hose" as there isn't enough time to use sprites for it.
Maybe I could EOR after drawing the sprites but that would look ugly! Maybe an invisible hose as it wouldn't affect gameplay. I could use a small sprite to show where the end of the hose is!

[caspian]

I've been looking at the 7800 code.
It looks like there are 3 types of monsters that have different behaviour according to the table MODETAB:
DIGVERT prefers following you in vertical direction, DIGHORIZ in horizontal direction, and DIGDIAG in whichever of the two is the greater part of the distance to the target.
The target can be you (normally) or a point around the top left (I guess when the last monster is aiming there).
It may not be pooka vs fygar though, since it seems to be defined in a separate table.

[tricky]

It makes sense that it would be a little like pacman, but I wonder how close the 7800 code is to the arcade. Did they have access to the arcade source, developer or just an arcade cab in the corner!

[cardboardguru]

An arcade cab in the corner?! Luxury. I reckon most 1980s game porters had to visit the arcade with a pocket full of 10p pieces to check the behaviour of the original!

[tricky]

An arcade cab in the corner?! ...

I was allowing them a luxury as they may have been an internal team.

[caspian]

In the 7800 version the non-ghost monsters are generally blocked from reversing unless they have to. I reckon maybe what happens is they sometimes turn into a ghost for a moment, but aren't in a wall, so they don't stay a ghost.

There's a counter for turning into a ghost, it sometimes gets incremented by various amounts on a monster's turn and that monster becomes a ghost if it overflows. The incrementing is triggered by certain surroundings in the for surrounding tiles in the maze, when the monster is tile-aligned and deciding where to move next. Going through a straight tunnel doesn't trigger it, hitting a dead end or going around a corner does. Fully open surroundings don't trigger it. I'm not sure how T-junctions are handled, or the sky and walls.

When the increment is triggered, it's incremented by several different amounts, and on any overflow it stops incrementing for that monster's move breaks it off the increment sequence and turns the monster into a ghost. One thing I noticed is it increments more when Dig Dug is stopped. In the arcade version it makes a horrible noise then, maybe warning about it.

[tricky]

That's more great detective work
I'm going to get the tunneling affecting the dirt maps next so that the monsters will know where they can and can't go and then come back to the decision making logic later.
Adding various amounts to the monsters frustration level for different events sounds sensible, as does adding small amounts just because the player is taking a little break out setting up a rock ambush!

[lovebug]

great work tricky , well done

[tricky]

Thanks lovebug.
This evening I have added the code to update the two tables that hold which bits of the soil have been dug.
Each tile (16x16) has two bytes, one representing horizontal soil and one vertical.
Each bit represents one of the eight sections that can be excavated in each direction.
As you can dig a bit from one side and then go around and dig a bit from the other side this seemed like the easiest way!
So once you have completely dug from one edge to the opposite however you did it, you score 10 points and I clear the middle 6 bits in the other direction. You only score it for the first pass through a tile (I think) so I check the byte for the other direction and if it is already 0, you don't score.
Looking in the debugger, it seems to be working, but also the scoring would be wrong if it wasn't working.
Saying that, I'm sure I saw it score two 10s in quick succession, so I probably have an off by 1 or something to look into.

3184 bytes free

PS I'm sure that I have explained the dirt before, but couldn't find it!

[lovebug]

clever idea, I like it

[Arcadian]

Beautiful!

We were actually talking about your DigDug port on the ABug meeting when you posted the new version!

[MillieTD83]

Only version I've played of DigDug is the one that comes in Return of Arcade for Windows. Pretty much a conversion of the arcade one so should behave the same. Just firing it up to have a quick play.

[tricky]

Hi Millie, I think most of those are emulators, so should be good.

I've been out today, birthday trip for the Mrs, so not much progress.

I've added a basic animation system but no AI to choose what to do next.
I realised that I need at least another frame of animation for the Phygars going vertically, I was going to make them fly, but should probably sheck what should be done!
I don't know what is leaving a copy of the sprites in their starting positions, they shouldn't even be drawn there once!

3056 bytes left

PS Startup timing is still wrong, so you can get flicker or missing bits!

[tricky]

I spent nearly all the time I had today debugging a stupid bug, not restoring the Accumulator after handling an interrupt.
The code was there but I replaced it trying to debug another interrupt issue which as usual RichTW had already come accross and Ed had also beeb involved - reading T1 low on the cycle that it was supposed to trigger an interrupt - it is just crazy to acc the int - well, that's my excuse!

I've added showing the levels by skipping whilst the RETURN key is held down.
It isn't doing it cleanly, so there is a bit of screen corruption, but it gives an idea of the levels I have put in and the way that the monsters currently speed up. It wraps at level 256.

2861 bytes free

OK, I seem to have broken the movement and still not fixed the timing but you can see the levels and monster speed progression!

[tricky]

Took about 1 second to spot my last (hopefully) bug this morning.
Fixed the timing, there should be no flicker!
Tidied next level, there should be no screen corruption.
tidied the rock drawing, although I'm still not 100% happy with it as it is currently about 16 bytes bigger than the old code.

2849 bytes free

Hopefully someone finds my ramblings interesting as well as the insight into the way my brain works; the agonising over spending 16 byte to make the code work and the hour spent trying to do it the old way without spending memory!

[BigEd]

Certainly is very interesting to follow along with the incremental progress!

[tricky]

Thanks Ed

Only another short blast tonight, apparently the lawn needed mowing!
Added the flowers to count the levels but at the side as I realised it would be a pain to stop your character from digging through them!
Holding RETURN should skip through the levels.
The ROUND counts up to 9999, the flowers 500+ before interfering with the bonus icons that I am planning on displaying on the left (like I did with PacMan) as they are collected. The game loops at level 256, so everything slows back down.

2692 bytes free

So, is that a good use of 147 bytes - probably not, but I can reuse some of the code for drawing the fruit.

[tricky]

Ill again, miniscule update, just added the other basic anims

2669 bytes free

[tricky]

Spent most of the morning fixing bugs that I wrote when not feeling well.
About one in every four instructions in the monster movement code and data was wrong!
Monsters will now carry on when there is only one alternative and reverse if they get to a dead end.
The will follow you tunnel, but you will have to go around corners both ways to clear the right bits - more work to do there!
If they come to what the they is a choice, the demo will stop - the decision is too hard (or I have just put a BRK there!).
My lovely, make a bit mask of available exists that was 16 bytes is now more like 66 because I forgot that they need to go into tiles that are empty apart from the far wall! I daren't look how long it takes, but fortunately, it on average it is needed by less than one monster per frame.

2529 bytes free

[tricky]

The monsters will now try to chase you, but only look for a new direction at a T junction or cross roads.
If they got to the top level of the map, they get very confused and just bob up and down into the scores!
So, at least one bug still in the monster movement, but I think I have all of the maze tunneling updating the correct parts of the maps and the movement checking the right bit, but probably not!
Loads more code and only a few bytes wasted that can be reclaimed once it works.

2368 bytes free

[caspian]

The monsters will now try to chase you, but only look for a new direction at a T junction or cross roads.
If they got to the top level of the map, they get very confused and just bob up and down into the scores!
So, at least one bug still in the monster movement, but I think I have all of the maze tunneling updating the correct parts of the maps and the movement checking the right bit, but probably not!
Loads more code and only a few bytes wasted that can be reclaimed once it works.

2368 bytes free

Cool!
A couple more monster movement bugs I noticed:
At a T-junction or cross roads, they don't avoid reversing direction.

And for some reason the monster in the screenshot reversed as it came to a corner instead of following the corner around so it would get me - maybe something special about being on the bottom row?

The monsters going confused when they hit the top of the screen reminds me of Repton 2 - I think in that case the issue was arithmetic overflow, so if they were on row -1, and you were below them at row 4, they'd compare 255 (representing -1) vs 4 and assume they had to keep going up. Something like that.

[tricky]

If they are getting confused about following a tunnel, I haven't got the maze updating correctly

I didn't remember the no reversing at junctions, but that is easy to add as I have a bit mask of valid directions and the direction they were going to get here, so should be just a few instructions to clear the reversing bit.

I think I'm going to have to do some more work on the debugger, even though I have already added about four features in the last week.

[caspian]

If they are getting confused about following a tunnel, I haven't got the maze updating correctly

I didn't remember the no reversing at junctions, but that is easy to add as I have a bit mask of valid directions and the direction they were going to get here, so should be just a few instructions to clear the reversing bit.

I think I'm going to have to do some more work on the debugger, even though I have already added about four features in the last week.

I've noticed quite a lot of situations where they won't follow me into a tunnel, and will just turn around instead. A couple more attached.

One where all the monsters have followed me close but then keep going back and forward in a nearby tunnel.

The other where there's a monster above me that followed me down into the tunnel after I'd done a certain amount of digging and/or reversing, but then when I moved into the position in the screenshot it wouldn't follow me in anymore. The second one was weird, because it seems like I had cleared enough dirt that the monster was able to come in, there was just something about my position that made it not try.

I did wonder if when my X position is not to the left of the monster, it assumes it is to the right, when in fact it could be at the same X. That could explain some of what I've seen, but not all of it - as I said, sometimes the monster will follow me down a tunnel.

[tricky]

Positions are calculated by subtracting one from the other and then dividing by 2 before looking up the square of the distance to add together to give distance squared. The div 2 is just to make the table smaller but in doing the subtract, it doesn't seem the carry, with the effect that where you are affected the rounding.
To decide which way to go, it offsets the lookups for X or y by 1 to see which direction would be getting closer. I'm sure that this could be done with less code, but is was how PAC man worked!
I'm doing to add dynamic memory visualisation in the debugger so that I can watch the digging code dig through the dirt tables.

If run at 5x speed, you can clear all the dirt both horizontally and vertically and they can then move freely off you want to check their hunt code.

[fizgog]

I'm doing to add dynamic memory visualisation in the debugger so that I can watch the digging code dig through the dirt tables.

Ooh how are you going to be doing this as I’m going to want to watch my missile and alien tables when I code the collision

Do you have a custom debugger or is it just some sort of setup on a particular emulator?

[tricky]

I usually as features to my old beebem as I find it the quickest to change. But sometimes add stuff to b-em.
I might even take beebjit and as a debugger to that as it does seem to be the best emulator but I really don't like platform independent library.

[fizgog]

Thanks for the info, I’ll probably run it through Mames debugger and that seems to be the best AFAIK

[tricky]

Mame still needs some work on the 6845, but if you are using a standard-ish mode, you should be fine.
I tried adding the debug window to beebjit, bt for some reason it wouldn't respond, so I went back to old faithful
I've only just tried enough to see that it will work so there is no control other than typing in the address in the top left and moving the window around etc.
The code is just copy and paste from the ImGui github and then I added the code below to a page transposed from the usual view as my rows and columns are swapped. As it stands, the dynamic memory watch window will run at about 5,000 FPS without a Sleep.

Code: Select all

		static unsigned short addr = 0x2E00;
		volatile unsigned char * mem = WholeRam + addr;
		ImGui::Begin("mt &%04X");
		ImGui::SetCursorPosX(4);
		ImGui::SetNextItemWidth(35);
		ImGui::InputScalar("00", ImGuiDataType_U16, &addr, nullptr, nullptr, "%04X", ImGuiInputTextFlags_CharsHexadecimal | ImGuiInputTextFlags_NoHorizontalScroll | ImGuiInputTextFlags_AlwaysOverwrite);
		ImGui::SameLine();
		ImGui::Text("10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0 0123456789ABCDEF");
		for (int l = 0; l < 16; ++l, ++mem)
		{
			ImGui::Text("%04X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", addr+l, mem[0], mem[0x10], mem[0x20], mem[0x30], mem[0x40], mem[0x50], mem[0x60], mem[0x70], mem[0x80], mem[0x90], mem[0xA0], mem[0xB0], mem[0xC0], mem[0xD0], mem[0xE0], mem[0xF], mem[0], mem[0x10], mem[0x20], mem[0x30], mem[0x40], mem[0x50], mem[0x60], mem[0x70], mem[0x80], mem[0x90], mem[0xA0], mem[0xB0], mem[0xC0], mem[0xD0], mem[0xE0], mem[0xF]);
		}
		ImGui::End();

If you don't know ImGui, it is a GUI library for windows, linux and mac with different choices of rendering API where available.
It is an immediate mode GUI, meaning that you have to add the things you want every frame, so it can feel a little alien.

[Pernod]

Mame still needs some work on the 6845, ...

Thanks for the reminder

[tricky]

Maybe the CPC guys will do it