Asteroids Deluxe?

[MrMaddog]

There was the assumption that any 16-bit computer could do 8-bit (or even 16-bit) games easy because of the extra power.

 

Ok, we know how blocky arcade ports were on 8-bit computers due to the limitations of video resolutions.  Then we move up to the ST when it first came out and use that for playing the official ports made by Atari Corp.

 

I guess a most likely issue would be that since it was early days, the graphics looked like they were drawn on DEGAS or NeoChrome which, though better than 8-bit, still had a cartoon look to them.  And the "higher" resolution of ST Low Rez also made it 'different' from the 8-bit graphics we were used to.

 

In fact, when I had the ST version of Missile Command (which changed colors like the 2600 cart), I couldn't get pass this one level that had a yellow sky that covered up the missile trails which were hard to see on the screen being only a single pixel wide.

 

All the other ST ports done by Atari had something "off" about the graphics and I guess that's why they had a bum rap.  Of course things looked much better in high rez if you happen to have a monochrome display...

 

[Keatah]

In many 16-bit games the sprites felt off. Sort of flat and square. Something read from the memory and pasted to the screen. The fact that most sprites in 16-bit rigs were drawn with a paint program and pasted into the game logic meant that the interaction between the sprite and other game elements seemed of a lesser quality than what happened on 8-bit machines.

 

In 8-bit games the sprites seemed very well integrated into the game program. A part of the program. Not just something retrieved from memory and rendered on the screen at point x,y.  Collision detection seemed sharper and obeyed the boundary of the visible image of the sprite better. Not a square box around the sprite. This was more evident if the sprite was animated.  Or so it all seemed.

[Lynxpro]

17 hours ago, ParanoidLittleMan said:

I don't think that in 1985 Atari developers, sales department wanted to go with some more colors at once (like 256 instead 16) graphic solution. Of course main reason was extra cost of it. It is not big deal to develop such graphic HW logic - but at that level of integration that would cost pretty much. Remember that TOS was in 6 ROM chips in first Atari STs - 'till 1987, when came first ones with more integrated, only 2 chip TOS ROMs.

Of course, because then it was what costed less. 

Other thing is that 256 colors at once means 2x more video RAM at same resolution, so would be 64 KB for 320x200 . And worst: in that case CPU must've have stop cycles, actually lot of them, since whole design is done with RAM bandwith enough for 32 KB video RAM and CPU (shared 1:1 during line draw) . So, when actually more CPU power is needed - for bigger video RAM just opposite would happen - less CPU power.

Sure, some will say now - they should use faster RAM, faster CPU ...     Sure, I would like Atari ST with 64 MHz CPU in 1985 - and I would like it only via some shop window, with indicated price of 10000 bucks.

All this is matter of compromise.  They had in mind average users, average needs, not some audio or lot of colors fanatics.

 

That's an assumption about it taking more resources. I haven't had a chance to inspect an [Atari Games Corp] Atari Systems 1 arcade board to document how much RAM Atari Games' used for video processing on the likes of Gauntlet, Gauntlet II, Paperboy, and Road Runner, amongst others. At any point, Atari Corp could've had empty spots on the motherboards as an option to add video RAM had the SHIFTER been designed to support optional VRAM separate of the main RAM. Atari Corp certainly slapped a lot of video RAM in their Atari PCs at and below the same price point as the STs. And it's not a case of Atari Games using a much faster - or much more capable - CPU since they were using 68010s at 7.16MHz.

[Lynxpro]

13 hours ago, youxia said:

I must say, I've heard quite a few "out there" comparisons in my day, but hearing this - from a presumably ST fan - really wins the  day. People who have never seen what TOS/GEM looks like (or better yet, how it behaves) are welcome to have a gander ?

 

@ParanoidLittleMan: for once we agree...

 

Then you've only listened to Amigans because plenty of ST owners thought the Amiga GUI was fugly compared to GEM. And it was. 4 colors at 320x200. Ridiculous.

[Keatah]

640x200

[ParanoidLittleMan]

15 hours ago, Lynxpro said:

 

