Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

Here is some c64 love for our "freind" Mr "aren't you dead yet" Rockey the c64 loon.

Here is the fantastic Ikari warriors circa 1986.. He he!

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

 

It's not a bad game really considering it was knocked out in a couple of months at most (Elite hardly took their time)...not much different to the much later 7800 version.

Link to comment
Share on other sites

Geez Oky, at least link to a vid in which the guy playing knows how to get in a tank:

 

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

 

Of course, we're looking at the far superior UK version here, whereas the screen posted earlier was from the dire US version. (Don't tell frenchman that!)

 

Atarian63, this thing you're doing where you run off to Lemon64, search for low-rated games, and then post pics of them here is pretty dumb, honestly. You must know that anyone with the inclination could post an absolute boatload of shots of extremely crappy looking Atari games from your so-called golden age. But what would that prove? That there were crappy games released even during the system's best years?* OMG, say it aint so!

 

At least Rockford is actually comparing games that appeared on both systems, rather than just digging out shots of any crappy game he can find. Meanwhile, you're starting to look like a guy with a full-body skin condition who is trying to point and laugh at the odd patch of scaly skin on somebody else's elbow.

 

*I say 'best years', but the way you're carrying on, I'm starting to wonder if your so-called Atari 'Golden Age' is actually maybe three weeks somewhere near the start of 1983. Except, funnily enough, although you'll immediately insist that a game like Gauntlet is unfit for comparison due to coming after this mythical 'Golden Age', I have a feeling that somehow we wouldn't hear a peep out of you on that score when it comes to certain other '85 releases being put on the comparison table: Rescue on Fractalus, for example. The Eidolon, maybe? Alternate Reality?

Edited by Barnacle boy
Link to comment
Share on other sites

Glad you like it barnacle brain. It just shows how bad the system was during the period. There are many examples. Your problem is that you have bias towards c6 as you silly comments here have shown for quite some time. You just don't like it when the example doesnt further you silly view of things. Rockey on the other hand is really a goof. You guys should get together.Also you seem to have missed the C64 "hard Drivin" example posted earlier. c64 1988. Major company produced.

1985 had a few great title for Atari but it was mostly over by then due to the crash and c64 catching on only due to being cheap and that it was.

You really are out there. Go on back to lemon now. I am sure you will find many who have your view and that will make you feel good. :D

Edited by atarian63
  • Like 1
Link to comment
Share on other sites

Man, seeing that you were on here and posting, I waited something like fifteen minutes just to see what you had to say...

 

And that ramble the best you could do? Disappointing. I won't bother sticking around next time.

 

It just shows how bad the system was during the period. There are many examples.

But does it? I mean, really? If I post one hundred screenshots from crappy looking Atari games released in '82-'83, would you say "Well yes, that just shows how bad the Atari was during that period".

 

Or would you start up with the "Yeah but, no but, see, the thing is... they were just bad programmer jobs, etc etc."

 

Do you not see how dumb (and hypocritical) your position is here? Come on. Be honest with yourself.

Edited by Barnacle boy
Link to comment
Share on other sites

Man, seeing that you were on here and posting, I waited something like fifteen minutes just to see what you had to say...

 

And that ramble the best you could do? Disappointing. I won't bother sticking around next time.

 

It just shows how bad the system was during the period. There are many examples.

But does it? I mean, really? If I post one hundred screenshots from crappy looking Atari games released in '82-'83, would you say "Well yes, that just shows how bad the Atari was during that period".

 

Or would you start up with the "Yeah but, no but, see, the thing is... they were just bad programmer jobs, etc etc."

 

Do you not see how dumb (and hypocritical) your position is here? Come on. Be honest with yourself.

Your childish comments are hardly worth replying to, though I am glad I can irritate you. Now back to the Lemon64 site with you ;)

Link to comment
Share on other sites

Today another classic copyrighted by Atari !!! as always especially for number 63 :D

 

36 - GAUNTLET

 

post-24409-125485998533_thumb.png

