what should i write next?

[Grasshopper]

Regardless of what type of game you decide to write, please consider utilising multiple banks of sideways RAM. I would imagine that almost everyone who is still using an actual BBC Model B these days has already added a sideways RAM board of some sort to their machine. And all the various emulator options out there (both software and FPGA) also support sideways RAM. So, in 2022, there is really no need to squeeze a game into 8.5K of RAM, or employ various tricks like reducing the screen size to eke out a few extra bytes of RAM.

With regards to what type of game to write, I've always had a penchant for large Metroidvania style platform games. With the arguable exception of Exile, games from that genre don't really exists on the BBC Micro. I'm guessing that was due to the severe RAM constraints that programmers had to deal with on a stock BBC B.

I'm actually quite jealous of some of the more recent homebrew Metroidvania style games that have appeared for the ZX Spectrum. Some of them are remarkably sophisticated. It just shows what can be achieved on 8 bit machines when there's sufficient RAM available.

However, if you still want to write a Gauntlet clone, then you might want to consider Acornsoft's Labyrinth as a starting point. The game has nice high-resolution sprites, and makes very effective use of flip scrolling.

[Beebson]

Lovebug, this is a late comment, but I wanted to say I feel sorry for you. I hope you can see at least some light in your life now.

Although, maybe icons might work?
Bow and Arrow, sword, wand and Battle Axe for the players, skull or scythe for death - but then maybe it should just be character based - Ahgr!

It sounds like Battle Xor, that would be an interesting concept, honestly! Maybe with less puzzles and more arcade action. But maybe not for a game what is meant to look like Gauntlet. But as a icon graphics version of Gauntlet, it can be a really nice game!

[Beebson]

Regardless of what type of game you decide to write, please consider utilising multiple banks of sideways RAM. I would imagine that almost everyone who is still using an actual BBC Model B these days has already added a sideways RAM board of some sort to their machine. And all the various emulator options out there (both software and FPGA) also support sideways RAM. So, in 2022, there is really no need to squeeze a game into 8.5K of RAM, or employ various tricks like reducing the screen size to eke out a few extra bytes of RAM.

With regards to what type of game to write, I've always had a penchant for large Metroidvania style platform games. With the arguable exception of Exile, games from that genre don't really exists on the BBC Micro. I'm guessing that was due to the severe RAM constraints that programmers had to deal with on a stock BBC B.

I'm actually quite jealous of some of the more recent homebrew Metroidvania style games that have appeared for the ZX Spectrum. Some of them are remarkably sophisticated. It just shows what can be achieved on 8 bit machines when there's sufficient RAM available.

However, if you still want to write a Gauntlet clone, then you might want to consider Acornsoft's Labyrinth as a starting point. The game has nice high-resolution sprites, and makes very effective use of flip scrolling.

I am the one who is not among those almost everyones, as I don´t have sideways RAM. At least not yet, as I have wanted to stick with the stock BBC B, except having DFS. But if somebody wants to make sideways RAM game, go ahead! Perhaps enough favourite games will persuade me to purchase sideways RAM? Atari ST like, 64Kb mode 1 Gauntlet would be great.

I don´t know those Spectrum conversions well, but wasn´t Vampire Killer based game made for 128Kb Spectrums? The one having Vampire Killer cover art as a loading screen. It wasn´t a direct port though, but probably based on sequels? I mean 64Kb might not be enough?