That's an assumption about it taking more resources. I haven't had a chance to inspect an [Atari Games Corp] Atari Systems 1 arcade board to document how much RAM Atari Games' used for video processing on the likes of Gauntlet, Gauntlet II, Paperboy, and Road Runner, amongst others. At any point, Atari Corp could've had empty spots on the motherboards as an option to add video RAM had the SHIFTER been designed to support optional VRAM separate of the main RAM. Atari Corp certainly slapped a lot of video RAM in their Atari PCs at and below the same price point as the STs. And it's not a case of Atari Games using a much faster - or much more capable - CPU since they were using 68010s at 7.16MHz.

It is not assumption. I even explained it little - the key is shared RAM between CPU and screen draw. And it is pathetic talking about how much RAM games use for 'video processing' . Screen video is always 32 KB. How all it is processed depends mostly from how game is coded. And that's the key here.  

It is easy to came with diverse ideas for extra RAM slots, etc . And don't think that designers were not aware of such solutions . As said, that would increase manufacturing costs a lot - for limited count of buyers.  Atari ST even does not have general expansion slot, common on home computers of that time . They saved even on it - what was bad idea by me, and caused later inconsistency with expansion slots - one type in Mega ST, other one in TT and Mega STE (VME bus - really bad idea if you ask me), and of course different on Falcon (that one has real reasons to be different) .

 

So let see very good example how it went:  Atari ST design was from start with blitter in mind. And it was present first in Mega STs, in 1987 . The reason to omit it in first versions was:  time needed for developing it, production costs - surely gone lower in 2 years - it is high integrated chip.

And blitter was present in STFM machines too from 1987, STE, Falcon  ..  The real bad thing is that game programmers just did not take effort to use it, except few cases.

So, very popular game   Great Giana Sisters. Published first in 1987 - surely could not do blitter support then. However, there is second Eu release in 1988 (French, UK) - did they change anything ? No. While game screams for scrolling.  And yes, blitter can solve it - pretty smooth one.

How I'm so sure in it ?  Before someone again says something very stoopid - because I solved it. For free. Those who programmed it for money - did they care about it ? Probably did not expect that it will make so bigger sales that is worth.  OK, Giana is special case, and was removed from sale because similarity with some famous game - I don't know when was it exactly.  And even if we could think that it could be reason for not being motivated - here is another, similar case:  Hard & Heavy - from practically same team, year 1989 . And of course, no blitter usage.

Indeed, Atari corp. is partially responsible for poor blitter usage - for instance because not so good DOCs, as usual .

 

To the end of this:  those blaming Atari ST HW design for not having (good) scroll in most of games - they are wrong. It was said that fast CPU and lot of RAM can replace special graphic HW, present in XL, C64 (designed by same man, Shiraz Shivji)  - and that's pretty much true.

There are games with excellent scroll, working well without blitter too, on 512 KB machines - Heartland 2000, Terry's Big Adventure, Potsworth & Co ....   The key is in programming - and that needs lot of time, experience, new ideas . Much more on much more complex, 16-32 bit CPU than with some 8-bitter.

[zzip]

6 hours ago, ParanoidLittleMan said:

And blitter was present in STFM machines too from 1987

No it wasn't.   At least not in the 520STfm we had.

 

[zzip]

13 hours ago, Keatah said:

In many 16-bit games the sprites felt off. Sort of flat and square. Something read from the memory and pasted to the screen. The fact that most sprites in 16-bit rigs were drawn with a paint program and pasted into the game logic meant that the interaction between the sprite and other game elements seemed of a lesser quality than what happened on 8-bit machines.

As opposed to?  Aren't all sprites read from memory and pasted to the screen?   What's wrong with drawing them in a paint program?   It gives better-looking results than the 8-bit sprites that were often drawn on graph paper.   It all comes down to coding.   Some games integrate them well, and others don't.

 

13 hours ago, Keatah said:

In 8-bit games the sprites seemed very well integrated into the game program. A part of the program. Not just something retrieved from memory and rendered on the screen at point x,y.  Collision detection seemed sharper and obeyed the boundary of the visible image of the sprite better. Not a square box around the sprite. This was more evident if the sprite was animated.  Or so it all seemed.