C64

post-24409-125486003224_thumb.gif

C64

post-24409-125486006187_thumb.gif

C64

 

The C64 version has better graphics, handling, more colours and plays smoothly. The Atari version is anemically slow and it has limited number of colours (all monsters, chests etc. are always in the same colour as the background :D ). C64 defeats Atari again. :cool: BTW, It's really amusing how an Atari game looks and plays better on C64. :D

 

post-24409-125486075401_thumb.png

ATARI

post-24409-125486077009_thumb.png

ATARI

post-24409-125486079554_thumb.png

ATARI

 

Hey atarian63, what happened this time ? :D

 

Whilst Gauntlet is an Atari arcade game, Jack Tramiel's Atari had nothing to do with it so really they are not related. Old stuff like Battlezone and Asteriods etc was the same company as the makers of the home computers yep but by this time (1985 onwards) it was a totally separate company.

 

C64 Gauntlet is actually pretty good for US Gold, they're UK output was pretty pathetic half the time on the C64...probably the best 8bit version (better than Amstrad, not seen it on MSX)

 

As fun as this is I don't think looking at games UNLESS they are games with a clear technically stunning bit of programming in them (regardless of what ports of it look like on other machines) is going to tell you which machine is better. Look at Gauntlet 1 on the Atari ST and then try not to piss your pants when you look at Gauntlet II running on the Amiga ;)

Since it is closely related to the A8 series it should look good.

Edited by atarian63
Link to comment
Share on other sites

You really don't want to answer this question, do you?

 

It just shows how bad the system was during the period. There are many examples.

But does it? I mean, really? If I post one hundred screenshots from crappy looking Atari games released in '82-'83, would you say "Well yes, that just shows how bad the Atari was during that period".

 

Or would you start up with the "Yeah but, no but, see, the thing is... they were just bad programmer jobs, etc etc."

Link to comment
Share on other sites

See, this is what I don't mind seeing - just the pics.... Opinion not necessary. We report....you decide. I WANT to know what's "good" on C64. I think this one qualifies. What the hell happened to the Atari version? I remember playing it back in the day on the 800XL and was glad I could at least play at home. Then I (think?) I played it on the ST. I have it on the NES and the Genesis (very good port). But the old Commodog did this one well back in the day, admittedly.

 

 

Today another classic copyrighted by Atari !!! as always especially for number 63 :D

 

36 - GAUNTLET

 

post-24409-125485998533_thumb.png

C64

post-24409-125486003224_thumb.gif

C64

post-24409-125486006187_thumb.gif

C64

 

The C64 version has better graphics, handling, more colours and plays smoothly. The Atari version is anemically slow and it has limited number of colours (all monsters, chests etc. are always in the same colour as the background :D ). C64 defeats Atari again. :cool: BTW, It's really amusing how an Atari game looks and plays better on C64. :D

 

post-24409-125486075401_thumb.png

ATARI

post-24409-125486077009_thumb.png

ATARI

post-24409-125486079554_thumb.png

ATARI

 

Hey atarian63, what happened this time ? :D

Link to comment
Share on other sites

Actual US release of Ikari Warriors for c64. You guys seem to just want to pick what suits you. UK version bites well... then the US version must be the only one that exists.. or vice versa,whatever shows your view icon_rolleyes.gif

 

The US version seems to be better somehow. At least the gamescreen is 320(160) wide. While the "preferred" version only has 256(128) pixel width.

Link to comment
Share on other sites

The US version seems to be better somehow. At least the gamescreen is 320(160) wide. While the "preferred" version only has 256(128) pixel width.

Goodness me, what were they thinking? It's almost as if they wanted to make the layout a little closer to the vertical orientation of the arcade original.

 

If only you had been there to witter pointlessly at them and show them the error of their ways.

Link to comment
Share on other sites

The US version seems to be better somehow. At least the gamescreen is 320(160) wide. While the "preferred" version only has 256(128) pixel width.

