Why was dizzy series not on the Beeb

[Chuckie]

Why was the dizzy code master series not on the Beeb. Would i be possible to make one now?

[VectorEyes]

I don't think Codemasters did many games at all for the BBC Micro, possibly because they just started out doing C64 / Spectrum stuff, or more likely because they looked at the commercial side and decided it wasn't worth it.

I'm sure they absolutely could have been ported to the Beeb, although fitting everything into memory on an unexpanded 32k Beeb would have been ... challenging.

[RobC]

It is a shame. The CPC version of Crystal Kingdom Dizzy looks really good on a Beeb under my CPC emulator. Looking back, it does seem that the CPC replaced the Beeb in the minds of most major games developers.

I guess memory would have been a problems as already said - pity Acorn didn't bring out a 64KB Beeb using sideways RAM in 1984...

Maybe a M128 version could be done now.

[BeebMaster]

That's a very good question, I used to like playing Dizzy on my Speccy +2. I can't remember which ones I had, but I do remember an underwater bit. Be nice to see it on a Beeb.

[Andy1979]

Absolutely loved Treasure Island Dizzy on my Atari ST, and the various sequels (think we had one on the Megadrive too). Was only playing it recently using Hatari on my Pi 400 - forgot how hard it is to time the jumps, and when you die it sends you back to the very start!

Would love a Beeb and/or Archimedes version.

[Arcadian]

Did you know Dizzy began life on the Beeb? Apparently the Olivers produced the concept graphics on a BBC before switching their attention to the Speccy instead...

[Kecske Bak]

This is as close as you can get to it at the moment...

http://bbcmicro.co.uk//game.php?id=1842

[Chuckie]

It is a shame. The CPC version of Crystal Kingdom Dizzy looks really good on a Beeb under my CPC emulator. Looking back, it does seem that the CPC replaced the Beeb in the minds of most major games developers.

I guess memory would have been a problems as already said - pity Acorn didn't bring out a 64KB Beeb using sideways RAM in 1984...

Maybe a M128 version could be done now.

Is that beeb cpc emualtor published any where?

[Chuckie]

They did publish and develop for bbc micro ...https://www.olivertwins.com/rescuemisson

[RobC]

Is that beeb cpc emualtor published any where?

Yes - it's here.

It needs a VideoNuLA (for the CPC palette) and a Pi Co-pro (for the Z80 emulation).

[tricky]

I don't think it looks great, but Fantasy Dizzy seems to be on the C16, which has a 6502, 32K RAM, the same video memory layout as the beeb, worse sound, but a better palette.

[Chuckie]

The BBC Micro was never designed to run gams. Looking how all these 8bit machines were developed i m surprised anything worked. They didn't care about end user Just make it as cheap as possible. It was marketed to kids. Many people in fact never owned one. The consoles games along and captured the gaming market.

[cardboardguru]

At the time though it was fantastic. Previous to getting a Beeb, the only home computer I'd played games on was a Commodore PET at school. I thought the Space Invaders on that was amazing... even though it was monochrome green and was drawn as characters from the PETSCI character set.

Planetoid in "full colour" with horizontal scrolling was amazing in comparison!

[ThomasHarte]

I share the analysis above: Dizzy was probably never available for the Acorn machines because the extra development effort required by the tighter memory footprint wasn't justified by the potential sales by the time Dizzy arrived in 1987.

Despite the far-and-wide porting reported above, the original was only a C64, CPC and ZX Spectrum game, and that remained the full list of 8-bit micros for official releases. Everything else is a fan effort.

---

The fun speculative part:

The early Dizzy games use tilemaps for their screens; having had a quick look at the map for Fantasy World Dizzy there are 58 screens total. On the Spectrum each screen is 30 columns by 17 rows and there are clearly a lot more than 16 tiles so naively let's say an uncompressed 58*30*17 = 29,580 bytes of map data alone.

The final two 8-bit games were written by a different team and switched to a Citadel-esque vector description of screens in order to fit more than 100 in but the change is pretty obvious. So I don't know that Citadel provides a useful data point on the storage issue.

I guess it's not impossible you'd be able to compress the map data enough to fit into a 32kb machine though, if you were happy with Mode 4 or 5-esque graphics? I think it might need to be a manual job though; if you look at something like the image below then you or I could encode it as a painter's algorithm-style three tree trunks, add branches and leaves, overpaint barriers and floor, and fit that into less than 510 bytes.

That said, I wouldn't be surprised if you ended up needing to abridge the original content.

