Atari v Commodore

[Rockford]

17 - PANTHER

 

C64

C64

C64

 

C64 has better graphics, sprites and more colours. C64 wins again.

 

ATARI

ATARI

ATARI

[emkay]

Yeah, your DMA controller is a fortune teller and knows all related stuff by presuming the next to use

 

Oh dear, you're trying to sound like you understand programming again and it isn't working... the DMA on a C64 RAM expansion doesn't work alone (and i never said that it did) but it takes a lot of the potential donkey work away from the CPU, leaving it with lots more time for the other jobs a game requires.

 

You wrote a lot of stuff. Possibly it's my limitied english, but I read a lot of facts that do not come to a common point from where it could do any benefit for a games like Space Harrier.

It's a clear thing that, if you can put changes to the memory that is used to show the objects, yoy can give them additional "faces" and resulting better animations. It wouldn't look that boring as the original Space Harrier looks like.

 

You could explain how this "DMA" controller is working for real.

Assuming it works the same way as pointer programming, it just is acting for a defined memory range and starting/ending-adress. But it cannot act as a real blitter, which means that one command can set a full object onto the screen?

So you'd have to set the pointer to every line new?

Well, chars do well here with the VIC II . Just defined chars set to the screen cost some cycles, and no shifting is needed...

 

And now? How can a DMA controller do speedups here.

Edited September 17, 2009 by emkay

[emkay]

Co-ordinates and overlay priority are never going to be an issue because Space Harrier on the C64 in it's current form already handles them - you're forgetting that this isn't a 3D world we're dealing with, it's not anywhere near as complex as something like Encounter on either machine.

 

X and Y coordinates you need to set the objects on the screen, even without the 3D usage

 

And, well, if you going to use full graphics, you have to calculate the overlay, that the VIC does with the Sprites. So it may cost more CPU cycles.

All the preparations of the DMA controller, handled with different object sizes and coorninated relations in the programm, will speed the game down, not up.

 

And, If you only use the DMA for the char's memory updates, you'll only get more difference in shapes, but you don't save cycles to have the game running any faster.

[Allas]

I think Atari Panther version has a little better music, sound effects and good choice of saturation colors. Instead, C64 has better design of sprites. Playability on both are the same, strangely it feels more accurate on Atari version.

 

Other way your Atari screenshots are not right.

 

This game should be declared as a draw, as there is not a clear superiority on one version from another.

[Lazarus]

You could explain how this "DMA" controller is working for real.

Assuming it works the same way as pointer programming, it just is acting for a defined memory range and starting/ending-adress. But it cannot act as a real blitter, which means that one command can set a full object onto the screen?

It can easily copy horizontal stripes onto the screen. For every 8 rasterlines blitted you would start the copy process one time and do the edges via the CPU. The REU memory would have to be filled with pre-scaled and shifted objects.

 

So you'd have to set the pointer to every line new?

Every 8th rasterline.

 

Well, chars do well here with the VIC II . Just defined chars set to the screen cost some cycles, and no shifting is needed...

But there are only 256 chars which is far too few to stuff all objects in all sizes and X/Y shifts into.

 

And now? How can a DMA controller do speedups here.

It doesn't do speedup, but Space Harrier is already quite fast. It just doesn't LOOK fast because the object positions are bound to an 8x8 block and have only few z-positions, so every new frame only a few objects change which makes the framerate look much lower than it actually is.

[emkay]

I think Atari Panther version has a little better music, sound effects and good choice of saturation colors. Instead, C64 has better design of sprites. Playability on both are the same, strangely it feels more accurate on Atari version.

 

Other way your Atari screenshots are not right.

 

This game should be declared as a draw, as there is not a clear superiority on one version from another.

 

Well, the gamescreen is bigger than on the C64, just another point for the A8 version.

[TMR]

Co-ordinates and overlay priority are never going to be an issue because Space Harrier on the C64 in it's current form already handles them - you're forgetting that this isn't a 3D world we're dealing with, it's not anywhere near as complex as something like Encounter on either machine.

 

X and Y coordinates you need to set the objects on the screen, even without the 3D usage

 

Yes of bloody course you need X, Y and some form of Z co-ordinate and i never said you didn't if you'd actually read what i said. It's just not a major job to process them and Space Harrier on the C64 is quite happily doing that at speed already so obviously it's not an issue and wasn't even worth your mentioning the first time, let alone repeating.

 

All the preparations of the DMA controller, handled with different object sizes and coorninated relations in the programm, will speed the game down, not up.

 

