Atari v Commodore

[Oswald]

Oswald, do not know... I mean overscan can be usefull for such things but I never played around with these new techniques. I am enabling in general overscan if possible...

 

and for softsprites in general does make a real difference as instead of 40 bytes scanlines f.e. you have 48 instead....

 

the size doesnt makes a diff, as with the scrolling tech you only need to update the stepping in chars. what I would like to know that how much chars would one need to reserve to make a few softsprites, hmm or is it even possible to use a bitmap with this scrolltech ? how much 16x16 softsprites is possible to plot at 50/25fps into a bitmap/charsceen ? I think there's room for a nice platformer, tho with only 4 or 5 colors (bitmap/text)

[Heaven/TQA]

Yeah. Beyond Evil handles around 4-5 soft sprites, too... (flexible sprites which means can move in any direction).

[Heaven/TQA]

to be honest... the "wrapp scroll" is far beyond what I have understood so far...

 

I am more traditionalists and use the "gameboy"-method...

[Oswald]

Yeah. Beyond Evil handles around 4-5 soft sprites, too... (flexible sprites which means can move in any direction).

 

at what speed? and how many chars reserved/sprite?hmm or iirc it uses several csets as a bitmap?

[Heaven/TQA]

8x16x3

 

uses 3x3 chars and 3x2 in special cases.

 

look here... when I am at home I will post my sprite engine test:

 

http://www.atariage.com/forums/index.php?s...9206&st=425

Edited November 25, 2008 by Heaven/TQA

[analmux]

As I mentioned above: You need 4 players to have two 3-color players on Atari with the OR-restriction on the 3rd color. Take 4 C64 sprites and join them similar to A8 player joining -> you have 3 independent colors for both resulting sprites and even 4 spare sprites left with another 4 free colors + 2 combined colors. On A8 the missile colors are 100% shared with the player colors, so by using the C64 sprites that way you have much more freedom on color choice and still much bigger sprites.

 

Yes, I know VIC2 features. The OR-feature shouldn't be regarded one-sided as a just a restriction, most of the times it comes out very natural. But let's not discuss restrictions, as it is a never-ending story, f.e. there are VIC2 modes (iirc multicolour charmode) where you cannot use all 16 colours in the colour-ram, but only 8, as the 3rd bit selects hires/multicolour.

 

But you see, in theory c64 has 96 pixels wide multicolour sprites, which is 6 times bigger than the poor atari multicolour pms, but to simulate them properly you'd need 3 times as many sprites. That's why comparing 96 pixels on c64 to 16 (20 with missilis) on a8 is a one-sided comparison.

 

"Sprites" is just a more general term than "Players" and "Missiles".

 

Well, the thing that really sucks about atari PM is that you need CPU-time to change y coordinate of a sprite object. That's why I would call PM softwaresprites instead ...to me still the most natural use for PMs is for underlays for colour-enhancements.

 

320k in 1982?

 

o.k. good point, of course that would triple the price ....so the cheapest way would be to get a commy.

[Irgendwer]

even my game 'ECKN' uses 19 colours in the in-game screen (without interlacing!). Of course this game would also work on the C64 with less colours, but it would be different.

 

Well, to be totally honest the game wouldn't lose anything at all since most of those colours are in the face... that's far different to, for example, Zybex or Draconus only having 50% of the resolution on the Atari or Fractalus running slower on the C64. If it were me converting it, i'd say trade the colours in the face off against resolution, go down to about five colours and halve the width of the pixels.

 

1 colour background

+3 for the face and written comments

+12 for the stoneset!

+3 for the title

(just to supply correct information)

 

I asked myself, if this thread would be more friendly if the subject would be named:

Games that are better on the Atari even the C64 is the better machine...

1. The Great American Cross Country Race

2. ...

 

and than

Great exclusive games for the Atari even the C64 is the better machine...

1. Dimension X

2. ...

 

and finally

