Atari v Commodore

[Fröhn]

So you basically dislike inertia movements in games?

[emkay]

DL programming can give additional CPU speed which could be compared with the Sprite Handling of the C64.

 

No, that's just rubbish... if it were true, that preview of a Turrican engine would have somewhere nearer the number of sprites the C64 game slings around but it doesn't.

 

Well, just another time to mention it:

 

THE C64 can do better "sidescrollers" with it's built in features. THE A8 can do better 1st person 3D with it's built in features.

What's so hard to understand here?

[frenchman]

That is what I mentioned before, maybe TMR, Emkay and Frohn and such C64 fanboys are not capable of understanding: When David Crane programmed Dragster with a 12 pixel wide dragster car, the other Atari VCS guys said '12 pixels wide? It cannot be done on the VCS'.

David Crane answered 'I just did it'. (Now don't quote me on the 12 pixel thing, maybe it was just 10 pixels or such. Mainly he did something where others said it is not possible on the VCS but he did it anyway).

To say it cannot be done, is just pure ignorance of the C64 fanboys.

 

And I think The Tail of Beta Lyrae is an excellent side-scroller on Atari XL anyway.

[frenchman]

Oops sorry, I didn't mean 'emkay'

[Barnacle boy]

I shouldn't have to work that hard or need an expert to direct me to a good responsive game, it kinda sums up the experience.

Frankly, this stuff you're saying about c64 games being generally unresponsive sounds like a load of bollocks. The majority of 2d games on the c64 run at 50fps for PAL. That was one of the c64's strengths. If you're going to seriously suggest that most c64 games you've tried have some kind of inherent lag in responsiveness, you'd better start giving some examples.

 

The lemon64 review also notes slow response of ship.

I just read the review here and it said no such thing.

 

So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image).

More non-factual theorising stated as fact. How do you explain those c64 games that multiplex sprites together to create large enemies without any glitching? Reading through some of these posts, it's clear that the way some of you guys perceive the c64 is actually quite different to reality.

 

The C64 has twice the horizontal resolution for smooth scrolling, games like Io or Slayer move at half a multicolour pixel per frame.

And don't forget

!

 

why do you keep using io as an example, I just stated earlier in the thread I loaded it on real hardware, and it was far from speedy or smooth in fact lemon64's fanbase points out all its failings..

Not smooth? It runs at 50fps, updating all scrolling and movement every frame. You're really playing fast and loose with the truth here. The vast majority of criticisms in the lemon64 comments are about its difficulty level, as it is indeed a challenging game. Not a single one of those comments suggests that the game doesn't move smoothly. Is it possible that you're trying to play a PAL game on an NTSC system, and so seeing some kind of framerate glitch?

 

As for speed... Clearly the enemies move swiftly. The bullets move swiftly. The speed of the player ship is obviously a design decision. It's still responsive. Don't confuse speed with responsiveness -- they're not the same thing. With your approach, you might as well look at Raiden in the arcades and say "Ha! It can't move the player ship quickly!"

 

The high frame rate would best be traded a little to service and handle the ship I am controlling

Oh yes... lowering the frame rate will make a game more responsive. Oh yes indeed.

 

Again click the links to lemon64 and you shall see what others have noticed as well and since it is being judged by people who like the machine, it must decidedly be so.

And again, not a single person in those comments is claiming the game isn't smooth. Stop trying to twist the truth. One person says "the craft moves kinda slow over the screen" which has nothing to do with smoothness. If the devs wanted the ship to move faster, it wouldn't be hard, would it? They'd just have to make it jump 2px per frame instead of 1px. OMG! Technical nightmare!

Edited March 31, 2009 by Barnacle boy

[TMR]

So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image).

 

i wouldn't expect that because there's far too many examples where it simply doesn't happen...

 

Rather than be vague about it, you can calculate it

 

i've quite happily done it several times myself without the issues you're theorising, i'm not being the slightest bit vague.

 

if you keep things simple and try to do it in one scanline, you don't have enough cycles to update all 8 sprite positions, shape ptrs, irq latency, etc.

 