Labyrinth, flip-screen might work for Gauntlet, but as Gauntlet scrolls, normally there would be many enemies and enemy generators what will become visible every now and then. I think it will not be exactly the same, if the player can kill every enemy and then can just rest in an empty screen, standing even on a very edge of the screen, knowing there are tens of enemies lurking just behind the corner, just an inch or two away, but they can´t attack, because they are located in the next screen. Maybe nearest enemies behind the corner could come from the open "doorways"? But then the game must take into account all those invisible enemies and enemy generators in nearby screens and their locations, too, to know, how many enemies can attack from the "doorways", maximum case being enemies attacking from top, left, right and bottom edge "doorways" and the game must count how many of them are lurking behind the 4 invisible screens and how many will be born from the enemy generators in those same invisible screens. Another problem would be, that the nearest enemies appearing from the "doorways" can´t be dodged at all, as they might materialize near the player just at the very moment when the player is near at the edge of the screen, thus unneededly draining player´s energy and possibly killing the player. Player might not even see, what caused the death. The player with very low energy might be able to escape lots of enemies when the screen scrolls, but with the flip-screen, there will be unnecessary deaths, if the enemies are allowed to enter the same screen from the "doorways". If the enemies are not allowed to enter from invinsible screens, the game may be too easy. Perhaps if the screen flips before the player reaches the edge of the screen? That might work better. Just my thoughts.

[paulb]

Labyrinth, flip-screen might work for Gauntlet, but as Gauntlet scrolls, normally there would be many enemies and enemy generators what will become visible every now and then. I think it will not be exactly the same, if the player can kill every enemy and then can just rest in an empty screen, standing even on a very edge of the screen, knowing there are tens of enemies lurking just behind the corner, just an inch or two away, but they can´t attack, because they are located in the next screen. Maybe nearest enemies behind the corner could come from the open "doorways"? But then the game must take into account all those invisible enemies and enemy generators in nearby screens and their locations, too, to know, how many enemies can attack from the "doorways", maximum case being enemies attacking from top, left, right and bottom edge "doorways" and the game must count how many of them are lurking behind the 4 invisible screens and how many will be born from the enemy generators in those same invisible screens. Another problem would be, that the nearest enemies appearing from the "doorways" can´t be dodged at all, as they might materialize near the player just at the very moment when the player is near at the edge of the screen, thus unneededly draining player´s energy and possibly killing the player. Player might not even see, what caused the death. The player with very low energy might be able to escape lots of enemies when the screen scrolls, but with the flip-screen, there will be unnecessary deaths, if the enemies are allowed to enter the same screen from the "doorways". If the enemies are not allowed to enter from invinsible screens, the game may be too easy. Perhaps if the screen flips before the player reaches the edge of the screen? That might work better. Just my thoughts.

That's quite the paragraph!

I don't know if you've played Dunjunz or Icarus, but unlike Labyrinth, the map involves large open sections and not rooms aligned to the flip-screen navigation method. So, there are always risks of crossing a screen boundary and stepping into a trap, which isn't particularly fair, but then the gameplay tends to involve exploratory shooting to discover if there is a trap on the next screen. Meanwhile, enemies wander freely between screens, so they don't wait off-screen to attack, nor can they be left off-screen, either.

One compromise is a form of paging where the screen scrolls occasionally to keep up with the player, seen on games like Exile and Frak! (on the Electron). Although the player can still be surprised, they won't risk just walking into traps and enemies.

[tricky]

I think memory and horizontal scrolling are what have stopped platform explorers on the beeb.

I have had a few goes at scrolling games/demos on the beeb but they all have compromises!
Here are most of the ones that do horizontal scrolling, nearly all captures off real hardware using a PiRGB2HDMI:

N.B. For some reason YT takes a while to start playing these videos correctly despite them being tiny, sometimes you have to watch 20+ seconds before they smooth out!

My latest is my R-Type alike tech demo that does single MODE 1 pixel scrolling in Hardware so can have lots going on.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
The main problem here is that it wont work on a beeb connected directly to a non-CRT.
It also has to draw one frame with 2 black pixels on one side and the other with two on the right!
The second downside is that it uses 20K for the display as it double buffers so sideways RAM is needed.

My version of Scramble uses 2 MODE 1 pixels per frame software scrolling so sprite drawing is much simpler.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
The main restriction here is that it only works if there ar large sections of solid colour.