You use the DMA when the job is large, the CPU for smaller objects where that'd be faster than configuring the DMA; this isn't an either/or situation, you can quite happily use both in the same refresh as suits the job in hand. One of the largest jobs (as i've already mentioned) is clearing the screen, the DMA can do that nine times faster than the stock C64 (so about five or perhaps six times faster than the A8 depending on circumstance and display mode), so guess what would get used for that job. Some of the smallest background objects are only a byte or two wide so it's faster to just process them with the CPU or even do what the C64 version of Space Harrier already does, that's where most of the hardware sprites are.

[analmux]

It can easily copy horizontal stripes onto the screen. For every 8 rasterlines blitted you would start the copy process one time and do the edges via the CPU. The REU memory would have to be filled with pre-scaled and shifted objects.

All nice and well, but does the REU also do LDA, AND, ORA, STA sequences, needed to mix f.e. software sprites into a background? I think this is one of the things emkay tries to point out.

[STE'86]

 

Yup, same with Ghosts 'n' Goblins, the maps it does have are all interleaved into one big uncompressed area from what i remember. Elite's policy towards just about every 8-bit was "get 'em out the door" really, that's why Airwolf was just a re-badge of Blue Thunder on the A8, explains why Airwolf 2 was just a scrolling shoot 'em up on everything and as for Ghosts 'n' Goblins and Commando on the C16... eek!

 

yeah i know well how they worked they were based about 4 miles from where i live. i knew a few people who passed thru their doors over the the years

 

in fact PeteD was a "trainee" there during his formative youth.

 

Ask him about the several dozen copies of "space Invasion" he had scattered about his home at one time

 

(Space Invasion was the demilitarised version of Commando for the German market way back when u couldnt sell "army" games there in open sale)

 

Steve

Edited September 17, 2009 by STE'86

[PeteD]

It can easily copy horizontal stripes onto the screen. For every 8 rasterlines blitted you would start the copy process one time and do the edges via the CPU. The REU memory would have to be filled with pre-scaled and shifted objects.

All nice and well, but does the REU also do LDA, AND, ORA, STA sequences, needed to mix f.e. software sprites into a background? I think this is one of the things emkay tries to point out.

 

No, but TMR has tried to explain this to him over and over Use the DMA to copy large chunks and the cpu to do the "edges". If you build up a line store you can do sequential DMAs and fill in the overlapped parts later (also using the line store to get the graphics addresses). It's an overhead to build the line store but one that should be negated by the dma doing the bulk of the drawing instead of the cpu. Emkay seems to keep going back to talking about char mode for some reason when TMR is saying you could draw a bitmap in the same time using the reu.

 

 

 

Pete

[frenchman]

I think Atari Panther version has a little better music, sound effects and good choice of saturation colors. Instead, C64 has better design of sprites. Playability on both are the same, strangely it feels more accurate on Atari version.

 

Other way your Atari screenshots are not right.

 

This game should be declared as a draw, as there is not a clear superiority on one version from another.

 

 

Yeah as Rocky Mountains has proven, most UK programmers couldn't program the A8 for toffee, but sometimes they did make an effort, here's UKs Tynesoft:

Atari:

 

C64

 

 

Atari

 

C64

Edited September 17, 2009 by frenchman

[emkay]

It can easily copy horizontal stripes onto the screen. For every 8 rasterlines blitted you would start the copy process one time and do the edges via the CPU. The REU memory would have to be filled with pre-scaled and shifted objects.

All nice and well, but does the REU also do LDA, AND, ORA, STA sequences, needed to mix f.e. software sprites into a background? I think this is one of the things emkay tries to point out.

 

I simply doesn't.

It's just a filling of char based lines high clusters. To have at least kept the current speed, it still works at charmode resolution....

 

Tolle Wolle

[emkay]

 

No, but TMR has tried to explain this to him over and over Use the DMA to copy large chunks and the cpu to do the "edges". If you build up a line store you can do sequential DMAs and fill in the overlapped parts later (also using the line store to get the graphics addresses). It's an overhead to build the line store but one that should be negated by the dma doing the bulk of the drawing instead of the cpu. Emkay seems to keep going back to talking about char mode for some reason when TMR is saying you could draw a bitmap in the same time using the reu.

 

 

 

I know what TMR wants to explain. But the use of simply exchanging graphics clusters doesn't quite help for games like Space Harrier.

[PeteD]

But you're missing the point that once the setup of object positions is done (something the game does ALREADY) the reu can be used to draw in bitmap mode at about the same speed as char mode. Yes it's exchanging graphics clusters but then that's all thats happening on the A8 version and without delving into the code you can't know for sure if something else isn't happening on the vanilla C64 version such as decompressing stuff on the fly so slowing it down.

 

It's just an example of people saying something can be better on A8 because you're allowed 320k but then if the C64 stuff was using the REU it would not only have to extra ram but data copying is a lot faster. To C64 users it's a non standard because it wasn't really needed to produce the games available so it's never thought about but it is there and can be used, just like the atari ram expansions. I'm sure if it was a standard or C64 coders started to use it as such now some amazing things would be possible.

 

 

Pete

[analmux]

Emkay seems to keep going back to talking about char mode for some reason when TMR is saying you could draw a bitmap in the same time using the reu.

Well of course in charmode everything would be different, but the big negative point of C64 so called bitmap mode is the non-linear addressing. This is not charmode, but still charmode resolution.

 

Doing software sprites (also large objects) in charmode resolution needs more logic, not only moving data. The ratio of CPU usage for doing this logic is far worse than you could think. REU doesn't take all work from CPU by far.

 

Also when the CPU does the edges, even more logic is needed. This would depend on the coordinates etc. So, after all I think you'd win only 50 % of time instead of 95 %.

[PeteD]

Well, it's another case of won't know till someone tries

 

As far as the bitmap addressing mode goes, it depends on what you're doing with your data, if you're going to allow pixel Y offsets etc, something which doesn't happen on spaceharrier anyway in which case there's no problem with dumping data from the reu on 8 pixel lines. Once again, until someone writes the code and works out the edge cases, how much actual cpu softspriting is needed then it's guesswork. As you say I can imagine it taking more time but then that's the fun of coding. You write it, it takes too long, you work out ways around it

 

As a quick thought on method I'd see it as you make your "blit" list to copy the 8x8 of data on each "sprite" below to the bitmap so it's already there then the hardest part left to do is after all the dma is done, go back over the list, go back 8 bytes from the start addresses (of the "above" graphic) and then you're in the data that needs to be mixed with the background, problem, where do the masks come from? Either a known ram offset in the reu or make them from the graphic in which case you've got something like LDY GRAPHIC,X LDA MASK,Y then the usual or and store. It's how many of those there are per screen that would be the killer.

 

Anyway, once again, it's not just space harrier we're talking about but lots of things. I think "conversations" in this thread lose track of themselves very quickly. lol

 

 

Pete

[analmux]

I was just reasoning based on experience, not on 'just some floating theoretic thoughts'

 

Of course C64 is not the world where swsprites (or bit blitters or whatever) are needed that much. It's really A8's territory. I've tried working out some code for generating swsprites in charmode!

 

On A8 we can optimize a little. Imagine moving a REU object one scanline down on C64, then all logic must be reinitiated etc. That's why in my experiments I used char-clusters like:

 

0 4 8 C
1 5 9 D
2 6 A E
3 7 B F

 

instead of the 'linear' charmode resolution settings of C64.

Thus, this would need somewhat less logic as on C64, as we can just keep copying bytes at different offset, in a linear loop. On C64 the loops will always be broken up, unless also switch over to charmode.

My routines already used up to 50% only for the logic. The other 50% was just the LDA,AND,ORA,STA part.

That's what I mean. However, it was just a first try, and maybe there are faster ways...

 

 

But, I'd be surprised if it could be more than 50% faster, using the r.e.u., but, we are put on this world to surprise others now and then, aren't we?

[PeteD]

Yep, vertical chars for speed is a well known one on C64 as well, but then when you come to do things in 5 colours (as discussed someowhere else recently) you rapidly run out of spare chars, have to split definitions with LMS instructions and then the vertical speedy sprite routine goes at least partially out the window also Also, I already agreed reu would be useless in that situation for moving 1 scanline down, unless of course you stored all your sprites with scanline offsets, and then you've got the problem of you've got to go back in fill in what the reu then destroyed in the background.

 

As I say, there are ways around a lot of things, you code stuff and then recode it and recode it until it's as fast as possible. I've been writing different versions of scrollers, softsprite routines etc for the past 25 years and I still don't have code that I'd just say "this is my library and I use it for every game" because it'll almost never be optimal.

 

I'm not trying to tell you or anyone else how to code here, just trying to point out that this discussion started a long ways back with is it ok to compare an unexpanded c64 to an A8 with 320k. Then it got dragged up again and TMR started talking about the REU and happened to mention Space Harrier quite probably just off the top oh his head, then that turns into a big backwards and forwards about if its faster or not JUST for space harrier. I can think of lots of uses for it to enhance games.

 

As far as surprising others, I'd like to be surprised by one of these new all singing all dancing A8 games WHEN they actually get released to show us all how great it is (and I include my own in that, but hey, I've not been writing mine since 2002)

 

 

Pete

[emkay]

But, I'd be surprised if it could be more than 50% faster, using the r.e.u., but, we are put on this world to surprise others now and then, aren't we?

 

On the C64 it may extend the whole graphics content, but the game gets slower. VIC II already is supporting all necessary/possilbe to support the slow CPU.

adding more graphics content, reduces this aiding and adds new CPU dragging "features", which slow down the already slower CPU.

[andym00]

But, I'd be surprised if it could be more than 50% faster, using the r.e.u., but, we are put on this world to surprise others now and then, aren't we?

 

On the C64 it may extend the whole graphics content, but the game gets slower. VIC II already is supporting all necessary/possilbe to support the slow CPU.

adding more graphics content, reduces this aiding and adds new CPU dragging "features", which slow down the already slower CPU.

 

Once I'm done with the first of my A8 plans, I'll write, just for you and you alone a Space Harrier PoC using the REU..

Would Sir like that running in 1 frame or 2 ?

Edited September 17, 2009 by andym00

[Lazarus]

Well of course in charmode everything would be different, but the big negative point of C64 so called bitmap mode is the non-linear addressing. This is not charmode, but still charmode resolution.

And that's actually an advantage when you render solid parts of objects since you can process 8 rasterlines with one DMA setup.

 

Also when the CPU does the edges, even more logic is needed. This would depend on the coordinates etc. So, after all I think you'd win only 50 % of time instead of 95 %.

I don't think the A8 code would differ much. A zeropage pointer loaded from a table of rasterline addresses. The more complicated part would be the clipping compares etc anyway, and that can't be avoided.

[Heaven/TQA]

It's the 128 characters that become an issue i reckon (i've been thinking about this for a long time now!) For one soft sprite at 8x16 pixels you've got to reserve nine characters so eight sprites is going to leave just 56 - C64-sized sprites would need the entire font for eight! You can split the fonts of course, but that's like recycling C64 sprites with fixed splits and you'd end up with "zones" they can move within.

 

