Tazz-Mania

[cardboardguru]

@0xC0DE: Wow! OK. You really did mean trample all over everything from 0 upwards. Sorry if it seems like I'm being a bit slow on this, but this is all a bit radical for me. I've never ventured below &E00 before, apart from the recommended &70-8F in ZP.

At the moment, yes, I really have stopped using MOS for anything. But no I haven't looked at sound yet. I'll take a look at that before I commit myself!

@Tricky, thanks for the code example. That'll help. More of that self modifying stuff I see. I'll have to get into that when I try and speed up my sprites. I probably don't need to go as far as compressing this game. I need a bit more space for some sprite images, but it's not like I have level maps to store.

Did a bit more messing about with the title screen. But can't decide if I've just made it worse...

[0xC0DE]

@0xC0DE: Wow! OK. You really did mean trample all over everything from 0 upwards. Sorry if it seems like I'm being a bit slow on this, but this is all a bit radical for me. I've never ventured below &E00 before, apart from the recommended &70-8F in ZP.

Don't apologize. We all learn from "those who went before" Mainly from the OG 8bit heroes from the 80s...

Did a bit more messing about with the title screen. But can't decide if I've just made it worse...

I think it's looking better!

[tricky]

I like both images, but the second one seems a little more beeb-like and slightly more childish (but in a good way - like POD).

I don't even leave the addresses that 0xCODE leaves, but I would recommend doing as 0xCODE does if it is not inconvenient.

I didn't use the compression until Astro Blaster I think and once I had added it, it is just one extra line in my build .bat and one in the ROM header that I also build into all my games. It basically just replaces the loop I posted with INCLUDE "..\tools\beebop.asm" (71 bytes).

The relocation could just use a pair of ZP words and (),y, incrementing the high bytes instead of self modding, I just tend to use the self modding for code that will only run once as it is smaller and (),y for reused code.

[lurkio]

Did a bit more messing about with the title screen.

It looks great!

[lovebug]

taz-mania is coming along great, wonderful work dude

[Arcadian]

Title screen looks fab, gameplay is looking really good now too - I'm going to have to hurriedly familiarise myself with the game on MAME as your version doesn't seem far off now at all!

[cardboardguru]

Thanks all. Don't hurry Dave, software development follows the Pareto Principle.

[cardboardguru]

That feeling when you have random crashes and corruption of memory. You can't even work out what part of the program is responsible. And you've left it way too long since last committing a version to source control.

Time to take a copy of the code I have, then revert back to a version that I'm sure is stable. Then put the changes back in one by one and test. Bah.

[cardboardguru]

Day... 20ish?

I've had a week or so off. Random crashes were frustrating me. I'm not sure if I've fixed the problem or not, but it's not happening right now. I worked on another project instead for a few days.

This version has the title screen loader, and relocates the main program down to &E00.

I've also added in the cut scene between levels, with Tazz having a walk animation.

https://youtu.be/lT26J1kEjWo

[tricky]

That's looking great.
I never have room for that sort of thing as I have squandered it all on the "tricky" bits

[cardboardguru]

I'm not surprised you have no space left with the super scrolling mega fests you do!

[tricky]

Sometimes the trade-off isn't worth it, but that doesn't stop me!
If I had allowed a couple of scan lines of flicker when Pacman and all the ghosts were on the top of bottom row, I could probably have saved over 1/2 KB.

[cardboardguru]

Day 21 & 22 - Animation & scores

I haven't done an update for a while. Progress has really slowed up, as other projects currently seem more shiny and exciting. But I've done a couple of days more work on this.

First off is I've implemented animation for the player. In doing so, I've gone back to arcade authentic gameplay. You either move your player, or you shoot. But not both. If you are shooting, your player stays still.

This does make the game really hard to control on the keyboard though... it's a mechanic designed with an 8 way joystick in mind. Maybe I'll make it a player option. Allow the easier and more enjoyable shoot and move mode. If I do that, I'll make the high-score table show which mode the score was achieved with.

I've also added scoring. In the arcade version, the score is 6 digits with leading spaces. And the last digit is always zero. I've implemented this as 3 bytes of Binary Coded Decimal, which is just as easy for adding scores, but makes print out easier.

As the last digit is always zero, I actually store the score/10. And only print the last zero at the start of a level. Additionally, to spread out the work of printing the score, I only print one digit of the score per frame. And only that if the score has actually changed.

No picture this time, as animation and increasing scores need a video to show.
https://youtu.be/Pwf5hDipWtc

[tricky]

If it wasn't for a bit of flicker on the player, I would have assumed that it was the arcade game - honestly!
Is it autofire?
If not, the move or fire on keyboard could have autofire to make it a little fairer.
Are you planning dual joystick support?
This would maybe work better on an emulator using a modern game pad, but still possible on a beeb.

[cardboardguru]

