Atari v Commodore

[emkay]

Running 3D is nice - but games have already shown off some of the extra 'power' of the A8 ... look at Wayout , or Mercenary.

The Numen engine is cool for a demo - but the Framerate is really low for a 'doom' game.. Although it would be quite cool for a Dungeon master style game.

 

The Numen Engine is all but usable for a game. Even the "fast" Rescue on Fractalus is not optimized for Speed. Most games on the A8 that uses some 3D render, do this by acting on the VBI. Just run RoF in 50Hz and 60Hz. You see it running slower at 50Hz, where more cycles been free for the calculations.

What is needed for a fast action, is to exchange full mathematics with simpler game logics where needed.

Flickering as in Space Harrier would not be necessary in a "Wolf 3D" like game.

Example for a door: You draw the upper part, so you know the Y-axis. So you can tell GTIA to set a Player to the needed x position, with the needed colour and width and with overlay colours (gives 2 extra colours for the door). At the Bottom of the door, you simply send GTIA to put the Player to pos. 0 ... together with 2 players you can colourize 2 doors in the near range or 4 doors in the far range. Which is logically also correct. Because if you stand in front of a door, you only see one. And if you stand far away, you may see hundreds of doors

 

Possibly no DLI is needed for the Gamescene. For the Scoreboard the DMA of the PM Graphics could be switched on, but only for the heidth of the Head and the weapon. The scoreboard itself could be build by the small ranged hires mode with a PM lineup

 

And so on ...

Edited November 30, 2008 by emkay

[Bryan]

Same old oswald, losing an argument then curses

 

This is a worthless argument. In fact, it stopped making any sense to me pages ago. Why anyone would get so personally invested in it is beyond me.

 

This is what I think I've learned:

 

The Commotari has half-DMA cycles but not when 2 players exceed the resolution bitmap. That's when the 64 badline is mostly 500Khz of sprite SID filter cycles. Pokey sprites have more stack loading and can exclusive OR the CPU. So, if your game needs twice the foreground waveforms, the Cataridore will display character cell priorities.

 

Does this stuff happen in C64 forums?

 

-Bry

Edited November 30, 2008 by Bryan

[atarian63]

Same old oswald, losing an argument then curses

 

This is a worthless argument. In fact, it stopped making any sense to me pages ago. Why anyone would get so personally invested in it is beyond me.

 

This is what I think I've learned:

 

The Commotari has half-DMA cycles but not when 2 players exceed the resolution bitmap. That's when the 64 badline is mostly 500Khz of sprite SID filter cycles. Pokey sprites have more stack loading and can exclusive OR the CPU. So, if your game needs twice the foreground waveforms, the Cataridore will display character cell priorities.

 

Does this stuff happen in C64 forums?

 

-Bry

I don't know your age but you probably had to grow up back in that time to get it. It was pretty heated.

[Bryan]

I don't know your age but you probably had to grow up back in that time to get it. It was pretty heated.

 

I'm 38. I was 11 when I got my first 800. I remember it was quite heated, and most of the people arguing were just pirates who didn't really know the internals anyway.

 

What I don't understand is why anyone loses sleep over it today. If someone thinks the TRS-80 Model I beats the Amiga, then I will pat them on the head and leave them be.

 

-Bry

[ApolloBoy]

What I don't understand is why anyone loses sleep over it today. If someone thinks the TRS-80 Model I beats the Amiga, then I will pat them on the head and leave them be.

 

Precisely. I never grew up with either the A8 or C64, so I can enjoy both without prejudice. Why the hell would you still have a thing against either computer in this day and age?

[atarian63]

I don't know your age but you probably had to grow up back in that time to get it. It was pretty heated.

 

I'm 38. I was 11 when I got my first 800. I remember it was quite heated, and most of the people arguing were just pirates who didn't really know the internals anyway.

 

What I don't understand is why anyone loses sleep over it today. If someone thinks the TRS-80 Model I beats the Amiga, then I will pat them on the head and leave them be.

 

-Bry

Gotcha, Well, I am 45 and at the time we all us atari guys hated the 64, guess it never goes away, kinda like OSU vs Michigan.

For me I would never own a C64. It's kinda like the "Dark Side", powerful in it's own way but still wrong.

Edited November 30, 2008 by atarian63

