Atari v Commodore

[Heaven/TQA]

can we agree...sprite system of c64 is better???

 

and I still doubt the usage with the pmbase trick simply because of the wasting RAM. What happens when a sprite is crossing the border of a zone?

 

and you still need the repositioning of the sprites? so...what about the additional logic to handle all the cases? f.e. at top of the screen pm-zone 7, below pm-zone 0?

[Oswald]

can we agree...sprite system of c64 is better???

 

and I still doubt the usage with the pmbase trick simply because of the wasting RAM. What happens when a sprite is crossing the border of a zone?

 

and you still need the repositioning of the sprites? so...what about the additional logic to handle all the cases? f.e. at top of the screen pm-zone 7, below pm-zone 0?

 

but the atari sprites are 256 pixels high!

[Wrathchild]

The hi-res ball might not be so nice redone in the 2:1 mode but may be acceptable? The only options around that that come to mind would be to have the area the ball travels in hi-res mode too coloured by pmg's (would prob need to lose the floor colour) and the ball itself could then be a hi-res software sprite.

Good call, if the colours were chosen such that the floor colour was Color3, then the missiles could possibly be set to all use the same colour (colour 3) and then be stretched horizontally to make up the floor?

 

[Edit] Actually stretching 4 * 2 wide pixels to quadruple width still only manages 32 pixels (colour-clocks), so scrap that idea

Edited December 2, 2008 by Wrathchild

[Heaven/TQA]

well...when the game is "simple" in terms of logic, why not through the code into A800??? and see what happens?

[Heaven/TQA]

and where can I download the .PRG/.d64/.T64?

[Tezz]

[Edit] Actually stretching 4 * 2 wide pixels to quadruple width still only manages 32 pixels (colour-clocks), so scrap that idea

I'll have a think on the whole display being in hi-res with PM overlays. Will need to compromise the number of colours this way.

[Wrathchild]

ftp://arnold.c64.org/pub/games/p

or

http://s64.emuunlim.com/gameinfos/pingpong/pingpong.htm

Edited December 2, 2008 by Wrathchild

[Crazyace]

Is the ball really going to look bad at 160res - I didn't have any problems with the atari tennis game.

[emkay]

[Edit] Actually stretching 4 * 2 wide pixels to quadruple width still only manages 32 pixels (colour-clocks), so scrap that idea

I'll have a think on the whole display being in hi-res with PM overlays. Will need to compromise the number of colours this way.

 

Reducing them from 4 colours to 8 or up to 12

[Tezz]

Thinking about it, we'd be wasting all the pm's required for the paddles to colour the hi-res background so the original mix mode idea seems the most valid option.

 

Here is that Magnus demo attached by the way which appears to overlay the hi-res sin scroller over the 160 mode, I remembered eventually it was called "Revenge of Magnus". It's towards the bottom of the menu on the attached disk.

DEMOS001.zip

[Rybags]

Use 2 players for the ball - first one yellow, second one yellow/green with luma midway between the ball and table colour.

 

Might look reasonable.

[TMR]

So you agree that bitplanes are more flexible since you can adjust their position and get same or better color output than chunky modes.

 

Actually, i never offered an opinion regarding which was more flexible or anything, the point is that a four colour image on the Amiga is seen by the hardware as two independent bitplanes in the same way that what you're trying to call a single three colour sprite is still two sprites according to the hardware. And if the Atari can use two sprites to generate a three colour object it's an unfair comparison to for some reason disallow the C64 from doing exactly the same.

 

For a multiplexer the interrupts already have to be there. If you modify the Y-register at a high frequency (with different values), then you can even consider that as a small load but otherwise it's a lame argument as the sprite multiplexer interrupt is happening 16X as often every frame. Regardless, your claim Atari sprites are 11X slower to render is WAY OFF.

 

But we weren't talking about a multiplexer and the comparison was two three colour objects being moved on both machines, keeping it simple. On the C64 side of things i didn't allow any CPU overhead for an interrupt-based framework and my Atari code was working under the same circumstances; you claimed your example to be ten times faster than my Atari method but, with all the bounds checking and the interrupt framework ticking over every frame, i can see that claim being well off the mark you're claiming even before the exception cases where block shifting kicks in.

 

Sorry, but "static" does not mean "dynamic" in my dictionary. Read you original post and tell me you did not state STATIC:

 

Okay, lets look at what i said:

 

"...assume a static screen and two objects with three colours..."

 

...so for a start, i'm not saying the objects are static, merely the screen - there's another battle of semantics right there since i and others use the word "screen" in those contexts to mean the same as "background". You might doubt the sincerity of that statement, but it was backed up with...

 

