New version of Scramble for the beeb Finished

[jbnbeeb]

I've been thinking about difficulty and apart from the arcade difficulties that I know of:
- max 1 or 3 rockets flying at the same time.
- fuel draining slow or fast (4 or 6 for me).
I was thinking of adding:
- extra flying saucers: 4..6
- extra meteors: 4..6

I'm trying to think what would make a good difficulty ramp.
Which order should things be increased and how many should be increased per loop?

If the difficulty didn't change during the game, it could just be easy:1,4,4,4 medium:2,5,5,5 hard:3,6,6,6 but I want it to increase per loop.
I know this is bad game design, but with limited memory, it has to be something fairly small to implement.

When you say per loop .. you mean increase difficulty after getting through all levels? That'd be fine I reckon. After your easy/medium/hard, you could then have even quicker fuel drain or fewer FUEL containers (or both to be really cruel )

[Rich Talbot-Watkins]

This looks absolutely superb! I'm astonished with how much you're managing to pack into a 20ms frame! I think, technically, this must be your best work yet. Can't wait to give it a go when it's finished (although I already predict that I'm going to be terrible at it - Rocket Raid used to give me enough trouble as a 13 year old).

[simonm]

Agree with Rich. This is crazy good for a beeb. Amazing work tricky. Would love to see a 'how it works' type blog if you ever feel so inclined.

[Rich Talbot-Watkins]

+1000 to that!

[tricky]

I will try and write it up, but it won't be as good as pop.

For now:

The scrolling is similar to what I described in the smb thread.

I was asked about collision detection, and here is what I said.

For scramble, I check the character address of the shot/bomb against the character addresses of the rockets, fuel and mysteries (other wise the shot can go right as a visible pixel goes left and "misses". I do this by checking if the char ROW (high byte LSR) matches the shot for either rows and then the X (low byte ROR to include the lsb of high byte).
I then check the shot / bomb-tip for being over black and early out if so.
For the saucers, I do a bounding box check in pixels.
If nothing hit, but also not black, we hit land and remove the shot / bomb.
I have to remove (EOR) the player ship, shots and bombs before checking so as not to bomb yourself or shoot your own bombs!

In centipede, I have a character map of where the mushrooms are/what their destruction frame is and the BB for the centipede, char check for the fle and ROW/BB for the scorpion.

I Carnival, I use the hight of the shot when it is not over black to decide which thing to check.

In AstroBlaster, I check for not black and then pick then approx BB the alien. For the aliens shooting the player I have a monochrome low res copy of the ship that I do a bitwise comparrison as bombs are two pixels wide and your ship moves two pixels at a time.

For Space Invader, I use the colour of what I have hit to decide what it was and then go from there.

I generally don't like bounding box checks, but sometimes I can't be bothered to write the code for pixel perfect collision and sometimes pixel perfect would allow you to shoot through a moving object or gaps in the target that are only there to make it look nice.

[tricky]

I had also forgotten about the sound.
During play, the three tone channels are used for the engine noise (womwom), the bomb (descending) and shouting (dumdum) while noise is used for explosions, so can also be used for whistling when not exploding.

[Rich Talbot-Watkins]

The scrolling is similar to what I described in the smb thread.

In SMB weren't you plotting every non-blank tile every frame? Surely there's too many in MODE 1 to be able to do that with such a great frame rate? Do you just render edges instead? (Presumably with four versions of each tile for each pixel offset).

[tricky]

Spot on Rich

[kieranhj]

Hey Tricky, am I right in thinking (based on a half-remembered conversation at a previous ABUG maybe) that you're not just storing four shifted versions of all the tiles but also computing all combinations of tiles that are next to each other and essentially shifting them together? (Since we're only scrolling in a single direction and the landscape doesn't change.)

So in effect most of the tile blocks will end up something like:

• a leading edge (e.g. diagonal) shifting into an empty space
• a full tile shifting into a leading edge
• a trailing edge shifting into full tile
• an empty space shifting into a trailing edge

And then only updating the tile pairs that have changed, which in effect is just the edges - when there are large blocks of solid colour nothing is plotted. Obviously this wouldn't work if the main landscape was textured and not solid colour!

I'm also guessing that each character row is ruptured in two page boundaries for the left & right hand side clipping ala Frogger? Although do you need sprite clipping at the edges?

Is there an updated SSD available BTW? Looking forward to trying this on a real machine in the near future. Great work, as ever.

[tricky]

That is correct, four copies of four pixels per pair, I think my maps end up with 30 pairs which fits nicely into four pages.
Same clipping, mostly for the sprites, but also to keep things simpler (apart from those trixy masters). You can see it in the early video before hiding the sides.
I only have one interrupt every two rows/frames which latches the row about to start and then imediatly latches r12/13 for the following one.
I'll sort out the latest ssd tomorrow, but I'm not 100% at the moment.

[tricky]

I've added shooting/bombing the launched rockets and sound for the meteors (needs work). 665 bytes left.
You still can't die and the game instantly loops when you kill the base.
Exit with ESCAPE to tidy up properly.
There are two .SSDs in the .zip, one for beebem and one for everything else (may have corruption on bottom on VLSI master).

I spent all morning adding "live drawing" to beebem to find my launched rocket explosion corruption and then found it in about 10 seconds without even using my new debugging feature!
The feature records the palette and other bits that beebem uses to display beeb memory for each scan line as they are drawn while the debugger window is displayed.
When entering "LiveRedraw" mode, the screen is redrawn using the current contents of memory and the display settings and palette from the last time each scan line was drawn.
As a write to screen memory happens, that line(s) is redrawn and displayed immediately, making it very easy to see what drew on the screen where you weren't expecting it.
I didn't bother adding it for MODE 7 and there will be plenty of places where it will be a little off, but I think it will come in handy every now and then.

I would post the code, but: it is a little messy, for beebem403, I didn't get a great response before add I still don't use github. I haven't bothered.
PS It seems that beebem writes an AVI frame every time it redraws the screen, which might be what throws my FPS off when recording sometimes.

[tricky]

And a gameplay video

URL:https://youtu.be/_EvKYgXitcE View at 720p+ for 50hz.
My PC stutters a bit, but beeb is silky smooth

[tricky]

Added player/boss explosion. 558 bytes left.
Now I have a lot of clean up code to add for when you die as most things on screen when you died are still "alive"!

[leenew]

C'Mon!!
This is getting so close now......
Keep it up Tricky!
It's a rainy bank holiday so it's ideal to get this done

Lee.

[guddler]

Just catching up on this.

I'm using a Master 128 with internal data centre. Demo 4 has no timing issues and works fine, other than the whole of the fuel area at the bottom is just full of corruption (already noted).

I have also found that if I hold 'forward' then a lot of the time 'up' and 'down' will fire bombs. Don't know if anyone has mentioned that one?

And I had to turn off my internal co-pro. But I kind of took that as a given?

[tricky]

Thanks for the feedback, I'm glad it has no DC issues (yet!).

I hadn't looked at Key clashes as I assumed that lots of games had checked and use these keys.
I usually use SHIFT instead of SPACE, which is a little less convenient, but doesn't clash (at least on real HW).

I hadn't considered the co-pro. I stomp on everything except for three OS required bytes, so I'm not too surprised.
It might just be that my file has an 00xxxx load and run addresses and should have FFxxxx addresses.
I might have to upgrade my beebasm (I thought that I already had).
If you get a chance, please try changing them (I'm not sure how - probably *load *save) and see if it works with the co-pro on.

I have added dying and explosions for it and destroying the boss.
Explosions don't kill you and I've tidied up quite a bit of restarting code. 417 bytes left.

Main things left are:
1. Change keys! (maybe add remapping or a selection)
2. Update high-score when beaten (EDIT: 2a. maybe add some more digits and maybe have a high-score table)
3. add difficulty ramp (saucers, meteors and fuel usage) EDIT: 3a. And flags for loops completed
4. add joystick support (with auto detect and button 1 does fire+bomb until button 2 is pressed, maybe)
5. add attract mode and starting a new game (instead of current infinite lives)
6. Hide the corrupt bit on VLSI masters (should be fairly easy - would be nice to have beebem and VLSI compatible in one version)
7. Do a write up - it won't be as good as PoP, sorry.

EDIT: Added attract mode (5), high score update (2) and start new game (5). 339 bytes left.
EDIT: Added difficulty ramp (3) and flags for loops completed (3a). 281 bytes left.
EDIT: Changed SPACE to SHIFT (1) and added joystick support for B,B+,Master and Compact (4). 241 bytes left.
EDIT: Added an extra digit to the scores (2a), may even need another, but we will see. 222 bytes left.

I'm still hoping to have this ready for Cambridge, but I should also get some beebs ready

[guddler]

If you get a chance, please try changing them (I'm not sure how - probably *load *save) and see if it works with the co-pro on.

Hmm, you lost me a bit there. Try changing what? Happy to try anything as long as I understand what you mean

Honestly, I'm not sure I'd expect it to work with the Tube on. Very little else does!, I just figured I'd report it seeing as there is quite a bit of hype over the Pi co-pro these days.

As far as keys are concerned, clearly I would not think it is a priority that should take up precious bytes, a high score table or something like that would be much better, BUT some ability to remap or configure always gets my vote ever since I bought a copy of Zap and simply cannot play it as I find the key layout really awkward even though it's a fairly normal layout for the beeb.

[tricky]

Don't worry, I'll try it in my next .ssd.

Files with a load address starting with &FF then the four digit address should load in the beeb and the rest (I think) try to load into the copro if present. Beebasm writes the addresses as 00.... So if you have a copro, the file is probably going there, where a "legal" game would work, but games doing direct memory access won't.

I might do what I did on frogged and offer a few different options on first load, we'll see.

[guddler]

It's OK - I got it. I changed it and saved it back to the SSD.

Changing the Load and Exec addresses to FFxxxx does indeed do the trick and the game runs without having to disable TUBE. It doesn't exit cleanly when you press escape so there maybe something wrong going on at exit maybe? And once I got a blue background in the game - don't know what was going on there!

I've attached the SSD just in case I did anything wrong...

Scramble.zip

(190.27 KiB) Downloaded 93 times

[tricky]

Thanks,
I'm glad that it runs, but exiting is a shame.
Because I have stomped on everything, I try to force a power on reset with escape. Maybe the master needs more convincing.

Does anyone have any ideas?

Blue screen - well I do build on windows

[uniforix]

Game looks amazing, now I have a BBC i can try it

[AndyGarton]

Some quick feedback on demo4, other than it's awesome: on my real hardware (a Model B and Master 128, both with a DataCentre, both connected to Cub monitors), the game will often fail to load/initialise video properly. I hear audio and can fire missiles, but I either see a black screen (Master) or a white/black flickering/scrolling screen (Model B). Trying again will usually see it load fine - I'd say it's about 50/50 so far work/no work.

[tricky]

Thanks,
I noticed the same thing last night.
It is causes by the changes I made to support the VLSI (I think) 6845.
I'm going to try to get a better understanding of the incompatibility and if I can't, I'm going to revert that code for the release and have a second "exe" that will support the troublesome chip.

[leenew]

Hi Tricky,
Where is the latest SSD of Scramble please?
Are we (you!) close to completion?

Lee.

[tricky]

I was planning on releasing it at Cambridge, but someone kept on dying on the saucer level, which then sometimes caused a crash in attract mode after a while. There is also the issue that I introduced when adding support for the VLSI 6845 that meant that you sometimes just got a blank screen!

I have fixed the blank screen, but not found the cause of the saucer issue yet!

I was also hoping to find a way to work with beebem and hardware in the same game, but short of dodgy was of identifying beebem or someone fixing it, I can't find a work-a-round.

Attached is the version for everything except beebem, there is probably still corruption at the bottom of the VLSI 6845 masters but the game should play - maybe with a 2.5% slowdown!

Keys are: Z X / : RETURN and SHIFT
To activate the joystick, press fire, keyboard will still be active.

I'll have a look for beebem detection - would need to not work in a version of beebem that has fixed vsync timing.
I've just remembered that on the third or fourth loop, there is only one fireball on screen at a time (unless i fixed it)!

[tricky]

I keep getting distracted, first by getting the GOTEK working on my Master Compact and then by extending the B-Em debugger to help me diagnose the really tricky problem that I thought I would have with the corrupt GFX/Crash on the Compact.

Having just started to use the extra CRTC data in b-em, I noticed that instead of overwriting the analogue joystick code with the digital joystick code, I was overwriting it with a copy of the analogue to key mapping table which starts with a 0. When it tried to read the joystick, it hit a BRK, so the complicated fix was to copy the correct code!
I have just noticed that the joystick axis are reversed on the compact, so that needs swapping and I still haven't looked at the dying on the saucers + attract bug.

[tricky]

Here is a new version, I have broken the keyboard input on the Master Compact, but B, B+ and Master should work fine and joystick should work OK on all four platforms. My Compact seems to have a lot of bounce on fire (which does bomb too), nearly making it auto-fire, or I have another bug.

The Scrambl file can be loaded into a ROM or sideways RAM and run with *SCRAMBLE, default keys only.
If it is in SLOT 0, it will should turn your beeb into a Scramble machine, auto-booting without any choice in the matter.

I have also added a couple of alternative keyboard mappings and it should be easy(ish) to add your own should you wish.
I couldn't find a way to detect beebem, so that currently has a separate .ssd in the zip.
For now, for bbcmicro.co.uk, I can only think of having two entries where the beebem version doesn't have a play in browser option.

The currently known issues are:
1. beebem has screen corruption in the "official" version.
2. The two known VLSI Master's have a row of rubbish on screen.
3. The Game Over message gets some corruption at the end occasionally (I would like to know what causes this).
4. I've broken the keyboard input on the Master Compact!

If I could find a way to detect either beebem or VLSI, I could make a single version that works on all platforms.
I'm finding it very hard to get time on Scramble at the moment, so sorry for the painfully slow progress.

[leenew]

Looking pretty excellent!
Just tried it on BeebEm for now...

Lee.

[jbnbeeb]

Looking fantastic Tricky! I'll have to try it on the real thing rather an emu.. I think I'm better at this game on joystick.

[tricky]

Small update with game over screen, now the compact joystick has stopped working, but its keyboard is OK!

I'm looking for ideas for my next game if anyone has any suggestions.
PS still separate version for beebem in .zip and VLSI will still have corruption.