Atari v Commodore

[atariksi]

STe has no sprites.

 

IIRC, it adds fine H-scrolling, the ability to set screen address on a 2-byte boundary instead of 256, 12 bits per palette entry rather than 9, and the ability to change the current screen fetch address on the fly.

 

Never could get my hands on an STe (not yet anway). Too expensive on Ebay.

[Barnacle boy]

One multicolor Atari sprite is two monochrome sprites ... TWO atari MULTICOLOR sprites gives 6 colors

 

So in effect to create two atari MC sprites, you're sacrificing four monochrome ones.

 

And as frohn mentioned, four sprites on the c64 would give you 6 colours too. Better yet, three of those four sprites could be hires.

 

Even if you want to just overlay two sprites for 4 colours, you'd make the overlaid one hires. There'd be no reason to make both multicolour.

[atariksi]

Even if you don't accept Atari sprites in multicolor mode (deny reality) and I don't enable bit 5 of 53275, then you have to compare 2 or 4 monochrome C64 sprites with 2 or 4 monochrome Atari sprites which also gives you more net colors on the Atari side (due to GPRIOR effects w/PFs). Duh! The only way to get C64 the edge in colors/sprite is to compare Atari monochrome sprite with a C64 multicolor sprite (unfair comparison) which TMR insists must be done because he has no insight into planar mode or is too biased to admit that it is and goes as far as to speculate the future that no one ever will claim that they work like planar mode (which has already been proven false).

[Fröhn]

>"Bitplanes" are the groups of bits in a picture with the same ordinality. Chunky mode also has bitplanes

 

The way you look up color information in planar organization of bitplanes vs chunky is different.

You are mixing up "planar" and "bitplanes". Bitplanes exist in every digital image.

 

Did you like miss the point of the past hundred+ posts. One multicolor Atari sprite is two monochrome sprites-- that's what all this bitplane/planar mode discussion starting from. Read again: TWO atari MULTICOLOR sprites gives 6 colors; two multicolor C64 sprites gives 4 colors; Atari has a better multicolor sprite but it has less of them.

I don't see your problem. You use pairs of objects to build up more color objects, why is it not allowed on C64?

[Barnacle boy]

Even if you don't accept Atari sprites in multicolor mode (deny reality)

 

Who's not accepting Atari sprites in MC mode?

 

Let me ask you this: How many monochrome atari sprites can be displayed on one scanline? And how many multicolour atari sprites can be displayed on one scanline?

Edited April 7, 2009 by Barnacle boy

[atariksi]

One multicolor Atari sprite is two monochrome sprites ... TWO atari MULTICOLOR sprites gives 6 colors

 

So in effect to create two atari MC sprites, you're sacrificing four monochrome ones.

...

Yes, keep the term monochrome or multicolor in front to keep comparisons fair.

 

>And as frohn mentioned, four sprites on the c64 would give you 6 colours too. Better yet, three of those four sprites could be hires.

 

You forgot to specify monochrome or multicolor-- that's where the vagueness is. Four monochrome C64 sprites gives you 4 colors. Four multicolor C64 sprites gives you 6 colors.

 

>Even if you want to just overlay two sprites for 4 colours, you'd make the overlaid one hires. There'd be no reason to make both multicolour.

 

Yeah, that's why the multicolor sprite on C64 is inferior to a multicolor sprite on A8.

[atariksi]

Even if you don't accept Atari sprites in multicolor mode (deny reality)

 

Who's not accepting Atari sprites in MC mode?

 

...

Frohn and TMR so far.

 

>Let me ask you this: How many monochrome atari sprites can be displayed on one scanline? And how many multicolour atari sprites can be displayed on one scanline?

 

4 sprites + 4 missiles on one scanline without using sprite replication.

2 MC sprites + 2 MC missiles on one scanline without sprite replication.

[Barnacle boy]

>Let me ask you this: How many monochrome atari sprites can be displayed on one scanline? And how many multicolour atari sprites can be displayed on one scanline?

 

4 sprites + 4 missiles on one scanline without using sprite replication.

2 MC sprites + 2 MC missiles on one scanline without sprite replication.

 