And 8-bit sprites were notorious for flickering when too many were on the same line.  They often used a different color palette than the background and stood out like a sore thumb,   sometimes you had weird XOR effects as sprites crossed over the playfield.    Collision-detection is a programmer issue.   If they make the entire square be the collision area, that's lazy.     Hardware collision detection isn't the end all either,  sometimes you need more granularity--  should a player drown if only their feet touched the water?

 

This Atari 8-bit baseball game looked amazing for its time (still does IMO), except that the players sprites look out of place:

 

The otherwise excellent Atari 8-bit Donkey Kong has sprite XOR type issues when crossing other objects,  notice how you can kind of see the ladder through the foxfire near the middle of the screen,  this is due to a limited number of hardware sprites so software sprites are used as well with imperfect rendering

 

You can see a similar effect in Hard Hat Mack in the sprite left/center.   I think this is the Apple II version, but I've seen the same effect on other platforms.

 

 

[TGB1718]

35 minutes ago, zzip said:

And 8-bit sprites were notorious for flickering when too many were on the same line.

That's only when sprites are multiplexed and you have the same sprite being displayed twice on the same line.

37 minutes ago, zzip said:

As opposed to?  Aren't all sprites read from memory and pasted to the screen? 

Not exactly, pasting to the screen to me means getting some data, find the screen and paste the data there.

Hardware spites have no connection with the screen, yes they are in memory, but the hardware takes care of placing

the image on the screen defined by a number of hardware registers (a true sprite by definition).

 

[ParanoidLittleMan]

10 hours ago, zzip said:

No it wasn't.   At least not in the 520STfm we had.

 

I did not say in all of them.

 

And TGB1718 is right about HW sprites.  For instance C64 has small size video RAM, and therefore limited color number in smaller area.  While HW sprites can have much more, and are small area. That's not possible with pasting data in screen RAM . Although saying 'have no connection with the screen' - they have, considering position on it, and to achieve that it matches timing is relevant - replacing background pixel(s) with sprite pixel(s).

 

Blitter in STs can draw sprites much faster than CPU code, and it is 'pasting to the screen' - but there are diverse ways of doing it. Like combined with shifting (for getting sprite positioned few pixels left or right) - and that is what is slow with CPU only draw.

[zzip]

1 hour ago, TGB1718 said:

That's only when sprites are multiplexed and you have the same sprite being displayed twice on the same line.

I know that,  but it was common to experience the flickering due to the limited number of hardware sprites most of these systems had.

 

1 hour ago, TGB1718 said:

Not exactly, pasting to the screen to me means getting some data, find the screen and paste the data there.

Hardware spites have no connection with the screen, yes they are in memory, but the hardware takes care of placing

the image on the screen defined by a number of hardware registers (a true sprite by definition).

I know, I've programmed them.   You still have to store a bitmap in memory for a hardware sprite, you still have to draw the data in it somehow- whether that be image editor or graphing it by hand.    Hardware sprites are nice to have on 8-bit systems because the number of cycles required to draw a software sprite with proper transparency is a bit much.

 

However due to the limited number of hardware sprites, software sprites were often required in games as well,  and they'd XOR against the background which requires many fewer cycles than proper transparency,  hence my Donkey Kong  and Hard Hat Mack examples.

 

Hardware sprites aren't really needed on faster computers because they can handle the transparency and do software sprites of unlimited size and many colors.   Now maybe it could be argued that the ST wasn't quite fast enough for that, and the hardware assist of the blitter was required.   True the blitter helps,  but there are still good and bad examples of sprites in games on non-blitter STs,   a lot comes down to how efficient the drawing routines are.

41 minutes ago, ParanoidLittleMan said:

And TGB1718 is right about HW sprites.  For instance C64 has small size video RAM, and therefore limited color number in smaller area.  While HW sprites can have much more, and are small area. That's not possible with pasting data in screen RAM . Although saying 'have no connection with the screen' - they have, considering position on it, and to achieve that it matches timing is relevant - replacing background pixel(s) with sprite pixel(s).

Yes all the 8-bits are very restrictive with color placement due to tight memory, and using sprites to get more color was common.   

16-bit can throw 16 colors or more on a line and so it's less critical to need sprites to add colors.

