Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

If someone were trying to replicate the Atari pm's directly they would use 3 C64 sprites to emulate 2 linked players. It wouldn't be elegant - but it would work.

 

That was part of my argument, except that i stuck to the same rules of two hardware sprites per object, two objects a scanline that the Atari has and got three unique colours per object (since only those objects used the multicolours, i gave them one multicolour each). i felt that was a fair comparison allowing both machines to throw the same number of sprites at the job, atariski didn't.

Link to comment
Share on other sites

2x2 pixel 24bit color display, 16k of ram, 1ghz cpu, 8 mono fixed frequency tone generators

-vs.-

80x60 pixel monochrome display, 512k of ram, 33mhz cpu, 2 stereo synths

 

Based just on the numbers - Which system sucks and which system rocks? :ponder:

 

Raw numbers are completely meaningless and only subjectively matter to people who care about that particular aspect in liue of the bigger picture.

 

clearly the 2nd one is better. 2x2 pixel and 16k ram is not enough for anything even if the cpu is fast.

what I find meaningless is how people are joining discussions finding meaningless, telling everyone its meaningless. its meaningless ;)

 

I think a better comparision would be:

 

RGB data latch, 16k of ram, 1ghz cpu, 8 mono fixed frequency tone generators

-vs.-

80x60 pixel monochrome display, 512k of ram, 33mhz cpu, 2 stereo synths

 

Then at least you could run a software loop to generate graphics - the CPU would be fast enough to handle coloured text :)

 

or - what if you want to be a synth... the 1st system could be better as you could run a softsynth to give 100's of channels... and stereo wouldn't be as important in a single instrument.

 

( Actually - even a 33mhz cpu would be capable of some quite impressive soft effects )

Link to comment
Share on other sites

9 game preview

20 games

23 utilities

39 non c64 based utility

 

how much on the a8 ? ;)

Many new entries (software and hardware) this and previous year for Atari too, of course! Check http://atarionline.pl/, http://www.atari8.info/index.php?lang=en, http://atariarea.krap.pl/, http://www.abbuc.de/index.php and other well known links for homebrew production.

 

 

how many in this year? just so we can compare if the c64 is dying with these nrs the a8 must be already dead ? :) I dont think it has more :) oh and ofcourse I wasnt allowed to count in demos, graphics, music, etc because the c64 has more of that .)

Link to comment
Share on other sites

Oswald,

 

That you and others cannot grasp the bigger picture, and therefore must focus on the baseline specification limits the ability of this discussion to move beyond mud slinging and into a constructive discussion of the ability of the respective platforms to create good entertainment software.

 

It's immature - the numbers prove nothing (see 360 vs PS3 for the same laughable excuse for debate).

 

Truth is the C64 has a large software library - and post 84/85 speeds away from the A8 in breadth and quality of titles - chief amonst the reasons being the A8 was no longer commercially viable due to Atari themselves etc etc.

 

There is nothing about the Atari precludes it from making great games - sure it has different strengths and weaknesses than the C64, so the games would/will be different.

 

Those images you posted prove the fact that the C64 reached more people and that means more talent got a chance to exercise their ability on it.

 

I find it sad you want to fight over bits and bytes and not celebrate the qualities of these old machines :(

 

sTeVE

Edited by Jetboot Jack
Link to comment
Share on other sites

I think a better comparision would be:

 

RGB data latch, 16k of ram, 1ghz cpu, 8 mono fixed frequency tone generators

-vs.-

80x60 pixel monochrome display, 512k of ram, 33mhz cpu, 2 stereo synths

 

Then at least you could run a software loop to generate graphics - the CPU would be fast enough to handle coloured text :)

 

or - what if you want to be a synth... the 1st system could be better as you could run a softsynth to give 100's of channels... and stereo wouldn't be as important in a single instrument.

 

( Actually - even a 33mhz cpu would be capable of some quite impressive soft effects )

 

16k of ram is still not enough for anything :)

Link to comment
Share on other sites

I think a better comparision would be:

 

RGB data latch, 16k of ram, 1ghz cpu, 8 mono fixed frequency tone generators

