Atari v Commodore

[TMR]

hmm, but on the a8 its used to achive some kind of gfx effects ? what kinds?

 

i think that what happens is that there are two high res pixels horizontally to one colour clock and setting only one of them produces a different colour on the screen (which is apparently governed by other factors such as if the machine has a CTIA or GTIA, if it's PAL or NTSC and so forth)... any Atarian want to say if i'm talking rubbish or explain it better?

 

on the c64 it wasnt used to do this.

 

Apparently it comes about from the interaction between the luminance and color signals and the the clock generators on the VIC-II chip are kept apart so that the colour crystal is seperated from the video shift rate to reduce the problem. Or something. Aw stuff it, i'm not going to even pretend i understand! Check page four of this thread (my post, number 86) for a quote from Spectacular Rise And Fall Of Commodore where Bob Yannes explained it properly. =-)

[Crazyace]

Artifacting is an annoyance - and I think the main reason it was used on early games was due to the movement of code from the Apple II - where it was the method for hires colour graphics. It didn't really work on PAL at all - and the standard 160x192x4colour graphics modes were much more flexible.

( This is my opinion - I had a PAL machine, so I'm probally a bit biased... )

[Fröhn]

hmm, but on the a8 its used to achive some kind of gfx effects ? what kinds?

i think that what happens is that there are two high res pixels horizontally to one colour clock and setting only one of them produces a different colour on the screen (which is apparently governed by other factors such as if the machine has a CTIA or GTIA, if it's PAL or NTSC and so forth)... any Atarian want to say if i'm talking rubbish or explain it better?

Artefacting uses alternating hires pixels to simulate a color carrier. This only works if the pixel clock is twice as fast as the color carrier frequency (which is the case on NTSC A8, Apple II).

 

Usually you would set the two hires colors to black and white, so 000000 is black, 111111 is white, 010101 is color A and 101010 is color B (color A shifted 180° on the YIQ/YUV color wheel).

 

Artifacting is an annoyance - and I think the main reason it was used on early games was due to the movement of code from the Apple II - where it was the method for hires colour graphics. It didn't really work on PAL at all - and the standard 160x192x4colour graphics modes were much more flexible.

It would work on PAL aswell, but usually the machines were first designed for NTSC and then "ported" to PAL keeping similar CPU and pixel clocks which kinda destroyed the artefacting due to the PAL color carrier being at a too different frequency than the NTSC color carrier.

[Crazyace]

As I said, it didn't work on PAL - there was a very weak 'tinge' but no real colours. And the 8 bit wasn't designed to use artifacting for colour - it had the 160x 4 colour modes already.

I remember Threshold and Drol as games that relied on artifacting for colours ( Apple conversions ) - and the first choplifter. However Bandits was converted to A8 using 4 colour graphics ( plus some player graphics ) and looked far better.

[Crazyace]

also - with a S-VHS connection on the 800 it didn't work at all ( at least not on my TV )

[Fröhn]

also - with a S-VHS connection on the 800 it didn't work at all ( at least not on my TV )

Same for NTSC. Ofcourse it can only work on Composite because you use a luminance change to simulate a chrominance carrier.

[Allas]

Atari 2007 game entries :

 

 

Atari 2008 game entries :

 

 

 

It will be interesting to see a brief of C64 complete productions those years.

Edited December 6, 2008 by Allas

[Jetboot Jack]

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

 

The difference is one is an albeit cool "cheat" the other is a very powerful and flexible technique capable of doing everything from Nightlore to Populous and beyond. The C64 method is interesting, buy not really extensible.

 

It is an isometric 3D game though, the question wasn't about complexity but speed and playability

 

TMR - please don't obscure the issue with additional caveats - I am merely clarifying the difference between LN AB et al and true isometric rendering. It's not about complexity, but about the definition of the technique - and being clear. Amaurote uses a per pixel clipping - look at the complexity of the foreground graphics you can go behind, and the screen edges too - remember the world scrolls...

 

sTeVE

[Oswald]

allas,

 

You searched for:

Releases matching:

Released between: 1 January 2008 and 1 January 2009

 

Found: 779 matches.

 

 

779 screenshots would be a bit too much to include here

[Bryan]

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

 

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

 

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

 

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

Certainly the A8 can do some things that look as good or sometimes even better than the 64, but it takes a lot of effort to simulate bit depth which is why many things look better on the 64. Once games were being written on the 64 first and then ported to other systems, we were in serious trouble. Maybe if all Atari software had been generated by a team of demo coders, then it would have remained more competitive past 1983-4.

 

Programmers were willing to go to that much trouble for the huge installed base of the 2600 (which was only built to play games like Combat) but not for the A8. Personally, I'd love to re-do a bunch of A8 games just to see how well they'd turn out with some hard-core programming.

[emkay]

TMR - please don't obscure the issue with additional caveats - I am merely clarifying the difference between LN AB et al and true isometric rendering. It's not about complexity, but about the definition of the technique - and being clear. Amaurote uses a per pixel clipping - look at the complexity of the foreground graphics you can go behind, and the screen edges too - remember the world scrolls...

 

 

The "last Ninja" Iso 3D starts with the screendesign and shows a realtive distance between the Ninja and an enemy of 2 meters for example. And the Iso 3D ends where the 2m distance gets broken, because the fist of an 80cm long arm hits the ninja, because the collision was detected.... Or the player simply has to try until the enemy gets hit. Without any relation to the isometrical correctness.

 

Every shot in Amaurote moves in a wave and hits correctly from the degree of view.

[Bryan]

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

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

 

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

It happens on the 64 to a degree, it just produces color errors instead of areas of solid color like NTSC Atari's do.

 

Connect the 64 to a TV using a single composite video connection (no s-vid) and fill the screen with an alternating high-res black/white pattern. You'll see some coloring in the bright pixels because the pattern messes with the color decoder. Now switch to s-vid and it will go away.

 

NTSC Atari programmers used the fact that the pixel clock was the same as the color clock to generate areas of solid color by putting high-res on-off pixel sequences on the screen. This created a false 3.579MHz color-carrier and TV decoded it as color giving you 4 colors in high-res. This doesn't work well on PAL Atari's where the color clock is independent of the pixel clock.

 

Load up Atari800Win+ and switch to NTSC. Then load up one of the Ultimas and turn artifacting on and off. You'll see what a typical TV did with the image (sort of.. it looks better on a real TV). The problem was that the colors weren't reliable from one computer model to the next because every time you rework the video circuits, you introduce phase differences between the chroma and luma outputs. Your colorburst reference always comes from the chroma line, but with artifacting your color signal is being generated via luma, so minor phase differences mean different artifact colors.

 

Personally, I don't use artifacting. I'm not convinced the benefits outweigh the compatibility issues.

 

-Bry

Edited December 6, 2008 by Bryan

[Oswald]

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

 

The difference is one is an albeit cool "cheat" the other is a very powerful and flexible technique capable of doing everything from Nightlore to Populous and beyond. The C64 method is interesting, buy not really extensible.

 

I'm interested in the details (really!)

 

Amaurote uses a per pixel clipping - look at the complexity of the foreground graphics you can go behind, and the screen edges too - remember the world scrolls...

 

I'd say its just anding with a bitmask. the "scrolling" is well, not really a scrolling albeit cool "cheat"

[Oswald]

thx, I get the artefacting stuff. I saw it on the c64 aswell, but it was a subtle and unstable effect. more weird stuff: on some machines&CRTs when you type ++++ in a weird color combo you will get on the screen ><><><><

[Bryan]

thx, I get the artefacting stuff. I saw it on the c64 aswell, but it was a subtle and unstable effect. more weird stuff: on some machines&CRTs when you type ++++ in a weird color combo you will get on the screen ><><><><

Here's the example I was speaking of. This is something like what most NTSC users saw when booting up Ultima. The 2nd pic is what's actually being generated. When you use s-vid, luma can't leak into the color decoder.

Edited December 6, 2008 by Bryan

[Fröhn]

thx, I get the artefacting stuff. I saw it on the c64 aswell, but it was a subtle and unstable effect. more weird stuff: on some machines&CRTs when you type ++++ in a weird color combo you will get on the screen ><><><><

Well there is a simple analog filter which seperates chroma and luma signal. Since the old Atari/Commodore etc machines select luma and chroma on a per-pixel basis, the filter doesn't work too well with the resulting frequency spectrum. If for example the chroma carrier changes from one pixel to another, you will get stuff from the chroma filtered as luma aswell. And if you change luma from one pixel to another, it will produce a lot of higher frequencies too because it is an approximated jump in a curve which produces a lot of action in the frequency spectrum.

 

Concerning the "subtle" effect: I think that C64s have a low-pass filter on the luminance which reduces the effect.

Edited December 6, 2008 by Fröhn

[Crazyace]

I think that there's no technical reason that stops exactly the same isometric 3D routines being used on a C64.

It may have a slower framerate though.

One really nice thing is that if the width is limited to 192 hires pixels you could underly the bitmap with a 2nd bitmap made up from multiple sprites - and get an effective 192x200 3 colour graphics mode.

 

Of course update may be in the seconds per frame - but the Amstrad CPC versions of Knightlore etc looked quite nice.

 

Another thing would be to place a sprite underlay on any character ( Maybe using 2 sprites to get 42 vertical lines ) You can combine a visual masking to allow hires with multiple colours.

 

Oswald or someone more familiar with the C64 can comment if there are games that do this already.

 

( You could also do something similar on the 8 bit, but the PM res is only 160 - so it needs a little more care )

[Fröhn]

I think that there's no technical reason that stops exactly the same isometric 3D routines being used on a C64.

It may have a slower framerate though.

I calculated that the 256x192 hires bitmap mode on A8 means about 40% more CPU speed compared to C64.

 

I think for the frontmost stuff you could use sprites instead of CPU masking, for example the border graphics may be done that way. That might gain some CPU cycles.

[Oswald]

I think that there's no technical reason that stops exactly the same isometric 3D routines being used on a C64.

It may have a slower framerate though.

One really nice thing is that if the width is limited to 192 hires pixels you could underly the bitmap with a 2nd bitmap made up from multiple sprites - and get an effective 192x200 3 colour graphics mode.

 

Of course update may be in the seconds per frame - but the Amstrad CPC versions of Knightlore etc looked quite nice.

 

Another thing would be to place a sprite underlay on any character ( Maybe using 2 sprites to get 42 vertical lines ) You can combine a visual masking to allow hires with multiple colours.

 

Oswald or someone more familiar with the C64 can comment if there are games that do this already.

 

( You could also do something similar on the 8 bit, but the PM res is only 160 - so it needs a little more care )

 

no, there's no horsepower. only some demos has such pictures. such a spritelayer also kills also about 30% cpu power. using 4 colors in an iso game is a better idea imho

[Alison DeMeyer]

If you don't like the discussion, or it's contributors, don't participate...

 

I will just do so, and ignore posts about what can be compared and whatnot. cheers

 

Hmm, ignorance is bliss, welcome to Oswald's world.

[Alison DeMeyer]

I remember some examples. and for the record: it wasnt me starting it.

 

 

He's like a baby, 'Oh it wasn't me who started it, it's always others', 'My C64 has more colours than your computer, but I love the games on ZX Spectrum' GROW UP, OSWALD CHILD. You cannot even argue properly.

[emkay]

I calculated that the 256x192 hires bitmap mode on A8 means about 40% more CPU speed compared to C64.

 

I think for the frontmost stuff you could use sprites instead of CPU masking, for example the border graphics may be done that way. That might gain some CPU cycles.

 

 

40% have you calculated with the moon or else? It is clearly more.

 

a) DMA is not as time cosuming as you think with the atari, and player overlay cost nothing...

b) The CPU of the C64 is not as fast as you think... Particular when talking about Color RAM and Sprite re-using....

[Alison DeMeyer]

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

 

 

Commodore 64 sold better in the UK than Atari 8 bit computer, still majority of the games are not better because of more talent, etc blah.

[atariksi]

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

 

I have a problem with your argument..

 

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

 

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

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

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

 

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

 

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

C64 : 2 independant colours + 2 shared = 4

 

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

 

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

 

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

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

...

 

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

 

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

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

...

Well, even if you count it in a restricted way, at least that feature exists. After all we are (at least I am) comparing hardware features.

 

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

 

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

 

Well if you want to compare the two sprites of both systems you do have to do interrupts else you are just taking some specific case which requires square area of sprite coverage. It becomes subjective if you claim horizontal resolution is better than vertical. Also, now if vertical useage becomes significant in some application, it's the C64 that requires more CPU power to replicate vertically.

 

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

 

It's not a strawman argument. Strawman argument is exemplified here:

 

Oswald,

 

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

 

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

 

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

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

 

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

...

 

It does not connect with anything I ever stated. He concocts something and tries to makes people think he's refuted me. Worse, he first agrees with me a few minutes earlier.

 

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

 

We went through that already though. PMBase and scanline DMA enable/disable are related to Y-positioning so it's definitely not 1D. Landscape uses the zooming feature of Z-axis.

 

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

 

If you needed to change shapes, color, and position on the same scanline, you're better off using a VBlanking method -- I believe Joust does that to show 8 sprite birds on one scanline. But as I stated, I did give the C64 the edge on sprites overall, but you are restricting Atari sprites too much. There are cases where Atari sprites work better because of their length. And if you really want to get technical about sprites being 1D, you can easily disprove that by using double line resolution and using VDELAY and PMBase together just to show there's hardware support for y-positioning.

[atariksi]

Yeah, even the standard 1.19Mhz timer on the PC cannot be used in Windows 2000/XP/Vista thanks to the HLI (hardware-limited interface, a.k.a API). But even if you have a high resolution timer, the caching, power management, dynamic frequency changes, non-standard hardware leading to inconsistently timed API calls, etc. will throw off timing unless you program for the worst case in which case you are not going to optimally use your 2+Ghz processor nor your hardware. That's one thing great about standardized machines like Amiga, Atari, C64, etc. is that you can directly access the hardware and know it'll be the same on the other machine. Earlier PCs were more exact than modern PCs.

 

Current consoles sometimes are programmed to the bare metal because it isn't customary to upgrade consoles apart from more space for savegames and whatnot. Early PCs used to have that in common with consoles but no longer. The model then was to hug the bare metal with display kernals and whatnot. Games would be developed on and look good on the primary platform then look half-hearted elsewhere.

 

These days sheer brute force is used to present (mostly) consistent APIs regardless of underlying hardware. I too romanticize and am nostalgic about machines where you can know everything about what ever memory location and every chip does. But the current way is much more practical. I can run atari800 on Windows, OS X , Linux, handheld consoles, phones and as long as a certain minimum of graphics capability and cpu cycles are available, the same reasonable approximation of my old computer works the same on all of them. Yeah it leads to bloat. And it is an obscene waste of computing resources compared to the spare but efficient 8-bits we grew up on. But this way allows for a very broad ecosystem of development and the inability to host that ecosystem is why nobody but Apple is still around....and they build machines out of PC parts too these days.

 

It was good that programs were targetted directly to hardware I/O. Apple missed out on those because of lack of hardware or using API-based standards. That's where PCs have taken a hit in creativity-- by limited to API-based games and applications rather than standardizing on hardware I/O ports and letting people be more creative. I mean you could still protect some ports like disk I/O, but in general hardware should be standardized on I/O ports for maximum efficiency. And of course processors could have been made to be more exact.... more later.