Atari v Commodore

[Rockford]

Actually Gyruss I don't see much difference between versions, could just be me though maybe A8 has more sprite sizes/positions. I'm rubbish at comparing stuff like this. lol

 

http://www.youtubedoubler.com/?video1=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DSA1PERH9i8Q&video2=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D98vAYjfR4u0

 

 

Pete

Don't worry Pete, I am good at this, so relax, have a drink and let me act. I've had Gyruss on my list anyway.

 

Try another Parker Brothers..

Gyruss 1984

Smoother and better game play than the c64 version. C64 is improving at this stage but still not as good as A8

For sure as I also own this arcade machine and play it frequently.

Stuff that one Rockford.

Aren't you dead yet?

 

http://www.youtube.com/watch?v=SA1PERH9i8Q&feature=related

Really... Imagine I've tested it on both computers and arcade too, and I've actually PLAYED 3 versions. You know, watching games on you tube is not enough.

Do you actually own the Arcade? I do! The Atari version is easily the better one. Is yours the Parker Bros version? I have seen all three and have the Machine to base that opinion on.. Get a life...

Do you know what you are talking about at all ? The original arcade was made by Konami, whereas A8 & C64 Gyruss was published only by Parker Bros. There are not other versions on A8&C64 LOL ... or maybe you have Parker's arcade

do you have a brain Rockford, I need no lecture on Arcade machines, I have nearly 50, including gyruss..You really are clueless. You always seem to come up with some version that is not of the same period and try to pass it off as a direct competitor. Get a clue guy!

Quite the contrary, you need some serious lecture on Arcade machines. When you ask me silly questions like above it only proves that you don't know what you are talking about :D

[TMR]

As regards programming properly, at a more general level most sensible coders wouldn't use the hardware collisions for shoot 'em ups anyway because pixel perfect collisions are too restricting; have a play of something like Gradius and you can get away with murder (especially if you do the volcanoes at the end of level 1 the way i do, with half the ship wedged into the upper landscape!) and the general rule of thumb is "the busier it gets, the smaller the hit box" to the point where Ikaruga and Psyvariar are only looking at a single pixel near the middle of the player's craft.

 

Of course, but knowing exactly what collisions are there in the first place, and then refining them, is a pretty handy starting point rather than manually faffing about and having no starting point to narrow things down with

 

The "project" i knocked out over the weekend actually proved more difficult than less with hardware though, the "stack" of sprites used for the nasties for example, either i have to read and clear the collisions after each is displayed (not easy in itsself because in atariksi's "honour" i tried to do the entire thing on a single entry point DLI so it actually splits the players every character line but doesn't change where it's getting the data from until every fourth) or use a combination of hard and soft collisions to work out which nasty has been shot... i'm going to remove the hardware collisions because i'd rather have the constant of the software ones than the "bursts" caused by the hardware noticing something needs checking and setting them off only occasionally.

 

I thought long and hard about this, and possibly using a VCS style kernel to colour players, but it just wasn't viable to burn the entire display time, and in character modes it's really not going to happen unless you throw some ugly contraints into the colour and positioning equation.. I tried various other DLI driven kernels (ie: 16/32 of them selected on a per scanline basis by the active player bits[1]) but ran into colour changing problems as you mention.. And gave up and went back to players with underlays[2]..

 

i might have to give it another go later just to see how far i can push things... i'm thinking a bitmapped background to even out the timing, 32 byte wide playfield (hopefully the second LMS won't cause too many problems) and an excuse within whatever game this starts to feel like in order to keep the players within that area to avoid splitting problems...

 

[2] Underlays as opposed to overlays, because then I can at least use the collision registers. in that case without spazzy looking sprites.. Though with expanded player underlays it's a murky and inaccurate world in collision-land

 

Speaking of underlays... what's your knowledge of the priority register like (it gives me a headache reading the docs to be honest...) because when i set the missiles to 5th player mode they insisted that they wanted to be on top of everything; is that the emulator snaffling things or is there another bit controlling them in those circumstances...?

[Rockford]

The c64 version is glitchey, slow and the sound is off..

....yeahh and the BIG TEN is the best college football conference Daydreaming is good for you

 

The Atari version is smooth,and much more like the arcade.