So why do you seem to get so annoyed when someone points out that to create one atari MC sprite you have to sacrifice 2 monochrome ones? Isn't that just a fact?

 

And if you layer your 2 MC sprites + 2 MC missiles, how many colours do you end up with in your object and what is the final width of the object, assuming the resolution is kept at a standard 160?

[atariksi]

>"Bitplanes" are the groups of bits in a picture with the same ordinality. Chunky mode also has bitplanes

 

The way you look up color information in planar organization of bitplanes vs chunky is different.

You are mixing up "planar" and "bitplanes". Bitplanes exist in every digital image.

 

Did you like miss the point of the past hundred+ posts. One multicolor Atari sprite is two monochrome sprites-- that's what all this bitplane/planar mode discussion starting from. Read again: TWO atari MULTICOLOR sprites gives 6 colors; two multicolor C64 sprites gives 4 colors; Atari has a better multicolor sprite but it has less of them.

I don't see your problem. You use pairs of objects to build up more color objects, why is it not allowed on C64?

 

In planar mode, the bitplanes are organized like in the case of Atari sprites in multicolor mode-- there's bit combinations being used from both planes not that one sprite happens to be on top of another. So it's not just building up color objects by putting sprites on top of one another. If I put sprite #0 on sprite #2-- that's NOT a multicolor sprite on Atari even with bit 5 is enabled in 53275. Just like if have two bitplanes on Amiga and mode is set to DPF, it's not a 4 color bitplane. By the way, Amiga tech. books use the word bitplane the way I am using it.

[atariksi]

>Let me ask you this: How many monochrome atari sprites can be displayed on one scanline? And how many multicolour atari sprites can be displayed on one scanline?

 

4 sprites + 4 missiles on one scanline without using sprite replication.

2 MC sprites + 2 MC missiles on one scanline without sprite replication.

 

So why do you seem to get so annoyed when someone points out that to create one atari MC sprite you have to sacrifice 2 monochrome ones? Isn't that just a fact?

 

And if you layer your 2 MC sprites + 2 MC missiles, how many colours do you end up with in your object and what is the final width of the object, assuming the resolution is kept at a standard 160?

 

I agree you do use 2 monochrome sprites to make one multicolor sprite, but certain people like to make things vague by leaving out the word monochrome and claiming "I am using 2 sprites to get 6 colors" whereas C64 is using one sprite to get 4.

 

I don't need to layer sprites vertically. Horizontally, I would have to replicate sprites to increase coverage. There are 6 colors in ONE Atari MC sprite.

[Bryan]

Why don't we look at the maximum number of sprite-generated colors?

 

For the 64 it's 2 (universal) and 8 (individual). That's 10 colors if you put all your sprites on the screen.

 

On the Atari, you have up to 5 base colors, plus 2 more mixed colors. That's 7.

 

I think it would take some real gymnastics to say Atari has the advantage here.

[atariksi]

Why don't we look at the maximum number of sprite-generated colors?

 

For the 64 it's 2 (universal) and 8 (individual). That's 10 colors if you put all your sprites on the screen.

 

On the Atari, you have up to 5 base colors, plus 2 more mixed colors. That's 7.

 

I think it would take some real gymnastics to say Atari has the advantage here.

 

But that isn't the point. My original argument which TMR and I argued for many months is that "Atari has a better multicolor sprite implementation." No need to change the subject now unless you want to start a new topic for discussion.

[Rybags]

I'd say both have their flaws for MC sprites.

 

Atari would probably have been better if it performed XOR instead of OR - it would have opened more colour mixing possibilities.

C-64 could have just had a mode where you paired up 2 MC sprites and combined the 2 bit-pairs to give direct colour selection for nonzero values.

[Bryan]

But that isn't the point. My original argument which TMR and I argued for many months is that "Atari has a better multicolor sprite implementation." No need to change the subject now unless you want to start a new topic for discussion.

 

But the Atari can only win by defining a very specific set of rules, and it doesn't translate to an advantage when it comes time to start programming.

 

If I put a multi-color 64 sprite on the screen I have 3 colors. Every monochrome sprite I put over it adds another color.

 

The advantage the Atari PMG really has is the wider base palette and the ability to easily generate very tall images. Other than that, the 64 has the 3-year technology advantage.