My version of Astroblaster uses 4 MODE 1 pixels horizontal and 1 pixel vertical scrolling.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
To have this many sprites move, the have to stay in their original characters and all animate together.
When the sprites get to the edge of their byte, the whole screen moves by a byte and they jump back to the other side.

Moon Patrol has parallax scrolling with the mountains and hills hardware scrolling and the ground software scrolling

Watch in 720p50 to see how smooth it is or download the demo from the thread.
The mountains and hills repeat their pattern every 127 pixels, so to move one pixel, the hardware scrolls by 32 bytes
The four pixels of the ground that appear to move are redrawn each frame, as are the edges of holes to appear to move.
Moon Patrol also supports Video NuLA, hence the arcade colours.

My Pac Land tech demo does hardware scrolling, but is only smooth at the running speed shown, walking looks horrible (to me).

Watch in 720p50 to see how smooth it is or download the demo from the thread.
This again uses the HSync pulse trick that the R-Type alike demo uses but makes the playfield so wide that you can see the edges.
If you were going to make a platform adventure game, this would be my suggested scroll, but it has to go at 2 MODE 1 pixels per scroll.

My Rally-X tech demo uses the same technique as the R-Type demo, but single buffered.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
The emulator wasn't very stable for this capture, hence the picture moves around!
It has to draw and clear the edges of the screen every frame of horizontal movement.
You could use this for a game, but there isn't much time to decode a map, draw the edges and add some sprites.

My SMB tech demo is the same technique as Scramble, but scrolling a single pixel per frame.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
As this is in MODE 4, it needs 8 copies of all of the graphics and here that is every horizontally adjacent pair of 8x8 tile combinations.
This and probably Scramble could be made to run in reverse, but as the mapdecodes to code, not data it would be tricky!

And finally, Gil and I wrote this back in the 80s, it is all software and runs at 17 fps, 1 to run logic and 2 to draw everything.

Watch in 720p50 to see how smooth it is or download the demo from the thread.
The attack waves and the landscape are not matched, if they were, you wouldn't get flickering on the sprites.
When sprites overlap, the overdraw parts are ORed on but when not, just STored on.
There are several lookup tables that are cleared, filled in and used every frame!
I can't remember if this was captured from an emulator or really crappy capture device!

[Beebson]

I haven´t played Dunjunz, I have watched a video though, so I know what´s it about. Haven´t played Icarus either, but I am familiar with Captain Fizz Meets The Blaster-Trons on the Amiga, it seems to be exactly the same game as Icarus, even the sound effects are the same. I checked Captain Fizz video now to see if it was what I remember. Yes, enemies and their bullets appearing behind the screen seems to work well Captain Fizz. There are lots of flip-screen games with traps just behind the screen, so maybe flip-screen Gauntlet is allright. Perhaps I am just so used to scrolling in Gauntlet, so it was hard to think other options.

Occasional screen scrolling sounds good, too.

[Beebson]

Thank you, Tricky, it was nice to watch your so smooth tech demos once again. Pac-Land was flip-screen on all 8-bits, except on 64, so it was a nice surprise to see it scrolling smoothly in your demo! 2 mode 1 pixels is smooth to me.

[paulb]

I haven´t played Dunjunz, I have watched a video though, so I know what´s it about.

You'll find a lot of Electron game videos here that illustrate some of the dynamics being discussed.

Haven´t played Icarus either, but I am familiar with Captain Fizz Meets The Blaster-Trons on the Amiga, it seems to be exactly the same game as Icarus, even the sound effects are the same. I checked Captain Fizz video now to see if it was what I remember. Yes, enemies and their bullets appearing behind the screen seems to work well Captain Fizz. There are lots of flip-screen games with traps just behind the screen, so maybe flip-screen Gauntlet is allright. Perhaps I am just so used to scrolling in Gauntlet, so it was hard to think other options.

See this video of Icarus.

Occasional screen scrolling sounds good, too.