[+Sauron]

Gotcha, Well, I am 45 and at the time we all us atari guys hated the 64, guess it never goes away, kinda like OSU vs Michigan.

For me I would never own a C64. It's kinda like the "Dark Side", powerful in it's own way but still wrong.

 

I don't get this mentality at all. I've been a hardcore Atari nut since the 2600, and my first computer was a 130XE, but I still love the Commodore 64, even though I never owned one. In fact, that's what I originally wanted thanks to a friend of mine having one. I think both systems were powerful enough to get the respect of most computer owners back in the day, and cheap enough to introduce many of us to computers who otherwise may not have been able to afford one.

 

Don't get me wrong...I participated in many a heated debate over the merits of the A8 over the C64. Even though the C64 was what I originally wanted, the A8 is essentially what I grew up with, and even still to this day prefer it. I just don't see the need for these arguments to get so heated well over 20 years past their heyday.

[atarian63]

Gotcha, Well, I am 45 and at the time we all us atari guys hated the 64, guess it never goes away, kinda like OSU vs Michigan.

For me I would never own a C64. It's kinda like the "Dark Side", powerful in it's own way but still wrong.

 

I don't get this mentality at all. I've been a hardcore Atari nut since the 2600, and my first computer was a 130XE, but I still love the Commodore 64, even though I never owned one. In fact, that's what I originally wanted thanks to a friend of mine having one. I think both systems were powerful enough to get the respect of most computer owners back in the day, and cheap enough to introduce many of us to computers who otherwise may not have been able to afford one.

 

Don't get me wrong...I participated in many a heated debate over the merits of the A8 over the C64. Even though the C64 was what I originally wanted, the A8 is essentially what I grew up with, and even still to this day prefer it. I just don't see the need for these arguments to get so heated well over 20 years past their heyday.

Probably due to age, nothing personal. I was a dealer and a VP of the local user group at a time when I was 20-24, you would have had to have been there in that time period I guess.We even raised money by smashing C64's at the meeting, you know, so much a hit. I am sure there is alot less brand loyalty in the younger generation though I have seen some in the modern console area here