In what aspect ? vivid purple & green stars and space ships or ugly sprites in low-res ?

How did we get to football? I could care less.

 

As for looks and play... again get a clue, I have the machine, and the A8 version looks and plays correctly, the c64 version is not smooth and doesn't play like my machine. Again C64 loses

 

I wrote it as an example of prattle. You know, some people still believe that A8 Gyruss is superior as well as the Big Ten is the best in football, whereas most rationally thinking people know it's rubbish You live in Ohio, so you should know it better :D

Edited September 30, 2009 by Rockford

[PeteD]

 

 

Speaking of underlays... what's your knowledge of the priority register like (it gives me a headache reading the docs to be honest...) because when i set the missiles to 5th player mode they insisted that they wanted to be on top of everything; is that the emulator snaffling things or is there another bit controlling them in those circumstances...?

 

Here's a snipperoo from the Altirra site, it also explains the weirdness that was being seen the other day (I think)....

 

First, the error. It pertains to the fifth player, or P5 above. The fifth player is a mode enabled by PRIOR[4] where the four two-bit missiles take on the color of the seldom used playfield 3 instead of using the individual player colors, thus allowing you to move the missiles together to make a fifth 8-bit player. The way this is actually implemented in the priority logic is simply to OR the missiles into PF3 instead of P0-P3, which means that it acts just like PF3. This is the only way that more than one playfield signal can be set, and as it turns out, PF3 wins. The one case that matters is the PRIOR[3:0]=1000 mode, where the players split the playfield. This leads to the weird result that the fifth player is covered by players unless PF0 or PF1 is underneath, in which case P5 shows up on top. Weird.

 

 

Pete

[Rockford]

OK I don't see what the fuss is about, there is clearly no difference between both version using VICE or Win800plus. The only differences are sound (personal preference) and that you need to be slightly more accurate shooting the ships in the centre of the screen on the C64 version, possibly because it is running in a slightly higher resolution.

 

There is the odd bit of flicker on the C64 version but this could be a sync issue on PC monitor/50hz PAL emulation of a C64. BUT on the A8 version (and I have two different copies of ATRs one with a trainer and one original dump) the enemy ships swarm around the screen at two thirds the speed of either the C64 or the Arcade version on MAME so clearly it is not exactly like the arcade as the ships move too slowly making perfect hits on the bonus stages on A8 a lot easier. So on has an interlace type effect and one runs the enemy ships at 66% of original speed.

 

Hardly a slam dunk either way...pretty much 1:1 if you consider these faults compared to the Arcade. I can see nothing more than personal preference between the A8 and C64 version myself so unless anyone has a technical explicit issue to add that's how it's staying for me.

 

And yes I know the arcade version very well and play it often but just played that too on MAME in succession. All games were played using one identical controller and I ended up on the same level on all three games with just 2 goes on each for fairness.

Just to remind everybody...wasn't it atarian63 who first put forward the nonsensical thesis that A8 version of Gyruss is better and closer to arcade ? :D There was the movie on youtube too LOL What's more funny, he still sticks to it

Edited September 30, 2009 by Rockford

[TMR]

Speaking of underlays... what's your knowledge of the priority register like (it gives me a headache reading the docs to be honest...) because when i set the missiles to 5th player mode they insisted that they wanted to be on top of everything; is that the emulator snaffling things or is there another bit controlling them in those circumstances...?

 

Here's a snipperoo from the Altirra site, it also explains the weirdness that was being seen the other day (I think)....

 

Thanks Pete - yeah, that's pretty much the weirdness i was having alright... i'll need to do some more experimentation then, but it seems that Plan A (how pretentious is that?! =-) will still work.

[frenchman]

do you have a brain Rockford, I need no lecture on Arcade machines, I have nearly 50, including gyruss..You really are clueless. You always seem to come up with some version that is not of the same period and try to pass it off as a direct competitor. Get a clue guy!

Quite the contrary, you need some serious lecture on Arcade machines. When you ask me silly questions like above it only proves that you don't know what you are talking about :D

 

And right at this moment Rocky Mountains has become the authority on cabs, actually lecturing owners of arcade machines. He obviously googled.

The C64ers must be very saddened by the fact they have him to defend Commodore 64.

[andym00]