As noted, Frak! and Exile employ this kind of technique, with the latter really using it extensively, to the extent that one of the Electron User reviewers was really quite critical of the "jerky scrolling", but I think that it forms part of the immersion of the player in the game and, if you are controlling the player or following his movement, is hardly as bad as the reviewer claims.

[fizgog]

Been away so missed the start of this.

First up I’m also one of the minority who doesn’t have sideways ram for my beeb (it’s why I try and target the 32K for games) but I should really take the plunge and get some fitted

Some people seem to think Gauntlet would be simple to do but it’s not, due to its 4 way scrolling and the massive amount of sprites moving on screen at the same time, but if anyone could pull it off Tricky, it’s definitely you.

If you do decide to do it then I think the DOS cga is the one you should base it from being similar to Mode 1. Looking at the cga game it seems to be using a 32 x 22 character display for the main area but there is no reason you can’t use your square mode, also I think 16 x 16 would need to be used for the sprites to get the detail,

[tricky]

Thanks Fizgog you may have too much confidence in me

The problem with scrolling is that you either have to redraw the whole screen (then why not use software) or you have to scroll in bytes (or half bytes and exclude new screens without PiRGB2HDMI).

Since software scrolling only really works with large areas of solid colour, that won't work for Gauntlet.

I wouldn't be happy with byte scrolling (4 pixels) and with the HSync trick, the sides of the screen would flicker and you loose most modern displays!

There is a survey somewhere on here showing that about half the respondents have 32K SWRAM and I think nearly 3/4 have 16K plus all the B+s (12K or 12+64K) and masters/compacts with 4+64K.

I have only forced SWRAM where the game wouldn't fit without, warlords and a not very secret project, but do allow speech and samples of you have it.

[tnash]

Oh my that R-Type demo is beautiful, I'm in awe.

I might be selfish and facetious but if everyone could just agree to develop for the BBC B with 32k SWRAM displayed on a good old CRT then that'd suit me just fine

On another note, the MMB card that was provided with my beeb included an SSD with the beginnings of a demo of Rainbow Islands. Not much was implemented but it looks great. Anyone know if anyone's actively working on it?

[RobC]

On another note, the MMB card that was provided with my beeb included an SSD with the beginnings of a demo of Rainbow Islands. Not much was implemented but it looks great. Anyone know if anyone's actively working on it?

I think it was written by sorvad (Steve O'Leary) who also wrote the Swift IDE (possibly as a means of developing the Rainbow Islands port). I don't think it's being actively worked on although sorvad did pop up on here a while back to say that Swift was being redeveloped in C#.

Completely agree that it looked really good and it would be wonderful to see it on the Beeb (even if it was only on a Master). I often play the Amstrad CPC version on my M128 (using the Pi CPC emulator) and it's a great game.

[tricky]

Nearly all of my beebs are Bs with 32K SWRAM and I always use them on CRT

There are really the levels, 32K B, B/B+ with SWRAM and Master/Compact that can double buffering the full display.

I aim for the B but don't use undocumented opcodes as I think it is a small space/performance price to pay for supporting all "beebs".

BitShifters' demos generally target the Master as they make heavy use of the two lots of display memory.

[Cybershark]

The thing that was a massive bitch with Dunjunz's flip-screen action was that there were sometimes doors just over the edge of one screen, so you'd be thinking you'd hit a dead end (because you couldn't see any better). It'd take quite some wall humping (and key swapping) to find a way through!

Also, Kourtyard and Ravenskull bear a look, if we're talking about clones, wannabes & derivatives.

[Beebson]

I haven´t played Dunjunz, I have watched a video though, so I know what´s it about.

You'll find a lot of Electron game videos here that illustrate some of the dynamics being discussed.

See this video of Icarus.

Occasional screen scrolling sounds good, too.

As noted, Frak! and Exile employ this kind of technique, with the latter really using it extensively, to the extent that one of the Electron User reviewers was really quite critical of the "jerky scrolling", but I think that it forms part of the immersion of the player in the game and, if you are controlling the player or following his movement, is hardly as bad as the reviewer claims.