Games that use overscan on the Atari even the C64 is the better machine...

1. Living Daylights

2. ...

 

(edit)

I forgot one:

Games that are almost equal on the Atari even the C64 is the better machine...

1. Spindizzy

2. ...

CU

Irgendwer

Edited November 25, 2008 by Irgendwer

[analmux]

Lets "keep it simple" (since some people seem to like doing that =-) and assume a static screen and two objects with three colours that are 8x16 pixels and yes i'm weighting this in the Atari's favour by not asking for C64-sized objects; to move both every frame the Atari has to clear and then write 32 bytes per object, so 132 bytes per frame including the four horizontal position registers compared to the C64's twelve register writes (since we're using four hardware sprites in pairs for this theoretical example, same as the Atari to get the same colour control). Unless someone plans on making some wild claim about the Atari being eleven times faster than the C64 that's a huge chunk of bytes more to transfer...

 

This 12 vs. 132 comparison is wrong, as the 132 bytes in the softwaresprite scenario need preprocessing (loading, masking etc.), so effectively should be multiplied by 4.

 

Well, let's estimate/compute the needed cpu cycles. Not very long ago I did some swsprite tests, and I was surprised by the amount of cpu time needed for just the logic behind the routine. The actual LDA - AND - ORA - STA routine, the part that physically shifts data, takes up only half of the cpu time in my tests. Only detail is, that I made it for charmode antic 4. Bitmap should require somewhat less logic I think.

 

for every gfx byte we need appr. 25 cycles....to prepare registers multiply by 2 --> 50 cycles

8*16 in antic 4 (not counting scenarios where 8 pixels are divided over 3 chars horizontally) times 2 objects = 2*2*16 =64 bytes. --> times 50 = 3200 cycles.

Suppose we want this every pal/ntsc frame, then, using a standard screen (dma), this gives us appr. cpu usage of 13% on pal machines, or even 16% on ntsc.

 

 

{edit}

or were you still talking about hardware'sprites' for atari? I was somewhat confused (got mixed up with the stuff heaven & ozzy discussed)

Edited November 25, 2008 by Analogue Multiplexer

[Heaven/TQA]

