Game # 7 : Frogger

Busy today, so just done the background for Frogger. This is probably most of the work though. It already scrolls, though just one way one speed as a bodge, at about 20 frames per second which is plenty. (Later: ESP32 it's more like 11-12 so that's something I'll have to work towards)

A couple of notes. Firstly, in real Frogger the top half, the river, is blue not black (it's near a chemical plant in this game). The system is perfectly capable of this, but at present the lanes are actually a 1 character high tilemap, there's 10 of them. This works quite well but the tilemap implementation currently has the problem that it can only do one background colour for a tilemap. I designed it that way. I might extend it to allow a different colour background but it isn't done this way. I could just write a routine to blit it out, but that would be cheating really. I'm trying to do as much as possible in straightforward BASIC. Just because.

Second point is the sprites are all monochrome. This is a limitation of the current sprite system, but I will probably extend it to do multi colour sprites at some time. The downside is because the blitter only blits one colour at a time, two colours requires twice as many blits.

I'll probably use the same trick for Space Invaders - the invaders will be a tilemap, so I can just scroll it or update it with one command.

A hack

I've added a Turbo mode to the emulator. Not for running the actual game ; that is still limited to the reference implementations approximate 0.95 MIPS. It's for testing ; if I have code that spends a while setting up, it means it just skips that bit more quickly, and on non Windows/Linux emulation or slow hardware, it doesn't matter.

Nitwit bug of the week.

I've got a 6 digit score .... and it uses 16 bit integers .....

Pacman working and 0.68

So Pacman is working ; though I think I've set the default speed a bit slow. This isn't because it can't go faster, it's just an arbitrary choice.

Definitely will fix that because I've just realised I forgot to decrement the life counter when you lose a life. Which makes it a bit easy.

I'll fix that for the next upload though.

This is version 0.68. One bug fix ; there was a gap between sounds in the queue which threw timing and the sound effects out. I've also add min() max() and quiet() to the keywords.

Pacman mostly working

It now far more resembles the finished product. In actual game elements, you can play it .... there just are no collisions so it's not particularly challenging. There's no sound either, or the bonus. But you can play most of it.

Shopping day today - treat of the week ! So not done a huge amount today.

Bug fixed.

Line editing now works properly. The kernel code which worked out where the line started and ended was a disaster. I'm amazed it ever worked at all :) However v0.67 now works.

Pacman under way but ...

Found a bug. Well, a couple of bugs, one silly, one not. The silly one was an error in the tile command, but the not silly one is to do with editing long lines of code, which has stopped working. It's generating a syntactic error.

So I'll have to fix that one before continuing with Pacman which is fairly advanced. Most of the plumbing is there, there's just the movement of the game objects, scoring, sound effects and bonus left to do. Which isn't too much. (the top line isn't an error, I ran it and broke it, so it's printed "break error" on the top line

More ideas.

While lounging in the bath this morning I remembered this language I'd found a while back ; it was called RPL, and it was for the Commodore PET. It was very similar to FORTH ; same basic idea, different syntax. It used the tokenising system as a sort of virtual machine code. Problem was the 6502 is great at one thing, being cheap, and not very good at many other things, so it was a bit limited.

Had the idea of doing a similar sort of thing here. I was going to do FORTH anyway, but I thought if I used an inlined FORTH I could take advantage of some of the things already there - for example variables and have a fixed dictionary. Then you could add quasi-FORTH using this sort of syntax

new.word = RPL(40 2 + dup . . )

So RPL would be a unary function that returned it's call address. Dup and + could either be in a fixed dictionary, or variables themselves. You could have immediate variables and so on as well. Implicit semicolon at the end. Once you've defined it you can just call it with sys new.word and it already knows about the variables. Arrays wouldn't work, but indirection would be fine a la structures in BCPL.

Now, to fix actual variables - there is a problem if you have a word in FORTH it 'knows' what it is. This doesn't. So the idea is something like - a variable compiles its address , so you could write

another.word = RPL(new.word new.word)

Variables would track the reference of the last compiled address, and use two operates to back patch. These couldn't be @ ! so I have used @@ and !! in the past e.g.

another.word = RPL(count @@)

would initially compile jsr #<whatever value count is> but in this case it would back patch and replace that with push r0 ; ldm r0,#<address of count>

I will give it more consideration.

Game #4/5 - Dodge ' Em

So this is game 4/5, modelled on Atari's VCS chasing game. It's actually a complete rewrite from the ground up, I wasn't happy with the first one. What I find with this sort of thing is you get a feel as you go.

So the next games are planned to be Frogger, Pacman and Space Invaders.

Now BASIC has its limitations, and the main one is being interpreted. In this you can write code in Assembler but that's quite heavy

Game #3 ... sort of ... Maze

It's not really a game. I did think about making it into a 2D or 3D chase game, but it's just a maze generator at the moment. I do plan to do "Sword of Fargoal" , the old Commodore game (partly because I've already reverse engineered it so I know how it works).

It's a hunt and kill algorithm. What I really wanted to do was bully the core a bit - things like the loops, local variables, arrays and so on to see how it coped.

Fairly well (the code is here). It's a 20x20 maze, and hunts maybe 20 times , and it takes about 13 seconds.

More to the point, it seems fairly reliable, doesn't crash, and ports okay. I've been tinkering a bit today, I found for some reason it built on Raspian before but it doesn't now, so I've changed things so that all the python xxx are python3 xxxx (python 2.7 doesn't work) and changed the screen layout so it fits on the screen.

As always, if you do run the javascript one, reload it, otherwise it might grab it from the cache.