( those arguments I just don't get). It's just one of those you had to be there things as evidenced by the heated exchanges here. Maybe a better Analogy would be a Chevy vs dodge vs ford argument.

Each has a very loyal following and those that are very loyal wouldn't drive the other brand if you gave them one for free. Best answer I have for you.

[atariksi]

C64

 

Atari 800

 

It may be small differences, but for me Bruce Lee is the lower image, not the upper one, so I find it "better" on the Atari...

Btw, good example of the sprite system:

 

A8: uses all players and all missiles for those 3 sprites. Cannot use 3rd OR color due to one color being black so bruce and the fat guy have to use 2 colors only.

 

C64: sprite system is heavily underused. 3 of the 8 sprites are used, in those 3 sprites not even 3 colors or full size are used.

 

But Atari could have used the 3rd OR color if they had slightly adjusted the luminance of the knight to say 2 or 4 instead of pitch black knight. Perhaps, they were porting from some other version or planning for another platform.

 

Because you keep repeating the same mistake. Atari only has 2 multicolor sprites (8-10 X 256).

 

This is more a matter of semantics than anything; since what you're describing as a multicolour sprite istill isn't a single entity and has two X registers for the seperate parts, it's still two sprites as far as the hardware is concerned.

...

 

That's your speculation. Ever heard of bitplanes vs. chunky mode. On amiga the bitplanes each have their separate addresses so you can have two X registers and still have one multicolor sprite. There's bit 5 of register 53275 which specifically states "Enable Mulitiple Color Players".

 

>No, you've got to show that, in order to match the totally arbitary selection of colours the C64 has, you can do the same thing; otherwise the claim about three unique colours per multicolour sprite has a huge "but".

 

Even if you give the ORed color less than 1.0 color value but greater than 0.0 (obviously), you still get more colors on two Atari multicolor sprites. Also, the fact that the two planes of the multicolor sprites have their own x-register gives you the option of slightly shifting them to increase their width.

 

>At which point block copying kicks in yes? So in these worst cases, how much faster than my suggestion does your method go if you include the bounds checking to see when things need copying?

 

You don't need to do the bounds check in the sprite renderer as that would be running at 16*60 Hz (for up to 32 multicolor sprites as in the current implementation). You can check the bounds when setting the virtualY position. Also copying does not necessarily have to be done in a zone conflict. You have several other options including (1) interleave it with VBLank so it renders at 30Hz [on NTSC], (2) Not to render it (so it disappears in that zone), (3) Use Grafn to fix DMAd data for 2nd sprite. Even if you copy data, it'll be done < 1/8 of the time [avg] as when doing normal Y positioning.

 

>That's the thing... we weren't just moving things in Y, it was about matching facilities; yes, your method works ten times faster than mine but it apparently doesn't replicate the other features.

 

I don't think your original post asked for animating it, but you can still use a similar solution-- either increase memory useage (if available) or decrease the PMBase table size so copying occurrence would increase but give you more memory.

[Artlover]

Gotcha, Well, I am 45 and at the time we all us atari guys hated the 64, guess it never goes away, kinda like OSU vs Michigan.

For me I would never own a C64. It's kinda like the "Dark Side", powerful in it's own way but still wrong.

 

I don't get this mentality at all. I've been a hardcore Atari nut since the 2600, and my first computer was a 130XE, but I still love the Commodore 64, even though I never owned one. In fact, that's what I originally wanted thanks to a friend of mine having one. I think both systems were powerful enough to get the respect of most computer owners back in the day, and cheap enough to introduce many of us to computers who otherwise may not have been able to afford one.

 

Don't get me wrong...I participated in many a heated debate over the merits of the A8 over the C64. Even though the C64 was what I originally wanted, the A8 is essentially what I grew up with, and even still to this day prefer it. I just don't see the need for these arguments to get so heated well over 20 years past their heyday.

I know, right.

 

As some one who had (has) both, I never did and still don't get it. They BOTH have their strong points and they BOTH have their weaknesses. NEITHER is overall better then the other. As I have pointed out many times, all the arguments are always the same; raw numbers taken out of context of the machine on a whole that mean nothing in practical application. Since the value of a computer is what you can actually accomplish with it, anything that doesn't specificly pertain to that outcome is irrelevant as a factor. 25 years laters, and people still fail to grasp that.

[emkay]

http://www.speedshare.org/download.php?id=8BCE416211

 

I don´t understand much of your technical notes, but that tune sounds great. Just copied it to a Floppy Disk to make sure it really is Pokey-Sound. It is. :-)

 

Ofcourse it is

 

Believe me, it also can be much better.

[Crazyace]

C64

 

Atari 800

 

It may be small differences, but for me Bruce Lee is the lower image, not the upper one, so I find it "better" on the Atari...

Btw, good example of the sprite system:

 

A8: uses all players and all missiles for those 3 sprites. Cannot use 3rd OR color due to one color being black so bruce and the fat guy have to use 2 colors only.

 

C64: sprite system is heavily underused. 3 of the 8 sprites are used, in those 3 sprites not even 3 colors or full size are used.

 

But Atari could have used the 3rd OR color if they had slightly adjusted the luminance of the knight to say 2 or 4 instead of pitch black knight. Perhaps, they were porting from some other version or planning for another platform.

 

I dont think that would have been possible for Bruce Lee - as the sprites were up to 16 pixels wide during kicks - if the players were multicolour then it might have shown more. Actually I think , with a little effort, that the ninja could have been improved - by changing the widths of the 4 missiles that made him.

 

Because you keep repeating the same mistake. Atari only has 2 multicolor sprites (8-10 X 256).

 

This is more a matter of semantics than anything; since what you're describing as a multicolour sprite istill isn't a single entity and has two X registers for the seperate parts, it's still two sprites as far as the hardware is concerned.

...

 

That's your speculation. Ever heard of bitplanes vs. chunky mode. On amiga the bitplanes each have their separate addresses so you can have two X registers and still have one multicolor sprite. There's bit 5 of register 53275 which specifically states "Enable Mulitiple Color Players".

 

>No, you've got to show that, in order to match the totally arbitary selection of colours the C64 has, you can do the same thing; otherwise the claim about three unique colours per multicolour sprite has a huge "but".

 

Even if you give the ORed color less than 1.0 color value but greater than 0.0 (obviously), you still get more colors on two Atari multicolor sprites. Also, the fact that the two planes of the multicolor sprites have their own x-register gives you the option of slightly shifting them to increase their width.

 