I guess it depends on your zone sizes, but I think it's manageable.. My first thought when confronted with 128 was how on earth can I manage it, but a bit of a sit down, and 12 character sets worth of memory later it'll work

In my case I'm using 2 line characters splits, and allocate 64 chars for static background objects, 32 for software sprites and 32 for character positioned non-background objects..

Given I'm running a big player multiplexer I'm only interested in providing enough coverage for the players, so that means in each zone a maximum of 24 characters gone anyway in the worst case, which is manageable.. I'm going to stretch it to 4 lines when I've got time and see how bad it gets and if 32 chars will provide enough for 4 lines, or if it needs some rethinking..

At least that's how it is.. I'm loathe to let the players flicker and have the software sprites lose their overlays/underlays so I, for now, just let the software sprites flicker as well to match the player.. But it's early days and maybe all the magic numbers of character set allocations get changed

 

But even with 56 characters left, that's still a bucket load of characters to build a screen out of, if you've got zones of character set splits..

I only want as many as 64 per 2 (maybe going to 3 or 4) lines because I want to compose the screen not from blocks or tiles but from 'sprites' that are blitted into the background, if you see what I mean ?

 

I was traveling the last 2 days so sorry if I don't capture the whole issue with the chars and soft sprites.... but for Beyond Evil I tried to do it first like in the menace sources... with 9 chars reserved for each sprite... but next stuff was then done like Oswald suggested in terms of using 3 charline zones and mimic bitmap mode instead and this works better and leaves 8 chars for the holly "oswald bullets"...