Goodness me, what were they thinking? It's almost as if they wanted to make the layout a little closer to the vertical orientation of the arcade original.

 

If only you had been there to witter pointlessly at them and show them the error of their ways.

 

 

If people knew how "huge" the borders of the C64 really were... and then they reduced the screen from 40 bytes to 32 bytes width.... they would have bought a 50" TV right in the 80s then.

Seems TV producing industry did miss the free riding on the C64 selling wave.

Selling slogan "C64 screens weren't too small, but your TV Set is"...

  • Like 1
Link to comment
Share on other sites

First of all, of course you're right, given the situation you describe. But, isn't it a highly theoretical situation, when we have say 64 sprites onscreen and we need to check all of them if they collided with one another? (be it in groups of 8, because of the 8-per-scanline-limit). And if so, then of course the VIC-II wins, when we're just looking at used CPU time.

 

However, in many situations, we have a player and an army of enemies. Most of the time we don't care if, say enemy 45, collided with enemy 57.

OK, if we have just 8, I think it makes more difference when there were multiple collisions. Maybe sprite 0 is the player, 1&2 are some bullets, 3-7 are enemies. Then f.e. 1&6 and 0&4 could be a real situation. One enemy dies, and the player dies.

 

Now suppose we have 1 player, 6 bullets, and the rest of them (57) are enemies (enemy bullets also count as an enemy). Then we can simply ignore a 57 * 57 collision table, can't we? And what IF we wouldn't ignore that. Say, we need to check a 57*57 collision table. Some games (see a simple one: Super Mario Bros.) have interaction between enemies, be it a simple bounce. Then, IF we see an enemy2enemy collision took place, we'd need to execute logic after that, to simulate the effect. Well, the collision of 57*57 isn't the most work for the CPU then.

 

You process a collision as your interrupt tears down the screen.. Then (either in the interrupt or later at the screen end, it's up to you) you just fire the collision events that occured at the entities involved, with collision events allowed to modify the entity state asynchrounously and without any dependency upon the entities current state (in my case mostly the late collision events only change the animation frame).. The entity logic would pick up changed state from the collision later on that were modified by the collision and process as normal..

Anyway.. This is all getting far too specific now, and well away from the point and of course there's other ways of doing things.. I'm simply headed down this route because it's the easiest way for me to handle collision and entity logic for a bucket-load of aliens and bullets..

 

And, seeing the world through Atari-eyes: 64 PM objects is already much. Just only moving all the data around is an enormous task. By the time the 64th has finished drawing, all frame time is up. So, in this situation an atari coder would already have made the step from using PM to software sprites (in many cases). At least using character-clusters, see f.e. Dropzone, then the CPU load will be less. When using f.e. Antic 4 with some charclusters, we could make the switch to player2playfield collision. We could stick to one of the 4 bitpairs to trigger some action, after collision took place. That's really another advantage of the GTIA, we could check collision between players/missiles and PF0-3 separately. There's no way to solve this on C64. We could choose between different bitpairs to trigger a different action....f.e. PF0 is an enemy, PF1 is a powerup, PF2&3: IGNORE (!).

 

Why is 64 too much ? If you want a game with that many 8 pixel wide objects that don't all have the same colours you don't really have a choice ? I think you'll find you don't burn your entire frame handling them.. I as doing 48 in an earlier test, and with improved interrupts, and a better update mechanism it was easily running in half the cpu time, in AnticE..

 

In fact sitting here right now, I've got a 32 player version running (using 12 pixel high objects) and it's taking ~100 scanlines for everything (AnticE scanlines).. The reason why, is simply because I want 32 4 coloured objects on screen, with each object being able to have a unique colour..

I want even more objects, so there's the beginnings of a seperate missile multiplexer added to this as well for even more..

 

There is simply no way I can do that in software sprites, not without looking like every other A8 game out there or reducing the sprite count to something tiny.. I tried character mode sprites, and whilst they're all fine and dandy and get me the 5th colour the speed is abysmal.. Even using allowing each charline to only access 32 chars to reduce the code needed still works out too much, and then there's the clearing cost.. Obviously you don't need to clear all chars, or even those used.. But the fastest option would be for the character drawer when it 'allocates' a character because the cell is 0 underneath still has to zero out the top Y&7 lines of data and the bottom !Y&7 lines in the first an last character line.. That combined with the logic of checking the character and generating an index to the character to write (ok, only ~20 cycles or so) just seems too much to me.. And the fastest way I could come up with involved some painful address setup.. I'll post the code if you want somewhere.. As it stands I was looking at about 24 scanlines in Antic4 to draw a 16x16 in it's worst case scenario, spread over 9 chars.. And being able to draw 10 of those in the visible screen area wasn't fast enough by a long way..

 

In the above mentioned character sprite thing I never even got as far as implementing the masking in that because I was mortified by how slow it was just copying data in and zeroing the above empty lines and bottom empty lines, with the per character masking it'd need to fix up new pointers for the source character when we are overlapping and other things.. I just canned it and went to bitmap mode instead, which I'm happy with.. For now.. Just can't help but miss that 5th colour though..

 

Anyway.. I think you and I have very different games in our heads ;) I've got more along the lines of Dangun Feveron in mine, and I'm imagining your having SMB in yours ;)

 