Edited July 27, 2022 by zzip

[Keatah]

4 hours ago, zzip said:

As opposed to?  Aren't all sprites read from memory and pasted to the screen?   What's wrong with drawing them in a paint program?   It gives better-looking results than the 8-bit sprites that were often drawn on graph paper.   It all comes down to coding.   Some games integrate them well, and others don't.

I'll need to rephrase it somehow. It's an ineffable quality.

 

11 hours ago, ParanoidLittleMan said:

It was said that fast CPU and lot of RAM can replace special graphic HW, present in XL, C64 (designed by same man, Shiraz Shivji)  - and that's pretty much true.

This seems to be true to today. And it's so much more versatile and allows for better migration of software across many CPU speed grades. I would argue this is one huge factor that helped PC and Mac rise to dominance.

[zetastrike]

How many ST games run at 50 or 60 fps?  The best made ones manage to hit 25, most run at what... 6 or 12 fps?  I don't think a 8mhz 68000 drawing the graphics on its own is good enough.

[ParanoidLittleMan]

9 hours ago, zetastrike said:

How many ST games run at 50 or 60 fps?  The best made ones manage to hit 25, most run at what... 6 or 12 fps?  I don't think a 8mhz 68000 drawing the graphics on its own is good enough.

And again, for the zillionth time factor of SW, good programming is just totally disregarded.

[zzip]

I think were a lot of 16-bit ports go wrong is that the developers will do things because they can, but will lose the soul of the game in the process

 

For instance, the Ultima games I-V had a particular aesthetic that suited it well.  It was very stylized, and based on the Apple II color palette, and most ports tried to stay true to that aesthetic to the extent the hardware allowed:

 

 

But not the Amiga/ST versions, lets throw colors everywhere because we can!   The end result of Ultima III doesn't look so good IMO and feels like a cheap Ultima knock-off

 

 

Another example,  Alternate Reality The City.   Here the Atari 8-bit version is the original,  it really pushes that hardware and create a very stylized scene of a city that feels kind of gritty.    The ST version of the city looks too clean,  all the lines are perfect,  any sense of grittiness is gone.   Looks like the scene was drawn by amateurs to be honest.   Sure it uses the higher resolution and color palette of the ST, but not very well.   The Amiga and PC version of the game have similar issues

 

 

And I can find other examples.   It's not that I'm against 16-bit enhancements, but they have to be done by someone who knows what they are doing and why.

[ParanoidLittleMan]

For me Atari ST city image is much more proper, mostly because of lot of grey, greyish . That 8-bit one is with too much contrast and oversaturated yellow, sky blue. Probably the reason is less color nuances available.  So, I think that some people just don't get some things. But thanks zzip, this was really good idea putting those 2 screenshots together ...

 

And one thing what I did not see mentioned lately:  the price factor. Sales of Atari 8-bit home computers (XL and others) were not good. In pre-Tramiel era too. And we know that company bankrupted.  I remember price of 2200 DEM when C64 was about 1000 . So, it is easy to talk how good it was solved in Atari 8-bitters.  I think that most of people was not ready to pay so much for basically gaming computer, known about poor Basic.

 

[+DarkLord]

I played Ultima 3-5 on the Atari 8bits and on the ST.

 

I played the game originally on my 800XL, then bought

it again for my ST when it came out. I was like, wow!,

the colors are so much better!

 

While I love the games on both formats, I much prefer

the ST version over the Atari 8bit version...

 

I have no problem with the colors at all (until we get

to Ultima VI, but that's another story).

 

[MrMaddog]

On 7/26/2022 at 7:37 PM, Keatah said:

In many 16-bit games the sprites felt off. Sort of flat and square. Something read from the memory and pasted to the screen. The fact that most sprites in 16-bit rigs were drawn with a paint program and pasted into the game logic meant that the interaction between the sprite and other game elements seemed of a lesser quality than what happened on 8-bit machines.

 

Well that explained why many early ST games looked like they were done in DEGAS or NeoChrome cause they were.  And w/o the custom hardware to handle sprite graphics like the Amiga, the ST has to do all the cut & pasting of graphics using the CPU.

 

But it eventually got better with later games, especially from the UK, where the art style got better.  Of course it could be argured that the brilliant 16-bit graphics covered up shallow gameplay (ie. Xenon 2) but the games were still fun for those who bought the 16-bit machines.

 

 

Edited July 28, 2022 by MrMaddog
Well * I * liked playing them anyway! :)

