Atari v Commodore

[atariksi]

Thanks for clarifying. Just saying "It has advantages" can be interpreted in different ways.

 

Let me clarify the sprite thing too.

 

Bit-planes means you have a graphics engine in which layers of DMA can be added or removed to control the number of colors available and the amount of RAM and bus cycles used. Adding planes usually means you can read further into a color register table. This means the graphics engine has modes. Each mode will require a different use of memory, but usually in an orthogonal way.

 

What GTIA has is a feature more than a mode. When 3rd color overlapping is enabled, GTIA still generates Players the way it always does with the same amount of data. The only difference is that an OR gate is enabled when two players exist in the same pixel. There is no extra color register and no additional DMA, just a modification to the way color is determined.

 

This is why it really isn't like bit-planes, but is rather a thoughtful feature.

 

-Bry

 

Well if you have dual playfield enabled, you essentially have TWO bitplanes working simultaneously without generating the third color but when you enable normal two bitplanes w/o dual playfield, you you get the third color. Memory/DMA is the same. As far as using a color register or doing an OR, that's also not a requirement for bitplanes since even Half-bright and HAM use logic rather than color registers.

[Bryan]

>If just only one would write a full POKEY supporting tracker. But this time, SID clearly wins in most cases...

 

I am not too much into making musical notes on Atari nor C64. Supposedly, the envelopes simulation would eat up too much Atari CPU time.

 

I think what he means is he wants a tracker that supports advanced Pokey techniques better.

[Bryan]

Well if you have dual playfield enabled, you essentially have TWO bitplanes working simultaneously without generating the third color but when you enable normal two bitplanes w/o dual playfield, you you get the third color. Memory/DMA is the same. As far as using a color register or doing an OR, that's also not a requirement for bitplanes since even Half-bright and HAM use logic rather than color registers.

 

What do you mean by dual-playfield?

[atariksi]

Well if you have dual playfield enabled, you essentially have TWO bitplanes working simultaneously without generating the third color but when you enable normal two bitplanes w/o dual playfield, you you get the third color. Memory/DMA is the same. As far as using a color register or doing an OR, that's also not a requirement for bitplanes since even Half-bright and HAM use logic rather than color registers.

 

What do you mean by dual-playfield?

 

Amiga has a way to set dual-playfield mode so if dual playfield was made up of one bitplane each-- you have two bitplanes in which the third color won't be generated but both bitplane ptrs are being used. If you set BPLCON0 to two, the third color will be generated.

[Crazyace]

The Exel 100 was really really cool (i have one) , unfortunaly there is not lot of game on it and the few that exists didn't really exploit the machine but are already quite nice (look Match point for instance , this tennis game was first create on EXEL 100 then ported on all other plateform)

 

 

It also featured speech in game thank to the integrated speech synthetiser .

 

Ok - I looked at all of the docs on http://dcexel.free.fr/

 

It reminds me a bit of the BBC machine - the graphics are really quite high res ( 320x250x8 colours/pixel ) but there's only 8 colours - and the video memory is also the system memory. I think I prefer the look of the Atari 8 bit ( or even the C64 games ) to the ones shown - The tennis is the best looking game though.

[Crazyace]

The colour 'or' mode for the players on the Atari is a blessing and a curse - I curse it for limiting the artistic choice of the 3 possible colours, but the way that it's implementation allows the PRIOR combination of the player colours with the PF ones as well is pretty cool.

[Bryan]

Amiga has a way to set dual-playfield mode so if dual playfield was made up of one bitplane each-- you have two bitplanes in which the third color won't be generated but both bitplane ptrs are being used. If you set BPLCON0 to two, the third color will be generated.

 

Ah, you can do the same thing with a custom palette (set the 3rd color to same as one of the other two). Anyway, I would call these settings on the Amiga features as well since they're unusual enhancements to the bit-plane concept.

[Crazyace]

Colours on the C64 will never exceed the count of 16. Only if they find a hidden register which activates the forgotten 16M colours palette. Even a 4GHz CPU will not help out of the misery. On the A8 -YES, IT CAN- produce endless Players and missiles. Ok. OK. With a 4GHz CPU you can switch VIC off and put the graphics via software on the screen..... but it will never exceed 16 colours. On the A8 you would gain something like a 256 colour mode with 168x240 pixel.... without interlace.

 

I think even with a 4GHz cpu you would still drive Antic/GTIA at 1.79MHz - so there's only 114 accesses per line ( roughtly ) - so I guess you could get 80x240 with 256 colours, and the refresh may still screw things up

[atariksi]

