Atari v Commodore

[emkay]

 

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 ?

 

Well, it's rubbish on the C64, guess why .... some more FPS do miracles

[andym00]

Well, it's rubbish on the C64, guess why .... some more FPS do miracles

 

Nothing can save that game, nothing at all apart from deleting it

[emkay]

Well, it's rubbish on the C64, guess why .... some more FPS do miracles

 

Nothing can save that game, nothing at all apart from deleting it

 

Your taste? OK

 

But,well, Hard Drivin would run 4 times faster on the A8 and you'd have a 16 colour mode there ....

[andym00]

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"...

 

The Holy one speaks the truth

Except maybe a few more zones than 3..

Edited September 17, 2009 by andym00

[frenchman]

I like Test Drive on C64 (and Test Drive 2 is even better), actually, Accolade hardly ever produced a bum game on C64 (maybe Rack 'em and TKO are rubbish). Grand Prix Circuit is my absolute favorite.

Edited September 17, 2009 by frenchman

[andym00]

But,well, Hard Drivin would run 4 times faster on the A8 and you'd have a 16 colour mode there ....

 

Of course it would..

[TMR]

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.

 

There's a relatively large block of RAM at the back end of the DMA, keep eight copies of the object at different heights and just do the masked top and bottom row with the CPU as need be.

 

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?

 

i'm clearing a bitmap in 8,000 cycles, that's a little more than 50% faster - even if that's the only job you used it for within a game, it's a significant speed boost; imagine Mercenary or Rescue On Fractalus able to go much faster purely because that the clearing of the screen took a fraction of the current CPU time. In fact, have a look at the second level of Savage because that's drawing to a bitmap; it's not difficult to extrapolate that out into something more complex if the screen clear is taken away because a DMA is doing the job.

 

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

 

Blah blah... keep it down emkay, people who actually know what they're talking about are busy here.

Edited September 17, 2009 by TMR

[TMR]

I can think of lots of uses for it to enhance games.

 

Want to see my full screen, single buffered vertical bitmap scroll? i plan to do a vertical version of Uridium with it at some point... =-)

[atarian63]

17 - PANTHER

 

C64

C64

C64

 

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

 

ATARI

ATARI

ATARI

Again wrong time period on atari... try pre 85

[analmux]

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.

War is peace

 

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.

To be more precize. When using C64 font mode there's no difference at all.

[analmux]

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.

 

There's a relatively large block of RAM at the back end of the DMA, keep eight copies of the object at different heights and just do the masked top and bottom row with the CPU as need be.

 

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?

 

i'm clearing a bitmap in 8,000 cycles, that's a little more than 50% faster - even if that's the only job you used it for within a game, it's a significant speed boost; imagine Mercenary or Rescue On Fractalus able to go much faster purely because that the clearing of the screen took a fraction of the current CPU time. In fact, have a look at the second level of Savage because that's drawing to a bitmap; it's not difficult to extrapolate that out into something more complex if the screen clear is taken away because a DMA is doing the job.

 

So, actually, in that case no logic would be needed at all?

And, we're still forgetting the 'edges', needed to be done by hand. Also no logic needed there?

We could as well use a passive RAM expansion, and use font-flipping instead. Then no DMA transfers are needed at all.

[analmux]

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.

What does a C64 coder need swsprites for??

[PeteD]

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.

What does a C64 coder need swsprites for??

 

C64 coder? Try, bbc, spectrum, c64, st, amiga, cd-i, psx, ps2, gba, pc, etc etc

 

*edit* I suppose I should add A8 onto the list now

 

Pete

Edited September 17, 2009 by PeteD

[analmux]

C64 coder? Try, bbc, spectrum, c64, st, amiga, cd-i, psx, ps2, gba, pc, etc etc

 

Oops, sorry, didn't know that

 

Anyway, what is the most cpu-economical swsprite engine should depend on which machine you're coding for, ain't it?

[analmux]

Still waiting for Rockford's new post

[PeteD]

C64 coder? Try, bbc, spectrum, c64, st, amiga, cd-i, psx, ps2, gba, pc, etc etc

 

Oops, sorry, didn't know that

 

Anyway, what is the most cpu-economical swsprite engine should depend on which machine you're coding for, ain't it?

 

In best case scenario yes. But taking the columns method you posted earlier, as I say if you're using the 5 colour mode (sorry, I'm repeating this from earlier posts so just skip to the next post if you read it already) you've got 128 chars, make a background out of those and how many do you have left? say 64 and that's generous so now you want a 16x16 sprite, that needs 2x2 chars BUT you have to allow for max diagonal movement 3x3 9 gone for 1 sprite. You already know all this, so how do you get around it, a8 the easiest way I can see is to do multiple LMS lines, even a new charset for each modeline, you can use the space offscreen for data so it's not wasted then your sprite routine becomes more complex than the column one. Not much more but that's already an overhead. what if you can't do an LMS per modeline for some reason? now you have to start checking the Y pos of your sprite to see if it's gone over one.... etc You can have a good/fast generic routine but I can guarantee you wont use it 90% of the time.

 

 

