Tazz-Mania

[cardboardguru]

So, I couldn't resist getting started on a game last night. As far as I could see there's no Tazz-Mania for the Beeb. It's not ideal because it's one you really want to play with a joystick, and I don't have one. We'll just have to see if it's at all playable with the keyboard.

So far I've:

1) Drawn a handful of tiles.
2) Written a small utility to convert the spritesheet to a BeebAsm include file.
3) Got Mode 1 working with a 256 pixel width. (Of which I'll use 224 pixels)
4) Wrote a tile plotter. As the tiles are 8x8, and there's no scrolling, this was a simple. And I made it unrolled, so will be fast as can be.
5) Mocked up the screen with simple hardcoded calls to the tile plotter. There's nothing animated or playable there.

Early days, but lots of fun.

[lovebug]

great, keep up the good work

[cardboardguru]

Thanks lovebug. You too with your Lady Bug project.

[cardboardguru]

I'm going to do a developer journal here. In excruciating detail. It helps me think, and other people might find it interesting. Or not. No one has to read it!

Day 2 of development. I've got the first animation in. The hoppers bob up and down (too fast) and the walls close in. It's not much to upload a video of. But I'm intending to upload a video each day I work on it, so I've got to start somewhere.

https://youtu.be/oPgEGkzXA38

Tazz-Mania is one of those early 80s games, like Donkey Kong, that uses a tile map for the majority of the graphics. The Beeb uses pixel addressed screen memory. So I need a separate 32*32 byte table to store tile numbers. So the game knows what's on screen, and can animate.

32x32 is 1KB of memory. And each frame, it needs to be scanned through to see what needs animating. Not just to cycle through the frames, but when the walls come in, they nudge the hoppers away. Scanning 1KB per frame will presumably take a significant amount of the available time, especially if there's any complicated logic in there per tile. So it needs optimising.

Easiest optimisation - only scan the active playfield. Which is at most 28x28. Probably 26x26 given that nothing interesting happens to the tiles other than within the outer walls. So that's down to 676 bytes to scan. Could even be less as the level goes on, and the walls move in.

In assembler, indexed addressing mode, using the X or Y register is good for tables. But as this is a 1024 byte table, that won't work in one go. Indirect indexed is the way to go. e.g. LDA (mapPtr),Y. Use the Y register for 32 bytes at a time. Then add 32 to mapPtr and do the next 32.

Originally I was going to order the tile map like Mode 7. Left to right, and then top to bottom. However, because I have to use the Y register as the quickly changing value in this addressing mode. I changed to storing the map top down first, and then left to right. It makes more sense for me to use the Y register as the Y coordinate, as I use the X & Y registers as parameters to my PrintTile routine.

The downside to this came when I dealt with the right wall nudging the hoppers. They have to be nudged to the left. Which means accessing a tile 32 bytes earlier in the tile map. I'd have to subtract 32 from mapPtr deal with it then add again. Or have a second pointer that also needs to be updated as we go along. It'd be nice to use the Y register to get at it, but you can't do negative offsets.

So in the end, I start with the Y register offset at 128, and the mapPtr 128 less than it should be. That gives the ability to easily look earlier in the map table as well as later. I don't like it much, as it's no longer really the Y coordinate. But that's where it stands at the moment.

[cardboardguru]

Day 2 - It's all in the timing

They say you should never optimise too early. But with a game I want to see whether the approach that I am using is going to be fast enough before I get locked into an approach.

I had sorted the animation out, so that the hoppers are changing their tile once every 4 times round the main loop. And I wondered, am I getting 50fps? Each loop finished within a frame? I set out to time it, using palette changes of the background colour.

At the top of the main loop, I wait for vsync, then set the background colour to black. Then at each vsync interrupt after that, I increment the colour number. So the first frame will show as black. The second as red. The third as green, and so on.

The result is that up to 31 hoppers will be displayed OK at 50fps. But any more than that takes 2 frames. The video shows 255 hoppers. 2 frames.

*** WARNING: CONTAINS RAPID RED FLASHING LIGHT ***
https://youtu.be/nkJ9wjhh1C0

Even to get to that I've done a bit of optimising. For example, on the arcade version the walls move in simultaneously. I've staggered that so the time is spread over 2 frames.

I don't know what the norm is for BBC Micro games. How many get 50fps, and how many are 25fps? Anyone know?

However, looking at the video I've been working from, off YouTube, I now see that it is at 30fps. I don't know if this is just the speed of the video or the underlying game. But that's the timing I've used for animations. And it seems acceptable enough. Maybe I should aim for 25fps. Do the tile updates on one frame, and the sprites on the other. It seems unlikely that I'll be able to do the hoppers AND maybe 5 big sprites and maybe 20 bullets in a single frame.