Supposing you wanted to do that, Codemasters have been very enlightened as to fan titles: as long as you acknowledge the copyright owners and don't seek to profit, they won't intervene. There's active engagement with the fans by the Oliver Twins — the recent Wonderful Dizzy is a collaboration with the team that previously remade Crystal Kingdom Dizzy.

Otherwise: I once wrote a Dizzy engine in C and used it to reproduce some of my favourite segments. The actual logic at play in terms of character movement and collisions isn't especially complicated — it's a fixed height jump, fixed speed left and right motion, and a simple slow upward push whenever Dizzy's feet are over an occupied square, or a complete exclusion if at least two thirds of one side of him has entered an occupied section. He spins when he jumps and continues spinning (and moving) until both he's the right way up and his feet are on top of solid ground. I forget whether he's normally timed to do exactly one loop or exactly two when jumping on a flat surface. Probably two.

[fwibbler]

Would using 16k of sideways RAM allow the use of MODE 1 for the game? Or would it need to be 32k SW?

[tricky]

I would have though a straight port from the C16, but I don't know if it has a character mode, or only the beeb like modes.
If the map is the issues, multi-load for overlapping sections would seem like an idea, but I suspect that they could be compressed.
In the survey, I think over half beebs and all emulators had two banks of SWRAM, so I wouldn't let memory stop someone.

[ThomasHarte]

I would have though a straight port from the C16, but I don't know if it has a character mode, or only the beeb like modes.

Like you, I found references to a Commodore-16 version, but I'm starting to think it might be a myth on the grounds that:

• I was completely unable to find anything to download; and
• the Plus/4 version is a 64kb title that describes itself as a fan port from the C64 (you can play it here).

Also, it's not really ideal as ports go — to deal with the fact that Dizzy is a hardware sprite on the C64 they've just turned him into a character that can move only block by block. Unlike every other sprite in the game, which the C64 draws in software and therefore so does the Plus/4 conversion, and which correspondingly have proper pixel movement.

[tricky]

I thought it was just a poor version.
Looking at the map, with basic compression, it looks like 24-32K and you still need gfx and animation after that.

[ThomasHarte]

I thought it was just a poor version.
Looking at the map, with basic compression, it looks like 24-32K and you still need gfx and animation after that.

To the extent that it adds anything, which it probably doesn't, I eyeballed the Dizzy sprite and it's at least 21 frames all in, around 24x24 at Spectrum resolution — so assuming you'd end up in Mode 5 on a BBC or Electron, I guess that'd likely be 12x24.

There's some scope for composing it of smaller common elements, but the jump animation isn't amenable to that due to the body rotation.

So all in, allowing for an appropriate form of compression, I reckon you're talking at least half a kilobyte.

Most of the other sprites are just a single frame, a few are two.

[tricky]

I think that you could store everything at 1 bit and probably cheaply mirror too, but it is still a lot!

[ThomasHarte]

I think that you could store everything at 1 bit and probably cheaply mirror too, but it is still a lot!

That was with mirroring factored in, though I misremembered the 21, that was before making cuts to get to 18. The minimum of frames you'd need somehow to be able to draw, to get the same animation as other platforms is two frames for standing still, an eight-frame walking animation, seven additional frames for the jump (for eight directions total, one of the walking steps being used for upright), and at least one to represent shock after hitting the ground from a great height.

That said, I've clearly forgotten to allow for rotational symmetry in that jump animation. So you could trim there with rotate-by-90 and rotate-by-180 sprite plotters, assuming you can get those below the cost of six additional images.

I think that if you did it by hand you could probably separate out the body and limbs, but I didn't see any obvious substantial savings there if it were a pure question of data.

EDIT: specifically, I was eyeballing the sheet below which, as the text says, is from the C64 version of Crystal Kingdom Dizzy. No need for the two swimming frames for most titles in the series,four frames for the rarely-seen fell-too-far animation could be just one with limited gameplay effect, and looking more closely the walking animation isn't actually eight unique frames. So I've actually done terribly at my estimation. Assuming the rotation-by-multiples-of-90 code I think it'd be:

• two frames for standing still;
• one for fell too far;
• four for walking;
• two for jumping.

Which is actually only 9. And most of them are 21 pixels tall rather than 24, but none is 16 or fewer across, so actually even the very naive storage is less than half a kilobyte. I was way off.

[MyJumpersFullOfFears]

I don't think Codemasters did many games at all for the BBC Micro, possibly because they just started out doing C64 / Spectrum stuff, or more likely because they looked at the commercial side and decided it wasn't worth it.