>At which point block copying kicks in yes? So in these worst cases, how much faster than my suggestion does your method go if you include the bounds checking to see when things need copying?

 

You don't need to do the bounds check in the sprite renderer as that would be running at 16*60 Hz (for up to 32 multicolor sprites as in the current implementation). You can check the bounds when setting the virtualY position. Also copying does not necessarily have to be done in a zone conflict. You have several other options including (1) interleave it with VBLank so it renders at 30Hz [on NTSC], (2) Not to render it (so it disappears in that zone), (3) Use Grafn to fix DMAd data for 2nd sprite. Even if you copy data, it'll be done < 1/8 of the time [avg] as when doing normal Y positioning.

 

>That's the thing... we weren't just moving things in Y, it was about matching facilities; yes, your method works ten times faster than mine but it apparently doesn't replicate the other features.

 

I don't think your original post asked for animating it, but you can still use a similar solution-- either increase memory useage (if available) or decrease the PMBase table size so copying occurrence would increase but give you more memory.

 

I'm still hazy on how cycling PMBASE helps to move multiple sprites - if I'm using paired sprites I have at least 2 objects moving independantly each frame. Cycling PMBASE only helps if they move in sync - which isn't a common game situation.

[Fröhn]

But Atari could have used the 3rd OR color if they had slightly adjusted the luminance of the knight to say 2 or 4 instead of pitch black knight. Perhaps, they were porting from some other version or planning for another platform.

I dont think that would have been possible for Bruce Lee - as the sprites were up to 16 pixels wide during kicks - if the players were multicolour then it might have shown more.

Also, I think they wanted a black ninja and not a dark grey ninja.

 

I'm still hazy on how cycling PMBASE helps to move multiple sprites - if I'm using paired sprites I have at least 2 objects moving independantly each frame. Cycling PMBASE only helps if they move in sync - which isn't a common game situation.

It helps for games where only one sprite moves in Y:

 

Mirax Force

[Crazyace]

