Hello there, wondered if anybody can shed any light on this which has been bugging me for years:
Technician Ted on the CPC has Spectrum-style colour clash.
I don't just mean it runs in Mode 1 (4-colour mode), I mean if you get Ted close to another sprite (easier to see if the sprite is moving horizontally) and walk really close to it, you can see the colour bleeding from the other sprite into Ted.
It's actually amazing that they did this, as from a technical point of view I can't see how it would be easily accomplished - but I'm sure it's there.
Would love to know how / why the developers did this (was always disappointed too that the amstrad version didn't have the animated loading screen with loads of Teds walking backwards and forwards across the screen).
Anybody else spotted this?
Well, I first quick guess.... The ported the game from speccy to CPC and the port was just too perfect... Now I will take a look at the game itself...
EDIT: Seen what you mean... The sprites are XORed on the Screen, therefore if they overlap, they get other colors.
Hey TFM, thanks for the reply.
I understand what you're saying, but surely if they were xored that would only affect pixels that actually overlapped - whereas this seems to colour non-overlapping pixels? (could be wrong though).
Hmmmm..... I gotta take a second look :)
Welcome in the forum here :) :) :)
Yeah, sometimes they actually emulated the attributes so the code needs less changes.
This is really the worst speccy port screw crook dick move ever... >:(
It feels like having a straight speccy port on an MSX2...
Thanks MacDeath :)
Can you think of any other ports where this was done? Seem to remember this was the one and only time I spotted it...
I can remember a few ones, for example one of most shameful is Spirits (http://www.cpc-power.com/index.php?page=detail&num=2030) :P
Yes there were a couple that did this, and really I don't know why. I think it would take more time and effort to code this, than to draw proper cpc mode 1 sprites.
The ultimate, I think is Bionic Commando.
It has the cheek to have a "colour" version on one side and a "mono" version on the other.
Take a look you will be thinking "wtf?"
Bionic Commando:
http://www.cpc-power.com/index.php?page=detail&num=397 (http://www.cpc-power.com/index.php?page=detail&num=397)
Ok, enough, or MacDeath will go crazy.
Haha, that's crazy - like you say, seems harder to implement than just drawing normally...
haha, yeah, Bionic Commando was infamous for this...
Plus they screwed up the sprite : it is inverted in colours actually...
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=397&slot=3&part=A&type=.png)
yurk...
Many speccy ports' sprites displayed the "white halo" often used to lessen a bit the colour clashes or the fact the speccy version was monocolour...
exemple :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1417&slot=6&part=A&type=.png)
Look at the boss. the "green outline" is a common exemple of speccy graphics remains, despite the thing all recoloured in Mode1. I don't have others exemple at the moment, wait...
this perhaps :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=854&slot=3&part=A&type=.png)
Sometimes the "colour clashes" was a bit more subtle.
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=811&slot=3&part=A&type=.png)
yeah... this is coulour clashes of a kind.
Looks like they used Mode0 and a raster palette change... not sure it would even be better actually.
Codewise it makes no sense on a CPC to have those shitfeast "emulation" applied... no wonder those games were often laggy.
I think games like Myth actyally have sort of attribute system, but it is not clashing because it sues a character based system... hence the "dark corners" when you are behind some objects.
Otherwise many games displayed "attribute clashes" artefacts... often in intro screen as well, when not re-touched and straight from speccy.
Just look at Pacmania, perhaps Victory road too... (and many more, Xybots...)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=109&slot=1&part=A&type=.png)
Oh, Pacmania :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1591&slot=1&part=A&type=.png)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1591&slot=2&part=A&type=.png)
WTF ? I don't want useless CPU grabbing Rasters, I jsut want actual colours and my 6128 actually exploited...
(http://www.cpcwiki.eu/imgs/6/6f/Recolored_pacmania1.png)
something like this coud really have been great and even faster.
Sad part : when the graphics are 1bpp + 1bpp mask for sprites (= 2bpp de facto, as in most masked sprites monocolour speccy games), and 1bpp for backgrounds... yet they failed to set another colour for the sprites, or to pass them in 2bpp with one ink used as mask, as it would need to modify whole routines... lol.
typical scene from the Amstrad era :
Let's try this game :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=962&slot=1&part=A&type=.png)
Wow, a Mode0 intro picture, thise looks nice and promising. and great Tim Follin music, yeah !!!
Let's see the rest :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=962&slot=3&part=A&type=.png)
Hey, this Mode1 is well used, I like how this thread is going...
.
.
.
.
.
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=962&slot=4&part=A&type=.png)
Oily sh***t, WTF ? give me my money back, fuc****ing U.S Gold !!!
Also my personal crusade :
Black Tiger CPC-Spectrum Comparison - CPCWiki (http://www.cpcwiki.eu/index.php/Black_Tiger_CPC-Spectrum_Comparison)
(http://www.cpcwiki.eu/imgs/a/aa/Black_tiger_screenshot.png)
instead of :
(http://www.cpcwiki.eu/imgs/2/22/Black_tiger_redone_11_CPC_mode1.png)
Fick dish, Tiertex, you stole both my money and childhood's innocence...
Wow, those title screens in particular are just plain ridiculous.
I was always happiest when developers went for Mode0, chunkier obviously, but so much nicer (I'm thinking Nebulus, Solomons Key, Rick Dangerous, Gauntlet, etc).
Always used to worry when I saw the name Tiertex handling the conversion...maybe that's a bit unfair.
Tiertex even raped Indianna Jones harder than Georges Lucas did with the crystall skull movie... way before.
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1152&slot=6&part=A&type=.png)
south park was somewhat not enough close to reality... and too late.
Indiana Jones Raped - South Park (http://www.youtube.com/watch?v=eG4W0LbIvW0#)
Another good example is "Oberon 69" - a really nice Spanish game, where I liked the gameplay a lot.
But the GFX are monochrome, as usual, for a speccy port.
I once patched this game to work with 128k CPCs and also added English translation, based on the Amiga version, which wasn't much better, but a bit more colourful.
http://www.cpc-power.com/index.php?page=detail&num=2537 (http://www.cpc-power.com/index.php?page=detail&num=2537)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=2537&slot=2&part=A&type=.png)
Saddly I must admit Spanish were also guilty of speccyporting...
Oberon 69 (G.LL/Diabolic) (1990) (Amstrad CPC) (http://www.youtube.com/watch?v=LEBsGccpTzQ#)
Anyway this games is not lazily ported...
there are no colour clashes actually... you can see the sprites overlaying on the backgrounds properly... so this is not really that bad and the games seems to play well.
Still you can see the "white halo" on the dude's face in the bottom right corner.
Anyway, this game looks nice playing.
reminds me of Slime World actualy...
Todd's Adventures in Slime World on Atari Lynx (http://www.youtube.com/watch?v=qUzZzTPUE2Y#)
like you know, the way you can shoot and your fire falls with gravity...
Great memories of the Lynx , awesome machine!
@MacDeath: Look at the credits/title screen on this:
http://www.cpc-power.com/index.php?page=detail&num=1707 (http://www.cpc-power.com/index.php?page=detail&num=1707)
pure cga fun!
Lol that's true. ;D
Quote from: MacDeath on 13:11, 21 November 13
Saddly I must admit Spanish were also guilty of speccyporting...
Dinamic did almost all the games in mode 0, plus the superb title screens. And all the games they did were high quality (Game over, phantis, freddy hardest, army moves, navy moves, narco police, capitan trueno...)
Topo soft did almost all the games in mode 0 too.
Opera soft did at the end all the games in mode 0 (mot, sirwood, livingstone supongo II) , and the games they did in mode 1 were superb (La abadia del crimen, Sol negro, mutan zone...).
Zigurat well they did a lot in mode 1, but, when they used mode 0 the games were very good (senda salvaje, jungle warrior)
Back in the day, I had a cousin with a MSX and all the spanish titles he had were direct speccy ports, horrible, when the same games on the cpc were in mode 0 and very good games. Here in spain I think that the CPC was more appreciate than any other 8bit by the companies, even some games were programmed first on amstrad and then converted to "other" computers (based on interviews with the programmers).
Only "B" software houses did crappy speccy ports.
Quote from: arnoldemu on 10:30, 21 November 13
Yes there were a couple that did this, and really I don't know why. I think it would take more time and effort to code this, than to draw proper cpc mode 1 sprites.
I used to think that as well, but I was trying to imagine why anyone would 'go to that trouble' a while ago, and the only thing I could come up with is that if someone was really trying to do a speccy port to CPC with the least possible changes, then 'intercepting' the display code at the last possible moment could well mean that it's easier to code by using the existing spectrum character based colour info they already had to colour in each monochrome character as it's written, depending on how they are handling the colour. Maybe.... either way, it was a clear sign for a No Sale to me! :)
For me an speccy port is a lot more that a bad use of mode 1.
For example, there is a lot of mode 0 games generating its screen in a hidden buffer and after doing that, this hidden buffer is transfered to the screen using an LDI list. When they could have used a real double buffer and a split for the scoreboard and the game would be a few frames faster and a lot smoother to our eyes.
The CPC always need love and dedication for giving its best ;)
Quote from: SyX on 09:07, 22 November 13
For me an speccy port is a lot more that a bad use of mode 1.
For example, there is a lot of mode 0 games generating its screen in a hidden buffer and after doing that, this hidden buffer is transfered to the screen using an LDI list. When they could have used a real double buffer and a split for the scoreboard and the game would be a few frames faster and a lot smoother to our eyes.
The CPC always need love and dedication for giving its best ;)
Barbarian does exactly this though. It has a buffer it copies to the screen.
It's not a bad game.
I agree, they all could have used double buffering.
For me, the poor use of colours, but the worse is where they emulated the spectrum attributes. But we already know this is the ultimate sin.
I used to think that recolouring game screens as a "what might have been" exercise was a bit of a waste of time, but having seen some of the abominations above, now I'm not so sure. The Gauntlet one in particular... :o Certainly I'm glad I managed to miss most of these games as a kid... :)
QuoteBarbarian does exactly this though. It has a buffer it copies to the screen.
Barbarian (Palace soft?)
Well it actually has few zone animated so it can simply do a small buffer... basically you don't need to use extra 16K while there are like 3 sprites on screen maximum.
Gotta remember the main issue when dealing with port of a game on a CPC was the 464 limitations.
64K compaired to a speccy48 or C64... all graphics content weight easily almost twice.
IMO had the CPC got like 80K or 96K at minimum, it would have enough RAM to really compete.
despite having +16k compaired to Speccy48... the CPC with its graphics doubled would need 32k on CPC to store the same surface as 16k of speccy graphics (I don't count the attributes), hence the technic with the 1bpp to 2bpp conversion.
Despite being able to double buffer, the 464/664 don't have enough RAM to do it with a big game engine. 664 could handle this, probably, with more multiloading...
Another scrappy aspect is that they often also used the same tape loading routines as speccy... which doesn't work well on CPC464 hence the hasardous and slow and not reliable tape loading on many games.
The good point is that now we are aware of this and there are more and more games that are patched to run in 128K to correct the errors of the past.
QuoteThe Gauntlet one in particular...
really interesting case...they missed the opportunity to get the sprites in another colour, as in pacmania or blacktiger.
some games like FireTrap, Wonderboy2 or Strider are better exemples of the little advantage the CPC could get...
Firetrap : sprites use different colour than background, despite being still 1bpp+1bpp mask. it really gains in gameplay.
Wonderboy 2 : shitty game, bugged and laggy, but at least the sprites do have another colour too...
Strider : 1bpp backgrounds, but sprites properly in 2bpp (3 colours + mask).
all of those games could run far better anyway in properly CPC graphics + 128K.
Just see R-Type 128k.
QuoteI used to think that recolouring game screens as a "what might have been" exercise was a bit of a waste of time, but having seen some of the abominations above, now I'm not so sure.
some properly re-done mock-up have the advantage that it can motivate some coders into doing something.
Another common issue was the speccy sized screen.
256x192 (often smaller, HUD doing 1/3 of the screen)
it was a way to gain in RAM (smaller screen Video RAM) but also to gain on the animation.
Also a convenient way to do less modification on the speccy code.
But on CPC the result was often catastrophic.
smaller screen : the scrolling would then often be activated too much...
examples :
=Strider :
sprites actually have the same size as PC version (somewhat) but game playfield is so small that it activates multiscroll each time you jump... ouch.
had they used a 256x256 setting, the vertical scrolling would activate more rarely indeed.
=Black tiger : the same... game's window lacks too much in height so each jump activates the scrolling uselessly.
This can really be an issue when you deal with multiple scrolling (horizontal + vertical).
Another less evident one :
= Final fight:
yeah just compare... it's the speccy version with proper CPC graphics...
But the small screen make it to use a vertical scrolling. When you grab an opponent and jump to crush him on the floor, or just when you jump indeed.... it activates a vertical scrolling, lol.
this one is totally useless if you go with a 256 vertical display... if the engine doesn't use this scrolling, you then remove some bits of code and gain quite some CPU as well... because you would just need the horizontal scrolling sometimes.
"256x256" pixels (or 128x256) is actually still in 16K VRAM (somewhat, let's say 256x248 then)
Many games actualy failed because of this artificial Speccy resolution limitation, which clearly can handicap the game in many subtle ways.
[AMSTRAD CPC] Strider - Longplay & Review (http://www.youtube.com/watch?v=B3twY7PaYa0#)
just look at the begining... you simply jump and then find out there is no background displayed lol...
All because of this huge HUD and 256x192 sized screen.
Quote from: Axelay on 08:47, 22 November 13
I used to think that as well, but I was trying to imagine why anyone would 'go to that trouble' a while ago, and the only thing I could come up with is that if someone was really trying to do a speccy port to CPC with the least possible changes, then 'intercepting' the display code at the last possible moment could well mean that it's easier to code by using the existing spectrum character based colour info they already had to colour in each monochrome character as it's written, depending on how they are handling the colour. Maybe.... either way, it was a clear sign for a No Sale to me! :)
I think it's a bit of a double whammy because the Spectrum screen RAM isn't exactly easy to deal with either - it's non-linear (like the CPC) but also split into 3 horizontal sections. Plus you have to use a separate piece of memory for the colour attributes.
I thought about converting Subtera Puzlo to the Spectrum until I saw that ;)
Quote from: ralferoo on 10:35, 22 November 13
I used to think that recolouring game screens as a "what might have been" exercise was a bit of a waste of time, but having seen some of the abominations above, now I'm not so sure. The Gauntlet one in particular... :o Certainly I'm glad I managed to miss most of these games as a kid... :)
Yeah, I agree. I can understand why they might keep a monochrome background in a Speccy port, but to not render the sprites in a different colour, or to redo the image+mask bitmaps into a MODE 1 sprite was such a shame.
To see the emulated attributes is such a shame, because that must take so much CPU time... I presume they render the background and sprites off-screen in a 1bpp Spectrum-screen-sized buffer and then copy the changed areas to the front screen with some code emulating the colour attributes - in effect rendering everything twice and inefficiently to boot.
Quote from: MacDeath on 10:35, 22 November 13
just look at the begining... you simply jump and then find out there is no background displayed lol...
All because of this huge HUD and 256x192 sized screen.
Ugh, and the scrolling is character unit sized but I bet the game is redrawing the screen rather than using the CRTC's hardware scrolling.
At least Strider's HUD is underneath and adds a bit of colour. Many games like Pacmania kept it to the side and with the speccy sized screens the play areas were ridiculously small. Nothing wrong with 256x192 is it's all game area and the HUD is shifted on top or below, and then you can use some CRTC tricks. Sadly, many games were 256x128 + 256x64 for HUD, or 192x192 with 64x192 HUD, or, often, 176x176 with needless border and HUD.
But the programmers didn't know the CPC well, the hardware tricks weren't well known at the time, and they had two weeks to write the port from the Speccy code (which may have been written on a CPC in the first place *cries*).
Quote from: redbox on 11:10, 22 November 13
I think it's a bit of a double whammy because the Spectrum screen RAM isn't exactly easy to deal with either - it's non-linear (like the CPC) but also split into 3 horizontal sections. Plus you have to use a separate piece of memory for the colour attributes.
I thought about converting Subtera Puzlo to the Spectrum until I saw that ;)
Heh,yeah, I saw a video a while back of a Spectrum loading screen loading off tape directly with the colour following, and I was surprised how much it looked like it would be a bit of a pain. Had me wondering why some people complain so much about the CPC screen memory layout! :)
Quote from: Axelay on 12:54, 22 November 13
Heh,yeah, I saw a video a while back of a Spectrum loading screen loading off tape directly with the colour following, and I was surprised how much it looked like it would be a bit of a pain. Had me wondering why some people complain so much about the CPC screen memory layout! :)
The Spectrum layout, whilst it looks odd is actually well designed. Just like the Amstrad layout is well designed in a different way.
So, for a spectrum, you can always get to the next pixel line within an 8x8 cell by doing INC H. The next character line is always L+=#20 and if there's a carry, also add 8 to H. Most stuff is within a character cell, so the INC H for down a line is a really useful optimisation.
Quote from: ralferoo on 13:37, 22 November 13
The Spectrum layout, whilst it looks odd is actually well designed. Just like the Amstrad layout is well designed in a different way.
So, for a spectrum, you can always get to the next pixel line within an 8x8 cell by doing INC H. The next character line is always L+=#20 and if there's a carry, also add 8 to H. Most stuff is within a character cell, so the INC H for down a line is a really useful optimisation.
As ralf is saying, it's no more difficult to code on than on the cpc.
You just need a "scr_next_line" function to handle the oddness of the 3 regions, then the code is about the same as on a cpc.
Of course you have to update the attributes to change the colours.
Quote from: ralferoo on 13:37, 22 November 13
The Spectrum layout, whilst it looks odd is actually well designed. Just like the Amstrad layout is well designed in a different way.
So, for a spectrum, you can always get to the next pixel line within an 8x8 cell by doing INC H. The next character line is always L+=#20 and if there's a carry, also add 8 to H. Most stuff is within a character cell, so the INC H for down a line is a really useful optimisation.
I wasn't suggesting it was worse. :) I just thought it looked like it would present some hassles of it's own to overcome, no less so than the CPC. Though given the way a fair number of the speccy ports on CPC I've looked at handle their screen buffer and LDI string copying to screen RAM, it might even be that the layout is a non issue in some cases. Even if it works great for the Spectrum, it doesnt look like anything that would suit the CPC with its' resizable & hardware scrollable screen. I was just really surprised when I saw the spectrum screen RAM layout as I've seen some pretty 'loud' complaints about the layout of screen RAM on the CPC from some CPC coders, so it had given me the impression that most other platforms must have had something 'much better', but seeing how a few other platforms layout their screen RAM I've come to realize that's not really the case.
Quote from: Axelay on 04:10, 23 November 13
Though given the way a fair number of the speccy ports on CPC I've looked at handle their screen buffer and LDI string copying to screen RAM, it might even be that the layout is a non issue in some cases.
Due to the introduced wait states on the CPC, LDI isn't the quickest way of block copying memory (you'd really want to use the stack as your image source and have a tight POP pq:LD (HL),q:DEC L:LD (HL),p:DEC L) but actually on the Spectrum unrolled LDI block is the quickest (and simplest) way of copying memory.
Quote from: Axelay on 04:10, 23 November 13I was just really surprised when I saw the spectrum screen RAM layout as I've seen some pretty 'loud' complaints about the layout of screen RAM on the CPC from some CPC coders, so it had given me the impression that most other platforms must have had something 'much better', but seeing how a few other platforms layout their screen RAM I've come to realize that's not really the case.
It's exactly the same remark that fano said me some days ago, when I spoke about "project".
He said me that the CPC screen architecture is more advantageous, if well programed.
I suppose that is what you mean too (in a close way) ...
Quote from: TotO on 11:06, 23 November 13
He said me that the CPC screen architecture is more advantageous, if well programed.
I suppose that is what you mean too (in a close way) ...
Yeah. For the things that matter for the purposes that Amstrad designed the system for, it's about the best choice possible. Ultimately, the decision was determined mostly by the choice of the (cutting edge at the time) 6845 chip that was intended for use as a text mode driver (it's really expected that there is a pixel ROM using the RAM data out (driven by MA) and RA).
The design was basically driven around the desire to allow scrolling on a per-character basis with minimal redraw. This explains why we have the fixed number of bit positions (addr&0x7ff) followed by a gap so that can wrap around.
The only choice then is whether to store the bytes for a character cell linearly (as with the BBC) or in separate blocks (as with the CPC). Either way, there's still a discontinuity on the last pixel line in a character and arguably the CPC way is the neatest as then each pixel line has linear bytes.
On the IBM, you can get an almost linear pixel mode (actually every other line is +#2000) by having 2 pixel high characters but because the maximum line count is 7-bit, this isn't possible for PAL resolutions. The next best choice is an interlace of 4, which is pretty silly when characters are 8 high, so Amstrad did the most obvious thing really.
Oh, also... it's quite common on Spectrum games to have a "line lookup table" so it's easy to go from one line to the next even over the third boundary. A lot of games ported from the Spectrum also used this on the CPC even though addresses are more consistent (but still awkward). One game that used this in a nice way was one of the Dizzy games (I think Treasure Island) where they temporarily invert this lookup table so everything is drawn upside down... :)
As I have understood, a linear pixel screen mode is not an avantage for drawing sprites on a CPC.
But, each type of games and programs don't have the same needs too... :)
We are just lucky to be not limited and assisted by too much hardware handling to keep free our imagination.
Quote from: ralferoo on 09:41, 23 November 13
Due to the introduced wait states on the CPC, LDI isn't the quickest way of block copying memory (you'd really want to use the stack as your image source and have a tight POP pq:LD (HL),q:DEC L:LD (HL),p:DEC L) but actually on the Spectrum unrolled LDI block is the quickest (and simplest) way of copying memory.
Sure, when I study a Spectrum port I regard it as a study of Spectrum coding techniques, not CPC. Still some interesting ideas to be found though. :) I think it was Ikari I was looking at a while ago that had something like the line lookup table you mention, plus using a 'rolling' buffer by moving the start point of the screen within the buffer so it wasnt wasting CPU time with soft scrolling the buffer for it's vertical scroll & only used the long LDI string copy for copying the buffer to the screen. Clever approach I thought, though if it was Ikari, evidently still not quite fast enough on a CPC.
Wow, another discussion on speccy ports! Can't get enough, especially with MacDeath's awesome examples :)
Speccy Port - CPCWiki (http://www.cpcwiki.eu/index.php/Speccy_Port)
Quote from: MacDeath on 13:11, 21 November 13
Saddly I must admit Spanish were also guilty of speccyporting...
Oberon 69 (G.LL/Diabolic) (1990) (Amstrad CPC) (http://www.youtube.com/watch?v=LEBsGccpTzQ#)
Anyway this games is not lazily ported...
there are no colour clashes actually... you can see the sprites overlaying on the backgrounds properly... so this is not really that bad and the games seems to play well.
Hey this game looks pretty cool. I've never heard of it nor seen it before. I think I will have to download it and give it a go. I quite like some of the funky colour schemes.
When you download it:
Make sure, you only use 64k!!! Otherwise the game will crash...
Or use my patched game:
Quote from: Devilmarkus on 17:13, 16 May 14
When you download it:
Make sure, you only use 64k!!! Otherwise the game will crash...
Or use my patched game:
Yup thanks I got your patched one from CPCPower. It's a pretty nifty game. Nicely defined sprites, lovely and varied colour schemes for Mode 1 and I enjoyed playing it. :)