[emkay]

 

 

Once I'm done with the first of my A8 plans, I'll write, just for you and you alone a Space Harrier PoC using the REU..

Would Sir like that running in 1 frame or 2 ?

 

Alike....

 

I'd just prefer some full A8 supporting games like "Test Drive" and similars

[emkay]

Well of course in charmode everything would be different, but the big negative point of C64 so called bitmap mode is the non-linear addressing. This is not charmode, but still charmode resolution.

And that's actually an advantage when you render solid parts of objects since you can process 8 rasterlines with one DMA setup.

 

It's a ridiculous comparision, if you know that just 5 cpu cycles can change 8K of RAM immediately on the A8. This would mean to have a movie in the background of a standard game on the A8.

[andym00]

Alike....

 

I'd just prefer some full A8 supporting games like "Test Drive" and similars

 

But test drive is rubbish.. Have some dignity and set your heights higher

How about Hard Drivin' ? Surely that can be done on the A8 ?

 

edit: Just for the record, way way back I actually saw a prototype of Hard Drivin' on the NES first hand back in '89/'90.. It wasn't *that* bad to be honest It was a bloody brave programmer that took that on, but with a bit of lateral thinking it can be done.. After seeing that I even started working on a method on the PC-Engine for achieving the same style of engine, so its not impossible, and given the A8 penchant for mega-buckets of RAM, the engine method kind of fits quite nicely

Edited September 17, 2009 by andym00