Amiga has a way to set dual-playfield mode so if dual playfield was made up of one bitplane each-- you have two bitplanes in which the third color won't be generated but both bitplane ptrs are being used. If you set BPLCON0 to two, the third color will be generated.

 

Ah, you can do the same thing with a custom palette (set the 3rd color to same as one of the other two). Anyway, I would call these settings on the Amiga features as well since they're unusual enhancements to the bit-plane concept.

 

Not really, you can't customize the palette and get the same effect. The two bitplanes have a priority so if there's a "0", you will see the other bitplane graphics otherwise it will be the color from the palette (just like two monochrome sprites on Atari). You can move/scroll each of the monochrome bitmaps independently just like two monochrome sprites. Once you enable the two bitplane mode (not dual playfield), you have the third color just like you enable bit 5 of 53275.

 

They call them bitplanes in Amiga books.

[potatohead]

I've heard others refer to that as bitplanes as well. Strong case either way, as they are little tiny bitplanes

 

So, does the C64 have anything like this with it's sprites? That's the real question, with the rest being semantics.

 

On A8, it's possible to use this stuff for colors, or to occlude things, or to show things, based on a sprite. C64?

[Bryan]

Not really, you can't customize the palette and get the same effect. The two bitplanes have a priority so if there's a "0", you will see the other bitplane graphics otherwise it will be the color from the palette (just like two monochrome sprites on Atari). You can move/scroll each of the monochrome bitmaps independently just like two monochrome sprites. Once you enable the two bitplane mode (not dual playfield), you have the third color just like you enable bit 5 of 53275.

I don't see why you couldn't. If you have no planes [0,0] then you get background. If you have one bitplane [0,1] then you have color 1. If you have the other bitplane [1,0] then you have color 2. When you have both [1,1] then you can set either color 1 or color 2 to determine which plane appears to block the other.

 

They call them bitplanes in Amiga books.

 

That's because they are. It's a stretch, however, to say that anything that resembles a particular feature of the Amiga's bit-plane implementation must therefore be a bit-plane.

 

Anyway, we all understand how the PM Graphics work so this is all trivial semantics.

[Barnacle boy]

...

Again, we're not talking about all of it and just the smoothness, please stop trying to change the subject. And on the C64 the colours are retained so it's hugely useful and would be on the A8 if the same were true....

You keep using straw-man arguments and chewbacca defense (which I am showing you how not just accusing you). You directly stated colors are retained and now you are stating it can scroll. Two different things.

 

TMR is clearly stating that on the c64 the colours are retained when scrolling in hires pixel increments (or half colour clocks as you might call them). Considering you guys have been arguing off and on about that very issue over the last several pages, it's incredibly disingenuous for you to now try to obfuscate the matter by pretending to misinterpret what he is saying as two separate unrelated points. And the irony is that you keep accusing others of "the Chewbacca Defence".

 

 