[ParanoidLittleMan]

Well, after lot of posts here talking about how Atari ST is bad for gaming and like, let see what we 'learned' here:

 

1. Atari ST's CPU is just too slow to draw sprites on screen with enough speed for some 2D game, so frame rate must be bad overall .

2. More color nuances of ST (512 of them) is worse than available some 32 with 8-bit computers

3. Those who ported from arcades, 8-bit home computers have bad taste

4. Drawing sprites on computer what can have any of 16 colors at current palette for any pixel is ... I will paste here whole statement from one of above 'enlightening' post:   "In many 16-bit games the sprites felt off. Sort of flat and square. Something read from the memory and pasted to the screen. The fact that most sprites in 16-bit rigs were drawn with a paint program and pasted into the game logic meant that the interaction between the sprite and other game elements seemed of a lesser quality than what happened on 8-bit machines. "   

 

Technical facts: 

1: MC68000 at 8 MHz and no wait states is at least 8x faster than some 6502 at 2 MHz . Partially because clock rate, then 16 bit data bus, complexer operations like multiply, divide  ...  There is plenty of games for Atari ST with pretty good frame rate, even with lot of sprites, scroll, etc .  And yes, there are plenty of bad ports - but what it means ? Not so well programming in first place.  Or not using well potentials of HW .

2-3: How those who ported dared to change colors ? Should keep all it same, as well other things in games. Because people did not buy Atari ST to see something new, better details, new user interface and like .... No ! Conversion from 8-bit must look and be controlled same ! 

Here to add that I had C64 and even XL800 for some time - but sold them because did not see that games look and play so good. Surely was better than on Sinclair Spectrum (what still have), but prices were much higher too. 