But even if I do 25fps, I'll have to get the hoppers drawing fast enough to be done in 1 frame. 31 hoppers isn't enough. I counted up on a later level and there was 139 hoppers. Needs a lot more optimisation. Probably a different approach, as I don't think I'll be able to do enough by finding the odd few cycles here or there.

One thing that's on my side is that there's no flickering of the hoppers. They are never erased. When they animate a new image just draws over the old one. And they are too small to show a tear if that happens.

Time for a ponder. Optimise the hoppers more as the next thing, or get some sprite drawing done?

[cardboardguru]

Day 3 - I sorted out my speed problem today.

The issue was I have all these little hoppers as tiles, and they all need to be animated every 4 or 8 frames. What I had been trying to do was to scan all 1024 tiles in one frame, and decide if each one needed animating. Most don't have a hopper in, and even when there is one, it usually doesn't need a the image flipping.

There was he possibility of only visiting some of the tiles each frame. In fact if I only visited a quarter or an eighth of them each time, I could animate the hoppers on every visit, and the timing would be right. But it seemed like that would show up as stripes across the screen where you could see different groups being updated at different times.

The penny dropped with Lovebug's discussion about pseudo random number generators. He was talking about them in terms of a mechanism that would return every number in a given range once, and then repeat the sequence. That' actually just what I need. To visit all the tiles in a random sequence, visiting them all over a number of frames, and then once they are all visited, repeat the sequence. Rather like doing a knights tour, then repeating it.

Well I didn't want to call a PRNG for every visit to a tile. However I didn't really need it to be that random. Just mixed up enough to avoid obvious stripes. It occurred to me that to visit all the locations in an array, what I could do was add a prime number to the index each time, and clamp the index within the array's bounds. Due to the way the numbers worked, I needed a number less than 16. So 13 it is. It works well. And I can make the routine handle any number of tiles in each frame. I could even dynamically change the number to give myself more time on a busy screen. But as it stands I can put 255 hoppers on screen, no problem animating at the proper rate as per arcade, and the game loop is operating at 50Hz. - But of course there's no sprites yet...

No video today because it will look too similar to the last two. I'll tackle the player sprite tomorrow, so there's something new on screen.

[tricky]

In some of my "ports", I have to compare a 32x28 emulated screen with my displayed screen. As most don't change, I unroll it into one loop that checks the four pages in turn with abs,X/Y branching to four separate routines when different that are hard coded for their quarter.
Pacman and Centipede use 28x32 and my new Rally-X use 32x56 tables, but only to check what is at a specific place, not to scan; they use lists (struct of arrays) of things to lookup.
Rally-X has a list of enemy cars, a list of "tiles" that need to be drawn and a list of Flags etc.
If a list is of addresses than can be directly used, they will be in ZP with all data indexed in 2s to allow (ZP),Y:

Code: Select all

.addrs : EQUW &4000, &4000, ...
.nme_x : EQUB 0                ; interleaved enemy car X
.nme_y : EQUB 0, 1,1, 2,2, ... ; interleaved enemy car Y

So, most loops look like: .lp : ... : dey : dey : bpl lp
If the data is too big for ZP (139 sprites), then I would store all values as individual arrays:

Code: Select all

.ad_lo : EQUB &00, &00, ...
.ad_hi : EQUB &40, &40, ...
.nme_x : EQUB 0, 1, ...
.nme_y : EQUB 0, 1, ...

Rally-X still has the "map" of tiles with each byte containing a bit mask for road exits, rock, flag, smoke and Road (may re-use for enemy car):
%RPSFWSEN Road, Pile of rock, Smoke, Flag, West, South, East and North
The Road flag is only used while converting the 1 bit per tile storred map into the tile map and creating the exits' bits of the entries.

I do the same thing as you with storring an offset address for looking up local data in Pac Man, but so far in Rally-X only need to look-up what is in the tile something is just entering. One thing is that if adding Y goes over into a new page, then it costs an extra cycle!

[cardboardguru]

Thanks Tricky.

Yeah, I'd considered having a list of hoppers with X, Y. I'd be ideal to do the animation quickly. But the problem is that I need to do collision detection, and there are a a lot of hoppers, and a lot of player bullets.

I could make more use of abs,X or Y addressing like you say, as I do know where the tile map is.. At the moment all my indexing is (ind),Y, and I'm calculating the base address way too often. I think I've done OK remembering 6502 assembler from 40 years ago, but I'm doubtless only using a small subset of what's possible.