Of course not, but then again you don't have to update all of that on one scanline so it's not an issue; sprite Y positions can be changed well in advance, read the sprite's Y, add 21 and write it back at any point whilst it's being displayed, the VIC-II insists on finishing the current sprite and then automagically moves it directly below to carry on where it left off. The only "problem" is changing eight data pointers and that can be done by simply having two screen RAMs (with a set of data pointers each at the end) and toggling between them to change all eight in a single LDA/STA pair.

 

Play Delta, it uses that technique for the sprite-generated landscapes at some points recycling seven sprites directly below themselves without any glitches.

[TMR]

why do you keep using io as an example, I just stated earlier in the thread I loaded it on real hardware, and it was far from speedy or smooth

 

That's because you've missed the point; you were quoting me as i offered Io as a technical example of a game that scrolls at fifty frames a second, half a pixel a frame. It does (unless the player is a bit crap and the sprite multiplex gets overloaded) so my point is absolutely valid, the C64 is smoother than the A8 can be at that speed.

 

in fact lemon64's fanbase points out all its failings.. it only rates a 7.6

 

Big deal, i wouldn't trust that lot to rate anything.

[TMR]

David Crane answered 'I just did it'. (Now don't quote me on the 12 pixel thing, maybe it was just 10 pixels or such. Mainly he did something where others said it is not possible on the VCS but he did it anyway).

 

That story could probably do with a little work, it tails off a bit at the end... the "don't quote me" bit makes it look rather weak, in fact.

 

To say it cannot be done, is just pure ignorance of the C64 fanboys.

 

That depends on what "it" is, doesn't it. i'd call it ignorance to accuse the fanboys of being wrong when there's no evidence available to the contrary, so since you're accusing me personally of ignorance here, rather than a nebulous "it" what specifically have i stated that can't be backed up?

 

And I think The Tail of Beta Lyrae is an excellent side-scroller on Atari XL anyway.

 

There are several others i prefer, Zybex or perhaps Matta Blatta would probably be near the top of the list but i have a soft spot for Lowca and Humanoid despite them being a bit simplistic as regards the attack waves and a truly perverse love of Transmuter even though it's terrible in most respects... oh, and the port of Vanguard from the 5200, i've played that quite a bit!

[atariksi]

If SID is so much better than POKEY, why is it that a simple game like pacman

can't it get the sounds dead on? POKEY did. Defender? You have got to be joking.

the POKEY sounds are arcade perfect and far from close on the C64.

 

Because in both of those cases the C64 version was written a year after the machine was released and the Atari version over three years. If two years more experience with a machine hadn't resulted in them getting the sound effects right i'd be worried.

...

You are changing the subject. Pacman Atari is better than Pacman C64 (perioed). NO excuses. Remember we're comparing games as one of the topics here.

 

>>With the right software control, POKEY will outflex SID anyday.

 

>That's a different comparison, if it's just SID versus POKEY without the CPU getting involved then the SID is more flexible but if you're wanting to bring the CPU in to help the SID can also gain benefits from that extra push.

 

Yeah, sure CPU can help both sides to some extent, but ultimately hardware support is better in this case as 4 multifrequency DACs cannot be made up for by software.

 

>The C64 has twice the horizontal resolution for smooth scrolling, games like Io or Slayer move at half a multicolour pixel per frame.

 

Biased answer. If you want to talk scrolling hardware, Atari wins-- it can scroll horizontally and vertically on per text line/graphics line basis with pointers. And it's not so bad to set up two buffers to simulate half color clock scrolling. Your scroll hardware basically is just a 3-bit value for horizontal and vertical and rest is upto software.

[atariksi]

Ahm, you forget that overscan eats up CPU cycles to limit your C64 multiplexer as well as bad scanlines as well as raster line interrupt overhead as well as all the cycles required to reuse sprite registers for vertical multiplexing.

Opening upper/lower border areas is just 2x LDA STA per frame, and those don't even need to be rasterline accurate. Plenty of tolerance here. That's also what is often done in games to have score/lives/etc display in the upper/lower border areas.

 

The bad lines also don't matter. You have 21 rasterlines tolerance to switch the sprite y-positions, and to switch the gfx contents you just need to have 2 interleaved sets of gfx contents to get you ~10 rasterlines tolerance. The rest is done automatically.

 

The CPU overhead also isn't much. As I said before: Opening upper/lower border is just 2x LDA STA per frame. Switching the 8 Y-positions and 2x screen base register (to switch all 8 gfx data vectors of the sprites at once) also only eats 10x LDA STA every 21 rasterlines. What you get from that is a whole 192*280 gfx layer which can move independent from the background graphics.

 

...

Okay, so you are just doing a monochrome sprite layer; I thought you were going for a multicolor sprite layer which would require updating X positions as well every scan line and thus you would end up with very little time to update Y-positions on the 21st scanline of the sprite unless you had a kernel running. With overscan, you would be going over the 8K bitmap limit. For monochrome bitmap, Atari doesn't need any interrupts.

[atariksi]

...

So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image).