-vs.-

80x60 pixel monochrome display, 512k of ram, 33mhz cpu, 2 stereo synths

 

Then at least you could run a software loop to generate graphics - the CPU would be fast enough to handle coloured text :)

 

or - what if you want to be a synth... the 1st system could be better as you could run a softsynth to give 100's of channels... and stereo wouldn't be as important in a single instrument.

 

( Actually - even a 33mhz cpu would be capable of some quite impressive soft effects )

 

16k of ram is still not enough for anything :)

 

It would be enough to run a synth - I've done it before with less :)

or if you want a fractal display..

 

The ram difference is a bit excessive though....

Link to comment
Share on other sites

i don't accept your definition no because the Atari itself is quite clearly telling me that i've got two sprites and they can optionally work in tandem when the multicolour mode is enabled; i looked at a few books on Atari Archives just to confirm my memory, none of the ones i checked said that enabling multicolour gets you two multicolour sprites rather than four working in pairs either.

 

I'm trying to figure out why this is even a big deal to atariksi without re-reading the last 40+ pages. If you call them separate sprites, then it's a nifty feature that they can work together. If you call them a single sprite then congrats! You've just reduced the system to fewer available sprites. Doesn't matter what you call it- what you can do with it remains the same.

 

I was arguing that Atari multicolor sprites are better implementation than C64 multicolor sprites. Yes, I did agree that this would reduce number of sprites. After TMR loses the argument, he tries to change the premises like he did with his sprite Y position argument. Two multicolor Atari sprites give you 6 colors + black + any priority conflict colors. Two C64 multicolor sprites gives 4 colors. End of argument. Now he's arguing that I should use Atari monochrome sprite and compare with C64 multicolor sprite (i.e., compare apples w/oranges) since Atari came to him (in the middle of the night) and told him that they are two sprites not one multicolor sprite (after arguing for a while it's semantics). I gave him the example of Amiga bitplanes and Amiga sprite merging but I guess he did not read it or did not understand it. The definition of multiple player color is here:

 

http://www.atariarchives.org/c1bag/page192.php

 

And it agrees with reality and with Commodore's Amiga Hardware Reference Manual. I don't see the point in wasting my time arguing over apples and oranges. According to his warped logic, Atari ST 640*200*4 mode is superior to Amiga's 640*200*4 mode since Amiga is using TWO bitplanes. Of course, what can you expect from someone who initially was arguing that the Atari's palette being superior to C64's is a subjective thing. I get the drift that he just keeps repeating the samething regardless of what is reality until someone accepts him. Then you got a couple of people who did not understand the argument jump into it and try to refute me without taking the facts into account.

 

His mentality is pretty clear to me. If I gave the question that one 18-wheeler shop-rite truck and one BMW get on the George Washington Bridge at the same time going at 70mph and let go of the gas peddle at the same time, who will get across the bridge faster? So after the issue is done and over with, he'll claim Shop-rite does not have 18-wheelers! They are just a trailer and a front vehicle! Of course, he's not as bad as the other two people who are trying to find fault without even knowing what the argument is!

 

ehm, no? I was telling the same? I was complaining about the Y-pos thing, too? I was telling, yes... they are (from hardware point of view) still 2 sprites? and if you compare "2" virtual multicolour sprites to 2 c64 ones you are still using ALL 4 hardware sprites on atari side??? maybe I am wrong here but I am on Jason's side... I guess he nothing more wanted to say...

 

and yes... you can talk to me, too... :)

 

In the link I gave, it states: "Bit 5 Multiple Color Player Enable" which is similar to "ATTACH" mode on Amiga and they work like bit planes vs. chunky modes. You can't have it both ways-- either you compare C64 monochrome sprites to Atari monochrome sprites or you use this definition of an Atari multicolored sprite to a C64 multicolor sprite.

Link to comment
Share on other sites

I gave him the example of Amiga bitplanes and Amiga sprite merging but I guess he did not read it or did not understand it. The definition of multiple player color is here:

 

http://www.atariarchives.org/c1bag/page192.php

 

