Crappy C64 screen resolution

[Zak]

I wonder if people would prefer a 160x256 super lores screen mode on OCS Amigas if it had 4096 colors all at once? Or maybe 16.8 million all at once on AGA Amigas? Would that beat all standard Amiga graphics in your opinion?

[saimon69]

Originally Posted by Zak

I wonder if people would prefer a 160x256 super lores screen mode on OCS Amigas if it had 4096 colors all at once? Or maybe 16.8 million all at once on AGA Amigas? Would that beat all standard Amiga graphics in your opinion?

In a way is what was happening with the chunky screens on AGA

[AestheticDebris]

Originally Posted by CCCP alert

What is interesting is Monty on the Run for CPC uses mode zero not mode 1 but the C64 has the same sort of graphics as the ZX release. You can decide which you prefer. Usually it's the other way round, 64 port has chunky pixel bespoke graphics and the CPC gets some 4 colour mode 1 ZX port job of the 16 colour original (Manic Miner etc) so ends up much less colorful.

The great thing about modern times is you can play app the versions. Personally, I've always thought the Spectrum versions of Monty Mole have the edge. Although I'm not a big fan, the games are too reliant on random deaths you couldn't possibly avoid.

Originally Posted by CCCP alert

Either way there is nothing to praise about deciding 16kb screen and 4mhz Z80 with bad lines == much less than 4mhz performance. The CPC has ZERO innovation to help the little CPU shift the screen round at 50fps, you won't be playing anything as good as early games like C64 Terra Cresta on a 464, ST has exactly the same problem. Without innovations like character screens with colour/attribute RAM you need massive CPU grunt and some hardware assistance to scroll to overcome lack of innovation/engineering talent.

That's not entirely true. Firstly the CPC doesn't have "bad lines", that's a C64 concept. Contention on the CPC is applied in a very uniform way, stretching some instructions so that they all end up a multiple of four clock cycles. It's very predictable and the impact doesn't have to be that bad - what usually hurt was taking code from the Spectrum (which has an insanely complex contention model) and running it unaltered. Some sequences of "optimised" Z80 run slower than supposedly "less optimised" code (due to aforementioned instruction stretching) so if you don't specifically optimise for the CPC, you take an extra performance hit.

Secondly, the CPC does have some options to help move the screen around. It can hardware scroll the display continuously in character sized chunks (that is 8*8 pixels in 320*200 mode or 4*8 pixels in 160*200 mode). The 6845 CRTC, which controls display timing and address generation is also incredibly flexible and can be persuaded to do a lot of things that shouldn't necessarily be possible.

Things like Mission Genocide or TLL show what could be done when you got clever with the hardware. And Pinball Magic is probably the pinnacle of pulling off clever display tricks. But all too often back in the day it was just the spectrum code hastily converted over with, at best, minimal changes (fancier games actually bothering to redraw graphics).

[roondar]

The ability to move the screen by hardware in coarse chunks (8x8 or 4x8) is actually quite useful. The C64 needs to use VIC-II trickery to be able to do that and most commercial games for it (barring a few in the 1990s) did not use such methods. Partially because it was not widely known it was possible at the time and partially because using it for horizontal scrolling can make some C64s unstable.

Most scrolling C64 games did use the smooth scroll registers for pixel precise scrolling (which, interestingly, operated at 1 hires pixel increments irrespective of screen mode), but used the CPU for coarse/character scrolling. This was very CPU intensive, though it could be spread over several frames, which made it much less of an issue if you used properly written code. However, that does not work for the colour RAM scroll as that can't be double buffered. Colour RAM needs to be updated all at once*, which often meant that coders chose to only do partial colour RAM scrolling.

Nowadays tricks like VSP/AGSP scrolling are used a lot more often and methods of making C64s that can't handle the trick run stable though HW fixes have been created.

*) Technically you can kind of spread it over two frames by doing the top half in frame one and the bottom half in frame two, but that still takes considerable CPU time.

[paraj]

Originally Posted by Zak

I wonder if people would prefer a 160x256 super lores screen mode on OCS Amigas if it had 4096 colors all at once? Or maybe 16.8 million all at once on AGA Amigas? Would that beat all standard Amiga graphics in your opinion?

There's not enough bandwidth on an OCS Amiga for a 160 12-bit mode, and even if there were I don't think it would be popular with games since you also need to factor in the memory bandwidth it takes to fill such a screen. With AGA you can have effectively 320x256 @ 18-bits (like saimon69 mentions) with HAM8, but I've really only seen it used for static images since just displaying the frame takes up so much bandwidth and updating it is grueling.

[Megalomaniac]

'Bad lines' isn't a technically accurate way of describing the CPC's processor method, but it does accurately convey that the 4Mhz clock speed isn't an accurate measure of its speed. Can you really completely erase the issue with natively-written code (i.e. not Spectrum-ported)? Are there any examples of processor-heavy games (e.g. isometric or other 3D, where the C64 generally loses out to both Amstrad and Spectrum) which demonstrate running faster than the Spectrum can?

As for scrolling, Mission Genocide is indeed impressive, Xyphoes Fantasy even more so, I'd add the newer Pinball Dreams and CPC Soccer, neither of which I'd expect the C64 to be able to match, for looks or scrolling. Still, it's telling that even most of the great homebrew or French games on the CPC don't use scrolling, it's not easy to get right. Pixel art, on the other hand, the Amstrad's true 160x200x16 and varied vibrant palette probably makes it the best 8-bit.

I think Zak's 160x256 4096 colours (12-bit) might be a rhetorical "taking the colours-over-resolution debate to an extreme" argument. I doubt people used to 8-bit or even ST games would really appreciate how many colours 4096 was, and I doubt many artists would have been able to leap straight from 16 or 32 up to 4096 and make any kind of practical use of them. Besides, such screens would take up over 50kb, I'm not sure even an Amiga could scroll that smoothly at 50fps with much going on the screen?

[tomcat666]

Originally Posted by Megalomaniac

on the other hand, the Amstrad's true 160x200x16 and varied vibrant palette probably makes it the best 8-bit.

It is actually over saturated, what you call vibrant most other people find way too bright with mostly same colours.
Best 8 bit palette goes to Plus/4 line of computers.

[lmimmfn]

Originally Posted by tomcat666

It is actually over saturated, what you call vibrant most other people find way too bright with mostly same colours.
Best 8 bit palette goes to Plus/4 line of computers.

For the CPC:
It's a 3 bit per R,G,B palette(3x3x3)=27 colours, and therefore equally spaced, same as Amigas 16 bit per R,G,B palette(16x16x16)=4096 colours.

So I don't consider it over saturated unless you consider the Amiga having the same issue?

The CPC is colourful so games with somber colours don't work on the platform, but games requiring a colourful artistic style are best. In terms of palette it is one of the best balanced 8 bits(plus 4 is great until it moves)