"to move both every frame"

 

...where "both" in this case refers to the previously mentioned two objects and no, they're not static because we're moving them and i think it's fair to say i didn't limit that by saing "move both vertically" or similar.

 

One thing i've noticed on reading back is that i did miscalculate the C64 load a little because i forgot the sprite data pointers, but since i was dealing with the MSB every frame when it's not needed i'll correct my calculation now by swapping the two over and adding a single MSB register transfer per cycle - the MSB won't be accessed that regularly at any point under usual circumstances but i got paid today so i'm feeling generous. =-)

 

So that's 13 bytes as opposed to 12 now for the C64, with the Atari taking 132 so my example requires ten times the CPU load. That's positioning in X and Y as well as changing definitions when required.

Edited December 2, 2008 by TMR

[emkay]

plus moving the data for the DLIs and if there are PM content this has to be shuffeled around, too? and the G2F code does use tight code which means most of the time no tables but LDA STAs?

 

 

You're thinking too complex. The whole thing starts with the first DLI command that is set in the Displaylist. This command follows the first line of every vscrol line...

All that is to do, is to exchange the DL starting line for the DLI one up or down, after going though all 8 steps of the vscrol.

The only rule is to use PM only with the shapes, not via DMA.

[Heaven/TQA]

1:0 MK...

[+CharlieChaplin]

Thinking about it, we'd be wasting all the pm's required for the paddles to colour the hi-res background so the original mix mode idea seems the most valid option.

 

Here is that Magnus demo attached by the way which appears to overlay the hi-res sin scroller over the 160 mode, I remembered eventually it was called "Revenge of Magnus". It's towards the bottom of the menu on the attached disk.

 

[off-topic]

Be warned !

This demo also includes an unwanted formatting "option", press the wrong key (was it Start, Select or Option or some other key ?) and it will format your disk or disk image - if the disk/disk image isn`t write protected... -Andreas Koch.

[end off-topic]

[miker]

Hmm... IIRC it is Cosinus demo (also by Magnus) which formats disk after pressing OPTION key. Don't remember if Revenge of Magnus does it, too.

[Tezz]

It could be Andreas, the demo does state "Formats!" in the menu. I found this disk image Googling looking for the demo this morning to post it here, I've not seen the actual Magnus demo since the early nineties on my real hardware, I don't recall the formating keypress being in it though.

 

I've not looked into this demo in monitor yet, you can see that the screen isn't displaying correctly under emulation with the planet graphic wrapping round.

[Crazyace]

I think that demo is just standard mode f scrolling - but it's using the players and missiles to show a starfield

[Tezz]

I fear that might possibly have been the case after I downloaded the demo again after so many years. I was hoping that it was a clever page flip between the modes. Prob not the case though sadly. I know that any attempt I did many years ago produced a poor result with the technique

 

I'll go and take a look at it now instead of pondering

Edited December 2, 2008 by Tezz

[Tezz]

Looking further at Konami Ping Pong today, the concept for the layout is feasable with two pm's only needed to colour the top hi-res section leaving the remaining two pm's free for the paddle (the overlap provides it's 3rd colour). The paddle at the bottom of the screen has all of the players and missiles available as the rest of the screen down is simply char based. Very few chars are required so splitting the screen sections and using a software sprite for the ball shouldn't create any difficulties.

 

Here's an xex attached anyway showing the layout that could be used in a working game. The screen can easily be coloured further adding some nicer shading on the table and other areas etc but I've left it just as a simple comparision here.

pong_layout.zip

[Crazyace]

If you want a high res ball the bottom of the screen will need to be high res, as if you miss your serve the ball shrinks..

It's quite a accurate conversion of the screen though

[Tezz]

I concidered the completely hi-res concept but if at all possible it'd not look as good and with all the available sprites needed to span the screen for the underlays, there would be none left for the paddles. The easiest thing in regard to the ball would be just to use a low res one. It presents a difficulty with the software sprite crossing into the hi-res section but I suppose a careful routine could get around it maintaining it's 2 pixel horizonal movement. If we were to draw the ball simply in "color2" it's shape would display the same in both modes.

Edited December 2, 2008 by Tezz

[Crazyace]

The original arcade game is 256 pixels wide - have you looked at that?

[Tezz]

I had a brief look at the original via Mame several years ago, I should take another look. I remember the game mostely from the Spectrum conversion.

[Allas]

11 - COSMIC TUNNELS

 

Atari screenshots

 

On early year of Atari, this game was very fun! Practically both versions are the same.

I prefer the Atari because his colors combinations along of different screen levels.

 

C64 screenshots

Edited December 3, 2008 by Allas