The "project" i knocked out over the weekend actually proved more difficult than less with hardware though, the "stack" of sprites used for the nasties for example, either i have to read and clear the collisions after each is displayed (not easy in itsself because in atariksi's "honour" i tried to do the entire thing on a single entry point DLI so it actually splits the players every character line but doesn't change where it's getting the data from until every fourth) or use a combination of hard and soft collisions to work out which nasty has been shot... i'm going to remove the hardware collisions because i'd rather have the constant of the software ones than the "bursts" caused by the hardware noticing something needs checking and setting them off only occasionally.

 

Ah, okay I see, that would complicate matters Reading them on the last line of a displayed sprite, when you reload the next one up gives you a complete an accurate picture of the collision events as they unfold which requires just a simple lookup to get the sprite index that caused the collision with your just read sprite..

 

I like them.. It allows (and encourages) other ways of doing things.. I mean making entities event driven and such like..

 

i might have to give it another go later just to see how far i can push things... i'm thinking a bitmapped background to even out the timing, 32 byte wide playfield (hopefully the second LMS won't cause too many problems) and an excuse within whatever game this starts to feel like in order to keep the players within that area to avoid splitting problems...

 

Is it considered poor form to do an LMS on every line ? I've opted for that simply to allow flexible DLI control, though I feel that might be slight overkill

 

Speaking of underlays... what's your knowledge of the priority register like (it gives me a headache reading the docs to be honest...) because when i set the missiles to 5th player mode they insisted that they wanted to be on top of everything; is that the emulator snaffling things or is there another bit controlling them in those circumstances...?

 

Only what I've read here, and it seems fairly straight forward, though the Altirra thing I see Pete just posted went a long way to clearing up things for me.. I was horribly confused after the many things I'd read on AA..

 

As for the 5th player stuff, grrrr, I don't like.. I hate having to grab all 4 collision registers and the retarded setup code for positioning it drives me mad In really heavy sprite use, setting those 4 positions are the cause of more glitches than anything else thanks to the extra cycles to position them and read the collisions.. So I'm trying to find more uses for them as four 2 pixel wide sprites now, and making 10 pixel wide players pains me because of the cost of loading the graphics up each frame..

[jvas]

It's time to leave atarian fantasy land and return to reality

 

29 - GYRUSS

 

C64

C64

C64

 

The C64 plays more smoothly and has better music, sprites, graphics in hi-res, in which it resembles arcade version (on C64 everything is near arcade perfect: displays, proportions of ships, death sequence - check out the last picture and compare). The Atari version has graphics in low-res (strange colours as always ) and chunky, deformed sprites - very often it's hard to distinguish asteroids from alien ships If you don't believe PLAY INSTEAD OF WATCHING THEM C64 is better again

 

ATARI

ATARI

ATARI

 

ARCADE VERSION

 

The colors of your Atari screenshots are very inaccurate.

Blame Atari sites (like atarimania or fandal), not me

 

But you are the one, who compare games based on false facts (colors in this case)

[andym00]

And right at this moment Rocky Mountains has become the authority on cabs, actually lecturing owners of arcade machines. He obviously googled.

 

Actually Emkay has that honour I believe, since according to his royal highness lower resolution is better from a gameplay and graphics point of view, and therefore the A8 version is better than the arcade..

 

The C64ers must be very saddened by the fact they have him to defend Commodore 64.

 

I've got plenty of popcorn

[TMR]

Ah, okay I see, that would complicate matters Reading them on the last line of a displayed sprite, when you reload the next one up gives you a complete an accurate picture of the collision events as they unfold which requires just a simple lookup to get the sprite index that caused the collision with your just read sprite..

 

S'a bit more complex than that apparently, you have to write to a register to zero the collisions and that apparently does everything so i'd end up having five blocks of collision data from various points on the screen and would need to compare within those blocks; it's not much more efficient than using software really, plus i get the looseness that i'd prefer to have into the bargain...

 

Is it considered poor form to do an LMS on every line ? I've opted for that simply to allow flexible DLI control, though I feel that might be slight overkill

 

i don't know how the A8 coders feel about it but i'd not have called it poor form personally; Zybex is doing the same thing presumably so it knows the steps between each scanline of the sprites for example. It's not the most optimal solution if you're relying on the processing time during the frame, but if you're drawing software sprites in the extra calculations you'll need for a minimal LMS scrolling display probably take a teeny bit more grind anyway.

 