But my point was that the cost of the players is high just for the additional unique colour (or the 2 shades or'd mode) that it provides, something that the A8 doesn't do very often, something the breaks away from the quite traditional look you have.. I'm really curious about htis or mode though using 2 players because I just can't find anything really colourful to make with it.. I'd love to see examples of what's considered cutting edge in the use of players with this stuff..

 

But, good luck finding an artist that'll draw your colour-collision-world like that for you, and trying to debug it :) Green is good, Red is Bad :) I'm sure you could come up with some wacky game that suited that.. In fact I'm sure there's a game in the idea of colour collisions alone ;)

 

But this is an endless subject.. There's been 30 years of game programming idea on collisions and logic and all that gumpf, none of which is the single correct answer, you use what you use that suits your game.. I only wanted to stress the fact that A8 collision isn't perfect in many ways, and that the C64 isn't perfect either, but not as useless as is often made it.. It does what it says on the tin, and in many cases that's more than enough..

 

As for other ways of collisions, I'm not going down that discussion route, life is too short ;)

 

I'm sorry, but to me it wasn't clear we were talking about a specific usage. Someone (save2600) just said in general C64 sprite collision is better. That's not really the case. My original post on that was a reply on save2600's post. So, I'm not sure how you interpreted we were talking about 64+ sprite multiplexers.

It didn't start off like that, I just wanted to press home the fact that the cost of the collision registers on the A8 start to get expensive as sprite number rise..

Probably me taking this particular cause to heart at the moment since it's been a massive bugbear for me... I was expecting the collisions to be sweetness and light on what I'm writing because, on paper at least, it looked like handling the collisions was going to be a walk in the park.. It didn't turn out to be at all, and hence my gripe about it being easier and faster to treat the A8s Player to Player collisions as you would on VIC, but there's still the additional cost of all those register reads..

 

That's a very universal statement, as if it has only disadvantages. The feature could also be used as an advantage. For example, how many games were published where the protagonist had to kill a large final boss, by hitting him at some specific place? I played many.

 

Of course there's pros and cons for it.. But using the player underlays as collision masks isn't always going to be possible for all uses..

And in your game, it'd lit up bright red anyway :)

 

However, don't get it all personal, but in a sense you're trying to turn an advantage into a disadvantage. We could compare it to C64's colour features. Almost every C64 user visiting this thread makes the statement "colourcells is superior", or at least start laughing when an A8 user doesn't see that, or doesn't want to see that ;).