And it agrees with reality and with Commodore's Amiga Hardware Reference Manual.

 

i looked at that page previously and here's the part that struck me as most relevant (i've added my own emphasis): "Do you have an object that you want to animate that is just begging to be multicolored? Here is your method of implementation. And if you need even more than three colors, you could use all four (or three, or five) players to display it." So show me where it says that two sprites in tandem become a single multicolour sprite in there...? And if it doesn't that invalidates your point so comparing one multicolour object generated from two sprites to a single multicolour sprite isn't a fair or objective comparison.

 

53275: "Bit 5 Multiple Color Player Enable". Objective is to compare monochrome vs. monochrome and multicolor vs. multicolor.

Link to comment
Share on other sites

I was arguing that Atari multicolor sprites are better implementation than C64 multicolor sprites. Yes, I did agree that this would reduce number of sprites. After TMR loses the argument, he tries to change the premises like he did with his sprite Y position argument. Two multicolor Atari sprites give you 6 colors + black + any priority conflict colors. Two C64 multicolor sprites gives 4 colors. End of argument.

 

I have a problem with your argument..

 

If we take 1 multicolour sprite, just to simplify things..

 

Atari is 2 players - so 2 independant colours + 1 mixed colour or black.... that's only 3 colours - with the 3rd colour being very restricted.

(The other priority combinations are very interesting - but they also involve playfield, so they almost negate the 'sprite' aspect - I would use them in the number of colours per line argument )

C64 is 1 independant colour + 2 shared sprite colours. - so for a single sprite there are effectively 3 unrestricted colours.

 

For 2 muticoloured sprites things start to go to the Atari side

 

A8 : 4 independant colours + 2 shared/black = 6

C64 : 2 independant colours + 2 shared = 4

 

so if you stop here ( as you did ) the Atari seems superior...

 

but that's a fallacy.. as you have pretty much exhausted the Atari H/W capabilities here ( missiles could be considers part of the players to avoid any arguments about sprite size ) and the C64 still has 6 more multicolour sprites.

 

If anything the biggest weakness of the C64 sprite system is that there's only 1 unique colour per sprite. You can see it in action in most games and C64 programmers work around the limitation.

However even with this limitation the C64 sprites are still more powerfull than the A8...

...

 

Good at least you understood the definition of multicolor. Original argument was for comparing two multicolored sprites and I did agree C64 has more multicolored sprites. So as you state Atari has superior implementation, however you got the priorities thing screwed up. You can get the black even with sprite overlaps without involving playfields. First multicolor sprite has 3 colors + black if it intersects with part of 2nd multicolor sprite. Second multicolor sprite has 3 colors + black if it intersects with first multicolor sprite so its 6+black. This is without considering conflict with playfields.

 

>If someone were trying to replicate the Atari pm's directly they would use 3 C64 sprites to emulate 2 linked players. It wouldn't be elegant - but it would work.

 

No, it would not unless you use raster line interrupts. I already proved earlier atari sprite hardware renders more pixels per frame than C64. Remember, I am one of those that live in more than one dimension so you have to take my position into account. And if I take interrupts into account, I can also have more multicolor sprites horizontally.

Link to comment
Share on other sites

So show me where it says that two sprites in tandem become a single multicolour sprite in there...? And if it doesn't that invalidates your point so comparing one multicolour object generated from two sprites to a single multicolour sprite isn't a fair or objective comparison.

 

53275: "Bit 5 Multiple Color Player Enable". Objective is to compare monochrome vs. monochrome and multicolor vs. multicolor.

 

Where does that say that two sprites working in tandem with that bit enabled become one sprite?

 

Objective is to compare monochrome vs. monochrome and multicolor vs. multicolor.

 

If one machine needs two sprites to generate a multicolour object then comparing it to half of those applied resources on the other is never going to be an objective or fair comparison.

Link to comment
Share on other sites

Good at least you understood the definition of multicolor. Original argument was for comparing two multicolored sprites and I did agree C64 has more multicolored sprites. So as you state Atari has superior implementation, however you got the priorities thing screwed up. You can get the black even with sprite overlaps without involving playfields. First multicolor sprite has 3 colors + black if it intersects with part of 2nd multicolor sprite. Second multicolor sprite has 3 colors + black if it intersects with first multicolor sprite so its 6+black. This is without considering conflict with playfields.

 