Oh, i tried what i was talking about with the colour splitting whilst on my lunch break; i can split all four player colours on a scanline with a 32 byte wide playfield (with horizontal scrolling enabled) but can't go to 40 bytes wide because the second LMS causes one of the colour splits to happen during the screen. Of course, it's a tiny area but the part-time perfectionist in me just isn't happy knowing it'd be there...

 

So I'm trying to find more uses for them as four 2 pixel wide sprites now, and making 10 pixel wide players pains me because of the cost of loading the graphics up each frame..

 

i'm thinking bullets and using the 5th player mode to assign 'em a uniform colour personally...

[Rockford]

It's time to leave atarian fantasy land and return to reality

 

29 - GYRUSS

 

C64

C64

C64

 

The C64 plays more smoothly and has better music, sprites, graphics in hi-res, in which it resembles arcade version (on C64 everything is near arcade perfect: displays, proportions of ships, death sequence - check out the last picture and compare). The Atari version has graphics in low-res (strange colours as always ) and chunky, deformed sprites - very often it's hard to distinguish asteroids from alien ships If you don't believe PLAY INSTEAD OF WATCHING THEM C64 is better again

 

ATARI

ATARI

ATARI

 

ARCADE VERSION

 

The colors of your Atari screenshots are very inaccurate.

Blame Atari sites (like atarimania or fandal), not me

 

But you are the one, who compare games based on false facts (colors in this case)

You are wrong again I always PLAY BOTH VERSIONS (sometimes even more )However some atarians (like number 63 ) usually judge by pictures or movies on youtube :D But even when we assume that the colours are slightly different from what you see on screen (after all vivid pink and green stars always look hilarious ), it doesn't change the number of colors or the resolution. So, rest assured

Edited September 30, 2009 by Rockford

[TMR]

The C64ers must be very saddened by the fact they have him to defend Commodore 64.

 

Not really no, but i think that if i'd been on the A8 side of the fence during this discussion there would've been a few things said that would've had that effect.

[Rockford]

And right at this moment Rocky Mountains has become the authority on cabs, actually lecturing owners of arcade machines. He obviously googled.

 

Actually Emkay has that honour I believe, since according to his royal highness lower resolution is better from a gameplay and graphics point of view, and therefore the A8 version is better than the arcade..

 

The C64ers must be very saddened by the fact they have him to defend Commodore 64.

 

I've got plenty of popcorn

ROTFL One day you will kill me

[Mclaneinc]

 

 

Speaking of underlays... what's your knowledge of the priority register like (it gives me a headache reading the docs to be honest...) because when i set the missiles to 5th player mode they insisted that they wanted to be on top of everything; is that the emulator snaffling things or is there another bit controlling them in those circumstances...?

 

Here's a snipperoo from the Altirra site, it also explains the weirdness that was being seen the other day (I think)....

 

First, the error. It pertains to the fifth player, or P5 above. The fifth player is a mode enabled by PRIOR[4] where the four two-bit missiles take on the color of the seldom used playfield 3 instead of using the individual player colors, thus allowing you to move the missiles together to make a fifth 8-bit player. The way this is actually implemented in the priority logic is simply to OR the missiles into PF3 instead of P0-P3, which means that it acts just like PF3. This is the only way that more than one playfield signal can be set, and as it turns out, PF3 wins. The one case that matters is the PRIOR[3:0]=1000 mode, where the players split the playfield. This leads to the weird result that the fifth player is covered by players unless PF0 or PF1 is underneath, in which case P5 shows up on top. Weird.

 

 

Pete

 

 

Pete, can you link me to that please, I'm not seeing it on the site so maybe I'm missing a section?

[emkay]

Actually Emkay has that honour I believe, since according to his royal highness lower resolution is better from a gameplay and graphics point of view, and therefore the A8 version is better than the arcade..

 

 

Ah! I guess you start to learn ...

 

Ofcourse, framerate and -all in all fitting- presentations on the screen got to be the first point where a game should be built on.

If the hardware can do better, you just have to do "all better" to keep the content fitting together....