[tricky]

It certainly looks like you are going great guns.
I wasn't suggesting swapping the map for a list, but having both.
The map could hold the index for the "entity" and decode it based on ranges.
It is extra work to keep the two in sync, but probably not worth the effort if you don't need to.

[cardboardguru]

Day 4. Today I wrote my sprite routine.

https://youtu.be/TYUfr-CyQQ0

It's for fixed 16x16 sprites. 4 colour. And it has a resolution of 4 pixels horizontally. I'll double up on sprites to make for 2 pixel movement.

I might actually use the doubling of sprites horizontally as part of the walking animation. See how that works out.

There's no erasing as yet, as you can see. And there's no masking. For the player sprite, that's fine. He never walks in front of anything without dying. And it might make sense to make it self erasing by making a big enough black border around it, once I work out velocity.

There are enemy sprites though that do float in front of the hoppers. They probably need masking. And I might erase by redrawing the tiles behind them.

The video also shows 255 hoppers on the go. Which is more than it'll ever need. Blue background is drawing the hoppers and walls. Yellow is drawing the sprite. Green is unused time at the end of the frame.

[cardboardguru]

Oh my word, I just discovered a massive bug. It caused the strip of wall tiles on the leading edge on each side to be drawn every frame, rather than, as I intended, just when the walls actually advance.

Fixing this has suddenly make things much faster. Same colours as in the last screenshot. I suddenly have much more time to play with at 50fps. All that expanse of green!

[tricky]

Nice
If your timing begins at vsync, then there will be another 2 (or 3, depending on *TV setting) character rows off the bottom before it gets to vsync.

[cardboardguru]

Of course, on the frames where the walls do draw, a lot of time is still taken up. Not as much, given I only have to draw one at a time. But drawing both simultaneously would look better and match the arcade game better.

It's actually drawing a column of tiles right now, where as actually it only needs draw a half tile strip - the walls appear to advance 2 pixels at a time. I may write a specialised draw routine for that. Then I'm only drawing half as much, AND don't need to calculate screen address from X&Y for each tile.

But I'll leave that for a later optimisation when the rest is done, as it does at least work for now.

[cardboardguru]

Day 5 - Who is that masked sprite

https://youtu.be/BtTvUOBbYYE

Today I've got masked sprites working. Plus erasing sprites with either colour 0 or by redrawing the tiles.

Left one is unmasked and erased with black. Right is masked and erased by drawing tiles.

They both disappear about a 3rd of the way down because I'm not chasing the beam as yet.

[cardboardguru]

I took at look at the graphics from the game rom. There's 256 characters. Which would be 4KB of memory.

However, they're split up into 68 8x8 tiles, and 47 16x16 sprites.

For my purposes I'll need the sprites preshifted by 2 pixels. Which means double the sprite storage. And to draw them as masked would mean doubling again. Just for the sprites, not the tiles.

All in all, it would add up to 13KB.
And I'm already using 16KB for screen memory.
And 1KB for the tile map.
That's 30KB. Leaving 2 KB to share between the game and the OS! LOL.

That was a small worry for a moment. Then I thought well, the enemy sprites appear on different levels. So what I could do is generate the preshifts and masks that I need at the start of each level. So I won't need to hold them in memory all the time. And I guess, if it came to it, I could even load the sprites I need for a level from disk. But I'd rather not.

Also, the player sprite frames won't need masks, as I'll always be drawing them on a black background. So there are no masks at all that I need available all the time.

[tricky]

There is a thread around here where RichTW and I talk about auto masks, that is a table of 256 entries were you use the byte that you are going to draw to index the table to get the mask. I't a bit of a pain if you stick to straight 6502, but RichTW has a faster routine that runs in the end of ZP into the bottom of the stack!

[cardboardguru]

I'd be interested n reading that thread if you can locate it.

[cardboardguru]

DAY 6 - Keyboard

Today I did the keyboard handling. To take the fastest option, and the one that will still work if I kick the OS out later, I went for direct hardware access. Pretty simple, I just copied a few lines from here:

http://www.retrosoftware.co.uk/wiki/ind ... are_access

One problem I did have is I tried to go for the BBC keyboard colon key for up. But via this method on the emulator I'm using (b2), the key is not returned. Of course on my Mac keyboard it's not marked as a colon, but a single quote. If in the emulator I press shift-7, which is where single quote is on a BBC micro, then I do get a response for that keycode. But shift-7 is not a practical thing to press for up!

I'm using semicolon for up now, which does work as expected.

I wonder if anyone knows about this and what's best to do?

[lurkio]