I'm happy to accept each machines features for what they are.. In some ways scrolling is easier in implementation on the VIC because you only have so many ways you can do it, so it's less of a decision to make, and the cost is known.. On the A8 you have far more options, but that combined with a multitude of ways to do everything else scrolling, sprites, collisions etc make it so much harder to come up with a functional kernel that delivers what you want, simply because you can't have the best of everything in there, at least from what I've been finding out anyway, and I at least spent far too long go round in circles trying to implement the fastest things on everything and not really making much progress with anything else..

 

All I wanted to say is there's far more things to keep an eye on on the A8 that'll come back and bite you on the arse later on if you're not careful ;)

 

With all of the super trick things you can do to some extent cancel each other other out when you try to bolt them all together.. ie: The fastest approach to sprites is scuppered by needing a insanely large screen stride to work effectively when scrolling in any direction as well.. It works, but at the expense of memory, and more cost for the sprite drawers when in the region where the screen wraps.. Or you use non page matched line sizes, and then incur more work in the sprite line steps instead of a simple inc.. It all adds up.. Anyway, point is I was just ranting on that because it's a personal bugbear with me at the moment.. To ensure speed is kept up, I've got to make sure that when the screen wrapped line occur on screen that I keep as many sprites away from that line as possible to ensure I don't drop frames.. And the whole approach (the best way for scrolling the screen) makes you pay for that ease by having more expensive sprites.. There is simply no way to have the best of all worlds on that count, not that I can see at least, nor can I see in the library of games on the A8 either..

 

However, when scrolling you need to move twice as much data. And that's only in the present days, when VSP scrolling is there. There's however only a handful of games making use of that. Many of the older ones use double buffers, for playfield and colourcell field, and all the char-tiles/colour-tiles needed to be shifted by CPU.

Twice as much memory, for 4 times as many colours :D Seems like a fair trade to me ;)

 

Anyway.. For the record you can't double buffer the VIC 4 bit colour-ram.. You have to copy it on the fly.. There is one way to do it though, and that involves abusing vics badlines and generating 16 high character lines so only half the colour-ram is used, you can then double buffer colour-ram.. The cycles saved in badlines (12*40), are about equal to the amount of cycles spent in the interrupts on those lines to skip the character fetch, so it's not a speed up in any way apart from less colour ram need to be processed, and less character ram to process..

 

Is it going to scroll ? If so then you need to devote X% of your frame time to moving screen data.. That percentage being dependent upon your maximum scroll speed and whether or not it's bitmap or not, and whether you're scrolling colour ram as well.. It's pretty simple, gives you less cycles to work with, but since it's once of the first things to go in, you know where you stand cycle-wise..

 

No wonder Turrican II didn't have enough cpu time for in-game music (except for the flying levels), and the scrolling isn't even 50, but 25 fps.

 

And are you 100% sure that Turrican didn't have music because there wasn't time ? There's some very fast music players out there, the macro ones are particularly nippy.. I think maybe you should double check if Manfred actually wanted an annoying piece of music playing over and over and over being cut off by effects all the time ;)

 

As for being 25FPS, are you sure ? I've never played it, I hate those type of games anyway, so I won't be playing it anytime soon :) So I'll take your word on that..

 

edit: It just struck me in the car, if it's running at 25FPS, then I'd speculate that a lack of CPU time is highly unlikely to be the reason there's no music.. Either it's because of memory, or (more likely in my opinion) that it was a design choice not to feature music in game..

 

 