But in this case the C64 has a clubfoot. It is simply not possible to have a game running fully in 320x200. One problem you find in the colour resolution handling, one problem you find in the "limited" sprites, and the biggest problem you find in the retarded CPU.

 

As I stated several times before. Games like Turrican and Katakis were cleverly done to fit to the C64 hardware. Most elements do not rotate, so the aspect ratio of 2/1 fits and can enhance the visuals there.

Rotating elements look better if they look same when shown same with a 90° rotation. So the developers have to use a shape that uses doubled pixels vertically ....

 

(if only this was something new yet)

 

Or, in "modern" words:

 

People playing games like Counterstrike CoD / Crysis or else, reduce the graphics until the framerate gets absolutely stable and the reaction of the game gets as immediate as possible. So they rule over all nerds that run their game in the highest resolution , just by the fact that they get slowdowns due to the used system and CPU that cannot handle all needed data fast enough when the action is going tough....

 

 

 

BTW: I don't feel insulted when you call me "royal highness" .... keep going ....

Edited September 30, 2009 by emkay

[PeteD]

 

 

Pete, can you link me to that please, I'm not seeing it on the site so maybe I'm missing a section?

 

Sure

 

http://www.virtualdub.org/blog/pivot/entry.php?id=243

 

 

Pete

[Mclaneinc]

 

 

Pete, can you link me to that please, I'm not seeing it on the site so maybe I'm missing a section?

 

Sure

 

http://www.virtualdub.org/blog/pivot/entry.php?id=243

 

 

Pete

 

 

Thanks for that Pete, I didn't realise it was from his mini faq he did, thought I was missing Altirra updates

 

Cheers..

[Rockford]

The C64ers must be very saddened by the fact they have him to defend Commodore 64.

 

Not really no, but i think that if i'd been on the A8 side of the fence during this discussion there would've been a few things said that would've had that effect.

I'm afraid that frenchman doesn't take the hint

[analmux]

As regards programming properly, at a more general level most sensible coders wouldn't use the hardware collisions for shoot 'em ups anyway because pixel perfect collisions are too restricting;

Bounding Box Solutions should be just as good?

 

(again) refering to the NES SMB : Even all Mario vs. Enemy collision etc. is done by bounding box checks by software.

[PeteD]

 

Thanks for that Pete, I didn't realise it was from his mini faq he did, thought I was missing Altirra updates

 

Cheers..

 

It does seem to be quite well hidden on the site I read it a while ago then couldn't bloody find it again until some random googling dredged it up for me

 

 

Pete

[analmux]

And right at this moment Rocky Mountains has become the authority on cabs, actually lecturing owners of arcade machines. He obviously googled.

Just give up on this guy. Arguing with him doesn't have any effect. I'd call this the "Oswald" effect.

 

So, I'd like to propose everyone to stop replying to Rockford. It'll stop, as he is only here for malicious delight, nothing else. Did you ever see him posting in another topic, or even reading one? Did you ever hear someting sensible from him?

 

Just to all: Ignore him! Shouldn't be too hard.

[analmux]

Ah, okay I see, that would complicate matters Reading them on the last line of a displayed sprite, when you reload the next one up gives you a complete an accurate picture of the collision events as they unfold which requires just a simple lookup to get the sprite index that caused the collision with your just read sprite..

 

S'a bit more complex than that apparently, you have to write to a register to zero the collisions and that apparently does everything so i'd end up having five blocks of collision data from various points on the screen and would need to compare within those blocks; it's not much more efficient than using software really, plus i get the looseness that i'd prefer to have into the bargain...

 

Is it considered poor form to do an LMS on every line ? I've opted for that simply to allow flexible DLI control, though I feel that might be slight overkill

 

i don't know how the A8 coders feel about it but i'd not have called it poor form personally; Zybex is doing the same thing presumably so it knows the steps between each scanline of the sprites for example. It's not the most optimal solution if you're relying on the processing time during the frame, but if you're drawing software sprites in the extra calculations you'll need for a minimal LMS scrolling display probably take a teeny bit more grind anyway.

 