>If someone were trying to replicate the Atari pm's directly they would use 3 C64 sprites to emulate 2 linked players. It wouldn't be elegant - but it would work.

 

No, it would not unless you use raster line interrupts. I already proved earlier atari sprite hardware renders more pixels per frame than C64. Remember, I am one of those that live in more than one dimension so you have to take my position into account. And if I take interrupts into account, I can also have more multicolor sprites horizontally.

 

 

great, now that you prooved atari multicolor sprites are superior, why not do with them a turrican clone which would be superior to the c64 ? :D

Link to comment
Share on other sites

What's interesting to me is how much the Atari benefits from CPU intervention. The default Atari modes aren't that great for colorful stuff, but throw some CPU behind it and the improvement can be dramatic.

 

The 64 benefits a little less from CPU usage but the graphics are pretty capable to begin with.

 

As far as I can tell, the Spectrum can't be helped. The limitations remain no matter what you do. This is also the case with the Apple II. These represent fundamental architecture differences.

 

Yeah, and everytime you re-use a color index with a different color horizontally and vertically or do multicolor sprite overlays, you are adding to the bit depth of the image with ceiling of bit depth set at 8 on the Atari (assuming no interlace). On C64, your ceiling is 4 so even if you had a C64 running at 10 Ghz you max out there.

Link to comment
Share on other sites

What's interesting to me is how much the Atari benefits from CPU intervention. The default Atari modes aren't that great for colorful stuff, but throw some CPU behind it and the improvement can be dramatic.

 

The 64 benefits a little less from CPU usage but the graphics are pretty capable to begin with.

 

As far as I can tell, the Spectrum can't be helped. The limitations remain no matter what you do. This is also the case with the Apple II. These represent fundamental architecture differences.

 

Yeah, and everytime you re-use a color index with a different color horizontally and vertically or do multicolor sprite overlays, you are adding to the bit depth of the image with ceiling of bit depth set at 8 on the Atari (assuming no interlace). On C64, your ceiling is 4 so even if you had a C64 running at 10 Ghz you max out there.

 

its 4 on the atari too. either monochrome, or monoluma :)

Link to comment
Share on other sites

>>53275: "Bit 5 Multiple Color Player Enable". Objective is to compare monochrome vs. monochrome and multicolor vs. multicolor.

 

>Where does that say that two sprites working in tandem with that bit enabled become one sprite?

 

Commodore came to me in the middle of the night and told me-- it's called implementation as I have given numerous other similar examples.

 

>>Objective is to compare monochrome vs. monochrome and multicolor vs. multicolor.

 

>If one machine needs two sprites to generate a multicolour object then comparing it to half of those applied resources on the other is never going to be an objective or fair comparison.

 

I am not comparing it to all your C64 sprite resources nor Atari's either. Perhaps Crazyace can help you.

Link to comment
Share on other sites

I'd always prefer this:

 

amaurote.png

 

Deviating from the comparison a bit but... that's going to look a bit different on a television because it's going to artefact fairly badly right?

 

Not again... Can we please stick to the real colours?

It's fully depending on the device you put behind the computer. While my old 1084 shows heavy artefacting, my 15 years old colour TV show no artefacting. And using SVIDEO nevers shows any...

 

It's more interesting that such a huge userbase is not able to create fast playable 3D on the C64.

 

If we're talking isometric 3D (since that comment follows on from the Amaurote screenshot then there are some C64 examples such as Action Biker, Spindizzy, Vendetta, Mission Impossibubble, Marble Madness, the Last Ninja and Sir Arthur Pendragon series and so on that handle isometric at what most people would consider a reasonable speed; the mistake here is assuming the C64 coder of Amaurote tried and failed to make it work in 3D, according to Ste Pickford he remembers the decision being made before code was started to not directly convert and use the top down view instead.

 