Mux, yes... that is exactly why soft sprites in charmode suck... first of all you think ok... little bit like bitmap sprites (and that is one of the reason why a lot of bitmap sprite games are around (Gremlins, Zone Ranger, Asteroids, Droll, etc... good linear bitmap mode... ) but as you mentioned... the logic is the time consuming imho (sprites clipping DLI zones etc). then you need longer setsprite code, maybe setbackground_pm, too...and then you have preshifted data etc etc... and when speaking of setsprite... i mean erasing the old data, restore background, load new background, mask in sprite data....

 

on c64 2 simple LDA STA XPOS, LDA STA YPOS and here you go...

Edited November 25, 2008 by Heaven/TQA

[analmux]

Heaven,

 

and what would it take to make a scrolling platformer (using that nifty wrapparound scrolltech) ? how much rtime and chars does it take to add a 16x16 softsprite into such a scenario?

 

See my previous post (where I mixed this up with the stuff TMR wrote). 16x16 swsprite is 13 % in pal (more when corrections are counted. 16x16 = 4x2 chars = 5x3 chars at max in the worst case when sprite covers max of char-boundaries ---> needed cpu-time almost doubles in these cases)

 

Note, I designed m.w.p. wrapped scrolling because of memory problems, i needed a minimum of screenmemory. The program pays for this by somewhat more complicated code = more cpu time needed. When swsprites come into play, I'm afraid the m.w.p. method gives conflicts, which are very hard to solve.

I think the GBA scroll method needs far less cpu time.

 

I think the best would even be to use a DLIST with lms for all playfield lines......but, why am I talking about this all? .....

[MaPa]

Note, I designed m.w.p. wrapped scrolling because of memory problems, i needed a minimum of screenmemory. The program pays for this by somewhat more complicated code = more cpu time needed. When swsprites come into play, I'm afraid the m.w.p. method gives conflicts, which are very hard to solve.

I think the GBA scroll method needs far less cpu time.

 

MWP with softsprites is not hard to solve IMHO.. the only problem is that the screen memory where you want to put softsprite may be wrapped, so you have take care of softsprite each char line where it actually lies in video memory.

[Heaven/TQA]

btw. check Alley Kat from Andrew Braybrook on C64...some nice coloured raster effects in the main menu without flickering and you hardly can "reckon" the c64 16 colours in the bar on a TV set... (i am just watching that on my sony TV plus C64DTV).

[frogstar_robot]

C64's biggest shortcoming is that is was a poorly made POS.

 

When i got my 800XL for Christmas it didn't work properly, it would throw up a red screen four or five times a day on average so i returned it a few days after new years day, described the fault to the clerk in the shop and he didn't even bother firing it up to test the problem because the chain of stores had already received several hundred returns with the same issue by that point. Compared to my first C64, a 1984 issue machine that had been thrashed by it's previous owners (a local software development firm) and subsequently took a major pounding from me as well but still works to this day, i know which one i'd call poorly made and it doesn't tally with what you've said...

 

My first 800XL had a fed-up SELECT key but the exchange unit lasted for 7 years until I lost it in a move. That sucker was tough as nails. There was nothing cheesy about the 800s either. Now the XEs on the other hand have to be some of cruddiest plasticky looking things I've ever seen. And the XF551 drive is infamous for lousy solder joints on the SIO port. On the other hand, a buddy of mine got a whole shed-load of C-64s he wanted to use for a video wall project. There were in the neighborhood of 18 machines in that lot and it took a bit of chip and board swappery to get 14 or so good machines out of that lot. None were that bad cosmetically but we didn't know how they treated by the previous owner. I'd say they were between the 800XLs and XEs in terms of materials used and I don't recall QC horror stories from when they were new units. I rather liked the build-style of the 128s and 64Cs better. Just losing all that empty space made them feel more rigid and solid IMHO though I suppose the older units would be easier to internally mod.

[Alison DeMeyer]

Atari computers were always more stylish, that's all you need.

[TMR]

or were you still talking about hardware'sprites' for atari? I was somewhat confused (got mixed up with the stuff heaven & ozzy discussed)

 

Yeah, i was talking about hardware sprites with the 132 versus 12 comparison, software sprites add considerably to that load as you said and software with hardware underlay even more so.

[TMR]

Atari computers were always more stylish, that's all you need.

 

Why do i find the phrase "style over content" springing to mind...? =-)

[TMR]

I don't recall QC horror stories from when they were new units.

 

The only real quality control issues with the C64 were with the very earliest machines, NTSC 1982 issue units from what i've heard and it was more machines arriving DOA than anything else; after that i've found them to be very robust; i spent seven or so years selling the C64C and the only returns i can recall right now were due to popped fuses when people tried connecting a tape deck with the power on.

 

I rather liked the build-style of the 128s and 64Cs better. Just losing all that empty space made them feel more rigid and solid IMHO though I suppose the older units would be easier to internally mod.

 

There's only a little less space really, as long as you remove the shielding there's still quite a bit of room inside the newer case especially near the front since the board is shorter - the C128 is surprisingly spacious too. The machine i have on my desk is a C64C with an older keyboard on... i have a machine the other way around somewhere, i just swapped them over when bored a few years ago. =-)

[analmux]

Note, I designed m.w.p. wrapped scrolling because of memory problems, i needed a minimum of screenmemory. The program pays for this by somewhat more complicated code = more cpu time needed. When swsprites come into play, I'm afraid the m.w.p. method gives conflicts, which are very hard to solve.

I think the GBA scroll method needs far less cpu time.

 