Pete

[Rockford]

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.

 

Allas, I took these pictures from atarimania and Bacardi's site, so they should faithfully depict this game on Atari. Anyway let's check them again (this time I will use your pictures)

C64 - realistic ground colour, much better sprites, more colours.

Atari - dark red ground, poor (small and one coloured) sprites, less colours.

C-64 - again, more natural colours and much better sprites

Atari - dark, dirty green, poor sprites, less colours.

C64 - more detailed waves, much better sprites, more colours.

Atari - all waves are the same, poor sprites.

C64 - better colour balance, much better sprites, more colours.

Atari - less colours (darker of course), poor sprites.

 

Sound/music and playbality are the same. C64 has better graphics (take a look at your ship destroying sequence - on atari it looks like joke), much better (very well animated) sprites and more colours. Atari has dirty-dark colours and very poor, small, one coloured sprites. Sorry Allas, nice try but the C64 version is better.

Edited September 17, 2009 by Rockford

[PeteD]

Still waiting for Rockford's new post

 

It's the highlight of my day

 

 

Pete

[PeteD]

Damn Rockford, where do you live? Near something radioactive if you think that green is natural

 

 

Pete

[analmux]

C64 - realistic ground colour, much better sprites, more colours...

C-64 - again, more natural colours and much better sprites...

Well, at least the colours could be chosen better on A8. Remember, the C64 palette is a subset of the Atari palette (up to some very minor differences).

 

Many times I wonder why in A8 games the programmers chose ugly colour combinations.

[analmux]

Why not trying to sell a new book: "Atari v Commodore, the neverending story:? It would sell millions

 

Another thing:

 

Suppose every time you ged a dollar for every reply made to a topic you started, then stevelanc could go on a deluxe holiday.

[Rockford]

Damn Rockford, where do you live? Near something radioactive if you think that green is natural

 

 

Pete

Not exactly radioactive but hey, what would you say about atari's green ? As andym00 said "when it comes to green Atari always wins" but this time it looks like digested grass

Edited September 17, 2009 by Rockford

[PeteD]

C64 - realistic ground colour, much better sprites, more colours...

C-64 - again, more natural colours and much better sprites...

Well, at least the colours could be chosen better on A8. Remember, the C64 palette is a subset of the Atari palette (up to some very minor differences).

 

Many times I wonder why in A8 games the programmers chose ugly colour combinations.

 

Colour choice is one of the things that really does let it down on a lot of games. That's why non-A8 people look at the A8 in a certain way. Maybe it's an NTSC/PAL thing, maybe it's a TV setting being wrong thing, or a strangely over average collection of colourblind people?

 

btw, to go slightly offtopic, the C64 palette is quite loved it seems by pixel artists and when you can do stuff like this http://www.wayofthepixel.net/pixelation/index.php?topic=8572.0 with it, surely it's not so bad? Some people might still think, "ewwwwww!" but I love this kind of thing, and the talent involved is amazing. Each section was done by a different person, each having 72 hours to draw their bit and not knowing what the surrounding ones (apart from the ones that had already been drawn, else it would never stitch together) looked like. Last page of the thread links to an animated gif of what order things were drawn in. Love it or hate it for the palette, that's some good pixelin'

 

 

Pete

[Rockford]

Still waiting for Rockford's new post

 

It's the highlight of my day

 

 

Pete

I am honoured :!:

[TMR]

i'm clearing a bitmap in 8,000 cycles, that's a little more than 50% faster - even if that's the only job you used it for within a game, it's a significant speed boost; imagine Mercenary or Rescue On Fractalus able to go much faster purely because that the clearing of the screen took a fraction of the current CPU time. In fact, have a look at the second level of Savage because that's drawing to a bitmap; it's not difficult to extrapolate that out into something more complex if the screen clear is taken away because a DMA is doing the job.

 

So, actually, in that case no logic would be needed at all?

And, we're still forgetting the 'edges', needed to be done by hand. Also no logic needed there?

 

What edges...? i'm talking about just clearing a block of RAM and nothing more there, leaving the existing CPU-based code to do it's job afterwards. Have a look through the refresh loops of some of these games, they have to clear the entire bitmap out each time they go to draw; just replacing that with a DMA-based overwrite would make a significant difference to the performance of those games, even in the case of Savage where each line would need to be cleared seperately (the background could be dumped in at the same time in that particular case).

 

We could as well use a passive RAM expansion, and use font-flipping instead. Then no DMA transfers are needed at all.

 

It's not really the same thing, is it? i'm talking about clearing an 8,000 byte work buffer ready to draw objects into it and you're talking about flipping to another one, you'll run out of clear buffers pretty quickly...