Thank you for the videos, paulb. Exile like scrolling will surely work in Gauntlet. But maybe just moving part of the screen by clearing the screen and then redrawing the screen several characters nearer the player, when the player moves to that direction, may work well. Perhaps this game video, Amstrad Super Tripper is not a best example, but shows what sort of "scrolling" I mean. Redrawing of the screen should be faster, though. I think for this technique the player shouldn´t always be in the middle of the screen, but should be allowed to move around before the screen gets cleared and redrawn. But the redrawing should happen before the player gets too near to the edge of the screen.

Electron Frak!´s scrolling suits well to that game, but I think in Gauntlet´s case, that fast "jerky scroll" is too fast, otherwise it works. In my opinion it´s better to use slower character scroll than what it is used in Electron Frak! or sort of "scrolling" in Super Tripper.

On 64 Gauntlet, the scrolling is smooth, but the enemies are moving jerkily, but that "jerky" enemy movement looks very acceptable in my eyes. Both 64 and Amstrad are using 160x200 mode, BBC Gauntlet can be "blocky" as well.

[Beebson]

The problem with scrolling is that you either have to redraw the whole screen (then why not use software) or you have to scroll in bytes (or half bytes and exclude new screens without PiRGB2HDMI).

Since software scrolling only really works with large areas of solid colour, that won't work for Gauntlet.

Doesn´t Gauntlet have large areas of solid colour, at least if you make floors "empty", like they did on 64, Amstrad, Atari, Spectrum and MSX? Or do you mean, that there can´t be walls and lots of enemies and enemy generators, etc. around, but just part of the screen having the scrollable graphics, like in your Scramble conversion?

I wouldn't be happy with byte scrolling (4 pixels) and with the HSync trick, the sides of the screen would flicker and you loose most modern displays!

Are there any video or SSD file to show how much flickering there is?

[Beebson]

The thing that was a massive bitch with Dunjunz's flip-screen action was that there were sometimes doors just over the edge of one screen, so you'd be thinking you'd hit a dead end (because you couldn't see any better). It'd take quite some wall humping (and key swapping) to find a way through!

Perhaps that can be solved, by just changing the original map a bit, by just moving problematic doors/traps/exits two characters left, right, up or down. Then 16x16 sized player can enter that screen.

[tricky]

The problem with scrolling is that you either have to redraw the whole screen (then why not use software) or you have to scroll in bytes (or half bytes and exclude new screens without PiRGB2HDMI).

Since software scrolling only really works with large areas of solid colour, that won't work for Gauntlet.

Doesn´t Gauntlet have large areas of solid colour, at least if you make floors "empty", like they did on 64, Amstrad, Atari, Spectrum and MSX? Or do you mean, that there can´t be walls and lots of enemies and enemy generators, etc. around, but just part of the screen having the scrollable graphics, like in your Scramble conversion?

Sprites are not solid colour and I forgot to mention that any sprites need to play nice with the landscape by not getting within a few pixels of it.

I wouldn't be happy with byte scrolling (4 pixels) and with the HSync trick, the sides of the screen would flicker and you loose most modern displays!

Are there any video or SSD file to show how much flickering there is?

Sorry, not on my dev machine, but it is two columns of pixels that show on one side, then on the other and back when moving horizontally and doesn't work on modern TVs without PiRGB2HDMI. I might mock it up anyway, but have just had some more boards from JLCPCB and feel a soldering session coming on

PS I did some rough calculations and with 16x16 sprites, a small status area at the bottom and hardware scrolling with flickering sides, you should be able to get 30 sprites on screen without tearing or flickering but you would probably lose two or three of those for each player!
For 8x8 sprites, no scrolling on a 32x32 map, it should be more like 100 active + maybe another 100 inactive! losing about 5 active for each player.

[Beebson]

Thank you, Tricky. I was confused, how your Scramble could manage the enemies and the scrolling.

