Changes
/* How these should have looked */ Atic Atac
* Xyphoes Fantasy
* [[Head Over Heels]]
* Atic Atac
Some CPC games share similarities with the Spectrum version, and probably share a lot of code, yet are in mode 0 (16 colours, lowest resolution). [[Ocean]] made a lot lilke and thanks to a more professional graphic treatment (compared to many other British companies) and actually good porting tactics this produced some of the finest CPC games.
*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.
====Input====
* The 48K spectrums had a rubber membrane keyboard, later versions had proper keys, and the Amstrad made Spectrum's have the best keyboards. The early Amstrad CPC464's and 664's had really good strong keyboards, comparable to those on the BBC Micro, whereas later ones were more flat and less good. Both Amstrad and Spectrum have a good selection of keys.
'''NOTE: Sinclair Research (the Spectrum's manufacturer) was acquired by Amstrad after the Spectrum 128K had been made. '''
Amstrad then improved the build quality and enhanced the Spectrum's design. The result was that the Spectrum +2, which was closer in looks and build to the CPC464/6128 (same kind of compact keyboard as CPC6128, but built-in "Datacorder"). The Spectrum +3 was also quite similar to the Amstrad CPC6128 because both had a internal 3" drive. So the Spectrum became closer in design to the CPC. However, the overall hardware of the Spectrum didn't change, the graphics were the same, the sound was the same, but those later Spectrum's had built in joysticks, built in cassette or disc, connections for printer etc, just like the CPC, but almost all of which the Amstrad had starting with the CPC464.
===Disc drive===
===Consequences of a Spectrum Port===
====Input====
The Spectrum has more joystick standards than the CPC, however reading the keyboard and joysticks and handling the input on the Spectrum is much simpler, takes less code and takes less CPU time than on the Amstrad.
On the Amstrad it is best to read the keyboard and joystick in one pass and store the data into a buffer which can then be queried later. Then read from this buffer when you need to check the inputs.
====Disc Loading====
* Recolour the graphics using the Amstrad's palette to improve the look.
====Colour Clashfrom the Cell based colouring====
The cell based colouring used on the Spectrum has its disadvantages. [[image:clash.png|right|thumb|Colour clashing in Knight Tyme. Observe the appearance of the character sprite as it merges with the background. (Background colours have priority here in this game.)]]
* Super Wonder Boy (Monochrome background and monochrome sprites)
* [[Deflektor]] (main play area has one set of colours, status panel has another set)
====Advantages of the cell based colouring====
The Spectrum's cell based colouring has advantages.
===== Conveying state on a HUD =====
The state of a game play element on the HUD can be coloured accordingly. e.g. a bomb that is about to explode could change colour from white to red.
'''What should be done on CPC:'''
* If you have enough free palette entries, e.g. mode 0, then you can change the colour for the pen used to display the item in the palette. This is quick. However if you are using mode 1, then the number of palette entries is much more limited and you should draw the bomb in a different way. The consequence of this is that you may need to store additional graphics for this and it will take much longer to update the HUD than on the Spectrum.
===== General colouring =====
Since the background and foreground colour can be defined per cell then you can use all the Palette of the Spectrum at once.
'''What should be done on CPC:'''
* If you are using mode 0 then you are free to define the colours per pixel from the 16 colour palette. This is ok if the chunkier pixels can be used, not so good if there is detail in the graphics that needs to be retained.
* If you are using mode 1 then you will see less colour. You can set the colour palette for multiple regions on the screen, or you can use the 4 colour palette more creatively.
====Sound====
There is 1 sound source on 48K spectrums: it's its beeper, and 2 sources of sound on 128K spectrums: beeper and AY.
Beeper sound is simple. The spectrum has a speaker which you can turn on/off through a I/O port on the Spectrum's ULA. To make different sounds, you turn it on and off at different rates, all under control of the CPU. Speaker sound is CPU intenstive intensive because the timing is all done through the CPU and delay loops. The consequence on the Spectrum is that not many games have beeper music during the game, and those that do are often staccato like (e.g. Manic Miner) (the game takes some time to update, then some time for sound, and this repeats). If the sound was made for the Spectrum beeper, this would need to be converted to AY sound for the CPC, the result would not be exactly the same.
Sound written for the AY in 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. When this is done, the music is almost the same.
Consequences:
* The pixel data and colours are stored in a different way than the CPC, so some conversion must be done before the graphics can be used. Either the graphics are remade, or often converted through some automatic process.
* There is a trade off between mode 1, keeping the same resolution as the Spectrum but having only 4 colours, or using mode 0, with half the horizontal resolution but 16 colours. The choice depends on the detail required in the graphics.
The following sections describe possible ways to handle the graphics on the Amstrad.
=====Graphics with transparency=====
======Storage======
A common way to do this is on the Spectrum is to store 1 byte of mask, followed by 1 byte of pixel data, and to repeat this for the width of the sprite divided by 8. (Each byte representing a 8 pixel wide single line slice of the sprite).
If we consider a sprite which is 16x16. Each byte contains 8 pixels. For each line 2 bytes would be needed for pixel data and 2 bytes for mask. The total storage space required would be (2+2)*8 16 = 32 64 bytes.
If we consider mode 1 on the Amstrad, and we used the same representation, we could freely use 4 colours for the sprites. The Amstrad would also need 2 times the ram space to store the data, because in mode 1 there is half the number of pixels per byte.
So, each byte contains 4 pixels. For each line 4 bytes would be needed for pixel data and 4 for mask: (4+4)*8 16 = 64 128 bytes.
However, if we sacrifice 1 colour, so we have 1 pen which is fully transparent and 3 for opaque sprite colours then we don't need the mask to be stored this way. The mask is common for all sprites and we could store this as a single 256 byte array. We would still need 4 bytes for the pixel data but the result now is: 4*8 16 = 32 64 bytes. The same weight as the Spectrum.
Mode 2 is generally not used for games on the Amstrad because of it's lack of colour. The pixels in this mode are half as wide as the Spectrum's. If the Spectrum data was used directly, which it could be, then the sprites would be half the width of the Spectrum's. We would still be forced to store mask and pixels In this case the data storage is the same as on the Spectrum, and . If we wanted to maintain the same resolution we would need to double up each pixel, effectively magnifying it in the width by 2. The result would be twice the size of the Spectrum data.
If mode 0 is used, we could either store a mask and byte, as for the Spectrum, or more commonly we use pen 0 for full transparent and leave the other 15 pens to define the sprite. We could then use half the number of pixels horizontally and lower resolution too. Each byte now contains 2 pixels. The sprite is 8x16 now = (8/2)*16 = 64 bytes. So again twice This the same storage sizeas for mode 1. If the size of the sprites were too small, then we would need to increase the size and the storage space.
Therefore, depending on the representation, this would determine how much ram is consumed on the Amstrad.
The best it seems is choices are to go for mode 1, and use a common mask table, with 3 colours per sprite. The situation is different if you consider tilesOr use mode 0, here we don't need use a common masktable, with 15 colours per sprite. For the spectrum a 8x16 tile: (8/8)x16 = 16 In both cases we use 256 bytesmore than the Spectrum equivalent graphics. CPC mode 1: (8/4)x16 = 32 bytes CPC mode 0: (4/2)x16 = 32 bytes CPC mode 2: (8/8)x16 = 16 bytes
So we show that some games could be recoloured and still use about the same amount of data as the Spectrum.
The above do not consider the size or speed of the code to clip or draw the sprite to the Amstrad's screen compared to the Spectrum code. The values above assume the Spectrum version is not storing pre-shifted sprites, or using a pre-shift table, and when drawing to pixel positions is shifting the pixel data during draw. The comparison becomes more complicated when these are involved.
Examples of games probably ported from the Spectrum (the use a Spectrum sized screen), in mode 1 and recoloured:
Examples of games where re colouring could have been done:
* [[Pacmania]]
=====Graphics without transparency=====
======Storage======
Tiles are often used to define background graphics. These are opaque and don't need masks. The benefit here is that on CPC we can use all the colours in the palette, so for mode 1, all 4 colours can be used and in mode 0 all 16 colours can be used.
However on CPC generally non-transparent graphics will often take more storage space:
For the spectrum a 8x16 tile: (8/8)x16 = 16 bytes.
CPC mode 0: (4/2)x16 = 32 bytes
CPC mode 1: (8/4)x16 = 32 bytes
CPC mode 2: (8/8)x16 = 16 bytes
In mode 0 and mode 1, the tiles on the CPC will take twice as much space compared to the Spectrum. This will impact the memory used and depending on the number of tiles this is a significant memory impact.
=====Real-Time Conversion of Spectrum graphics=====
A common way to get the Speccy game running on the CPC and using the same storage space for the graphics was to perform real-time conversion of from the Spectrum graphics.
* Graphics are stored on the Amstrad in the same format as on the Spectrum (2 colour, 1BPPwith sprites having masks)
* Amstrad's mode 1 is used to maintain the same pixel resolution.
* A routine function converts the graphics on-demand, while the game is running, into the form that is displayed for the screen.
Needless to say, this enabled the port without the use of additional graphics artists, so . Therefore it was would be cheaperand easier if a programmer was tasked with making a conversion alone.
Disadvantages:
* This process takes a lot more CPU power compared to the Spectrum version, because in addition to drawing and erasing the sprites, the pixel data must also be converted at the same time.
* This resulted in a significantly slower game.
* Amstrad version had less colours (often as little as 2 colours)
Advantages:
* Pixel data took less RAM compared to storing than if it was stored in an Amstrad's mode 1 native form, so the game could run on a 64K Ram machine (CPC464 and CPC664, 464Plus).* If the colour attributes of the Spectrum were not simulated then the attribute data would not need to be stored for the CPC.
=====Mode 1 and screen dimensions=====
Amstrad's mode 1 is the closest mode which compares with the Spectrum's graphical abilities.
However, the CPC has a different "pixel clock" compared to the Spectrum. The CPC was designed for a 320x200 display instead of a 256x192 display and in fact the the pixels are smaller on the screen when you compare mode 1 (the closest equivalent on the CPC) to the Spectrum.
So when the screen is reprogrammed, you end up with a larger border on the CPC.
This (the larger border) led to the false argument that the CPC's resolution was inferior to the Spectrum one although the amount of pixels on the screen is EXACTLY the same.
=====Mode 0=====
When using mode 0, the screen can be reprogrammed to use the same sized screen as when using mode 1. However the resolution would be 128x192.
Using mode 0 has additional impact on the gameplay and game logic:
- there are fewer pixels horizontally therefore both tiles and sprites are described by fewer pixels in width (although pixels are wider). Then any calculations that use pixel coordinates will need to be adjusted. This includes positioning sprites on the screen, sprite to sprite collision, converting sprite pixel coordinates to a tile map location, converting sprite pixel coordinates to a collision map location, determining if a sprite is moving off the right side of the screen.
If the original sprites were square on the Spectrum (e.g. 16x16), then with mode 0 they are 8x16, and we may need additional code for these calculations to handle that.
- movement per pixel will be faster horizontally than vertically. We can accept that, or if movement is meant to be the same in all directions then sprites may need to move faster vertically to ensure the movement is consistent. This then has an impact on gameplay because sprites will take less time to move over the screen and any time based goals may need to be adjusted to compensate and make the game goals consistent.
Using mode 1 is the route to a quicker port because there are less changes to the game code.
=====Screen dimensions=====
By setting CRTC register settings the Amstrad's screen dimensions can be reprogrammed to match the Spectrum's.
The normal values used are R1=32, R6=24.
There are advantages to reprogramming the screen dimension to match the Spectrum's.
* The gameplay is similar because the player sees the same amount of map and there are the same number of enemies and they move in the same way.* Graphics/levels would not need to be designed for a wider screen (e.g. in mode 1, 320 compared to 256)* For a smaller screen less memory is used for the Amstradscreen (16KB vs 12K). The memory used by the screen is the same regardless of CPC mode used. Unused areas can be used to store graphics, code and music. For a 320x200 CPC screen normally takes 16Kat &c000, but the unused areas are: c600-c7ff, ce00-cfff, d600-d7ff, de00-dfff, e600-e7ff, ee00-efff, f600-f7ff, fe00-ffff =====Random numbers===== Sometimes Spectrum games generated random numbers by reading from the Spectrum ROM which is always readable in the memory range &0000-&3fff. ''Consequences for CPC:''- There is not enough memory to store the Spectrum ROM in the Amstrad's memory therefore the same method can't be used. It may be possible to store a small part of the ROM depending on the memory range read by the program. It is possible to use the CPC's ROM when reduced paged in size but it takes 12K's contents will differ so the random numbers will also differ and therefore the gameplay will be different (although maybe not enough to be an issue). An alternative on the CPC is to use a function to generate a random number - which may result in more CPU instructions compared to the Spectrum random number generation method - or worse read the R register which is not really random enough. =====Double buffering===== TODO: =====Memory arrangement===== Spectrum game's often use the memory from &5500-&ffff. ''Consequences for CPC:''- If you are not using a custom disc or tape loader then during loading you will need to preserve the firmware memory regions. The easiest thing to do is start the game lower in memory (&0040), use the default screen at &c000-&ffff, and then once loaded copy data over these areas (provided you are not doing furthur loading/saving).
====Original consequences (under construction)====
*Last Ninja2
*Myth, history in the making
*[[Saboteur ]] I
*Saboteur II
*SWIV
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.
==Amstrad interrupt positions==
The following image shows where the Amstrad's interrupt positions are located relative to the screen. Here the CRTC Register values used are R1=32, R2=42, R6=24 and R7=30 and the colours are changed at the start of the interrupt.
To have different positions vertically you can change the value of R7 (and if the monitor will accept it R5) to move the screen up and down.
For example Gryzor sets R7=29 to have a 1 char tall panel at the bottom in mode 1.
To change at later positions you can also use a software timing loop, or fill the time with other code to delay the colour change from a chosen interrupt position.
[[File:Interrupt_positions_spectrum_sized_screen.png|Screenshot of Amstrad interrupt positions showing where mode and colours can be changed quickly relative to pixel graphics. R1=32, R2=42, R6=24,R7=30]]
This image demonstrates that if you wish to use mode 1, and change palette colours for HUD and game area, then the graphics need to be arranged or re-sized so that the colour change positions are most optimal. For some games, the dimensions of the HUD or play area may not allow the palette to be changed easily.
[[Category: Games| ]][[Category:Programming]][[Category:Games Programming]][[Category:CrossDev]][[Category:CPC History]][[Category:Non CPC Computers]]