Ah - makes sense ( also there's no animation ) - still seems quite expensive - I think that main sprite is 24 pixels high - so you need 24 copies for 1 line vertical movement - PMBASE has to be 2K aligned... so you've swallowed 48k of ram ( with 18k 'spare' in gaps ) and when you mirror the sprite you need to rewrite all the 24 PM definitions.

I'd just use the old fashioned method

[emkay]

It helps for games where only one sprite moves in Y:

 

Mirax Force

 

Mirax Force is a bad example. A nice gameplay is missing all over.

Can you imagine the game is leaving most resources untouched?

Particular this game would easily take benefit by a Multiplexer, which must not mean to have more "sprites" on the screen. It would mean to have free moving sprites with different attack waves.

[emkay]

Ah - makes sense ( also there's no animation ) - still seems quite expensive - I think that main sprite is 24 pixels high - so you need 24 copies for 1 line vertical movement - PMBASE has to be 2K aligned... so you've swallowed 48k of ram ( with 18k 'spare' in gaps ) and when you mirror the sprite you need to rewrite all the 24 PM definitions.

I'd just use the old fashioned method

 

I'd say Mirax Force is a first try of someone who learned his first lessons in Assembler. The whole machine is sleeping here:

All the game does ist the movement of the Player's ship and some vertical PMG splitting for moving them on the x-axis. The scrolling seems done with the simple LMS routine.. So, no byte on the screen is moved through all the screenmovement.

[Fröhn]

Particular this game would easily take benefit by a Multiplexer, which must not mean to have more "sprites" on the screen. It would mean to have free moving sprites with different attack waves.

It has a multiplexer already.

[Tezz]

Particular this game would easily take benefit by a Multiplexer, which must not mean to have more "sprites" on the screen. It would mean to have free moving sprites with different attack waves.

It has a multiplexer already.

it's not a multiplexer. simply the player stripes repositioned and recoloured in the dli

[Tezz]

I'd say Mirax Force is a first try of someone who learned his first lessons in Assembler. The whole machine is sleeping here:

All the game does ist the movement of the Player's ship and some vertical PMG splitting for moving them on the x-axis. The scrolling seems done with the simple LMS routine.. So, no byte on the screen is moved through all the screenmovement.

The game certainly is not using the potential of the machine for sure and is quite straight and boring, very few did ever use the machine to the degree that it required to produce something good. Chris Murray was quite acomplished on the A8 producing Henry's House in the same year so it's surprising that he didn't do more with it.

[TMR]

That's your speculation. Ever heard of bitplanes vs. chunky mode. On amiga the bitplanes each have their separate addresses

 

If the hardware saw them as a single entity it'd only have the one register, but you can quite happily place them independently; the multicolour enable bit only says that they'll OR together where they meet, not that they're bound together. The bitplanes on the Amiga are the same, what keeps them unified when displaying a picture is only what the programmer has said to do and, if he changes his mind, they can all bugger off in totally different directions because the hardware still sees them as independent to each other.

 

You don't need to do the bounds check in the sprite renderer as that would be running at 16*60 Hz (for up to 32 multicolor sprites as in the current implementation).

 

But there's bounds checking needed to see if objects are about to pass, that has to happen somewhere and constantly refreshed as objects move so it needs CPU load. That needs to be considered in the method's overheads, along with the load placed on the system by the interrupt framework holding things together.

 

You can check the bounds when setting the virtualY position. Also copying does not necessarily have to be done in a zone conflict. You have several other options including (1) interleave it with VBLank so it renders at 30Hz [on NTSC], (2) Not to render it (so it disappears in that zone), (3) Use Grafn to fix DMAd data for 2nd sprite. Even if you copy data, it'll be done < 1/8 of the time [avg] as when doing normal Y positioning.

 

We-ell... if this is offered as a faster alternative to my method i'd say that rules interleaving or dropping objects out because that wouldn't be emulating what the slower version did. So at those points the block copying will have slightly higher overheads (since the bounds checking that told the system to enable it has to be included)... i'm not sure about the Grafn solution to be honest, you'll have to explain that further.

 

I don't think your original post asked for animating it, but you can still use a similar solution

 

Well, originally i was offering my method as part of a comparison to C64's facilities so it was at least implied that mine could since it'd need to change definitions and so forth for that comparison.

[TMR]

It has a multiplexer already.

it's not a multiplexer. simply the player stripes repositioned and recoloured in the dli

 

It's a bit of a semantic issue; some people consider a multiplexor to need a sort, others consider any recycling of sprites to be multiplexing and there's loads of grey area inbetween...

[Fröhn]

It has a multiplexer already.

it's not a multiplexer. simply the player stripes repositioned and recoloured in the dli

 

It's a bit of a semantic issue; some people consider a multiplexor to need a sort, others consider any recycling of sprites to be multiplexing and there's loads of grey area inbetween...

Multiplexing is simply reusing an information channel. If PMs are reused, then that's multiplexing. I know that in the UK there is this "Andrew Braybrook definition of sprite multiplexing" which includes sorting, but then again: Where to draw the line? You can have different sorting methods too, up to pre-sorted sprites which would also apply to Mirax Force.

Edited November 30, 2008 by Fröhn

[Heaven/TQA]

It has a multiplexer already.

it's not a multiplexer. simply the player stripes repositioned and recoloured in the dli

 

It's a bit of a semantic issue; some people consider a multiplexor to need a sort, others consider any recycling of sprites to be multiplexing and there's loads of grey area inbetween...

 

Multiplexing for me is simple repositioning and reusing (hardware) sprites for more "virtual" sprites...so actually the sorting is not part in my definition. but to have an intelligent "multiplexor" you run into the sorting issue somewhere...

[Tezz]

It's not multiplexing, recycling, reusing the channel, all the 4 players are a 256 pixel stripe which can be repositioned anywhere within that vertical strip with ease in the dli. It's a basic feature of the system. That is another reason why describing the Atari sprites as only having 4 (5) is misleading. You can have many vertically positioned sprites, that's never a problem.

There are certainly different multiplexing methods but for me it describes additional sprites with free movement on the screen, or if you like more than 4 on a scanline.

The combined missiles to make up a 5th player can be useful in some situations but we don't gain a colour with the 5th this way so I would prefer them to be used individually as an underlay or as bullets as they were intended, it depends on the circumstances.

Edited November 30, 2008 by Tezz

[Heaven/TQA]

Tezz... of course you get a 5th colour by enabling "treat missles as 5th player" in the GTIA...