[atariksi]

But that isn't the point. My original argument which TMR and I argued for many months is that "Atari has a better multicolor sprite implementation." No need to change the subject now unless you want to start a new topic for discussion.

 

But the Atari can only win by defining a very specific set of rules, and it doesn't translate to an advantage when it comes time to start programming.

 

If I put a multi-color 64 sprite on the screen I have 3 colors. Every monochrome sprite I put over it adds another color.

 

The advantage the Atari PMG really has is the wider base palette and the ability to easily generate very tall images. Other than that, the 64 has the 3-year technology advantage.

 

You are speaking about the quantity of sprites not the efficiency of the multicolor sprite implementation which was the long debated point here in this thread. I don't need to define rules-- they already exist; having 4 colors coming out of a pair of MC sprites on C64 is less efficient than having 6 colors. Nothing to do with the broader palette either.

 

By the way, one reason the DPF can't be done by just manipulating the palette is that sprites can be in between the two playfields as defined by the priority register whereas when treated as one bitmap of two planes, sprites will be behind or in front of it. Also, you can set playfield priorities.

[atariksi]

I'd say both have their flaws for MC sprites.

 

Atari would probably have been better if it performed XOR instead of OR - it would have opened more colour mixing possibilities.

C-64 could have just had a mode where you paired up 2 MC sprites and combined the 2 bit-pairs to give direct colour selection for nonzero values.

 

But you see both did machines did not want to use up more color registers so one went with OR operation and the other had a fixed couple of registers.

[Crazyace]

