Atari v Commodore

[atariksi]

Going back to original question-- which machine can put up more sprites simultaneously on the screen. Atari can and I specifically mentioned thousands 8*1 flooded all over the screen. You stated C64 can do the same. Now you are arguing some other point-- there's a CPU restriction or Y-axis motion does not have enough cycles. First you need to make up your mind whether you are still going to stick to C64 can do the same or not before you try to raise other issues. Sprites are still sprites even if they don't move in the y-axis.

 

Just to clarify - are you talking about thousands of different 8x1 bitmaps moving around the screen, or thousands of identical 8x1 bitmaps , or thousands of 8x1 lines ?

 

How many thousands? and what resolution are these 8x1 bitmaps ( 320pixel, or 160 pixel )

 

You can have 2000+ sprites at 8*1 moving on the screen. It's easy math-- you have 4 players at 8*1 full height screen and vertically multiplexed every scanline and you have 4 missiles vertically multiplexed every scanline and zoomed to 8*1. That's 248*8 visible sprites on PAL, 240*8 visible sprites on NTSC...

[Goochman]

Id love to see a demo of 500 of these sprites moving on screen

[Crazyace]

Going back to original question-- which machine can put up more sprites simultaneously on the screen. Atari can and I specifically mentioned thousands 8*1 flooded all over the screen. You stated C64 can do the same. Now you are arguing some other point-- there's a CPU restriction or Y-axis motion does not have enough cycles. First you need to make up your mind whether you are still going to stick to C64 can do the same or not before you try to raise other issues. Sprites are still sprites even if they don't move in the y-axis.

 

Just to clarify - are you talking about thousands of different 8x1 bitmaps moving around the screen, or thousands of identical 8x1 bitmaps , or thousands of 8x1 lines ?

 

How many thousands? and what resolution are these 8x1 bitmaps ( 320pixel, or 160 pixel )

 

You can have 2000+ sprites at 8*1 moving on the screen. It's easy math-- you have 4 players at 8*1 full height screen and vertically multiplexed every scanline and you have 4 missiles vertically multiplexed every scanline and zoomed to 8*1. That's 248*8 visible sprites on PAL, 240*8 visible sprites on NTSC...

 

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

Edited April 9, 2009 by Crazyace

[atariksi]

Stop this thread it's getting silly.

getting silly?

 

Did we ever settle if the rubber feet on the 800 are superior to the ones on the 64?

 

The rubber feet on my Amiga 4000 melted (at room temperature) so at least those are inferior to those on Amiga 1000 and Atari 8bits.

 

Believe me my room temperature is not at melting point of rubber; it's 70 degrees fahrenheit.

[atariksi]

Atariski...you should really come down to earth... you seem to have fun in terms of try to discuss in a "correct" manner like we learned in school and in philosophic course at university... but is it pratical?

 

yes...of course you can call 240x8 = 1920 sprites but in reality? can you move them around? can you at least do something practical with them in games?

 

you would need to feed in a kernal 8 hpos registers plus 4 graphpx registers plus 1 graphm register not to mention the colour registers...

 

aehm... should we now state that 800 has 1920 hardware sprites? in 256 colours? come on...

 

same goes to some of your aspects refering to a single bit of hardware... sometimes I feel you are too academic with the loose for reality...

 