One problem I did have is I tried to go for the BBC keyboard colon key for up. But via this method on the emulator I'm using (b2), the key is not returned. Of course on my Mac keyboard it's not marked as a colon, but a single quote. If in the emulator I press shift-7, which is where single quote is on a BBC micro, then I do get a response for that keycode. But shift-7 is not a practical thing to press for up!

In the (probably slightly old) version of b2 I occasionally use on my Mac, the Beeb's colon key is mapped to the Mac's single-quote key:

And BeebEm does the same by default, on Mac (and Windows), I think. So too does JSBeeb -- although we get lots of queries from users of JSBeeb on bbcmicro.co.uk who are confused about where the asterisk key is! (Because Beeb games often refer to the colon/asterisk key simply as "*".)

However, some of those users seem to find that their browser has actually interfered with the default keymapping in JSBeeb, so that the Beeb's colon key really isn't mapped to the single-quote key on their Mac/PC. The keymapping seems to vary from browser to browser -- but I haven't been able to reliably reproduce the problem.

So, all things considered, perhaps it would be best if the Beeb's colon key were avoided? (Although if you use semicolon instead, it might be a bit of a stretch for the fingers if your game also uses the Return key for Jump or Fire or something..! But I don't think it does, does it?)

Better still, why not allow the player to redefine the controls and use whatever keys they like?

[cardboardguru]

Thanks for that. Hmm. Yes it seems no matter how I map it, b2 just returns a keycode of 0 for that key. And several of the other keys, like 1 and 5! And so does BeebEm5.

Odd.

You know I might go for A & Z for up and down, and < > for left and right, if that works. I always found that to be more natural for some reason. But it seemed like a lot of Beeb games do it with left and right on Z & X.

[tricky]

Emulators tend to have a logical / physical mapping option to make keys produce what is written on them vs which key is in that position on the keyboard. Some of them don't account for the PCs OS's key mapping.

I have gone back and forth on the key mapping options for games, with Carnival allowing key remapping and Scramble allowing a choice of sets of keys, but all of my games (except maybe Centipede) have a fixed set when used as a ROM (all of my games can have the main exe loaded to SWRAM or burnt to EPROM and will auto boot if in slot 0 - this is for using as a cartridge in a Master).

The thread about masked sprites is here: http://www.retrosoftware.co.uk/forum/vi ... f=73&t=932 (RetroSoftware is a sister site that has had all the forum size moved to stardot).

[cardboardguru]

Thanks tricky, that's a really interesting thread. Currently I have my sprite routing unrolled. But haven't used any self-modifying code. And I shudder to think about using zero page for code. I haven't learned yet what's safe to use, and what isn't. Or what's involved with kicking the OS out. At the moment I'm using the recommended &70 to &8F for variables. And just started on using the &50-&6F block that I read somewhere (AUM?) is also unused.

User defined keys? Seems like the very last job to do once the game is otherwise done... which probably means it won't get done at all.

[tricky]

...
User defined keys? Seems like the very last job to do once the game is otherwise done... which probably means it won't get done at all.

Yep!

Kicking the OS out is really just redirecting (&204) to your routine and RTIing from it + never calling any code that isn't yours.
Not letting interrupts get to the OS or calling it means it never gets a chance to do anything.

You probably should take control of the NMI handler first, but I have only tried this once and had a bug, so I don't think that I ever do. If you don't, you should probably have an RTI at &D00, but I don't bother with that either now.

NB I am sure I will get caught out by this at some point, but have got away with it for years!

If you do go nuts any use all memory, the OS won't be entirely happy when someone presses break (it can be fixed by power cycling or *FX200 2 CTRL-BREAK).
I have ESCAPE call:

Code: Select all

.reset
{
	LDA #&7F : STA &FE4E : JMP (&FFFC) ; RESET (near enough?)
}

Which disables all the interrupts on the system via and then calls the RESET vector which restarts the OS. One of the first checks is what the state of interrupts are on the system via and does a power on initialization if it finds them all disabled (or something like that).
This gives a clean exit when pressing ESCAPE.

You can leave a few memory locations set to do a *FX200 2 and have break also clean-up, but it isn't quite as clean.

[lurkio]

Thanks for that. Hmm. Yes it seems no matter how I map it, b2 just returns a keycode of 0 for that key. And several of the other keys, like 1 and 5! And so does BeebEm5.

For the record, what model of Mac are you using? And which version of macOS?

[cardboardguru]

For the record, what model of Mac are you using? And which version of macOS?

Macbook Pro. Big Sur (11.0.1).

[cardboardguru]

Day 7 - Stomping Memory