...Action Biker, and even worse "The last Ninja" .... They look like ISO 3D but they are handled 2D, depending on the sprites of the C64. Amaurote clearly works with "3D" collision on the Atari, while in "The last Ninja" you get crazy by the faulty collision handling, when playing through the game.

 

Actually, the C64 would have around the half speed available for a, ISO 3D game like Amaurote, compared to the Atari. And, I guess, Ste Pickford has known the last Ninja well. before doing the same mistake again, he seemed wanting to make a playable game instead of a badly interactive graphics and sound demo.

Link to comment
Share on other sites

I am not comparing it to all your C64 sprite resources nor Atari's either. Perhaps Crazyace can help you.

 

Your original claim several pages back was that one multicolour sprite on the Atari had three unique colours and one multicolour sprite on the C64 only had one and two shared - the point i've maintained is that your use of the word "sprite" is incorrect in the Atari's case because, as the book you cited and others say, it's a multicolour object constructed from two sprites. Two sprites versus one is never an even playing field.

Link to comment
Share on other sites

Oswald,

 

You said - "great, now that you prooved atari multicolor sprites are superior, why not do with them a turrican clone which would be superior to the c64 ?"

 

That is exactly the point your (and many others here) circular and meaningless arguments rotate upon.

 

Koronis Rift - better on A8 than C64, plays to the 800's strengths.

Turrican - plays to C64 strengths, unseen on A8 - but A8 version would be difficult to do and be visually less impressive.

 

Why not as an Atari programmer create a game that exploits all the A8's abilities and cannot be done on the C64 - would that prove a point?

 

No it would not - since each round of the argument would be met with the same idiotic "well mine can do this" blah, blah, blah - exploiting the DIFFERENCES between the systems - defining no "better" value, just points of difference.

 

History shows the C64 sold better than any other 8bit PC, it relieved as a result the efforts of the entire games industry to back it, to exploit it, to make money from it. That same popularity meant more people got the machine to use their artistic talents on, hence the great swathe of wonderful C64 demos and artwork - anyone who fails to concede that is just plain stupid.

 

That does not mean no one who loves their A8 should not try and do something great with it - Yoomp! is a wonderful game I bought this year, the presence or lack of a C64 version does not affect me or my enjoyment of it.

 

sTeVE

Link to comment
Share on other sites

Not again... Can we please stick to the real colours?

It's fully depending on the device you put behind the computer. While my old 1084 shows heavy artefacting, my 15 years old colour TV show no artefacting. And using SVIDEO nevers shows any...

 

thats something that never happens on the c64 (whats this artefacting stuff? I have no idea as never had a8). looks like the a8 designers had no idea how to make colors accurate in 320x resolution, the whole gfx engine is based on 160x.

 

 

...Action Biker, and even worse "The last Ninja" .... They look like ISO 3D but they are handled 2D, depending on the sprites of the C64. Amaurote clearly works with "3D" collision on the Atari, while in "The last Ninja" you get crazy by the faulty collision handling, when playing through the game.

 

whats worse about TLN than action biker?! :) and what has the c64 sprites has to do with how isometric games work? its up to the coder. collision detection has nothing to do with how you display the game map. if its isometric its isometric. ;)

 

Actually, the C64 would have around the half speed available for a, ISO 3D game like Amaurote, compared to the Atari.

 

actually the difference is never bigger than 1.7, and thats when the a8 doesnt displays anything. Amaurote displays a bitmap, so the difference is smaller there.

 

And, I guess, Ste Pickford has known the last Ninja well. before doing the same mistake again, he seemed wanting to make a playable game instead of a badly interactive graphics and sound demo.

 

LN was so bad that it was the best selling game for the c64. also it was ported from the c64 to a lot of other systems. ;)

Link to comment
Share on other sites

Oswald,

 

You said - "great, now that you prooved atari multicolor sprites are superior, why not do with them a turrican clone which would be superior to the c64 ?"

 

That is exactly the point your (and many others here) circular and meaningless arguments rotate upon.

 

Koronis Rift - better on A8 than C64, plays to the 800's strengths.

Turrican - plays to C64 strengths, unseen on A8 - but A8 version would be difficult to do and be visually less impressive.

 