Just for comparing, I thought to bring a link of some scrolling non-Acorn game, what used "artificial borders" on the side of the screen to mask all the garbage caused by scrolling, but I can´t remember the game name now. That flickering in few characters wide area was horrible as it did not use the same colour as the background.

If three sprites were used per player, there would still be 24 sprites for enemies. Does that mean 24 monochrome enemies? Ie there could be 12 two colour enemies at once? Are the enemy generators counted as sprites, too? I thought that maybe some of the enemies could stand still occasionally and that way there could be few more moving enemies?

If any enemy gets too close to the scrollable background character ie the wall or anything else, will that enemy or character get colour-clashed? Many enemies will stand next to the walls and doors, without any pixels between them. Will that be a problem during scrolling?

[tricky]

If you are in a four colour mode, the is no performance benefit to not using four colours.
The software scrolling would be very tricky for Gauntlet and not worth the effort.
Only mode 7 on the beeb is character based so there is no such thing as attribute clash.
Generators would count as sprites as they could get partially over drawn by sprites going diagonally across their corners.

[fizgog]

There is a survey somewhere on here showing that about half the respondents have 32K SWRAM and I think nearly 3/4 have 16K plus all the B+s (12K or 12+64K) and masters/compacts with 4+64K.

I've took the plunge and ordered some sideways ram for my beeb

Just been watching some Gauntlet videos for the C64 and Amstrad CPC, seems they are using equivalent Mode 2 / Mode 5 wide pixels, sprites are 8 wide by 16 high, also doesn't seem to be using single pixel scrolling and seems to have max 16 or so moving sprites

[Grasshopper]

I don´t know those Spectrum conversions well, but wasn´t Vampire Killer based game made for 128Kb Spectrums? The one having Vampire Killer cover art as a loading screen. It wasn´t a direct port though, but probably based on sequels? I mean 64Kb might not be enough?

You're probably thinking of this game:

Spectral Interlude

Here are some other remarkably good recent Spectrum games:

Aliens: Neoplasma

Marsmare: Alienation

Delta's Shadow

Guns & Gears

Interestingly, all of these games use flip scrolling. I didn't pick them for that reason. But it just so happens that most of the really good recent Spectrum games use that scrolling method. Personally, I don't think it has much of an impact on gameplay.

As an aside, I'm surprised at how well many Spectrum games have aged. I think one of the reasons for this is that all Spectrum games have to have square pixels by necessity, because of limitations of the hardware. However, on many other platforms from the early 80s such as the BBC Micro and C64, developers had the option of sacrificing horizontal resolution for a wider range of colours per pixel.

In the early 80s when most people were connecting their computers to low resolution 14 inch CRT TVs, that might have seemed like a reasonable trade-off. However, on modern hi-resolution displays, those double width pixels often don't look very good. I think for that reason, mode 1 BBC B games have generally aged better than mode 2 games.

[Beebson]

If you are in a four colour mode, the is no performance benefit to not using four colours.
The software scrolling would be very tricky for Gauntlet and not worth the effort.
Only mode 7 on the beeb is character based so there is no such thing as attribute clash.
Generators would count as sprites as they could get partially over drawn by sprites going diagonally across their corners.

I was thinking about performance, as the Electron User told that monochrome sprites are faster than multicolour ones.
If character scroll (8 pixels) were used and enemies will similarly have 8 pixel movement, wouldn´t that eliminate all colour clash between the enemies, generators, treasures and the walls? I´m not sure, though, if they will colour clash with the smoothly moving players?

I don´t know those Spectrum conversions well, but wasn´t Vampire Killer based game made for 128Kb Spectrums? The one having Vampire Killer cover art as a loading screen. It wasn´t a direct port though, but probably based on sequels? I mean 64Kb might not be enough?

You're probably thinking of this game:

Spectral Interlude

Yes, Spectral Interlude.