More non-factual theorising stated as fact. How do you explain those c64 games that multiplex sprites together to create large enemies without any glitching? Reading through some of these posts, it's clear that the way some of you guys perceive the c64 is actually quite different to reality.

...

 

You have a mentality like Oswald taking things out of context to construct a straw-man argument. You can create large enemies because you only have to update the Y-position/shape ptrs during the raster interrupt, but in the case of image enhancement using a mulitcolored overlay-- you need to update x registers, y registers, and shape ptrs which won't fit in one scan line time.

[atariksi]

So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image).

 

i wouldn't expect that because there's far too many examples where it simply doesn't happen...

 

Rather than be vague about it, you can calculate it

 

i've quite happily done it several times myself without the issues you're theorising, i'm not being the slightest bit vague.

 

...

 

You wrote initially: "i wouldn't expect that because there's far too many examples where it simply doesn't happen..." That's a vague statement since you are stating it as if so far no example has been found. It's like stating so far I can't distinguish between MP3 and uncompressed audio.

 

>>if you keep things simple and try to do it in one scanline, you don't have enough cycles to update all 8 sprite positions, shape ptrs, irq latency, etc.

 

>Of course not, but then again you don't have to update all of that on one scanline so it's not an issue; sprite Y positions can be changed well in advance, read the sprite's Y, add 21 and write it back at any point whilst it's being displayed, the VIC-II insists on finishing the current sprite and then automagically moves it directly below to carry on where it left off. The only "problem" is changing eight data pointers and that can be done by simply having two screen RAMs (with a set of data pointers each at the end) and toggling between them to change all eight in a single LDA/STA pair.

 

You need to change to new shape ptrs every 21 scanlines (200/21 = 10 times per frame) so you need 10 screen RAM areas along with the overscanned bitmap memory area.

[TMR]

You are changing the subject. Pacman Atari is better than Pacman C64 (perioed). NO excuses. Remember we're comparing games as one of the topics here.

 

One of the topics yes, but Gorf's post that i was replying to wasn't part of that area pf the discussion so if you want to remind someone, he'd be the person to talk to rather than me. i never said that the A8 version of Pac-Man wasn't better, but the C64 one wasn't very good not because of a lack of capabilities on the hardware side and instead because the programmer barely knew how to use it because it'd only recently been released when the conversion was started.

 

If i were more of a cynic i'd assume that since the conversion was done by Atarisoft there's always that chance that whoever wrote it was under pressure to not produce a superior version to their own Atari code... but i'm not. =-)

 

he C64 has twice the horizontal resolution for smooth scrolling, games like Io or Slayer move at half a multicolour pixel per frame.

Biased answer. If you want to talk scrolling hardware, Atari wins

 

But it's not biased because that wasn't the question; it was about smoothness and for games with multi-speed scrolling or fixed speed games that require half pixel movement that extra resolution means the C64 will always be either as smooth or in many cases smoother.

 

And it's not so bad to set up two buffers to simulate half color clock scrolling.

 

Unless i missed something, that doesn't work on 160 pixel resolution graphics because they can't be shifted half a pixel over the two buffers.

 

You wrote initially: "i wouldn't expect that because there's far too many examples where it simply doesn't happen..." That's a vague statement since you are stating it as if so far no example has been found.

 

It's only vague if you remove it from the original context where it was a direct reply to your saying "So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image)". As a response to that it's quite specifically saying that there are several existing examples that disprove what you've said, which there are.

 

You need to change to new shape ptrs every 21 scanlines (200/21 = 10 times per frame) so you need 10 screen RAM areas

 

No, you only need two and simply alternate back and forth, changing the one that isn't in use when the sprite Y positions are adjusted.