Oops - sorry, yes you do need double width c64 sprites ( I'm posting too early in the morning ) to cover the screen width.

 

I cant see any way that you can argue that the Atari multicolour sprite implementation is superior to the C64. You can argue that the composition of an Atari multicolour sprite is more interesting than the C64.

 

For example - a single multicolour sprite on the c64 can pick any 3 of the 16 colours, without restriction. On the Atari the 3rd colour is a fixed combination of the 2 monochrome player colours - there are combinations where the 3rd colour may not be distinct from the other two.

However there are some nice tricks - if the 3rd colour is in a smaller overlapping area - then the 2 players can be at different positions ( or even different sizes ) to give a larger effective width.

 

In practise in games there is no comparision - even with the limitation of 2 common colours the c64 can display more sprites than the atari

[Bryan]

To get a single 6 color object requires 4 players on the A8 (80% of available) and it requires 4 sprites on the 64 (50% of available). Plus, the 64 sprite will have 12 horizontal pixels instead of 8 or 10 and will not have the OR limitation on two of its colors.

 

As far as I can tell, Commodore won the "better color implementation" when they added that 2nd bit-per-pixel and 10 color registers. Atari's method was clever thinking and certainly the best of its day by far, but time moved on.

 

If the Atari had the 64's sprite capability I doubt any of us would be bemoaning the lack of overlapping color features.

Edited April 7, 2009 by Bryan

[atariksi]

Oops - sorry, yes you do need double width c64 sprites ( I'm posting too early in the morning ) to cover the screen width.

 

I cant see any way that you can argue that the Atari multicolour sprite implementation is superior to the C64. You can argue that the composition of an Atari multicolour sprite is more interesting than the C64.

 

For example - a single multicolour sprite on the c64 can pick any 3 of the 16 colours, without restriction. On the Atari the 3rd colour is a fixed combination of the 2 monochrome player colours - there are combinations where the 3rd colour may not be distinct from the other two.

However there are some nice tricks - if the 3rd colour is in a smaller overlapping area - then the 2 players can be at different positions ( or even different sizes ) to give a larger effective width.

 

In practise in games there is no comparision - even with the limitation of 2 common colours the c64 can display more sprites than the atari

 

C64 can display more multicolor sprites on a scanline but that wasn't the argument. Having multicolor sprites of 8*248 (+/- missile) using OR color is better than 12*21 with 2 fixed colors. If the intent is to outdo the C64 palette, the ORed combinations will give you more choice than 16 colors. Even with two fixed colors/sprite, 4 MC sprites would give 8 colors + 4 ORed colors = 12 colors > 8 MC giving 10 colors as implemented on C64 currently.

[atariksi]

To get a single 6 color object requires 4 players on the A8 (80% of available) and it requires 4 sprites on the 64 (50% of available). Plus, the 64 sprite will have 12 horizontal pixels instead of 8 or 10 and will not have the OR limitation on two of its colors.

 

As far as I can tell, Commodore won the "better color implementation" when they added that 2nd bit-per-pixel and 10 color registers. Atari's method was clever thinking and certainly the best of its day by far, but time moved on.

 

If the Atari had the 64's sprite capability I doubt any of us would be bemoaning the lack of overlapping color features.

 

You missed the point again. Better multicolor sprite implementation. If C64 had atari's MC implementation, it would get 3 unique colors per MC sprite instead of 1 plus fixed 2 colors. Why are you looking at total available-- that's making the same point about quantity again not which has better multicolor sprite implementation.

[atariksi]

To get a single 6 color object requires 4 players on the A8 (80% of available) and it requires 4 sprites on the 64 (50% of available). Plus, the 64 sprite will have 12 horizontal pixels instead of 8 or 10 and will not have the OR limitation on two of its colors.

 

As far as I can tell, Commodore won the "better color implementation" when they added that 2nd bit-per-pixel and 10 color registers. Atari's method was clever thinking and certainly the best of its day by far, but time moved on.

 

If the Atari had the 64's sprite capability I doubt any of us would be bemoaning the lack of overlapping color features.

 

You missed the point again. Better multicolor sprite implementation. If C64 had atari's MC implementation, it would get 3 unique colors per MC sprite instead of 1 plus fixed 2 colors. Why are you looking at total available-- that's making the same point about quantity again not which has better multicolor sprite implementation.

 

And if you are going to make quantity part of the argument again, I'll just set up a DLI and show 128 colors for every sprite. End of argument.

[Bryan]

You missed the point again. Better multicolor sprite implementation. If C64 had atari's MC implementation, it would get 3 unique colors per MC sprite instead of 1 plus fixed 2 colors. Why are you looking at total available-- that's making the same point about quantity again not which has better multicolor sprite implementation.

 

And it would have only 4 multi-color sprites instead of 8. The cost of doing multi-color that way is very high.

 

And if you are going to make quantity part of the argument again, I'll just set up a DLI and show 128 colors for every sprite. End of argument.

 

Finally a valid argument! The Atari can display more than 16 colors. That is a genuine advantage over the 64.

[Bryan]

By the way, there was a time when my identity was too wrapped up in the Atari for me to say anything good about the 64. Today, I think I'm pretty rational and even-handed about it. Although the Atari is still my favorite 8-bit, I think I could hang with the 64 guys and resist the urge to pour Mountain Dew into their 1541s.

[atariksi]

You missed the point again. Better multicolor sprite implementation. If C64 had atari's MC implementation, it would get 3 unique colors per MC sprite instead of 1 plus fixed 2 colors. Why are you looking at total available-- that's making the same point about quantity again not which has better multicolor sprite implementation.

 

And it would have only 4 multi-color sprites instead of 8. The cost of doing multi-color that way is very high.

...

As if you can't do 8 mc sprites. You forgot again that resolution is maintained at the cost of using additional sprite. You can do the other way as well and using chunky method and get more colors as well. Duh.

 

>Finally a valid argument! The Atari can display more than 16 colors. That is a genuine advantage over the 64.

 

Because you are too biased to think clearly that an Atari multicolor sprite implementation is superior.

Even 4 MC atari implemented sprites give more colors than 8 C64 MC sprites.

[atariksi]

I think it's a matter of logic too. All those collisions add up. Probably a point of diminishing returns. Was just thinking about that, and the interrupt capability provided on C64. That is probably where they were headed too, when faced with all those collision conditions.

 

If you move in frame at a time, you can just test for collisions during VBLank so no IRQ is needed. There are the following combinations on Atari: M0..3 collides with PF0..3 (16 bits), P0..P3 collides with PF0..3 (16-bits), M0..3 collides with P0..3 (16-bits), P0..3 collides with other players P0..3 (16 - 4 useless bits) = 64- 4 = 60 bits of collision.