News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
S

Technician Ted - colour clash!

Started by shaymanjohn, 17:07, 20 November 13

Previous topic - Next topic

0 Members and 4 Guests are viewing this topic.

Sykobee (Briggsy)

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.

Sykobee (Briggsy)

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*).

Axelay

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!  :)

ralferoo

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.

arnoldemu

#29
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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Axelay

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.


ralferoo

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.

TotO

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) ...
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

ralferoo

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.

ralferoo

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... :)

TotO

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Axelay

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.

Gryzor

Wow, another discussion on speccy ports! Can't get enough, especially with MacDeath's awesome examples :)


Speccy Port - CPCWiki

Carnivius

Quote from: MacDeath on 13:11, 21 November 13
Saddly I must admit Spanish were also guilty of speccyporting...



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.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Devilmarkus

When you download it:
Make sure, you only use 64k!!! Otherwise the game will crash...

Or use my patched game:


When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Carnivius

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. :)
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Powered by SMFPacks Menu Editor Mod