Explanation of the procedure involved with Porting a Game fromSpeccy-CPC game?

[Puresox]

Any chance of someone giving an explanation ,in laymans terms, of the procedure that goes into porting a Spectrum game to Amstrad.
I'm no programmer , but I do appreciate trying to understand what goes into this process.
Can anyone give us a good run down of how this is done .?

[andycadley]

In the simplest terms you take the Spectrum code, replace all the machine specific code (reading the keyboard, drawing to the screen etc) and replace it with Amstrad specific code with the same input/outputs and then you're done. How difficult that is depends on where you're starting from (do you have source code? etc) and how dependent upon features of the Spectrum architecture it is (some games will use a column of black paper/black ink to automatically clip sprites for example). There may be additional complexity for games with a lot of colour, for example, as you may need to "emulate" the attribute system within your drawing routines in order for things to behave correctly (which is why you sometimes see "colour clash" in ported games, even though the Amstrad has no such limitation).


The more effort you're prepared to put into it, the better the end result will be. Redrawing all the graphics and redesigning parts to better suit the CPC can improve the end result.

[Joseman]

There are different procedures to make a spectrum port:

http://www.cpcwiki.eu/index.php/Speccy_Port#The_3_levels_of_Speccy_porting

I think that the type 3 "Good Job" is even a good game on CPC.

Talking about the type 1 "Rushed and Lazy", well, i did the Skool Daze port like this, i mean, i was not lazy nor Rushed, i only have to learn how to do it step by step.

If you have the source code and you're a expert coder i think that a port like Skool Daze can be done in days.

as andycadley said, you have to replace the spectrum specific calls to amstrad calls, in Skool Daze, the graphics, sprites and behaviour charts where "hardlocated", i mean, if the program increments 1 single byte, the program stops to works, and if you decrement the routine, the same. I think that the programmers did this for some reason and not for bad habits.

The advantage that i had is that skool daze code (sorry if i make mistakes, this was 1 year ago) starts at #6000, i changed the CPC screen memory to #0100 - #3EFF, and started my code in #3F04, that means that i had #6000-#3F04 -1 = #20FB -> 8.443 bytes to code my routines! (if i recall correctly), i even not bothered to alter the spectrum original routines!, i mean that in my port there are my routines, and the spectrum routines are still there wasting memory!.

Well this is lazy i know, if i coded my routines inside the spectrum routines and let 8k free, well, i know that i could remade some graphics, put more sounds, even i thought to put real voices on the teachers!

About the attribute system of the spectrum, i just ignored it, all the writes to the attribute system memory where removed, this is why my graphics are plain monochrome, i just ignored the colors on the spectrum, i convert the 1bpp graphics directly to the cpc screen memory.

If i wanted color on the Skool Daze port, then i could remade the 1bpp graphics to 2bpp graphics, this is a HUGE work, and of course the memory problem that this will bring, the graphics will double their size.

Or i could emulate the attribute system as the r-type original port makes (i think), this is problaby the best way to put colours on skool daze, but i didn't have the knowledge at the time.

Some people told me to make rasters and put different colours at different floor, but again, i didn't have the knowledge.

summarizing:

If you have the source code, then porting a spectrum game to CPC is easy, of course it depends of the game and how advanced is. If you do a lazy port, days. If you remake the graphics, the sounds, then perhaps weeks or 1 - 2 months.

If you don't have the source code and you disassemble the spectrum code... well just don't do it, is just crazy... Start the game from scratch. Every coder had his ways to do his routines, hell i even don't remember routines that i made 1 year ago!, you will need to learn thousands of lines that you didn't code!... This way of porting... well is not impossible... for me more than a year for sure!

[Puresox]

I didn't realise you had done the School Daze port. welcome port school daze
Thanks for both the descriptions , useful info. Not that I understand it all but it all helps.


Just another question regarding Jet Set Willy Final Frontier. The CPC was the original in this case and was converted back to the speccy, but it was necessary to do a lot of compression in order to allow it to fit. Any chance of giving a brief guideline to this process?

[Joseman]

I don't think that any compresion is needed to port a cpc game to spectrum

they need to convert 2bpp or 4bpp graphics to 1bpp spectrum graphics, then the graphics will reduce his size.

you have to realize that the spectrum screen memory is half the cpc screen memory 8k vs 16k, the graphics, sprites... they are memory double (mode 1) or quadruple (mode 0) on CPC!

i'm not fan of the spectrum, but i think that the attribute memory is some clever think to reduce memory requeriments, really to need only 1bpp graphics is a great advantage in terms of saving memory. But then there is the attribute clash that i hate and don't like on the spectrum... Well i don't think that anyone likes the attribute clash... but this is another history...