(I'm too hungover to go through properly and fix any mistakes in this post, it's too long and editing in this tiny little window is a pain, so it stays as is because I've got to run off)

Edited by andym00
Link to comment
Share on other sites

Atarian63, this thing you're doing where you run off to Lemon64, search for low-rated games, and then post pics of them here is pretty dumb, honestly. You must know that anyone with the inclination could post an absolute boatload of shots of extremely crappy looking Atari games from your so-called golden age. But what would that prove? That there were crappy games released even during the system's best years?* OMG, say it aint so!

 

At least Rockford is actually comparing games that appeared on both systems, rather than just digging out shots of any crappy game he can find. Meanwhile, you're starting to look like a guy with a full-body skin condition who is trying to point and laugh at the odd patch of scaly skin on somebody else's elbow.

 

*I say 'best years', but the way you're carrying on, I'm starting to wonder if your so-called Atari 'Golden Age' is actually maybe three weeks somewhere near the start of 1983. Except, funnily enough, although you'll immediately insist that a game like Gauntlet is unfit for comparison due to coming after this mythical 'Golden Age', I have a feeling that somehow we wouldn't hear a peep out of you on that score when it comes to certain other '85 releases being put on the comparison table: Rescue on Fractalus, for example. The Eidolon, maybe? Alternate Reality?

Woah ! It's so bullshitless and straight to the point!

Link to comment
Share on other sites

Glad you like it barnacle brain. It just shows how bad the system was during the period. There are many examples. Your problem is that you have bias towards c6 as you silly comments here have shown for quite some time. You just don't like it when the example doesnt further you silly view of things. Rockey on the other hand is really a goof. You guys should get together.Also you seem to have missed the C64 "hard Drivin" example posted earlier. c64 1988. Major company produced.

1985 had a few great title for Atari but it was mostly over by then due to the crash and c64 catching on only due to being cheap and that it was.

You really are out there. Go on back to lemon now. I am sure you will find many who have your view and that will make you feel good. :D

 

 

This is the bullseye, well put.

  • Like 1
Link to comment
Share on other sites

Atarian63, this thing you're doing where you run off to Lemon64, search for low-rated games, and then post pics of them here is pretty dumb, honestly. You must know that anyone with the inclination could post an absolute boatload of shots of extremely crappy looking Atari games from your so-called golden age. But what would that prove? That there were crappy games released even during the system's best years?* OMG, say it aint so!

 

At least Rockford is actually comparing games that appeared on both systems, rather than just digging out shots of any crappy game he can find. Meanwhile, you're starting to look like a guy with a full-body skin condition who is trying to point and laugh at the odd patch of scaly skin on somebody else's elbow.

 

*I say 'best years', but the way you're carrying on, I'm starting to wonder if your so-called Atari 'Golden Age' is actually maybe three weeks somewhere near the start of 1983. Except, funnily enough, although you'll immediately insist that a game like Gauntlet is unfit for comparison due to coming after this mythical 'Golden Age', I have a feeling that somehow we wouldn't hear a peep out of you on that score when it comes to certain other '85 releases being put on the comparison table: Rescue on Fractalus, for example. The Eidolon, maybe? Alternate Reality?

Woah ! It's so bullshit

 

 

you are so right.

Edited by frenchman
Link to comment
Share on other sites

As for being 25FPS, are you sure ? I've never played it, I hate those type of games anyway, so I won't be playing it anytime soon :) So I'll take your word on that..

 

Turrican is 25FPS, Turrican 2 is 50FPS. Turrican 3 came later but is 50FPS with in-game music.

Link to comment
Share on other sites

You really don't want to answer this question, do you?

 

It just shows how bad the system was during the period. There are many examples.

But does it? I mean, really? If I post one hundred screenshots from crappy looking Atari games released in '82-'83, would you say "Well yes, that just shows how bad the Atari was during that period".

 

Or would you start up with the "Yeah but, no but, see, the thing is... they were just bad programmer jobs, etc etc."

Once again, instead of beating around the bush, you get straight to the point, however, don't be so cruel on atarian63, please. ;) When I compare games on both computers (I poke a stick in the cage :D ) he always goes bananas and talks absolute rubbish. I love seeing him like this! :D

Link to comment
Share on other sites

As for being 25FPS, are you sure ? I've never played it, I hate those type of games anyway, so I won't be playing it anytime soon :) So I'll take your word on that..

 

Turrican is 25FPS, Turrican 2 is 50FPS. Turrican 3 came later but is 50FPS with in-game music.

 

Ah, thanks for clearing that up.. Saves me playing it ;)

But naughty Analmux, changing the facts to suit.. Tut-tut ;)

Edited by andym00
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...