Thanks. Yes, I'll come back to the flicker on the player at some point. Can't ship it like that! At the moment the screen is split in two for drawing, and there's a problem with overlaps. A week or two ago you made mention to lovebug that you'd done a game where you split the screen into 4 sections, and staggered the various erases and draws over them. I think something like that will solve my flicker problem.

It keeps shooting as long as you keep your finger on the fire button. Same as the arcade version.

Dual joystick? No, it was only ever a single joystick and fire button game. It's not like robotron or smashTV where you have two joysticks.

I don't have a joystick or gamepad for the beeb or my laptop. I could buy one, but I like the idea of it being playable by anyone from keyboard, without being at a huge disadvantage to joystick users.

I think I like it how I had it before, where there was no fire button. Where you shoot all the time, and can move whenever you like.

But the problem is what to do about the sprite animations. At the moment there are 18 different images for Tazz, which with pre-shifts for X movement actually doubles up to 36. There's different images for all 8 directions for shooting. And then when running, there's 4 directions, but each direction has multiple frames for the running animation. It all adds up.

The problem is running plus shooting at the same time: If I did an animated for running plus all 8 directions of shooting set of images, I'd think I'd need (6*4+2*3)*2 images = 60 images!

Potentially I could reduce the space needed by plotting 2 sprites for the player. One containing the upper torso, arms and gun, and the other the legs. But I'm trying to reduce time spent drawing sprites not increase it!

One to ponder on. I can work on other things meanwhile...

[tricky]

I was thinking about moving at half speed when shooting, but it doesn't solve the animation frames issue as you couldn't swap every frame.
What do you think about one cycle of walk anim, then shoot a few bullets, then walk again?
Sorry, I thought that Taz was twin stick, I wasn't suggesting additional features

[cardboardguru]

The first YouTube video I was working from confused me, as it has the shoot and move at the same time behaviour. It doesn't animate the walk at all. Not sure how that video came about. Either it's a mame cheat, or they've played it with an autofire gamepad, and that's the effect it has. Probably a cheat.
https://www.youtube.com/watch?v=x8ho_HOkloI&t=251s

This video shows authentic arcade behaviour.
https://youtu.be/oCVf-FJ9t6I?t=81

I might just do the equivalent of video 1, and do without the running animation all together apart from in cut scenes. Won't look as good, but it works.

What do you think about one cycle of walk anim, then shoot a few bullets, then walk again?

It might work. I'm loathe to cut down on the bullet rate. But maybe do what you suggest for animation, and keep on fire all the time anyway? Will have to try it to see if it looks ridiculous.

[cardboardguru]

Looks like the rare crash might have been an NMI after all.

Looking at the debugging in b2, it is stuck in an infinite loop in the DFS.

Code: Select all

.loop
LDA &A2
BMI loop

The DFS is 2.26, which I can't find a commented disassembly for. But it seems &A2 is in the zp NMI workspace area. So it does seem highly likely it's to do with NMI!

People have said that &D00 is the NMI interrupt routine, and I need to put an NMI there, which I hadn't got round to. To be honest I couldn't imagine why there would be an NMI happening completely at random. Especially not a DFS one, as I've switched to TAPE. Anyway it turns out there was a PHP there, so clearly that is the start of the existing NMI routine. So now I've put an RTI there. See if it solves the problem.

[cardboardguru]

Nope, wasn't that. Still crashes.

[cardboardguru]

Well, a couple of years on, and the lack of any updates makes it pretty clear this project fell by the wayside. There were a number of things that just made me start to dislike the project, and it wasn't fun anymore.

1) In the arcade the controls were an 8 directional joystick and a fire button. Turns out that using buttons on a keyboard, you can technically reproduce that. But actually producing the rapidly changing 8 directions with 4 direction keys and also needing to use the fire button wasn't that much fun.

2) I'd forgotten just how little processing power the Beeb has. I tried to reproduce the game very closely, including masked sprites and many objects being animated. And it was just a bit too much. Downgrading the graphics on what I'd already produced wasn't fun either.

3) I had a nasty intermittent bug, one that would allow the game to play for a couple of minutes, then crash. Sometimes with a small part of the screen corrupted, sometimes not. I followed a few hunches on what it might be, but never got to the bottom of it. Definately not fun.

4) The Mac I was developing on died. Whilst I did have backups, I was working with a PC for six months or so, and switching development environment and making new build scripts and so on was the final hurdle. I didn't do any more.

On the positive side it was a learning experience, part refreshing stuff I'd learned 40 years ago, and learning new stuff. And I've now started on a new project

[fizgog]

A shame as I was looking forward to this and also enjoyed reading your development blog.

If you don’t already, then I recommend using GitHub to store your projects in and then you can link from VisualCode either from a Mac or Windows machine, it’s saved my bacon a few times whilst I’ve been developing 6502 stuff.

Good luck on the new project