unfortunately is the other way... the CPC needs sometimes to lack things to allow an entire spectrum game inside... is that right Elite? Ghosts n' goblins? Anyone?

[TotO]

you have to realize that the spectrum screen memory is half the cpc screen memory 8k vs 16k, the graphics, sprites... they are memory double (mode 1) or quadruple (mode 0) on CPC!

The required memory is always 16K, as the resolution change too.

[reidrac]

When I ported "The Return of Traxtor" I had the source code (obviously, it is my game after all). I don't like "port", it was more like a conversion, in a similar way you would do trying to make a version of an arcade game in a 8-bit computer.

It took me a little bit over a month IRRC, I had to remake the graphics in mode 0 in the right size and, as you've been told already, had to change the routines for input, interrupt handling, audio and graphic bits.

On top of that I had to write the music using the AY chip, because the original game was for the Spectrum 48K and only had beeper.

Because I had some memory left I added some things like an extra tileset for people having problems to see colours in the original tileset, a jukebox, and things like that. Traxtor is not a memory hog and it fit in 48K, so converting to the 64K of the CPC I had lots of memory left; even with mode 0 graphics and the AY tunes!

Summing up: there aren't many things that you can reuse unfortunately, if you want to make a proper CPC game coming from another version (even if is Z80 based).

In Traxtor there are some bits of code that are the same (game logic, find matches in the board); but very often the games are designed around the features of the machine they're targeting, so the port in order to be "a good port" has to be more a remake than a port (IMHO), or my preferred term: a conversion.

[fano]

Speccy port is Evil, i'll never make one 

[andycadley]

Just another question regarding Jet Set Willy Final Frontier. The CPC was the original in this case and was converted back to the speccy, but it was necessary to do a lot of compression in order to allow it to fit. Any chance of giving a brief guideline to this process?

Now this specific example, I can tell you a lot about because I've spent a fair bit of time reverse engineering it. 


The original Speccy JSW is a fantastic game, but the code behind it is absolutely terrible. It's massively inefficient both in terms of how it stores levels and in the number of different temporary buffers it creates to draw the screen. As a result it's actually running a lot slower than the Speccy could manage and consumes much more memory than was necessary.


The "port" of this to the CPC is actually a complete re-write, the design of the game has been copied but the code is all new (which leads to some subtle differences in how conveyors work and removes some of the quirky bugs that some level-edited Speccy games rely on). A consequence of it just being written "better" is that level storage is a lot more efficient. This meant that JSW2 on the CPC is essentially just the "original" CPC version with a bunch of additional rooms added in the spare memory.


So then you get to JSW2 on the Speccy, which is a direct port of the CPC version using a technique not dissimilar to the one I described above (though the "other way round" of course). This is why the nasties in the Speccy version are restricted to one of four colours (a consequence of Mode 1) where the original Speccy JSW used its full colour selection. It's also why JSW2 on the Speccy plays faster and has conveyor behaviour consistent with the CPC versions.

[andycadley]

you have to realize that the spectrum screen memory is half the cpc screen memory 8k vs 16k, the graphics, sprites... they are memory double (mode 1) or quadruple (mode 0) on CPC!

It's not quite that bad, or at least in many cases. Consider, for example, a 16*16 sprite:


On a speccy that's 2 bytes wide and 16 bytes high for a total of 32 bytes. But a two colour bitmap doesn't give us any lenience for decent masking, so you're mostly going to have to augment that with another 32 byte pixel mask. A grand total of 64 bytes.


On the CPC it's 4 bytes wide and 16 bytes high (in Mode 1, as is the "equivalent" 8*16 sprite in Mode 0), so we're at 64 bytes already. However 4/16 colour sprites are much more generous in allowing us to be clever about masking, we can reserve one of our colours to be treated as transparent giving us 3/15 colour sprites with no extra mask. A grand total of 64 bytes then.

[Joseman]

The required memory is always 16K, as the resolution change too.

Hi @TotO

I wasn't talking about the screen memory as always is 16k's no matter the mode is.

I was talking that the sprites and graphics stored in memory are bigger on amstrad, 1byte are 8pixels on the spectrum, 1 byte are 4 pixels on the CPC (mode 1), we need 2 bytes on the CPC to paint the same with 1byte on Spectrum. Directly the same sprite or tile will take up twice memory than on spectrum.

Depending on the game, if there is not compression, and it has a lot of tiles and sprites and the spectrum memory is totally full, is evident that we will have memory problems on the cpc side (mode 0 is even worst).

I know that you know this TotO, i don't have too much experience in graphics as it can be noted on Skool Daze port.

Is more than possible that i'm mistaken!

Regarding Ghost N' Goblins... is possible that this was the problem for the lack of the last levels on CPC?

[Joseman]