I did give example of practical use that I did-- enhance an image by overlaying top of Graphics 9 mode (that's antic mode K)-- in that case there were 4 8*1 per line and 4 2*1 per line and few more wherever I could squeeze them in (total > 2000).

 

You don't need to set GRAFn more than once per line. You have the GRAFn set via DMA automatically for the 4 players and missiles and you have enough time to setup another GRAFn and set another HPOS >100 times per frame even after updating all 8 HPOSes for players and missiles.

 

I don't know what you are talking about regarding the "single bit of hardware".

 

And if by "correct" manner you are complaining about my dealing with Frohn-- he was being duplicitous-- first he states C64 can also do what Atari can regarding 2000+ sprites and then when proven wrong he has this backup plan-- it's useless or it's impossible to do on Atari as well. Nice deceptive way to argue huh--

plan A: whatever Atari can do just say C64 can do until someone proves you wrong;

plan B: if they do prove it wrong, just say it's useless until someone thinks of good use for it;

plan C: if they do find a good use for it, just say that Atari can't do it either until someone actually goes and does it or prove it can be done.

plan D: if they prove it can be done, pretend you missed that posting because you left town, went on vacation, etc. and repeat the same point again (The TMR may have been the original found of this plan).

[atariksi]

Going back to original question-- which machine can put up more sprites simultaneously on the screen. Atari can and I specifically mentioned thousands 8*1 flooded all over the screen. You stated C64 can do the same. Now you are arguing some other point-- there's a CPU restriction or Y-axis motion does not have enough cycles. First you need to make up your mind whether you are still going to stick to C64 can do the same or not before you try to raise other issues. Sprites are still sprites even if they don't move in the y-axis.

 

Just to clarify - are you talking about thousands of different 8x1 bitmaps moving around the screen, or thousands of identical 8x1 bitmaps , or thousands of 8x1 lines ?

 

How many thousands? and what resolution are these 8x1 bitmaps ( 320pixel, or 160 pixel )

 

You can have 2000+ sprites at 8*1 moving on the screen. It's easy math-- you have 4 players at 8*1 full height screen and vertically multiplexed every scanline and you have 4 missiles vertically multiplexed every scanline and zoomed to 8*1. That's 248*8 visible sprites on PAL, 240*8 visible sprites on NTSC...

 

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

You forgot the "..." in my message (I had to run away for a couple of hours).

 

The standard set of players and missiles replicated every line gives 240*4 of 8*1 and 240*4 of 2*1 missiles zoomed to 8*1 so total 8*1 sprites is 1920. Now you use horizontal sprite replication using GRAFn/HPOS of a player to get another 8*1 sprite every other scanline or so. This gives 2040 sprites for NTSC and more for PAL. So it's 2000+ as I stated. And that's with all DMA channels enabled at 54272. And this is without using GRAFn to replicate vertically for free (so not stretching it at all).

[Crazyace]

no problem, just curious , as I reckoned that reuse of pm's would add a whole world of pain if you're moving every sprite every frame.

[Fröhn]

Okay, frohn read the replies-- don't skip and state the same thing again and again based on your biased imperfect analysis. Here's the reply you forget to reply to again (see above).

My biased analysis? It is your biased analysis. What you are trying to do is to find something against the C64s strongest feature: sprites. If there is one field where the C64 can beat the A8 any day it's sprites.

[Heaven/TQA]

Going back to original question-- which machine can put up more sprites simultaneously on the screen. Atari can and I specifically mentioned thousands 8*1 flooded all over the screen. You stated C64 can do the same. Now you are arguing some other point-- there's a CPU restriction or Y-axis motion does not have enough cycles. First you need to make up your mind whether you are still going to stick to C64 can do the same or not before you try to raise other issues. Sprites are still sprites even if they don't move in the y-axis.

 

Just to clarify - are you talking about thousands of different 8x1 bitmaps moving around the screen, or thousands of identical 8x1 bitmaps , or thousands of 8x1 lines ?

 

How many thousands? and what resolution are these 8x1 bitmaps ( 320pixel, or 160 pixel )

 

You can have 2000+ sprites at 8*1 moving on the screen. It's easy math-- you have 4 players at 8*1 full height screen and vertically multiplexed every scanline and you have 4 missiles vertically multiplexed every scanline and zoomed to 8*1. That's 248*8 visible sprites on PAL, 240*8 visible sprites on NTSC...

 

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

You forgot the "..." in my message (I had to run away for a couple of hours).

 

The standard set of players and missiles replicated every line gives 240*4 of 8*1 and 240*4 of 2*1 missiles zoomed to 8*1 so total 8*1 sprites is 1920. Now you use horizontal sprite replication using GRAFn/HPOS of a player to get another 8*1 sprite every other scanline or so. This gives 2040 sprites for NTSC and more for PAL. So it's 2000+ as I stated. And that's with all DMA channels enabled at 54272. And this is without using GRAFn to replicate vertically for free (so not stretching it at all).

 

fair enough... but would it be not more fair to speak of sprite overlay? nobody would actually speak of sprites when talking about G2F PM over/underlays?

 

If my memories are right I would found sources in this thread when you were talking about sprite overlays and treat it like separate bitplanes? which is imho better when we are using them as an overlay...

[youki]

I spent few hours on Youtube comparing C64 and A800 version of the same game.

 

In most of the case C64 games seems better.

 

And to quote one comment put by "sctriplefox" on a video :

 

I love the Atari but I have to admit that the C64 usually looks better in period games....Atari can look better only if the game is designed around the hardware. Good for tech demos and hobbyists, not so good for commercial products with limited time/budget.

 

 

So it tends to confirm that in the "real" life , the C64 is a better machine. More polyvalent, more homogeneous.

 

I have never see one commercial game on Atari looking like Mayhem in monsterland on C64

 

 

I found something very nice on Atari : crownland , but it is not completed and looks like more like demo. And the scrolling seems not so smooth (may be due to the video..)

 

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

 

@Atariksi . Can i see somewhere what you do with your Atari? I'm new to this forums , may be your work is very famous here, but i have never seen what you did.

[emkay]

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

Since missiles were also single moving objects, 1920 may be the correct value. But, you could double four players , or at least have 2 players with different shapes. But, because we may talk about the "same faces" of the sprites, you can add 960 to the 1920 moving objects.

 

hm... sum it up to 2880 oneline sprites in a perfect case.

[www.atarimania.com]

Crownland not finished? What do you mean?

 

Anyway, the discussion is pointless because, for one thing, comparing Atari and C64 is ridiculous. Too many hiccups and years lost on the Atari side where NOTHING was happening.

 

It makes a lot of difference when you have a market that can boost your creativity. Progress in programming techniques has always been linear on the C64, not so on the Atari due to a number of circumstances: the "crash", poor marketing, high prices... Atari never was a serious contender in the UK either and this is where A LOT of time was lost.

 

--

Atari Frog

http://www.atarimania.com

[Fröhn]

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

Since missiles were also single moving objects, 1920 may be the correct value. But, you could double four players , or at least have 2 players with different shapes. But, because we may talk about the "same faces" of the sprites, you can add 960 to the 1920 moving objects.

 

hm... sum it up to 2880 oneline sprites in a perfect case.

8 objects per line * 240 rasterlines = 1920. I can't follow you with that "2880" sprites. That with repositioning each rasterline -> no doubling possible.

 

Oh btw, if you count C64 sprites per rasterline too, you get similar numbers, but this time 24 pixels wide

Edited April 10, 2009 by Fröhn

[Heaven/TQA]

Ok - So you mean 992 ( 248x4 ) 8x1 sprites, and 992 ( 248x4 ) 2x1 sprites( using the missles ) - that's stretching it a bit to claim >2000 , I'd say for 8x1 sprites you should group the 4 missiles as a 5th player , which would give you 1240 (248x5) 8x1 sprites

 

Since missiles were also single moving objects, 1920 may be the correct value. But, you could double four players , or at least have 2 players with different shapes. But, because we may talk about the "same faces" of the sprites, you can add 960 to the 1920 moving objects.

 

hm... sum it up to 2880 oneline sprites in a perfect case.

8 objects per line * 240 rasterlines = 1920. I can't follow you with that "2880" sprites. That with repositioning each rasterline -> no doubling possible.

 

Oh btw, if you count C64 sprites per rasterline too, you get similar numbers, but this time 24 pixels wide

 

he ment adding one player per rasterline by repositioning on the rasterline.

[Rybags]

Even though the idea of 1,900 + moving objects is bordering on rediculous on either machine, I doubt you'd be repositioning many sprites per scanline on the C-64.

 

Badlines are the enemy here, although I suppose you can use VScroll tricks to just repeat the one line of characters indefinately without incurring any badlines?

 

Such a demo might be interesting, but you'd need compromises like using positional data multiple times. Maybe something like using a 128 byte X-pos buffer per object.

Read it in order first time, read it backwards and add an offset the second pass.

[Heaven/TQA]

Even though the idea of 1,900 + moving objects is bordering on rediculous on either machine, I doubt you'd be repositioning many sprites per scanline on the C-64.

 

Badlines are the enemy here, although I suppose you can use VScroll tricks to just repeat the one line of characters indefinately without incurring any badlines?

 

Such a demo might be interesting, but you'd need compromises like using positional data multiple times. Maybe something like using a 128 byte X-pos buffer per object.

Read it in order first time, read it backwards and add an offset the second pass.

 

you can not reposition sprites on c64 on a rasterline. no sprite #0 twice per line...

 

so...on the "new" definition here...when I am moving around 7168 pixels per frame... i could claim >7000 software sprites????

[emkay]

he ment adding one player per rasterline by repositioning on the rasterline.

 

I ment adding/re-using/repositioning 4 more player with the same shape.

 

 

I hope, you haven't forgot the demo:

 

 

 

It's that type of player reusing... 4 player used 2 times per scanline = 1920 different moving oneline "sprites" possible

Missiles were not used there but could be added.

[youki]

Crownland not finished? What do you mean?

 

Anyway, the discussion is pointless because, for one thing, comparing Atari and C64 is ridiculous. Too many hiccups and years lost on the Atari side where NOTHING was happening.

 

It makes a lot of difference when you have a market that can boost your creativity. Progress in programming techniques has always been linear on the C64, not so on the Atari due to a number of circumstances: the "crash", poor marketing, high prices... Atari never was a serious contender in the UK either and this is where A LOT of time was lost.

 

--

Atari Frog

http://www.atarimania.com

 

Crownland seems very short for a game and don't seem to be really challenging for a game. Seeing the video, it looks like more an very nice interactive demo. But i can be wrong , i will try to test it as soon as possible.

 

#edit : sorry about crownland , it is completed , i think the youtube video was just a preview. I will try it as soons as possible.

 

I also agree it is ridiculous to compare Atari and C64 . But guys here pretend the opposite and want to compare, so it is why i ask to prove what they say by fact and not theory.

 

Personnaly i really love the 2 machines. The only thing i can say is that both are very good. which one is the best... commercially it is cleary the C64 , in term of overall quality of commercially released games it is also the C64. But Technically i could not say each machine having their own domain where they are better than the other.

Edited April 10, 2009 by youki

[Fröhn]

he ment adding one player per rasterline by repositioning on the rasterline.

I know that. But given his constraints (everything moves + background gfx) it's simply impossible.

[Fröhn]

It's that type of player reusing... 4 player used 2 times per scanline = 1920 different moving oneline "sprites" possible

Missiles were not used there but could be added.

Yeps and C64 sprite engine can do the same (but with 320px wave) without sprite doubling by just using the sprites which are there. That's part of what I ment with "C64 sprite engine beats A8 sprite engine any day".

[atarian63]

Atariski...you should really come down to earth... you seem to have fun in terms of try to discuss in a "correct" manner like we learned in school and in philosophic course at university... but is it pratical?

 

yes...of course you can call 240x8 = 1920 sprites but in reality? can you move them around? can you at least do something practical with them in games?

 

you would need to feed in a kernal 8 hpos registers plus 4 graphpx registers plus 1 graphm register not to mention the colour registers...

 

aehm... should we now state that 800 has 1920 hardware sprites? in 256 colours? come on...

 

same goes to some of your aspects refering to a single bit of hardware... sometimes I feel you are too academic with the loose for reality...

 

I did give example of practical use that I did-- enhance an image by overlaying top of Graphics 9 mode (that's antic mode K)-- in that case there were 4 8*1 per line and 4 2*1 per line and few more wherever I could squeeze them in (total > 2000).

 

You don't need to set GRAFn more than once per line. You have the GRAFn set via DMA automatically for the 4 players and missiles and you have enough time to setup another GRAFn and set another HPOS >100 times per frame even after updating all 8 HPOSes for players and missiles.

 

I don't know what you are talking about regarding the "single bit of hardware".

 

And if by "correct" manner you are complaining about my dealing with Frohn-- he was being duplicitous-- first he states C64 can also do what Atari can regarding 2000+ sprites and then when proven wrong he has this backup plan-- it's useless or it's impossible to do on Atari as well. Nice deceptive way to argue huh--

plan A: whatever Atari can do just say C64 can do until someone proves you wrong;

plan B: if they do prove it wrong, just say it's useless until someone thinks of good use for it;

plan C: if they do find a good use for it, just say that Atari can't do it either until someone actually goes and does it or prove it can be done.

plan D: if they prove it can be done, pretend you missed that posting because you left town, went on vacation, etc. and repeat the same point again (The TMR may have been the original found of this plan).

That does apear to be his plan from what I have seen in this thread.

[Rybags]

What I meant before was repositioning for display on the next scanline, not repeating on the same scanline.

 

Obviously, we want to do this, otherwise you can hardly call 2 pixels moving nearby on adjacent scanlines seperate objects.

[Fröhn]

Let's just reverse the plan: I do something on C64 and atariski tries to do it on A8.

[drac030]

Let's just reverse the plan: I do something on C64 and atariski tries to do it on A8.

 

I have a better plan: I do something on A8, and you do that on C-64.

 

Now:

 

1) software-wise: POKE 559,35

 

2) hardware-wise: power up the computer, and then disconnect the jostick and connect it back, 10 times.

[Heaven/TQA]

Let's just reverse the plan: I do something on C64 and atariski tries to do it on A8.

 

I have a better plan: I do something on A8, and you do that on C-64.

 

Now:

 

1) software-wise: POKE 559,35

 

2) hardware-wise: power up the computer, and then disconnect the jostick and connect it back, 10 times.