Interestingly, all of these games use flip scrolling. I didn't pick them for that reason. But it just so happens that most of the really good recent Spectrum games use that scrolling method. Personally, I don't think it has much of an impact on gameplay.

I think flip scroll suits better to platform games, than Gauntlet type games, but it´s worth trying to make a flip scroll Gauntlet demo! Even if all the enemies and their projectiles are just solid squares, just to see how it works. It will be very playable game and then it will be easier to see the possible problems and think the ways to fix them.

About flip scroll platform games, I think there are cases where there will be a difference, if the same game is a flip scroll type or has smooth or character scrolling. Think about the case where the game logic keeps the enemies always in the room where they are born and a new enemy is born as soon as the previous one is killed or when the previous enemy has walked few characters away from the door. And if there are enemy generators in a form of a door or trapdoor on a certain platform near the edge of the screen, you may be able to get rid of them by simply walking to the next room. But if the screen will scroll smoothly (or character scroll), new enemies can keep coming from that door and all of them will follow you and the amount of enemies will rise as long as that door is visible. If the next room has one or more enemy generating doors, you might be soon overwhelmed by the amount of enemies. In Gauntlet type maze game, fast enemy generating rate is a feature and needed to make the game enjoyable.

As an aside, I'm surprised at how well many Spectrum games have aged. I think one of the reasons for this is that all Spectrum games have to have square pixels by necessity, because of limitations of the hardware. However, on many other platforms from the early 80s such as the BBC Micro and C64, developers had the option of sacrificing horizontal resolution for a wider range of colours per pixel.

In the early 80s when most people were connecting their computers to low resolution 14 inch CRT TVs, that might have seemed like a reasonable trade-off. However, on modern hi-resolution displays, those double width pixels often don't look very good. I think for that reason, mode 1 BBC B games have generally aged better than mode 2 games.

I like both, square and double width pixels! Though, unlike BBC, 64´s feature was that it can mix hires and multicolour characters and hires and multicolour sprites. Thus BBC mode 2 game may look more dated than 64 version.

[tricky]

The beeb's palette doesn't help when it comes to games aging well, even when they were new

[tricky]

Here is a demo that plays most of the speech from the game (~130 out of ~150) if your beeb or emulator have a speech chip - no ROM required.

GauntletSpeech.zip

(31.27 KiB) Downloaded 30 times

I've also included the source code, but it is littered with debug code, mostly commented out with a semicolon at the beginning of the line.

[tricky]

I've been having a play, converting the sprite routines that I did for my not-so-secret game to have making and the results are OK, but a little disappointing! The sprite routine only requires one copy of the sprite and no maks and then calculates the shifted version of the sprite and mask on the fly. This is very expensive and so the best that I have managed is 8 sprites on screen if they line up nicely in some way (horizontally in the demo). If they misalign horizontally or vertically then they have to redraw 6 tiles instead of 4 and if both, then 9 tiles! as well as drawing 5 bytes wide when not aligned to 4 pixels.

This method supports, flipping, mirroring, drawing at any pixel position and masking so that colour 0 is transparent.

The graphics are only for test as I know that there are at least two other people working on BombJack and I think that there are too many sprites later on for this method to work.

The demo requires one bank of sideways RAM but has over 10K free in main memory. I think to do BJ, a second SWRAM/ROM would be nice to store all the levels.

[paulb]

If character scroll (8 pixels) were used and enemies will similarly have 8 pixel movement, wouldn´t that eliminate all colour clash between the enemies, generators, treasures and the walls? I´m not sure, though, if they will colour clash with the smoothly moving players?

A point about terminology here, since I seem to remember that "colour clash" is what all the Spectrum owners cried out when seeing Beeb and Electron games EORing sprites onto non-uniform backgrounds. They were, of course, confused and just carried over a term about the colour model of the Spectrum to something completely different.