MWP with softsprites is not hard to solve IMHO.. the only problem is that the screen memory where you want to put softsprite may be wrapped, so you have take care of softsprite each char line where it actually lies in video memory.

 

Actually, you are right. My head's not in atari-mode these days ....still wondering why I wrote that....maybe this:

 

Few days ago I was thinking about a game-engine with a charmode scroller including char-clusters/softwaresprites.

There CAN occur problems however, when a sprite is partially in the sideborder, and gets partially overwritten by the scroll-depack buffer.

A time-scheme must be designed, which tells us whether buffer-update or sprite-engine should be executed first.

Mainly this kind of problem could be trickyer when using the MWP method.

[atarian63]

C64's biggest shortcoming is that is was a poorly made POS.

 

When i got my 800XL for Christmas it didn't work properly, it would throw up a red screen four or five times a day on average so i returned it a few days after new years day, described the fault to the clerk in the shop and he didn't even bother firing it up to test the problem because the chain of stores had already received several hundred returns with the same issue by that point. Compared to my first C64, a 1984 issue machine that had been thrashed by it's previous owners (a local software development firm) and subsequently took a major pounding from me as well but still works to this day, i know which one i'd call poorly made and it doesn't tally with what you've said...

I really dont think you are being accurate, I worked retail at the time in those days and the Atari stuff was rock solid, the C64's on the other hand came back in droves, multiple exchanges etc, I would often get them to buy an Atari and the problem was solved. Terrible stuff, bad keyboards bad video, bad power bricks, cheap faulty rf modulator switch boxes. It was huge, we used to laugh when someone bought one as to how long it would be till they were back returning it..

[atarian63]

Atari computers were always more stylish, that's all you need.

 

Why do i find the phrase "style over content" springing to mind...? =-)

Actually Content and style! Those C64's were Ugggg leeee!

[atariksi]

>>I have been playing around with 160*200*8, 160*200*10, and 160*200*11 modes (w/o interlace) on Atari and I don't have any problem setting up my palette using the OR player mode. For example, set register 704 to 2, 705 to 4 and the OR will be 6 and you have 3 shades of gray using 2 indices.

 

>And what about if you want three colours and the third isn't the value produced by the OR?

 

In a shaded palette (shades of any of the 16 colors), you can always set up the palette a priori knowing the OR result. So 2 OR 4 = 6, 12 OR 2 = 14, 2 OR 8 = 10, 4 OR 8 = 12. There's a way to generate free black as well without requiring a color index (using priority conflicts), but I haven't done that yet in my implementation. So there's no restrictions.

 

>Well yes... although that does mean you're running the Atari sprite hardware at full tilt and the C64 is leaving three...

 

But implementation-wise, it's a better way to do it with OR and priorities and the original point was whether OR is restrictive. As far as then how many times I can retrigger the dual sprite channels throughout the scan-line, it depends on how many DMA cycles are stolen during the scanline whereas C64 would have to retrigger them vertically. (Since this is for increasing color content of picture).

[FastRobPlus]

I don't recall QC horror stories from when they were new units.

 

The only real quality control issues with the C64 were with the very earliest machines, NTSC 1982 issue units from what i've heard and it was more machines arriving DOA than anything else; after that i've found them to be very robust; i spent seven or so years selling the C64C and the only returns i can recall right now were due to popped fuses when people tried connecting a tape deck with the power on.

 

 

I'm a C64 lover, but those machines were not made to the same quality standard as Atari 8-bits. Today I see roughly the same amount of dead C-64s and Atari 800s, but back in the day it was really bad. My first job was for Softwaire Centre and we quit selling the C64 by 1984 (so before I worked there) as a result of dealing with the returns. They sold the software and 3rd party peripherals but not the system. More to the point, my grandfather was a cutting edge nerd and bought the C64 in Christmas of 1982 and went through 2 in the first day (they were out of stock so could not give him a third.)