[the maddestman]

This is the thread that never ends. It just goes on and on my friends. Somebody started it not knowing what it was, and it will go on and on just because, this is the thread that never ends...

[supercat]

Yeah, sure CPU can help both sides to some extent, but ultimately hardware support is better in this case as 4 multifrequency DACs cannot be made up for by software.

 

In many cases, I think one should evaluate what a sound chip can do if there will be periods of 1,000 cycles or more during which one is not allowed to write to it. Many sound chips can do marvelous things if one is willing to babysit them constantly; even the Atari 2600 can do nice four-voice music with a five-octave range (15.75KHz sample rate), if one doesn't mind spending 60.5% of the CPU cycles on EVERY scan line processing the audio, but for the most part such techniques of sound production aren't practical within a game. Both the SID and POKEY have unique abilities; the SID's filters are unlike anything on any other machine, and the POKEY's four-voices cannot be matched by the SID's three.

[Heaven/TQA]

hmmm.... been quite awhile away from Atari due to personal things and getting Mac OS x on my Samsung NC10 for the iphone SDK.... (working now btw... )

 

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

 

 

 

If SID is so much better than POKEY, why is it that a simple game like pacman

can't it get the sounds dead on? POKEY did. Defender? You have got to be joking.

the POKEY sounds are arcade perfect and far from close on the C64.

 

Because in both of those cases the C64 version was written a year after the machine was released and the Atari version over three years. If two years more experience with a machine hadn't resulted in them getting the sound effects right i'd be worried.

...

You are changing the subject. Pacman Atari is better than Pacman C64 (perioed). NO excuses. Remember we're comparing games as one of the topics here.

 

>>With the right software control, POKEY will outflex SID anyday.

 

>That's a different comparison, if it's just SID versus POKEY without the CPU getting involved then the SID is more flexible but if you're wanting to bring the CPU in to help the SID can also gain benefits from that extra push.

 

Yeah, sure CPU can help both sides to some extent, but ultimately hardware support is better in this case as 4 multifrequency DACs cannot be made up for by software.

 

>The C64 has twice the horizontal resolution for smooth scrolling, games like Io or Slayer move at half a multicolour pixel per frame.

 

Biased answer. If you want to talk scrolling hardware, Atari wins-- it can scroll horizontally and vertically on per text line/graphics line basis with pointers. And it's not so bad to set up two buffers to simulate half color clock scrolling. Your scroll hardware basically is just a 3-bit value for horizontal and vertical and rest is upto software.

[frenchman]

David Crane answered 'I just did it'. (Now don't quote me on the 12 pixel thing, maybe it was just 10 pixels or such. Mainly he did something where others said it is not possible on the VCS but he did it anyway).

 

That story could probably do with a little work, it tails off a bit at the end... the "don't quote me" bit makes it look rather weak, in fact.

 

 

That 'don't quote me on that' came from me, not David Crane.

 

As a matter of fact, that story doesn't need ANY work, as it was a David Crane interview in Retro Gamer, a UK magazine dedicated to old gaming. I suggest you try a newsagent in UK and buy it, it is a very good read indeed. Also, try the Atari XL article in the magazine (Well, you gotta find the relevant issues for yourself if you can manage that).

[frenchman]

That depends on what "it" is, doesn't it. i'd call it ignorance to accuse the fanboys of being wrong when there's no evidence available to the contrary, so since you're accusing me personally of ignorance here, rather than a nebulous "it" what specifically have i stated that can't be backed up?

 

 

Exactly, YOU cannot back it up that it CAN'T be done on the Atari XL, so you just answered your own nebulous 'it'.

[Godzilla]

This is the thread that never ends. It just goes on and on my friends. Somebody started it not knowing what it was, and it will go on and on just because, this is the thread that never ends...

 

I just wish there was more on-topic stuff. I love seeing game comparisons where the a8 beats the c64

[TMR]

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

Antic F can be done with two buffers offset by a pixel to pick up the difference, display buffer 1, display buffer 2 which is offset one pixel to the left, flip back and move the hardware scroll. i was pondering about doing a tech-tech that way when i last thought about demo code, but i wouldn't use it for a game personally.

[TMR]

As a matter of fact, that story doesn't need ANY work, as it was a David Crane interview in Retro Gamer, a UK magazine dedicated to old gaming. I suggest you try a newsagent in UK and buy it, it is a very good read indeed.

 

Thanks for the recommendation and all that but i've been a reader of Retro Gamer since the first issue back in the Live publishing days, contribute to their message board, have had my games reviewed previously, appeared under this user name in the "from the forum" section and asking reader questions... oh, and i write two pages an issue and have done since issue 51.

 

Ta for calling it a very good read, though. =-)

 