As you undoubtedly know, the Spectrum applies colour at a lower resolution than the actual graphics resolution, meaning that cells at a character-level resolution are given particular colour properties or attributes, but this means that graphics relying on sub-character resolutions have to be designed carefully not to expose obvious colour discontinuities or discrepancies. This is where initial coverage of the Spectrum managed to play down or conceal such limitations by careful choice of graphical examples.

Therefore, on the Spectrum, sprites positioned at sub-character resolutions expose such discontinuities if they stray across into a character cell that does not employ the right colour attributes. And as a sprite gradually moves into an inappropriately coloured cell, it gradually takes on that inappropriate colour, its own colour attributes "clashing" with those already there, or the cell takes on the sprite's colour, suppressing the scenery's proper colour, as the plotting engine ends up with two or more different kinds of attributes to apply, ultimately applying one of them that only works for one of the sprites or scenery tiles at that particular place on the screen.

Meanwhile, the screen modes on the Beeb and Electron (ignoring mode 7, as the Electron does) have colour applied at the pixel resolution, so there are no character-level attributes to cause "colour clash" or "attribute clash". But what games often do is to plot sprites using EOR (exclusive or) because the plotting and unplotting operations are the same: if you plot something somewhere, you can undo that plotting by simply plotting again at the same place. But what that often does, when the background is non-uniform, is to produce a rather messy result if the palette is not set up to mitigate it. So, if you look at games like Citadel, you'll see the player character take on weird colours as he or she moves past various objects or backgrounds.

So, discussion of colour clash might be confusing when you possibly mean something else. Then again, I've not been closely following the discussion here, and you do seem to think that the proximity of sprites to scenery might be a problem. I might only say that proximity wouldn't generally be a problem, but overplotting could be a problem depending on the plotting techniques used, but that isn't colour clash.

[Beebson]

Nice demo, tricky! 8 sprites are enough for a horizontal or vertical shoot´em up, to occasionally show around 5-8 enemies in a row in Nemesis type game. The ones what are shown in the beginning of the each level in Nemesis. Nemesis can show 2 rows simultaneously, though. Unless this technique is too expensive and you can´t add a player and few more enemies and their bullets to the screen simultaneously.

Paulb, yes, I know very well the Spectrum´s 2 colours per character cell. The same applies to 64´s hires character cells as well. I have never minded the pixel colour clash (EOR) in Amstrad and BBC games, as it is part of those machines. I just thought to ask about this colour clash, as some people seem not to like how the results of EORing will look like. If the graphics can be EORed without "colour clash", it´s of course nicer to look at, but I don´t mind to see EORed different coloured pixels. Maybe perhaps if there are lots of them with big contrast against other sprites or the background. I am just asking about things to learn more about BBC and Electron.

[tricky]

It is only for games with a tiled background that the sprites have to move over.
Depending on the conditions, you can easily draw 64 16x16 sprites but a good compromise is the first wave of flapping sprites (12xVariable pixels, 16 sprites) or the balls (16 sprites 12x12 pixels each - first few seconds) that go around in a circle in my 50fps flicker free B-Type demo above. You can see from the timing bars how much time is being used - they start at the top of the play area when nothing is happening.

[tricky]

And a MODE 2 version that uses the 3 foreground, 4 background colour palette trick (wow, it's over 40 years since I first did that!) and I didn't like the chunky pixels then either

SCREENDUMP.png (6.94 KiB) Viewed 2133 times

It does allow more sprites though, so might be a better option for this game.
In the arcade, the main character moves 1 pixel one frame and the 2 the next horizontally, so it covers 30*1+30*2 pixels a second = 90.
On the beeb in MODE 2, it would be one chunky pixel per frame which would be the same as 50*2 pixels, so 10% faster than the arcade and smoother!
Of course, it could be MODE 1, have sprites that you could tell what they were, still mode 2 pixels per frame, but may flicker occasionally on later levels!

TrickycadeTileGame2.ssd

(15.5 KiB) Downloaded 22 times

Any thoughts?
- still not really thinking of doing this game, nor a MODE 2 game!