Today, I was fixing up some bugs to do with moving my sprites horizontally. And then I noticed that the sprite that hard been drawing perfectly before now had a chunk missing. Went through the code with a fine tooth comb, and found nothing.

Then I noticed what whenever I added an instruction to my code, I'd lose a bit more of the sprite. And my sprite data is at the end of my code. But what was odd was that my BeebAsm file has a GUARD &3C00 statement, that should tell me if I've fun out of space. My 256 Wide Mode 1 starts at &4000, and I have a 1KB tilemap below that so &3C00.

Looking at the Assembler output I definitely wasn't hitting that. But what I figured out was that any part of the sprite data beyond &3000 didn't draw. What's so special about &3000? I wondered if there was some issue with shadow RAM or sideways RAM. Being that my 1980s Beeb was a Model B, I never had those things and didn't know how they worked. No it wasn't that.

Finally I realised that &3000 is where a full Mode 1 starts. And though I'm using a modified Mode 1, my code asks the OS to switch to Mode1, and then changes only the 6845 and ULA values that I need to narrow it to 256 pixels. What I hadn't thought about is that after my code is loaded, when I change to Mode 1. The OS clears the screen, and takes have my sprites with it.

Several hours to work that one out. Hopefully I won't make that mistake ever again. It's all a learning experience.

In the process I typed up all the mode parameters from the AUM so it was easier to compare them and create new modes. Here it is in case anyone wants a copy.

BBC Micro Screen Modes 6845 and ULA.xlsx

(8.29 KiB) Downloaded 38 times

[cardboardguru]

Day 7 - Stomping Memory

Today, I was fixing up some bugs to do with moving my sprites horizontally. And then I noticed that the sprite that hard been drawing perfectly before now had a chunk missing. Went through the code with a fine tooth comb, and found nothing.

Then I noticed what whenever I added an instruction to my code, I'd lose a bit more of the sprite. And my sprite data is at the end of my code. But what was odd was that my BeebAsm file has a GUARD &3C00 statement, that should tell me if I've fun out of space. My 256 Wide Mode 1 starts at &4000, and I have a 1KB tilemap below that so &3C00.

Looking at the Assembler output I definitely wasn't hitting that. But what I figured out was that any part of the sprite data beyond &3000 didn't draw. What's so special about &3000? I wondered if there was some issue with shadow RAM or sideways RAM. Being that my 1980s Beeb was a Model B, I never had those things and didn't know how they worked. No it wasn't that.

Finally I realised that &3000 is where a full Mode 1 starts. And though I'm using a modified Mode 1, my code asks the OS to switch to Mode1, and then changes only the 6845 and ULA values that I need to narrow it to 256 pixels. What I hadn't thought about is that after my code is loaded, when I change to Mode 1. The OS clears the screen, and takes have my sprites with it.

So my solution is to switch to Mode 5, a 10KB mode, and then program CRTC and ULA with the differences from that. I suppose I could not change mode at all, and program the differences from that. I guess it's all the same.

Several hours to work that one out. Hopefully I won't make that mistake ever again. It's all a learning experience.

In the process I typed up all the mode parameters from the AUM so it was easier to compare them and create new modes. Here it is in case anyone wants a copy.

BBC Micro Screen Modes 6845 and ULA.png
BBC Micro Screen Modes 6845 and ULA.xlsx

[tricky]

Kieran did a nice 6845 explorer that would be a good companion to that.
I think the link was in his ABUG video, but it's probably on the bitshifters github - will look later when on PC.

[cardboardguru]

Kieran did a nice 6845 explorer that would be a good companion to that.
I think the link was in his ABUG video, but it's probably on the bitshifters github - will look later when on PC.

Yes, I watched Kieran's brilliant talk before starting on Tazz. And played with his explorer program. It's what gave me the confidence to code the new screen mode right at the start.

[cardboardguru]

Day 8 - State of Play

A very productive day. And for a change I didn't hit any problems.

I implemented autosprites as per Tricky's suggestion. One of the things that was holding me back from that was that that some of the enemy sprites in the arcade version have a lot of black in the part of the sprite that should be solid. But I decided to take some artistic license and reduce the amount of black used. It makes for a better sprite anyway.

I didn't stick the code in zp/stack though. That's one to leave for the future, if needed.

I also implemented a game state machine. And a tick counter.And used them to orchestrate the events that happen at the start of a level.

And I reduced the amount of pure red on screen by dithering the bricks. It's actually made them look more textured like bricks on an emulator. But I imagine the colours will merge a bit more to make a lighter red on an actual Beeb and Cub monitor.

It's beginning to look like the start of a game.

https://youtu.be/my5H82xLaoc