That depends on what "it" is, doesn't it. i'd call it ignorance to accuse the fanboys of being wrong when there's no evidence available to the contrary, so since you're accusing me personally of ignorance here, rather than a nebulous "it" what specifically have i stated that can't be backed up?

 

Exactly, YOU cannot back it up that it CAN'T be done on the Atari XL, so you just answered your own nebulous 'it'.

 

Sorry, but i can back up what i'm saying because it's based on some personal experience programming the hardware, the reference manuals on the web including Atari's own and discussion with other Atari programmers who are more seasoned than myself.

 

The quoted story is nice and all that but unless there is somebody taking David Crane's role in this situation to actually do what i've stated to not be possible it's not even vaguely relevant. Unless you want to take David's part, in which case please tell me specifically what i've said that you have working code to disprove rather than that nebulous "it".

[the maddestman]

This is the thread that never ends. It just goes on and on my friends. Somebody started it not knowing what it was, and it will go on and on just because, this is the thread that never ends...

 

I just wish there was more on-topic stuff. I love seeing game comparisons where the a8 beats the c64

I agree, me too, but I was just making the point that this thread seems to have done a skynet and become self aware and won't die, lol

 

I have found it very interesting, I've discovered games I would never have known about otherwise, and some of the more technical discussions have also been very interesting when they have been kept factual and verifiable.

 

Personally, I think it's sad that JM is no longer with us and didn't get to continue to develop his unique style of hardware which I'm a big fan of, no matter if it had an Atari or a Commodore sign attached to it.

[TMR]

I have found it very interesting, I've discovered games I would never have known about otherwise, and some of the more technical discussions have also been very interesting when they have been kept factual and verifiable.

 

This thread'll die eventually, it's just a matter of time - but another will rise to take it's place, they always do!! [Muahaha!! cough, akk, splutter] i've waved the idea of a forum hosted elsewhere that is dedicated to these sorts of discussions (and more, Amiga versus ST, SNES versus Megadrive, you get the idea) but nobody seems up for it.... shame really, because it sort of seems like a good idea since every 8-bit board or USENet group could greet similar threads with "you want to be reading this site" and those with more delicate sensibilities/blinkers on could stay away.

 

Personally, I think it's sad that JM is no longer with us and didn't get to continue to develop his unique style of hardware which I'm a big fan of, no matter if it had an Atari or a Commodore sign attached to it.

 

i agree absolutely (apart from i still don't like how the sprites were handled on the A8 or Amiga personally) and i like the A8, it's hardware from a programming point of view and quite a few games an' all, that's why i'm here. What irks me somewhat is that a lot of people here seem... well insecure for want of a more polite phrase (hey, i've been called "ignorant" this week, i think that gives me the okay to be less polite than usual!) which is presumably why the initial question in this thread was the specific and rather leading "which games are on both but better on the A8" rather than just a general "which games are on both".

[Gorf]

> DL vs Raster, it's the same thing, the C64 has scanline accurate timers so it is identical

 

?

show me code to display memory like Apple2 on c64.

 

atari code for ANTIC (no 6502 usage)

 

gr8 equ $f

blank equ $70

jvb equ $41

 

antic dta BLANK,BLANK,BLANK

:192 dta $40+gr8,a(apple_ekr+((#%*$400)+((#%$40)/8)*$80+(#/$40)*$28)

dta jvb,a(antic)

 

 

For some odd reason, C64 people think it's better to just POKE a register and set a graphics mode rather than have a coprocessor let you set various graphics/text modes on a scanline basis and thus save CPU time and memory. They have less CPU time to begin with and they still prefer not having that option.

 

 

It's that river in Egypt again.

[TMR]

It's that river in Egypt again.

 

What, just because xxl said it didn't use any 6502 power you mean? =-)