2011 - what can a cpc'er look forward to?

[sigh]

That's different as background is a fixed array , you can not move a tile separatly.Sprites are limited to 8 , it is possible to use multiplexing to get more but you are normaly limited to 8 per scanline.More , if you use all the sprites to add to background , you will not have more for the game objects.

That's very interesting.

[TMR]

Oh... go on then although i can't help feeling i'm going to regret this... =-)

Yes, you can mix two lowres sprites to get up to 6 colors.

Four colours total, each multicolour sprite has it's own unique colour register and shares two more with all the other sprites so those colours are a constant. The four colour objects noted previously are usually a monocolour sprite overlaid onto a multicolour one to give four colours and what appears to be a 1:1 aspect ratio.

May be, if you compute software sprites, you lose the hardware scrolling support.

You may lose some of it's fineness (regardless of mode, the scrolling runs at 320x200 resolution so can move in half a multicolour pixel steps horizontally) but hardware scrolling on the C64 isn't coarse anyway so the scroll registers just offset the display by up to eight high res pixels before the CPU has to kick in and shuffle the actual data before the next cycle.

Running software sprites over a character-based display isn't really a problem, C16 games do it quite a bit and there's not a massive difference in speed between the two so porting most of those games isn't difficult with a bit of modification (as i did with the C16 version of Kikstart a few years back). But most C64 coders prefer using the hardware sprites and perhaps character-based bullets that just step between cells and are very quick to update.

[fano]

Finally , we are talking of C64 , i can not remember where thread deviated 

Running software sprites over a character-based display isn't really a problem

Rendering itself , but you still have the problem of color clash until you share the same palette for the whole screen , or your sprites are non masked (like it is visible in R-Type and Katakis for example), or there is a solution  (and i'd be curious to see how the problem has been solved)

[TotO]

4 colors by sprite w/o transparenty. 3 colors with.
If you want to mix sprites you have to see the second behind.
So you get 6 colors. (7 if the second don't have transparenty)

[TFM]

... Favourite game was Attack of the mutant camels.

Didn't know that game, but its really good done on Atari800! Some Links...

Atari:

http://www.youtube.com/watch?v=bXznbBA4nXU

c64:

http://www.youtube.com/watch?v=ybzUgiE_vQM

[TMR]

Rendering itself , but you still have the problem of color clash until you share the same palette for the whole screen

  Well, we're talking about character-based screen modes for scrolling so   that's happening anyway; three shared colours and one selectable in each   4x8 pixel cell. It'll still clash if differently coloured objects try passing over each   other yes, but it can be kept to a minimum with some forward planning and perhaps hardware sprites stepping in when two objects are going to cross.
 
 

or   your sprites are non masked (like it is visible in R-Type and Katakis   for example)

  To be honest, they're probably not masked for speed since C64 games of this nature rarely drop below 50FPS on purpose, although most of the bullets in those two   games are high resolution characters (the C64 can select 320x200 or 160x200 on a character by character basis) so they couldn't be merged into a multicolour background in the first place.

Despite it's age, Uridium is one of the best examples of a good number of small software sprites passing over a character-based scrolling screen.

4 colors by sprite w/o transparenty. 3 colors with.
If you want to mix sprites you have to see the second behind.
So you get 6 colors. (7 if the second don't have transparenty)

There's no option to disable transparency and no register to feed it with colour data even if there was; there are ten sprite colour registers in total, eight provide each sprite with it's own colour and the other two are the shared colours used by all sprites, so overlaying two sprites gets you two unique and two shared colours.

[TotO]

Ok, I have missunderstood.
Thank you for the explanation.

[fano]

Thanks for the explanation , that's always good to know more about theses machines.So , finally , every extra color for "multi" sprite costs an extra sprite.

Despite it's age, Uridium is one of the best examples of a good number of small software sprites passing over a character-based scrolling screen.

It is a great game on C64.As that seems, they used the same colors for background and for shots to solve the problem.
That's a shame to see CPC version has been made from Spectrum as it should fairly better on a CPC if they worked from C64 

[ukmarkh]

If you give Uridium the time on the CPC... you'll discover  one hell of a challenge, even despite the graphics. The C64 version blew me  away though!
 
Its blatantly obvious the C64 was a better games machine than the 464,  all-rounder is a different matter. I get the feeling that not every stone was  left unturned on the CPC, and where's the C64 and Speccy had the better  programmers and longer development time by and large (although not always the  case). Programmers today are only now discovering how best to push the  electrons through the CPC's microchips. I suppose you could say the same is  still true for all 8-bits, but I just feel it is more so for the CPC.
 
Star Sabre and Orion Prime being fine examples, as well as the new R-Type  remake. These projects just wouldn't have been given the time of day in the  80's. Possible yes; but probably wasn't worth it for the small return.
 
What I'm really interested in, is how the C128 compared with the CPC 6128? As  the latter was the machine I grew up with.

[Gryzor]

Wait... are we wildly off-topic? Shall I split the thread? And what is the subject of the new one?

[ukmarkh]

Wait... are we wildly off-topic? Shall I split the thread? And what is the subject of the new one?

That's the great thing about a conversation such as this, it can be a birth place for another hundred threads. 

[Gryzor]

Yes - also, that's the great thing about topics and subfora and organization - it keeps the entropy from spreading

[Bryce]

I think you're probably going to have to create a permanent thread with the title "Place to argue whether C64 was better than CPC" and people can come back every few weeks and re-discuss the issue

Bryce.

[TotO]

Programmers today are only now discovering how best to push the  electrons through the CPC's microchips. I suppose you could say the same is  still true for all 8-bits, but I just feel it is more so for the CPC.

No special tricks or magic stuffs for doing good games todays on CPC ... Only exclusive development (like Gryzor, Renegade, ...) and not more Speccy and C64 ports, like twenty years ago.

[TMR]

Its blatantly obvious the C64 was a better games machine than the 464,  all-rounder is a different matter.

S'pose it depends on what you want to do with it; 40 columns aren't as good as 80 columns obviously, but the C64 can hold it's own for many jobs and saw all manner of serious applications up to and including a GUI released during the 1980's which some folk are still using even now.

What I'm really interested in, is how the C128 compared with the CPC 6128? As  the latter was the machine I grew up with.

Ah, now i can help with that! =-)

Although only one can be used at a time, the C128 has two processors; an 8502 (a modified 6510) and a Z80A clocked at 0.98MHz and 2MHz respectively - there's also a "fast mode" which disables the 40 column display but doubles the clock speed of both CPUs and, since this feature is available from C64 mode, some games take advantage of it by switching up during the borders and back down for the display.

Two video displays are generated simultaneously, a standard VIC-II output which is identical to the C64 for almost any practical purpose and a 640x200 (or 640x400 with interlace) 80 column display which can be either bitmapped or character-based and offers the option of an attribute map to kick out a sixteen colour image; this second display is powered by the VDC chip and, although there's no sprites in this mode, hardware smooth scrolling is available, the origin point of the screen can be pointed anywhere in the dedicated display RAM and although i'm referring to it as 640x200/400 it can overscan to a degree as well.

There's a dedicated disk drive for the machine, the 1571 (or indeed the 1581, which is a 3.5" DS/DD drive) which is double sided and has a "burst mode" which moves very fast indeed and that and the Z80A gang up to give CP/M compatibility, in fact most programs for the at-the-time very popular Kaypro flavour of CP/M should be happy bunnies without modification.

Think that's everything...? =-)

[Gryzor]

@Bryce: now *that*'s an idea! I'm really tempted...
@Tot0: very valid argument...