unlike atariski I am not trying to proove that 2+2=5. I admit happily koronis rift is better :) I am enjoying how he is trying to make 2+2 equal to 5 :)

 

 

History shows the C64 sold better than any other 8bit PC, it relieved as a result the efforts of the entire games industry to back it, to exploit it, to make money from it. That same popularity meant more people got the machine to use their artistic talents on, hence the great swathe of wonderful C64 demos and artwork - anyone who fails to concede that is just plain stupid.

 

why it sold better? spectrum sold better in the UK than c64, still majority of the games arent better because of more talent, etc blah.

 

 

That does not mean no one who loves their A8 should not try and do something great with it - Yoomp! is a wonderful game I bought this year, the presence or lack of a C64 version does not affect me or my enjoyment of it.

 

Why do you implicate that I am insisting that anyone should stop loving a8 and stop being creative on it ? I dont.

 

I dont want to hurt Yoomp!'s author, but as a coder I dont find it very impressive. I have done enough tunnels myself, its simple to do. Crownland or Space Harrier is more complex, or that a8 turrican demo, imho. and why on earth do a8 people sell/buy games? dont you do it for fun ?

Link to comment
Share on other sites

Last Ninja is NOT an isometric game in the way the Ultimate Spectrum titles or A8 Amaurote is...

 

LN uses masks to allow sprites to appear to go behind objects, but they do not - rather than doing proper depth sorted isometric.

 

Now before anyone shouts and jumps up an down I would like to point out that I HAVE the C64 source code, I have studied John's code - back in the day I was developing an A8 conversion of LN II for system 3. Discussions of that would make fun thread...

 

In addition I worked on a series of games published by Microprose under the brand name X-COM, all of which were isometric games...

 

Rest assured I know what I am talking about - at least in this instance :D

 

sTeVE

Link to comment
Share on other sites

Artifacting = Chroma Distortion (C-64 terminology).

 

Can happen with singlular width pixels/lines on both machines. It's described in the C-64 Tech manual as well as many Atari ones.

 

Author a DVD with a black background then put up a picture with similar sized lines - you'll be able to generate it there too I'd suspect.

 

Has absolutely nothing to do with the computer - it's a weakness of the way the TV standards work.

Link to comment
Share on other sites

Artifacting = Chroma Distortion (C-64 terminology).

 

Can happen with singlular width pixels/lines on both machines. It's described in the C-64 Tech manual as well as many Atari ones.

 

Author a DVD with a black background then put up a picture with similar sized lines - you'll be able to generate it there too I'd suspect.

 

Has absolutely nothing to do with the computer - it's a weakness of the way the TV standards work.

 

hmm, but on the a8 its used to achive some kind of gfx effects ? what kinds? on the c64 it wasnt used to do this.

Link to comment
Share on other sites

Last Ninja is NOT an isometric game in the way the Ultimate Spectrum titles or A8 Amaurote is...

LN uses masks to allow sprites to appear to go behind objects, but they do not - rather than doing proper depth sorted isometric.

 

arent speccy iso games using masks to allow sprites to appear to go behind objects ? I see no difference. and what have depth sorting and moving objects have to do with the definition of isometric projection anyway ?

 

Now before anyone shouts and jumps up an down I would like to point out that I HAVE the C64 source code, I have studied John's code - back in the day I was developing an A8 conversion of LN II for system 3. Discussions of that would make fun thread...

 

wow! would love to hear the whole story about it, and your insights of the c64 engine. care to open a new thread ? :)

Link to comment
Share on other sites

Last Ninja is NOT an isometric game in the way the Ultimate Spectrum titles or A8 Amaurote is...

 