It's not anecdotal, the C64 was built more inexpensively. The good news was if you got a working one it would "burn in" and be good forever. By 1984 there was a whole cottage industry around replacement 3rd party PSUs and I remember it got to the point where every serious C= user got a beefier PSU (and this continued even through my beloved A500.) I'm not saying quality didn't get far better for later C64s, but by that point the reputation was that the machine's build quality was suspect. We also saw a little of this with the Apples, where just about every one had an external 3rd party cooler slapped on the side long after the early Apple II cooling issues had been worked out.

[atariksi]

>As I mentioned above: You need 4 players to have two 3-color players on Atari with the OR-restriction on the 3rd color. Take 4 C64 sprites and join them similar to A8 player joining -> you have 3 independent colors for both resulting sprites and even 4 spare sprites left with another 4 free colors + 2 combined colors. On A8 the missile colors are 100% shared with the player colors, so by using the C64 sprites that way you have much more freedom on color choice and still much bigger sprites.

 

For increasing color content of a picture, you want the missiles to behave the same way as players. For using as game moving object, there's a bit to enable the fifth player with it's color set from PF3 (53273) register instead of from 53266..53269 (P0..P3).

[atariksi]

And what about if you want three colours and the third isn't the value produced by the OR?

 

Good point, but let's look at VIC2 sprites. 2 out of 3 colours are shared by all sprites. This doesn't happen on atari

 

No, but running out of sprites when there are two on a scanline doesn't happen on the C64 either and i know which of the two i consider to be less of a disadvantage...

 

That's the reason why us atarians may use softwaresprites instead. Then, all we need to do is add one PM underlay to give us the 'same' freedom as on C64 (at least when the first 2 palette-colours of the sprites are the same as the gfx palettes)

 

That's a bloody huge "at least when" you have there mister... =-)

 

i'd disagree about the "same" freedom too, since the CPU load per software sprite is vast compared to what the C64 needs to juggle it's hardware; it may be only two thirds the CPU power (give or take) but we're talking a significant amount of data being chunked around per frame and all the pre-stored stuff to account for.

 

Lets "keep it simple" (since some people seem to like doing that =-) and assume a static screen and two objects with three colours that are 8x16 pixels and yes i'm weighting this in the Atari's favour by not asking for C64-sized objects; to move both every frame the Atari has to clear and then write 32 bytes per object, so 132 bytes per frame including the four horizontal position registers compared to the C64's twelve register writes (since we're using four hardware sprites in pairs for this theoretical example, same as the Atari to get the same colour control). Unless someone plans on making some wild claim about the Atari being eleven times faster than the C64 that's a huge chunk of bytes more to transfer...

 

Let's keep it simple was to keep the hardware aspects separate so the arguments can flow objectively not what you think is simple. Just like in a DMA control register, each bit controls some hardware DMA channel so by comparing sound hardware, sprite hardware, graphics modes, I/O speed, etc. separately it won't confuse things so that one person states I can read 50KB/second through the joystick port and another person states "Oh, but I have 256 8*1 sprites". Then we know how creative both sides are in mixing and matching things (like enabling multiple bits in a DMA control channel).

 

Your algorithm for moving sprites vertically on the Atari is poor and not the potential of the machine. For vertical motion of 8*16 sprites on the Atari, one could keep the shapes at various heights at different PMBases (say +1, +2, ... +15) and then use the same PMBase and keep same shape 16 pixels down. Thus, by triggering PMBase as well as HPOSn you can simulate the Y-axis without moving memory (although you would use up more memory).

[supercat]

I'm a C64 lover, but those machines were not made to the same quality standard as Atari 8-bits.

 

The original VIC-II chip on my first C64 had defects on sprites 0 and IIRC 5 that would cause isolated pixels to fail to appear. Probably a node with either too much stray capacitance or a deficient pull-up resistor. One of my CIA chips wouldn't carry time from 'seconds' to 'minutes'. Did make Raid Over Moscow much easier, since the clock would never count down all the way.