And here is good example of some different kind of game: flight simulator.  Sublogic FS2 worked pretty well on Atari ST - relative good frame rate, details, colors, etc .  I saw Sublogic FS2 or 1 (don't remember) running on C64 (not mine), and it was slide show rather - yeah, to slow CPU . And we could list here lot of games just too complex for 8-bit home computers. Only 1: Dungeon Master . Much more interesting than shooting some cosmic crap ?

4: I guess that those doing console, 8-bit game graphic, sprites did not use some kind of paint program - no they just typed in binary data for sprites and background !   Pasting to the screen - that's not exactly as pasting of text.  Sprite definitions have usually 2 parts:  sprite self data and mask data - later assures that background pixels will be visible when not covered with sprite data. So, that flat and square - please learn to crawl before learn to walk.

Interaction with other game elements:  that's matter of SW and effort.  I saw C64 games with pretty poor collision detection, despite some kind of HW support for that.  All in all - just silly prejudices that if it is in HW must be waaaaaaay better and faster. SW is slower, but not so much, so on 8 faster CPU can do it with even better speed, and it is way more versatile, because is 'soft' ? 

[zzip]

On 7/28/2022 at 2:47 AM, ParanoidLittleMan said:

For me Atari ST city image is much more proper, mostly because of lot of grey, greyish . That 8-bit one is with too much contrast and oversaturated yellow, sky blue. Probably the reason is less color nuances available.  So, I think that some people just don't get some things. But thanks zzip, this was really good idea putting those 2 screenshots together ...

The Atari 8-bit was the platform the game was developed, and the style of the game leaned heavily on using "color washes" as backgrounds created using DLIs, it was meant to be colorful and high contrast.   I can post more screens showing this.

 

Other 8-bit system would struggle to reproduce these aspects of the graphics because it was so geared towards the Atari graphics system.   However the ST and Amiga were both more than capable of doing it,  instead they just completely change the aesthetic.   The color palette used in the ST version is very bland,  the contrast is almost non-existant, the UFO doesn't even stand out very much in the scene.   And the city looks like it was drawn by an amateur, or at least used primitive drawing tools..  Everything is clean, parallel lines, simple fills.

 

On 7/28/2022 at 10:00 AM, DarkLord said:

I played the game originally on my 800XL, then bought

it again for my ST when it came out. I was like, wow!,

the colors are so much better!

 

While I love the games on both formats, I much prefer

the ST version over the Atari 8bit version...

 

I have no problem with the colors at all (until we get

to Ultima VI, but that's another story).

I love aesthetic Lord British created,  so I don't like when they take liberties with it. 

The Atari 8-bit version is less than perfect due to artifact color issues

But on the ST-  Ultima II is a GEM app, doesn't look right at all

Ultima III is the worst color wise,  Ultima IV is a little more restrained.

I think Ultima V is the first time an Ultima game looks right on the ST

 

Commodore 64 versions shows how more colors can be added to Ultima without violating the aesthetic.   

 

These days, if I was to play, I use a heavily-patched PC version 

[+DarkLord]

Guess it's just a matter of "opinion" then, because I think the 8bit

versions suffer when compared to the ST versions.

 

Thanks.

 

[Keatah]

On 7/27/2022 at 3:15 PM, zzip said:

Given the choice between the two I'd rather play 8bit. The ST version appears sterile and amateurish. The 8bit even has weather! Look at the clouds! Or are those mountains? Let your imagination engage! A blue gradient sky, rooftop details. Buildings with texture. A green prairie field..

 

ST is capable of all that and more. So why not do it?

[Keatah]

9 hours ago, ParanoidLittleMan said:

And here is good example of some different kind of game: flight simulator.  Sublogic FS2 worked pretty well on Atari ST - relative good frame rate, details, colors, etc .  I saw Sublogic FS2 or 1 (don't remember) running on C64 (not mine), and it was slide show rather - yeah, to slow CPU . And we could list here lot of games just too complex for 8-bit home computers. Only 1: Dungeon Master . Much more interesting than shooting some cosmic crap ?

Yes it did. FS2 was good on Amiga/ST.

 

I argue that FS2 shouldn't have been made on any 8-bit. Just not enough CPU power available. Oh at the time we thought it groundbreaking and sophisticated. But we never played with it much. There was no sense of progression from one airport to the next. We spent much more time with FS1.

 

Sometimes I thought it should've been packaged with an accelerator card (for Apple II).

[youxia]

People arguing about colours is always fun to watch ?

 

 

Edited July 29, 2022 by youxia

[zzip]

25 minutes ago, Keatah said:

Given the choice between the two I'd rather play 8bit. The ST version appears sterile and amateurish. The 8bit even has weather! Look at the clouds! Or are those mountains? Let your imagination engage! A blue gradient sky, rooftop details. Buildings with texture. A green prairie field..

 

ST is capable of all that and more. So why not do it?

I think they are mountains.   The ST's mountains are all pyramid-shaped, adding to the amateurishness of it.

 

The 8-bit version required a lot of skill to create,  extensive DLI use that scrolls with the screen,  you hear the sounds of the city before the UFO descends into the scene,  then when the UFO takes off and you follow it way up into the atmosphere into space where it makes a turn and jumps into hyperspace.

 

The ST version uses no vertical scrolling at all, the UFO pops into existence and leaves the screen (you don't follow it),  then it just jumps to the starfield/intro.   It is very low effort compared to the 8-bit.  ST was perfectly capable of doing it just as well if not better.   It was probably ported on the cheap.

 

26 minutes ago, Keatah said:

Yes it did. FS2 was good on Amiga/ST.

 

I argue that FS2 shouldn't have been made on any 8-bit. Just not enough CPU power available. Oh at the time we thought it groundbreaking and sophisticated. But we never played with it much. There was no sense of progression from one airport to the next. We spent much more time with FS1.

8-bit FS2 was one of the worst letdowns for me.   It had a good writeup in the magazines, but when I played it, it was like what?  1-2fps?   hardly any scenery --  two buildings in all of Chicago?

 

The ST version was a nice surprise.   Much better framerate for sure (though not great).  I liked the picture-in-picture feature.   But the main reason I liked it was it was a big improvement over the 8-bit.    Overall it was still kinda lacking in scenery.