Oh, i tried what i was talking about with the colour splitting whilst on my lunch break; i can split all four player colours on a scanline with a 32 byte wide playfield (with horizontal scrolling enabled) but can't go to 40 bytes wide because the second LMS causes one of the colour splits to happen during the screen. Of course, it's a tiny area but the part-time perfectionist in me just isn't happy knowing it'd be there...

 

So I'm trying to find more uses for them as four 2 pixel wide sprites now, and making 10 pixel wide players pains me because of the cost of loading the graphics up each frame..

 

i'm thinking bullets and using the 5th player mode to assign 'em a uniform colour personally...

I advice you to open a new topic / thread for this project. When discussing this stuff here, it will get lost in the war.

 

Anyway, the screenshot looks nice. Good job.

[andym00]

S'a bit more complex than that apparently, you have to write to a register to zero the collisions and that apparently does everything so i'd end up having five blocks of collision data from various points on the screen and would need to compare within those blocks; it's not much more efficient than using software really, plus i get the looseness that i'd prefer to have into the bargain...

 

But you just or the results of all 4 together as you read them, before clearing, and that's what gets stored on a per sprite collision basis..

 

Of course, if you've got variable height sprites or aren't using a round-robin re-use scheme then obviously things are much much more pain than that when it comes to resolving collisions

 

But depending upon your sprite numbers and actual requirements it all swings and roundabouts I guess

 

i don't know how the A8 coders feel about it but i'd not have called it poor form personally; Zybex is doing the same thing presumably so it knows the steps between each scanline of the sprites for example. It's not the most optimal solution if you're relying on the processing time during the frame, but if you're drawing software sprites in the extra calculations you'll need for a minimal LMS scrolling display probably take a teeny bit more grind anyway.

 

I thought LMS was only 3 cycles cost ? I'm quite happy to lose 696 cycles for a simple life

 

Oh, i tried what i was talking about with the colour splitting whilst on my lunch break; i can split all four player colours on a scanline with a 32 byte wide playfield (with horizontal scrolling enabled) but can't go to 40 bytes wide because the second LMS causes one of the colour splits to happen during the screen. Of course, it's a tiny area but the part-time perfectionist in me just isn't happy knowing it'd be there...

 

How's that triggered ? A fixed kernel or regions or interrupts ?

One of the things I was thinking of was using the Timer interrupts on each line to do something like that, syncing the timer up so that it arrived int the irq code just about level with the end of the displayed line by the time jitter and everything else was taken into account, then doing up to 4 load/stores for player colours, without hitting wsync at all..

I mean 114 - 9 (refresh) - 32 (narrow dma) - 5 (PM dma) - 3 (I think the LMS cost) = 65 cycles left, of which 32 of those are on the visible line..

It would burn a lot of CPU time during the lines when stuff is active, but at least it goes someway towards giving you some time back, and not leaning on wsync during the massively coloured regions and having all the changes off screen..

[jvas]

It's time to leave atarian fantasy land and return to reality

 

29 - GYRUSS

 

C64

C64

C64

 

The C64 plays more smoothly and has better music, sprites, graphics in hi-res, in which it resembles arcade version (on C64 everything is near arcade perfect: displays, proportions of ships, death sequence - check out the last picture and compare). The Atari version has graphics in low-res (strange colours as always ) and chunky, deformed sprites - very often it's hard to distinguish asteroids from alien ships If you don't believe PLAY INSTEAD OF WATCHING THEM C64 is better again

 

ATARI

ATARI

ATARI

 

ARCADE VERSION

 

The colors of your Atari screenshots are very inaccurate.

Blame Atari sites (like atarimania or fandal), not me

 

But you are the one, who compare games based on false facts (colors in this case)

You are wrong again I always PLAY BOTH VERSIONS (sometimes even more )However some atarians (like number 63 ) usually judge by pictures or movies on youtube :D But even when we assume that the colours are slightly different from what you see on screen (after all vivid pink and green stars always look hilarious ), it doesn't change the number of colors or the resolution. So, rest assured

 

I don't know what you played or not. I just reacted to your post: you posted screen shots of the games (no more proof/additional information) and comment that like this: "(strange colours as always )". If you say that your conclusion is based on that you played both versions, why posting inaccurate screen shots? If you played the Atari version, how didn't you realized that looks different on a real computer than on the screen shot? I haven't played the C64 version, I just know, that the pictures of the Atari version are not right.