...straw-man arguments and chewbacca defense (which I am showing you how...

If we isolate this sequence of words, a small jewel of pure shining truth emerges from your post.

[Bryan]

So, does the C64 have anything like this with it's sprites? That's the real question, with the rest being semantics.

Well, if we use the argument that something is a bit-plane even if the elements don't combine to make additional color, then you put all the 64 sprites on top of each other and call them a bunch of bit-planes. The truth is that sprites and players are graphic elements. They are independent or semi-independent objects designed to augment the playfield which is also a graphic element. Bit-planes are sub-element objects. They are usually locked in position relative to each other and all contribute to a single image. They are a way of making the system more flexible, although they can sometimes be used to create the effect of separate objects.

[atariksi]

Not really, you can't customize the palette and get the same effect. The two bitplanes have a priority so if there's a "0", you will see the other bitplane graphics otherwise it will be the color from the palette (just like two monochrome sprites on Atari). You can move/scroll each of the monochrome bitmaps independently just like two monochrome sprites. Once you enable the two bitplane mode (not dual playfield), you have the third color just like you enable bit 5 of 53275.

I don't see why you couldn't. If you have no planes [0,0] then you get background. If you have one bitplane [0,1] then you have color 1. If you have the other bitplane [1,0] then you have color 2. When you have both [1,1] then you can set either color 1 or color 2 to determine which plane appears to block the other.

 

They call them bitplanes in Amiga books.

 

That's because they are. It's a stretch, however, to say that anything that resembles a particular feature of the Amiga's bit-plane implementation must therefore be a bit-plane.

 

Anyway, we all understand how the PM Graphics work so this is all trivial semantics.

 

They wouldn't need the DPF (bit 10) of BPLCON0 if you could just get away with just color palette modifications. But I want to complete my initial point first since whether it can be done with palette tricks is irrelevant to the fact that Amiga can show two active monochrome bitmaps and two bitmaps that give more colors EXACTLY like Atari can do with two monochrome sprites. So essence being the same, rose with a different would smell just as sweet.

[atariksi]

...

Again, we're not talking about all of it and just the smoothness, please stop trying to change the subject. And on the C64 the colours are retained so it's hugely useful and would be on the A8 if the same were true....

You keep using straw-man arguments and chewbacca defense (which I am showing you how not just accusing you). You directly stated colors are retained and now you are stating it can scroll. Two different things.

 

TMR is clearly stating that on the c64 the colours are retained when scrolling in hires pixel increments (or half colour clocks as you might call them). Considering you guys have been arguing off and on about that very issue over the last several pages, it's incredibly disingenuous for you to now try to obfuscate the matter by pretending to misinterpret what he is saying as two separate unrelated points. And the irony is that you keep accusing others of "the Chewbacca Defence".

 

...

See you are also accusing me of the samething without getting all your facts straight. Here in msg #3167 TMR agrees there is distortion for hires mode:

 

"A lone high res pixels will distort a bit (less than on the A8, however) if moved half a clock but lone multicolour pixels won't be affected..."

 

He also claimed I was stating you can't scroll half a color clock which is different from stating color is not retained when you do scroll half a color clock. He also accused me of changing my mind, changing the subject, dragging in overlay, etc. etc. without any evidence. In fact, he confused the issues by misunderstanding me. YOU CAN SCROLL HALF A COLOR CLOCK -- I gave the double buffer algorithm previously to show how Atari can do it.

 

>If we isolate this sequence of words, a small jewel of pure shining truth emerges from your post.

 

First, go understand TMR's replies and my replies to him before you represent him. "Truth" in your opinion. I proved his confusing style of arguing-- chewbacca defense and straw-man arguments. Unless you want to prove your case, don't just give your opinion and label it the "truth".

[Gorf]

I've heard others refer to that as bitplanes as well. Strong case either way, as they are little tiny bitplanes

 

So, does the C64 have anything like this with it's sprites? That's the real question, with the rest being semantics.

 

On A8, it's possible to use this stuff for colors, or to occlude things, or to show things, based on a sprite. C64?

 

 

Both systems have the ups and downs but I still find the A8 gfx much more flexible as its hardware allows

for things the C64 HAS to do in software such as the multi mode screens ans such. The C64, considering

its natural limitation is impressive nonetheless. However when I look at both librarys, I have to go with

the Atari. I owned a VIC-20 and a C-64 too. My A8 always got the most attention.

[potatohead]

Well, if we use the argument that something is a bit-plane even if the elements don't combine to make additional color, then you put all the 64 sprites on top of each other and call them a bunch of bit-planes. The truth is that sprites and players are graphic elements. They are independent or semi-independent objects designed to augment the playfield which is also a graphic element. Bit-planes are sub-element objects. They are usually locked in position relative to each other and all contribute to a single image. They are a way of making the system more flexible, although they can sometimes be used to create the effect of separate objects.

 

I'll take that as a "Probably not"

 

I think it's completely fair to call sprites "a bitplane". They are composed of bits, and they do exist as planar things. The root of the discussion comes down to operators between the bitplanes. Edit: It's also fair to just say "sprites". Seeing Gorf's post below, I'm inclined to agree. All semantics however.

 

What Atari has is operators between the sprites, priority settings, and collision bits. Where the sprites and non-sprite graphics overlay, there is active, hardware functionality that the user gets to make some choices on, or act upon, depending.

 

Does the C64 do this?

 

And if so, is it a user controlled thing, or hardwired, such as higher number sprite appears in front no matter what?

 

Are there collision bits set upon two or more elements in the same space?

 

Yeah Gorf, I'm there too. The Atari systems really do have lots of little features. That's what I'm trying to get at. Either the C64 sprites are passive, or not, and either they offer collision or not, and they operate on one another and the non-sprite graphics or not.

 

So, let's just cut the word smithing and sort that out. Then the "what can be done with software" discussion really happens on top of that.

Edited April 7, 2009 by potatohead

[Gorf]

So, does the C64 have anything like this with it's sprites? That's the real question, with the rest being semantics.

Well, if we use the argument that something is a bit-plane even if the elements don't combine to make additional color, then you put all the 64 sprites on top of each other and call them a bunch of bit-planes. The truth is that sprites and players are graphic elements. They are independent or semi-independent objects designed to augment the playfield which is also a graphic element. Bit-planes are sub-element objects. They are usually locked in position relative to each other and all contribute to a single image. They are a way of making the system more flexible, although they can sometimes be used to create the effect of separate objects.

 

 

 

I feel sprites and pm's are not bitplanes. Now if you look at the Jaguar's OPL, you could probably

more accurately call that a bit plane set up than a bunch of sprites. Then again, the OPL of the Jag

is intended for both foreground and backdrop gfx.

 

When I think of plane I definitely think as in backdrops and not as foregrounds. Also the bit plane

nature of the Atari ST GFX (which I hate btw) for instance, work hand in hand to determine color.

Sprites and PM's are not intended for this, even if it may be an after effect of the hardware or tricky

coding.

 

I still do not recall seeing a C64 sprite cover more than a 24x21 pixel area...hardly a screen bitplane

by any definition.

[potatohead]

...and that's semantics really.

 

Better to shift focus from "bitplane" and just talk about what the entities actually do.

[atariksi]

...and that's semantics really.

 

Better to shift focus from "bitplane" and just talk about what the entities actually do.

 

Right, better to talk about their essence-- that they can behave as independent monochrome bitmaps or when multiple of them are treated as single units (if hardware allows) they form multicolor bitmaps. Atari allows for sprite #0 and sprite #1 to be treated as a single multicolor sprite with four combinations (0-0 gives background/see thru, 0-1 gives color P0, 1-0 gives color P1, and 1-1 gives color P0 OR P1). Same for sprite #2 and sprite #3. Corresponding missiles behave the same as their players unless formed into a fifth player (using bit 4 of 53275). Now, this combining of sprite bitplanes is a hardware feature since if you put P0 over P2 or p1 or P3, you won't get that single unit treatment.

 

This is exactly how Amiga does it's dual playfield bitplanes vs. single unit bitmap.

[potatohead]

So then, does the C64 do this?

 

What does it do, when sprites share pixels with either other sprites, or the non-sprite graphics?

[Rybags]

There's always a Priority decision. Without looking it up (so might be a bit wrong)...

 

Sprites always have a priority order among them, 0 on top through to 7 at back.

 

Sprites to foreground have a sprite or foreground choice per sprite, no tricks, ORing or other combining allowed.

 

IIRC, multicolour pixel type "01" is treated the same as background "00" ie - it's always overlapped by sprites regardless of priority settings.

[atariksi]

So then, does the C64 do this?

 

What does it do, when sprites share pixels with either other sprites, or the non-sprite graphics?

 

C64 sprites in monochrome mode are like Atari sprites but at 24*21-- they have a foreground color and a see thru color. In multicolor mode, they are chunky at half the resolution (12*21) so you get 2 bits defining the four combinations.

 

That's one advantage of bitplanes vs chunky is that you don't lose resolution when increasing number of colors (but you use up a bitplane channel or sprite channel in Atari's case) so you see on Amiga you can set 1..6 bitplanes in upto 320*400 and 1..4 bitplanes in 640*400.

[potatohead]

http://www.c64-wiki.com/index.php/Sprite

 

Sprite 0 is always on top, sprite 7 is at the back.

 

Color 0 reveals either another sprite, or the non-sprite graphics. (transparent)

 

For the two intermediate color combinations, (color 1 and 2) it appears there are two color registers that are shared between all sprites.

 

Each sprite gets it's own color definition for color 3.

 

Each sprite can either be 2 color (320 pixel resolution), or 4 color (160 pixel resolution).

 

Each sprite can be either behind, or in front of non-sprite graphics data.

 

Each sprite has two collision bits. One for "another sprite" and another for non-sprite visible pixels.

 

An interrupt can be triggered upon a collision sprite to sprite, or sprite to background.

 

Each sprite may be double sized horizontally and / or vertically.

 

Sprites are positioned with 9 bits of data.

 

Anything else in the hardware?

 

I didn't see sprites operating on one another, and that's confirmed by the post above. Also, I didn't know the 01 color is always overlapped. Interesting... Probably some tricks to be had there.

Edited April 7, 2009 by potatohead

[atariksi]

There's always a Priority decision. Without looking it up (so might be a bit wrong)...

 

Sprites always have a priority order among them, 0 on top through to 7 at back.

 

Sprites to foreground have a sprite or foreground choice per sprite, no tricks, ORing or other combining allowed.

 

IIRC, multicolour pixel type "01" is treated the same as background "00" ie - it's always overlapped by sprites regardless of priority settings.

 

Amiga sprites also have lack of priority settings and not as many bits for collision detection but I guess they thought the faster processor (7.16Mhz) would make up for these things.