Difference between revisions of "Speccy Port"
(→Colours & Colour Clash) |
(→Colours & Colour Clash) |
||
Line 83: | Line 83: | ||
What they should do for CPC: | What they should do for CPC: | ||
* Recolour the graphics appropiately for the CPC in either mode 1 or mode 0. | * Recolour the graphics appropiately for the CPC in either mode 1 or mode 0. | ||
+ | * Use the Amstrad interrupts and change the colours multiple times each frame, this will given each region it's own colours increasing the number of colours on screen. Ideal for HUDs. Note than any sprites or graphics that move over the transition will change colour. | ||
====Sound==== | ====Sound==== |
Revision as of 08:32, 19 April 2011
A Speccy Port or Spectrum port is the name given to a game which has been converted directly from the Sinclair Spectrum with little or no changes to the Amstrad CPC.
Mostly the Amstrad version ended up fairing worse than the original Spectrum version with the following results:
- Less colours
- Slower gameplay
These facts are not true for all "Spectrum Ports" because some ended up decent.
There is anger from Amstrad users in general, because they feel that if more time had had been taken on the Amstrad version, we could have had a version that used the abilities of the Amstrad better, looked better, perhaps sounded better, and played as well or better than the Spectrum version.
On a more positive tone, those speccy ports had the merit to exist, or else Amstrad may have a smaller games catalogue.
It is worth noting that Spectrum ports also existed on MSX, Enterprise and C64.
Contents
Reasons
The ZX Spectrum shared similar hardware with the Amstrad CPC (see Machine comparions).
The Spectrum was very popular and with the CPC having a much smaller market share, it made sense to develop the Spectrum version first and to save on time and money, the Spectrum code, music and graphics were re-used. (A typical port to the Amstrad is said to have been done in 3 days so was financially good).
This phenomenon was more prominent in the UK, where the Speccy was the dominant machine. In other markets, such as France of Spain, where the CPC was very popular, games were coded from scratch for the CPC, often using an Atari ST for Cross Development
Machine comparisons
Spectrum (48K machine) has 48K RAM, approx 6.5k of this is screen. The Amstrad has 64K ram, approx 16K of this is screen.
Spectrum and Amstrad both have a Z80 CPU.
The CPU runs at a similar speed (3.5Mhz in Spectrum, 4Mhz in Amstrad) (Note, both systems do not run at optimum speed due to waits inserted by the video hardware).
Spectrum and Amstrad both have a bitmapped display.
They have a similar screen size. Amstrad's screen can be reduced in size to match the Spectrum's (256x192). Normal display size on Amstrad is 320x200.
Spectrum (128K model and later) and Amstrad both have an AY-3-8912 sound chip. (1.7Mhz clock for AY in spectrum, 1.0Mhz clock for AY in Amstrad).
Spectrum 48K had a 1-bit beeper sound. Playing sounds through the beeper is very CPU intensive. The Amstrad doesn't have a beeper. The only way to simulate the beeper sound would be to convert it to AY sound.
The size and aspect of the pixels in the Spectrum's bitmapped display are comparable to the pixels in Amstrad's mode 1 bitmapped display.
The Spectrum's video ram takes approx 6K. The Amstrad's video ram takes 16K (approx 12K when screen is reduced).
The Spectrum 48k can't do double buffering in hardware, the Amstrad can. (To fix this problem on Spectrum they stored a bitmap in ram which they drew to, and then wrote changes to the screen). On the Amstrad you can use hardware double buffering, but then you need to sacrific twice as much video ram (e.g. 2 x 16K).
The Spectrum has a fixed palette of 16 colours (8 colours with bright versions of each making 16 in total). Amstrad has a palette of 27 colours. In mode 0 you can choose 16 of these, in mode 1 you can choose 4 of these, in mode 2 you can choose 2 of these.
The Spectrum's screen is "attribute" based. Each 8x8 cell can be assigned a background and foreground colour (and both colours must either be non-bright or bright). There is also the choice to flash the colours. This colouring results in "attribute/colour clash" on the Spectrum. The Amstrad's screen doesn't have this, and there is no restriction on how the colours can be placed.
The Spectrum can display all 16 colours on the screen. The Amstrad can only do the same in mode 0, but this has fatter pixels. If the CPC's mode 1 resolution is chosen, this is not possible because only 4 colours can be chosen.
The Spectrum has 1 interrupt per 50Hz frame, the Amstrad has 6 in fixed locations through the frame.
Normally Spectrum graphics is stored in 2 colours, which means 8 pixels for each byte. In Amstrad mode 1, each byte defines 4 pixels. So for the same graphics you often need twice the RAM on the Amstrad. (This is a case where graphics without transparency are used). If transparency is used, then the amount of data can be the same.
Neither had hardware sprites, therefore you have to use the CPU to both draw and erase the sprites.
Amstrad has hardware scrolling, Spectrum does not.
Consequences
Colours & Colour Clash
The cell based colouring used on the Spectrum has it's disadvantages.
When moving a sprite over a background, or a sprite over another sprite, and if both have colours you have to decide which colours take priority. It is not possible to have all the colours together because of the colour limitation within each 8x8 cell.
This then means that the graphics with a lower priority then takes on the colour of the higher priority graphics. If a sprite's colours takes priority, and it moves with pixel by pixel movement, as soon as it enters a new cell, the background will take on it's colours. The colour clash seems to extend furthur than the sprite. This is down to the 8x8 cell colouring.
Possible resolutions on Spectrum:
- Remove colour from the display so that background and sprites use the same colours, clash is eliminated.
- Move sprites in cell based movements. The colours still take priority but the clash is less of a problem.
- Add a black border around the sprites. Clash occurs, but because of the border it is not seen.
Consequences for porting to CPC:
- If colour priority, colour clash exists: CPC version has the colour clash simulated which is unnecessary.
- If 2 colours are used and colour clash eliminated: CPC version lacks colour, same as Spectrum
- If cell based movement is done, then CPC version has the same movement whereas it could be pixel perfect on CPC.
- If black border is used, CPC has the unnecessary black border.
- Because the CPC can't replicate the attribute system in mode 1, this means the mode 1 version has even less colours than the Spectrum version. The CPC version has 4 colours, compared to up to 16 possible colours on the Spectrum.
What they should do for CPC:
- Recolour the graphics appropiately for the CPC in either mode 1 or mode 0.
- Use the Amstrad interrupts and change the colours multiple times each frame, this will given each region it's own colours increasing the number of colours on screen. Ideal for HUDs. Note than any sprites or graphics that move over the transition will change colour.
Sound
Sound written for the Spectrum can't be ported directly because it would be out of tune, this is down to the difference in master clock given to the AY (1.7Mhz on Spectrum, 1.0Mhz on Amstrad). The music would need to be altered.
If the sound was made for the Spectrum 48K beeper, then this would need to be converted
What they should do for the CPC:
- Compose the tune for CPC
- Convert the tune to the correct master clock so that it is in tune
Graphics
The graphics take less RAM on the Spectrum compared to the CPC. This means the memory footprint of the game is larger on the CPC.
Original consequences (under construction)
The Amstrad CPC was one of the best 8-bit computers of its time in terms of graphical capabilities. But those advanced capabilities had an impact on CPU resources. As so many games were ported from the Spectrum, a machine with decidedly lower visual specs, the Amstrad range could hardly benefit from its main advantage while lack of optimization meant that aspects as scroll or playing area fared even worse than the Spectrum versions. You have to remember that Spectrum had less resources taken by Video RAM, so could handle animation or scrolling more easily. It is also a misconception to believe the screen was downsized in those games to gain processor resources. It was only done to use the Speccy graphics more easily, and we can doubt the code was (re-)designed so such a screen reduction would even gain CPU resources.
Interestingly, games in Mode 1 could have been good despite the lack of colours, if only those colours were used properly more often.
Most of them got their graphic totally unchanged, displaying some kind of colour attributes "artifacts", a tell-tale sign of a Speccy port.
On the other hand, as mentioned before, those games weren't always bad. Games with no need of scrolling and with re-coded graphics could actually be good.
The killer-list of the infamous speccy ports
Note: these lists are by no means comprehensive, they just include the most high-profile releases.
Computer originals Hits
(most of them ended up being decent) :
- H.A.T.E
- Highway encounter
- Lotus turbo Esprit challenge
- Fighting Warrior
- Vendetta
- Hard Drivin'
- Way of the Tiger
- Last Ninja2
- Saboteur I
- Saboteur II
The numerous CodeMaster or Hewson games are not listed. Many of them were cheap budget Speccy games to begin with, and were quite well ported or remained good...
Well known franchises
- Scooby Doo
- Thundercats.
- MASK 3 : Venom Strike Back
- Airwolf 2
Adult games
- Sabrina
- Samantha fox strip poker.
- Strip poker II
Movie Franchises
- Indianna Jones 3 action game.
- Back to the future 2 (half parts were straight speccyporked)
- Big Trouble In Little China
Arcade hits
- R-Type
- PacMania
- Salamander
- Dragon Breed
- Scramble spirit
- Black Tiger
- Strider
- Bionic Commando
- SuperWonderboy
- Double Dragon3
- Super Hang-On
- Enduro Racer
- Toobin
- Xybots
- Pit fighter
- Cabal
- Street Fighter
- Kharnov
Special Category of Death
- Myth, history in the making (grrrrr).
- Gauntlet 3
- SWIV
- Shadow of the beast
- Midnight resistance
The top list of the speccy ports
All those games are frequently used in 8bit wars style videos and reviews, hence they have served as a counter-argument to the CPC's superior abilities. Those games were well known hits ported on pretty much all computers of their time and therefore constituted the very basis of comparison between most systems of the era.
- Shadow of the beast
- Myth, history in the making
- Gauntlet 3
- SWIV
- R-Type
- PacMania
- Salamander
- Dragon Breed
- Scramble spirit
- Black Tiger
- Strider
- Bionic Commando
- SuperWonderboy
- Double Dragon3
- Super Hang-On
- Enduro Racer
- Toobin
- Xybots
- Pit fighter
- Cabal
- Last Ninja2
- Thundercats.
- Hard Drivin'
- Sabrina
- Samantha fox strip poker.
- Strip Poker II
- Airwolf 2
- Indianna Jones 3 action game.
- Back to the future 2
- Vendetta
The 3 levels of Speccy porting
Of course the level of porting could greatly depend on whatever strategy the programmers/graphists used to port the original Spectrum game.
- A monochrome game could remain monochrome or be recolored for the CPC, or only parts of it (only sprites or Tiles but not both - mostly only sprites.)
- A colored game with design-wise graphics (character based design) could be the exact same yet with even less colours.
- Or Tiles/sprites could simply be completely well re-done/re-drawn, even in Mode 0 sometimes.
Rushed and Lazy
The game is exactly as on the Spectrum, even displaying graphical artifacts as Colour attributes and/or monochrome display for the game's window but not always the HUD, which may even often feature extra colours thanks to Raster colour changes, yet this doesn't really help to see what happens on the game's window.
Also sprites may display Transparency/translucency with background's colour, a typical Spectrum "feature".
Probably achieved by using almost the exact Spectrum code and emulating the Spectrum attributes on the CPC.
Examples :
- PacMania
Typical example, yet it managed to be a nice game despite this. The title screen and HUD shows the color attributes and were almost completely unchanged, yet with less colours on screen than the Speccy version.
Ironically, the game manages to display 6 colours in the 4 colours Mode1 - yet the game's area remains completely monochromatic (coded in 1 bit) and colour attributes artifacts are still present.
- Black Tiger: Same as PacMania
- Super Hang On : graphics Transparency/translucency
- Enduro Racer : same as Super Hang On, even more displayed as Sprites more often cross the different colored parts of the screen (while jumping)
- Bionic Commando : there are even inverted/negative colored sprites
- Sabrina : same as Bionic commando
- Gauntlet 3 : HUD is properly recolored (3 shades) but in-game window is monochrome (1bit coded sprites and tiles)
- R-type : Monochrome background while sprites still are "coloured" as with Colour attributes, hence even featuring less colours than original Spectrum game, while the entire screen still displays more than the only 4 Mode1 colours...(HUD raster trick). This game was done in 3 weeks by only one man, who simply emulated the speccy stuff on CPC. Given that the Spectrum game was a great release the CPC port is not too bad.
Semi-lazy
Well redone graphically, but not always as would actually be needed.
Examples :
- HeroQuest: still has monochrome feeling (2 blue shades being used) while actually being properly 2 bit re-coded. Ditherings use 3-colour gradients instead of the Spectrum's 2, and the grey adds a feeling of more colour.
- Strider has recoloured sprites, displaying no attributes, but Backgrounds remains monochrome, and the game is sluggish (because the CPU must still convert 1bpp graphics into 2bpp), yet the HUD+Raster trick enable a 6 colours displayed on screen and the HUD looks good.
- Shadow of the Beast: No real 3-4 coloured ditherings or even additional colours thanks to dithering the 2 medium colours together in many graphics (exteriors or for many sprites), yet the square Spectrum attributes are not displayed, while the Spectrum version remains monochrome (in game window, not HUD) in order to simply avoid Colour clashes. Would have needed more development time and a real CPC version.
Good Job
Those games are often more to be seen as proper Cross-Dev.
Graphics, despite sharing a common ancestry, are well redone, and take into account the Amstrad power. Sometimes those games are not that well ported, yet their concept and gameplay are such that this is not that important: the game is simply too good to be annoyed by such detail as the use of Mode1, and they were still sufficiently re-done.
- Head over heels
This one was the prime example of what every Spectrum port should have been. Even the C64 version was totally like the Speccy version (monochromatic game's area) while the Amstrad graphics were perfectly recoloured and colour clash was avoided. Also as this games didn't need scrolling the animation was almost as good as in other 8 bit versions, and colour palette often changed inks to actually get a colourful feeling all around.
- Deflektor : example of a good speccy "cross development", thanks to a clever concept. Could perhaps have been better yet the concept of the game makes it a clever port. Details like the Tape version loading parts or the good chiptunes enable a proper CPC experience.
- Switchblade: the GX4000 cartridge version displays extra features such as large vertical ditherings in a lot of Red shades (sky) or PLUS Hardware sprites "patches" as extra coloured tiles. This is more than enough to get a properly coloured feeling.
Some Speccy port "done right" may also use Mode 0 instead of Mode 1. Hence being graphically fully CPC (yet tiles or sprites are still comparable in dimensions). The result may vary from awful (the code is not optimised enough for CPC) great.This can be seen in Space Gun: Mode 0 and even PLUS features, yet the attribute-designed-unmasked sprites remain, in a sluggish game.
Techniques used
Mode1 and screen dimensions
The use of Mode1 enabled the CPC to keeps the same graphics as Spectrum, in appearance only. While the square pixels looks almost the same, the code was completely different. Also, the CPC being set for a 320x200 display instead of a 256x192 display, the pixels are in fact smaller on screen, hence a bigger border was needed for the exact same resolution.
This (the larger border) led to the false argument that this was the CPC resolution and therefore it was inferior to the Spectrum one, although the amount of pixels on the screen is the same.
While some Spanish companies reduced the screen in order to get the game better running in low-spec 464, the infamous speccy ports just ran a reduced screen so the ZX Spectrum's code and graphics could run almost "unchanged".
Real-Time Conversion of 1bpp graphics
A common way to get the Speccy game running on a CPC was to get some routine to convert the existing and already coded 1bpp Speccy's Graphic Data (tiles and sprites in equivalent to Mode2 on CPC) into 2bpp datas (proper Mode1) when put into the video RAM. Needless to say, this enabled the port without the use of additional graphics artists, or a coder to redo the RAM mapping/addresses of such data.
But this came at a cost, CPU-wise since the CPU instead of simply having to take some bytes of data from reserve into the Video RAM has to convert them in real time, with the result being that a character couldn't use/display more than 2 colours while CPC had not such thing as character attributes.
Monochromatic playfield and Sprite Masks
Having a monochrome playfield on ZX Spectrum is a common way to have no colour clashes - simply because there are no colours to clash! Also, most of those games then had masked sprites. This meant that each set of sprites had another "sprite set" for the mask, being actually 2x1bpp (bit per pixel) sets of data.
Some games coders actually used this to get the Sprites coded in 2bpp and used one of the 4 inks in mode1 to be the mask. This then took up more RAM used by data than the original. As a result some of those speccy ports have sprites in another colour than the background, which is actually better in terms of playability/look.
An example of this is Super wonder boy which could have even used one more colour for the sprites, but didn't.
Needless to say, the Background Tiles and Letter fonts were still in 1bpp converted in real time so the CPU had no rest and such games weren't faster nor that much better looking.
On the other hand, some games, despite having such Masked sprite totaling 2bpp had absolutely no sprite re-code at all (although this could have easily been prevented). Black Tiger is such a case.
Nevertheless, those games had one advantage : the smooth movement of sprites.
Masked Backgrounds
Some (rare) games actually used a mask for the Bakcground tiles too. This explains why they could be fully recoded with no notable additional weight for the data. Such games are often Isometric games and are considered among the good speccy ports (or actual Cross-Dev).
Examples :
- Heroquest: the Background tiles are also in 3 colours. Yet there is a really poor use of the mask colour.
- Head over Heels: yet the colours are better used than in Heroquest. If you look carefully, there are 2 kind of "background" elements.
- Real non-masked Background (floor, walls) which use the full 4 colours,
- and masked elements such as Sprites, Doors, Platforms... which are 3 colours only.
Unmasked games and CPC colour clashes
This category includes some of the worse examples, since actual Spectrum deficiencies were ported to the CPC.
- Bionic Commando
- Enduro Racer
Attribute based Sprites and Animation
The cell based colouring used on the Spectrum has it's disadvantages.
When moving a sprite over a background, or a sprite over another sprite, and if both have colours you have to decide which colours take priority.
It is not possible to have all the colours together because of the colour limitation within each 8x8 cell.
The problem then comes down to is that the graphics with a lower priority then takes the colour of the higher priority graphics.
Such games had no smooth movement of sprites. The sprite moved "character per character". As such the sprites are unmasked, being not really more than "tile-mapped". This meant the sprites had to actually fill the character tile or there would be artifacts introduced for the unmasked character's corner.
This was a "good" other way to get rid of Attributes Clashes and having actual "colours" on ZX Spectrum. But some speccy ports were then emulating the attribute system, which can be quite bad because CPC in Mode1 has half the colours the Speccy has.
- R-Type
- Space gun: this game, although coming in the CPC era is not really good and was probably rushed to the release. Yet the Character based engine enabled enormous sprites - but lacked smooth movement. Such a technique was actually used for quite a fair amount of Mode0 games. This is not "Speccy port" but it is good to to mention, as it was a common game design technique for both machines.
- AMC (Astro Marines corps)
- Satan
Rasters
A common cheat was to get some Raster interrupt colour change so you could argue that the game is actually displaying more than 4 colours on screen while being Mode1. This is only to mimic some sort or Raster based Colours attributes yet is actually not a clever move in some way as getting some raster interrupt may take lots of CPU cycles. Also, despite the game displaying more than the allowed colours on screen, the playing area was still monochrome. In the end, all this did was getting the game even slower.
On the other hand this could also be done right:
- Deflektor : Raster done right.
- Strider : Raster done right. (useless but good looking)
- Thundercats : (though there are more playing area colours)
- R-Type
- PacMania
- Black Tiger
Many (if not all) of those games can actually run faster just by getting rid of CPU-wasting rasters.
Providing a game had to deal with 1bpp to 2 bpp conversion, Software Sprites and Scrolling and complicated gameplay, adding some Raster interrupt to the equation is a really bad move and a good way to waste even more CPU time.
Partial code re-use for proper CPC games
Some CPC games are in mode0 yet the similarities with the speccy version are still obvious. Ocean was actually a lot into this, but thanks to a more professional graphic treatment (compared to many other British companies) and actually good porting tactics (though not always the case) this produced some of the finest CPC games.
Those games are examples of Cross-dev done right. They remain quite playable because the CPU doesn't waste time to decipher 1bpp graphics or get Rasters interrupts.
- Robocop
- Chase HQ
Some of the games below were Mode1 but fully supported the 2bpp re-coding of graphics done right (by a human, not by the CPU in real time) hence got properly coloured backgrounds.
- Shadow of the Beast: basically an almost playable Amiga Demo from the start this just turns into a quite good speccy port on CPC.
- Midnight Resistance : some elements such as the projectile sprites (bullets, explosions) are certainly far too big on the CPC to get it smooth and fast enough. Also some animations should have skipped a few frames to lighten the proceedings. But at least this is an example of Mode1 looking good...
- Wec le Mans: excellent CPC version, just a bit on the slow side. Burnin' Rubber is the Plus version of this game, sort of.