Because I had some memory left I added some things like an extra tileset for people having problems to see colours in the original tileset, a jukebox, and things like that. Traxtor is not a memory hog and it fit in 48K, so converting to the 64K of the CPC I had lots of memory left; even with mode 0 graphics and the AY tunes!

are you using compressed graphics / tiles?

I think that depending on the game there will be problems with memory on CPC, but again, i must be mistaken!

[reidrac]

are you using compressed graphics / tiles?

I think that depending on the game there will be problems with memory on CPC, but again, i must be mistaken!

The tilesets and sprites don't compress very well if they're small, it is usually not worth it in my experience, unless is something large like a logo.

Traxtor used tiles of 12x9 to get a good shape & size for the tiles in mode 0, instead of the 16x16 used in the speccy version. It is a weird size but looks nice (benefits of using your own engine). Being a "tetris-alike" kind of game, there's no level data and limited number of sprites, so I had plenty of memory left for extras.

You're right that tilesets may use lots of space, but in my experience the biggest offender is map data. Magica uses around 60 bytes on average per map; that's 3K for 50 screens using compression and all the tricks I know to encode the screens

In comparison the complete tileset is only 960 bytes.

[Puresox]

I don't think that any compresion is needed to port a cpc game to spectrum

they need to convert 2bpp or 4bpp graphics to 1bpp spectrum graphics, then the graphics will reduce his size.

you have to realize that the spectrum screen memory is half the cpc screen memory 8k vs 16k, the graphics, sprites... they are memory double (mode 1) or quadruple (mode 0) on CPC!

i'm not fan of the spectrum, but i think that the attribute memory is some clever think to reduce memory requeriments, really to need only 1bpp graphics is a great advantage in terms of saving memory. But then there is the attribute clash that i hate and don't like on the spectrum... Well i don't think that anyone likes the attribute clash... but this is another history...

unfortunately is the other way... the CPC needs sometimes to lack things to allow an entire spectrum game inside... is that right Elite? Ghosts n' goblins? Anyone?

Yes the question about compression was just an additional question that I wanted to know, and as Andy was involved with the JSW Final Frontier game . I thought it an opportune moment to ask him . Because of the fact that Final Frontier was too large a program for the 48k Speccy it was necessary.

[Puresox]

A Futher question . I understand that 16k is what is allocated to screen RAM whatever mode you wish to use. But it seems that as Joseman says the different modes demand more K due to the size of sprites etc... have I understood that right?


So would a Mode 2 game, black and white or whatever combination , would this mode produce the best play ability if worked within and sprites done similar to say The Macintosh Black and white games?
Or does the Mode have other factors to consider?

[andycadley]

A Futher question . I understand that 16k is what is allocated to screen RAM whatever mode you wish to use. But it seems that as Joseman says the different modes demand more K due to the size of sprites etc... have I understood that right?


So would a Mode 2 game, black and white or whatever combination , would this mode produce the best play ability if worked within and sprites done similar to say The Macintosh Black and white games?
Or does the Mode have other factors to consider?

It doesn't really work like that, because ultimately you're making the same trade off between colors and resolution. A 16*16 sprite in Mode 1 needs 64 bytes and a 16*16 sprite in Mode 0 would need 128 bytes. But because pixels are twice as wide, your sprite would take up twice as much room on screen and look all stretched. So in the translation from Mode 1 to Mode 0, you'd actually want an 8*16 sprite which takes up the same amount of room on screen and only needs 64 bytes.


The oddity is actually Mode 2, because 1bpp graphics are difficult to draw in and you can't really reserve one of the pens to act as transparent in your sprite (unless you have very limited graphics). Instead you have to store a separate graphics mask, so the 64 bytes actually end up doubling up into 128 bytes, meaning its more memory intensive rather than less.


Of course there are tricks in all cases to reduce the effect. For example, games like Barbarian use sprites that are only three colour but drawn in Mode  0, halving the amount of memory required (at the expense of more complex drawing routines) - this also makes it easier to lift graphics straight from the C64, which is probably a more common reason to do it than the memory saving.

[Puresox]

Right I think I follow you with regard to the modes even-ing out. And with regard to the Mode 2 issue , if 1 other colour was available to use the situation would be dealt with?
Would Asteroids type game be hampered? (If attempted in mode 2?)Or have I missed the point?
Appreciate the info btw.

[andycadley]

If you have a plain background, like asteroids, it's not so much of an issue. But if you have detailed backgrounds it really doesn't work to only have one colour+transparent. If you consider even a simple sprite like Dizzy, his eyes would become see through and the background would bleed through - it quickly becomes messy and sprites just blend into the scenery.


There are tricks again which work in some cases, like only having transparency at the edges of sprites, but it starts to get trickier to draw whatever you like and you're just much better off in a mode with more colours.