It is an isometric 3D game though, the question wasn't about complexity but speed and playability. Speaking of Amaurote, i've just had an admittedly fairly cursory look at it (i've never been keen on it as a game personally) and i don't believe there is any height involved, background clipping and collisions seem to be done on a per tile basis and the movement is even locked down to stepping between tiles. To my mind, that means Action Biker is more complex in how the player interacts with the environment in that respect, it's got slopes, ramps and areas of the landscape that have differing heights to deal with and there are sections of the landscape that can be driven over or under depending on how they're approached.

Link to comment
Share on other sites

I was arguing that Atari multicolor sprites are better implementation than C64 multicolor sprites. Yes, I did agree that this would reduce number of sprites. After TMR loses the argument, he tries to change the premises like he did with his sprite Y position argument. Two multicolor Atari sprites give you 6 colors + black + any priority conflict colors. Two C64 multicolor sprites gives 4 colors. End of argument.

 

I have a problem with your argument..

 

If we take 1 multicolour sprite, just to simplify things..

 

Atari is 2 players - so 2 independant colours + 1 mixed colour or black.... that's only 3 colours - with the 3rd colour being very restricted.

(The other priority combinations are very interesting - but they also involve playfield, so they almost negate the 'sprite' aspect - I would use them in the number of colours per line argument )

C64 is 1 independant colour + 2 shared sprite colours. - so for a single sprite there are effectively 3 unrestricted colours.

 

For 2 muticoloured sprites things start to go to the Atari side

 

A8 : 4 independant colours + 2 shared/black = 6

C64 : 2 independant colours + 2 shared = 4

 

so if you stop here ( as you did ) the Atari seems superior...

 

but that's a fallacy.. as you have pretty much exhausted the Atari H/W capabilities here ( missiles could be considers part of the players to avoid any arguments about sprite size ) and the C64 still has 6 more multicolour sprites.

 

If anything the biggest weakness of the C64 sprite system is that there's only 1 unique colour per sprite. You can see it in action in most games and C64 programmers work around the limitation.

However even with this limitation the C64 sprites are still more powerfull than the A8...

...

 

Good at least you understood the definition of multicolor. Original argument was for comparing two multicolored sprites and I did agree C64 has more multicolored sprites. So as you state Atari has superior implementation, however you got the priorities thing screwed up. You can get the black even with sprite overlaps without involving playfields. First multicolor sprite has 3 colors + black if it intersects with part of 2nd multicolor sprite. Second multicolor sprite has 3 colors + black if it intersects with first multicolor sprite so its 6+black. This is without considering conflict with playfields.

 

I disregarded the player-player priority as well - as it still involves interaction with playfield. It also isn't really a free extra colour - as you need the other players. ( I think using the missile as an extra colour might be preferrable )

It is a cool feature of the atari priority system though :) and if the C64 sprite system only had 2 sprites I would count it as an advantage...

 

 

>If someone were trying to replicate the Atari pm's directly they would use 3 C64 sprites to emulate 2 linked players. It wouldn't be elegant - but it would work.

 

No, it would not unless you use raster line interrupts. I already proved earlier atari sprite hardware renders more pixels per frame than C64. Remember, I am one of those that live in more than one dimension so you have to take my position into account. And if I take interrupts into account, I can also have more multicolor sprites horizontally.

 

Yes it would work with the limitation of the C64 sprites ( 21 lines by 24 pixels wide )... If you wanted a single 224 line high multicolour sprite you would need interupts.

 

Saying the Atari sprite hardware renders more pixels per frame is a strawman argument. It is a lot easier to multiplex sprites vertically - and both systems tend to use interupts.

In my eyes the PM graphics are 1D sprites , and the C64 sprites are 2D - just because each player is a 224(ish)x8 object with one degree of freedom. The C64 is a 21x24 object with 2 degrees of freedom.

How many multicoloured independant objects can you have per line ( not sharing graphics data ) - there are 114 processor cycles per line and you need lda #/sta grafp0/lda#/sta grafp1/lda#/sta colpm0/lda#/sta colpm1/lda#/sta hposp0/lda#/sta hposp1 to change a multicolour sprite completely

 

That's 2+4 cycles * 6 to reposition a single multicolour sprite , and you need another (2+4)*4 cycles to reposition it for the next line ( normal player dma is quicker to refresh graf registers ) - so that's 60 cycles to reposition a single multicolour sprite - in a way that severely limits it's interaction or position. ( and Antic DMA may take most of the rest )

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...