Fruit Machine Simulator was the only Codemasters title that was ever released on the BBC Micro and Electron as well as the Sinclair ZX Spectrum, Commodore 64 and Amstrad CPC (it was also released on the Atari ST and Commodore Amiga under the name Advanced Fruit Machine Simulator):
http://bbcmicro.co.uk/game.php?id=851

Also, if anyone on here decides to unofficially convert the original Dizzy: The Ultimate Cartoon Adventure for the BBC Micro, they may wish to use Jon Paul Eldridge's title screen and in-game themes from the Amstrad CPC version (rather than David Whittaker's title screen theme from the Sinclair ZX Spectrum and Commodore 64 versions, as they did not have an in-game theme), while still making use of all eight colours from the Sinclair ZX Spectrum version. Furthermore, would the spinoff titles (Fast Food, Kwik Snax, Bubble Dizzy, Dizzy Down the Rapids and Panic Dizzy) be eligible for unofficial conversion, along with the December 1990 issue of Crash magazine's demo Dizzy Three...and a Half: Into Magicland?

[picosonic]

Not sure if I've posted about it before, but I am in the process of porting Dizzy 3, aka Fantasy World Dizzy to the Beeb.

Dizzy 3 loading screen

dizzy3_loader_beeb.png (14.03 KiB) Viewed 3013 times

It uses all the original graphics and levels, some from Spectrum and some from CPC version. The code is loosely based on the original z80 source code which was made available recently.

I've got to the point where I can view levels (which are streamed from disc as needed), I've also got the speech at the start to work. On the disc image is my attempt to use the music from the Amiga version as part of the loader screen.

Very much a WIP as I don't have much time, but the next step is navigation then object interaction.

dizzy3.ssd

Dizzy 3 progress so far

(43.5 KiB) Downloaded 30 times

[tricky]

Looking good.
Are you planning on changing the rendering from EOR?
If you can redraw the background quickly, OR might work well.

When I was looking at the memory footprint, I was thinking multiple copies of each sprite for each pixel offset within the byte so I was way off too but in the other direction!

[picosonic]

Are you planning on changing the rendering from EOR?
If you can redraw the background quickly, OR might work well.

When I was looking at the memory footprint, I was thinking multiple copies of each sprite for each pixel offset within the byte so I was way off too but in the other direction!

Thanks for the comments.

I will likely end up using COPY plotting for sprites with backgrounds stored.

But the memory footprint is very tight, which is why I'm having to stream the level data as you change rooms. It'd be better on a B+ or Master, but I'm sticking with the stock BBC model B for now.

I plot the level tiles using COPY/XOR with flip and clip, and they draw pretty quickly.

[tricky]

Cool, sounds good.
I always target the B, although a couple have needed sideways ram which is on every emulator and more than half responder's model Bs.

[BeebMaster]

Looking forward to Dizzy on a Beeb, I bet it will look great on Station 129's Cub!

[picosonic]

I ran it at the centre for computing history earlier in the year on Tom Williamson’s Beeb (WiFiSheep)

Running on a Beeb

[AJW]

---

The fun speculative part:

The early Dizzy games use tilemaps for their screens; having had a quick look at the map for Fantasy World Dizzy there are 58 screens total. On the Spectrum each screen is 30 columns by 17 rows and there are clearly a lot more than 16 tiles so naively let's say an uncompressed 58*30*17 = 29,580 bytes of map data alone.

The final two 8-bit games were written by a different team and switched to a Citadel-esque vector description of screens in order to fit more than 100 in but the change is pretty obvious. So I don't know that Citadel provides a useful data point on the storage issue.

I guess it's not impossible you'd be able to compress the map data enough to fit into a 32kb machine though, if you were happy with Mode 4 or 5-esque graphics? I think it might need to be a manual job though; if you look at something like the image below then you or I could encode it as a painter's algorithm-style three tree trunks, add branches and leaves, overpaint barriers and floor, and fit that into less than 510 bytes.

That said, I wouldn't be surprised if you ended up needing to abridge the original content.

Would using strings compress it? That is, stating the object,x,y and number of times?

Is that the same as a vector description of screens?

[picosonic]

In the original Spectrum files, which are very well compressed but only to 9175 bytes ..

The screens are each built from a number of tiles which have various attributes including

tile id
x
y
colour
solid or not
draw mode (normal/OR/XOR)
horizontal flip or not

the x and or y can be off screen so may require clipping

screens tiles must be drawn in the right order to make up the level correctly