Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

May I remind about something? One of the greatest games on the Speccy uses pure char(block) movement...

http://www.youtube.com/watch?v=8G4Q0Byqx1g

That's barely recognisable as R-Type though.. And the frame rate is truly abysmal..

 

Out of curiosity, has anyone ever built some demo or prototype of R-Type on the Atari 8-Bits ? That's something I'd love to see, and would answer a lot of questions for me ;)

Link to comment
Share on other sites

I don't see why a game with some PMG "attribute underlays" can't be done as a scroller.

 

Way to go would probably be to have the Players move with the Playfield and be assigned dynamically.

e.g. Player 1 appears on the right, moves towards the left and drops off, then gets reused.

Link to comment
Share on other sites

Out of curiosity, has anyone ever built some demo or prototype of R-Type on the Atari 8-Bits ? That's something I'd love to see, and would answer a lot of questions for me ;)

 

After seeing the Ripper demo and the multiplexed "free" moving multicolour "sprites" I'd bet that we can have really nice hires/lowres mixed sidescrollers. There are many tricks available to use different resolutions on the screen, plus a good count of moving objects.

Link to comment
Share on other sites

I just played Gauntlet on the A8. It is a truly HORRIBLE game, the graphics are really bad and monochromatic apart from your own player, the sound (what there is of it) is pretty abysmal and the music too is nothing special at all (sub VIC20 quality tune) and the speed...or lack of it..is terrible. It runs about 1/3 the speed of the C64 version.

 

If someone is doing a remake and the A8 is capable of better this is probably your priority ;)

Link to comment
Share on other sites

In a game? Please show me. ( Actually - are you suggesting that the Atari version would be a low res version of the Amiga screen? If so, I'd love to see that )

 

After G2F is actually supporting "all GPRIOR" functions ;)

 

 

Til then, a fair mockup with 9 colours... remember, it's about ambient colours.

 

Nice picture but why you use in some areas 1x1 hires pixel? (grass, mountains, tree, practically whole picture) And i think there is not possible in g2f, to many changes per line.

 

On C64:

convert from Amiga like you but first: to Hires 320x200 - no interlace, and second this is real picture not "fake".

stormlord.png

 

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" ;) or fake pictures.

We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

stormlord.zip

Edited by irwin
Link to comment
Share on other sites

May I remind about something? One of the greatest games on the Speccy uses pure char(block) movement...

http://www.youtube.com/watch?v=8G4Q0Byqx1g

That's barely recognisable as R-Type though.. And the frame rate is truly abysmal..

 

Out of curiosity, has anyone ever built some demo or prototype of R-Type on the Atari 8-Bits ? That's something I'd love to see, and would answer a lot of questions for me ;)

It's funny how people can rave about how great the speccy ports are when they look almost nothing like the original and the blocky limitations of the system are obvious in the game. The problem with many Atari ports is that the programmer tried to apply too much detail to everything and set the whole palette to shades of the same color.

Link to comment
Share on other sites

May I remind about something? One of the greatest games on the Speccy uses pure char(block) movement...

http://www.youtube.com/watch?v=8G4Q0Byqx1g

That's barely recognisable as R-Type though.. And the frame rate is truly abysmal..

 

Out of curiosity, has anyone ever built some demo or prototype of R-Type on the Atari 8-Bits ? That's something I'd love to see, and would answer a lot of questions for me ;)

It's funny how people can rave about how great the speccy ports are when they look almost nothing like the original and the blocky limitations of the system are obvious in the game. The problem with many Atari ports is that the programmer tried to apply too much detail to everything and set the whole palette to shades of the same color.

 

 

That original video of the speccy playing R-Type is a bit glitchy, pick another. Anyway people raved because the scrolling was quite smooth and the colours sort of worked for them (spectrum owners) and it had no more slow down than the ST version etc etc.

 

Personally even the Amiga version is just OK (all other home computer versions were inferior no arguments there) BUT the PC-Engine version is amazing considering it is an 8/16bit machine and that's the only version people should really be marvelling at IMO :)

 

(special note though for the proper arcade style parallax scrolling in level 2 of the C64 version, nicely done)

Link to comment
Share on other sites

The background on R-type isn't scrolling using char blocks..

 

Right. But the moving objects move in the fixed char resolution, regardless what's happening in the background.

What should stopp the A8 from doing the same (even in hires) and with added PMs, except the fact that no one ever wil do such project?

Link to comment
Share on other sites

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" ;) or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

Sorry, but this still misses the point.

 

It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

 

Perhaps an engine such as this shows promise... Two Moons and One Sun?

Link to comment
Share on other sites

But that IS the point Heaven...

 

There is NOT point criticizing a game (like stormlord) and presenting a silly static mockup as proof the A8 can do better than the C64!

 

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

 

This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

Sorry if that is harsh, but people need to get off soap boxes and get programming - if those unnamed people had spent the years they waffled on on this message board learning to code and demonstrating their thesis I would be impressed...

 

sTeVE

 

don't tell me...I spent years and still not get my antic 4 softsprite engine right... so how many skills do I need to get a full fletched over the edge g2f-scrolling game engine selfcoded? ;)

Link to comment
Share on other sites

So my table is correct?! :cool:

...

Atari literatures doesn't use PF4-- it's just background color. PF0..PF3 can alter their priorities in relationship to players but background is always last in priority.

 

Take an example, P0 covers 0..31, P1 covers 32..63, M0/M1 cover 64..79, P2 covers 80..111, P3 covers 112..143, and M2/M3 cover 144.159. Now even if you set all players/missiles to same color, you have choice of using PF0..PF3/BAK in 4*1 or 3 extra colors for a 8-color mode.

Basicly with rearranging x position we get two half a screen wide areas... (but don't have to... could set them all to same color).

Reason for setting all players/missiles to same color would be ability to draw one object anywhere on screen (no special cases, positions, regions... - more freedom to focus on game and not bother with position of graphics...)

...

To get an object to move around the entire screen using "OR" mode, one approach is that you can replicate the player (using 4X zoomed version) and just use 160*200*4 mode. This would make addressing simpler and also give you other players available for sprites. So just replicate say P1 five times and update it's GRAFn register so you get 4*12+6 = 54 cycles at most (since you can registerize a couple of STA/STX/STYs prior to kernel. So you would have just P1 of size 160*248 and be able to enable/disable any 4*1 of P1. When enabled, you get the P1 color + the 2 ORed colors based on PF0/PF1. So you get a uniform 160*240*7 mode and have P0 and P2/P3/P4 still available with their own 4 colors.

 

>I know there is a mix between P0 and P1 and so on... but there is no mix between P0 and P2 ? right ?

 

Rybags already answered this.

 

If you use narrow mode, you can replicate P0 and P1 on top of each other and get close to full screen coverage and a lot more color combinations. For static images, you don't need to have uniform color selectability throughout the screen, you just optimize player positions/colors based on the image and thus end up with a lot more colors than 16/scanline (use GPRIOR optimally).

Link to comment
Share on other sites

I don't know about a kernal in bitmap mode for a scrolling game though. Just too much CPU usage.

 

We also have the refresh cycles to contend with, only 31 cycles left in the visible area.

May as well disregard the last 8 of those, since they occur after the last replication is needed.

But we gain back in respect that you can have A/X/Y preloaded with the position/GRAF data you need for later at left of screen.

Also, you can coincide the first store with where the Player starts.

 

But, IIRC you might get 2 replications at best if the Players are adjoining. And even then, your Kernal needs to use Immediate mode on it's data which means it gets a bit memory hungry.

 

I think the use of 2 Players as underlays, using character mode and judicious level design such that horizontal reuse isn't required might be the key.

Link to comment
Share on other sites

...

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

...

I think this was also related to color depth not just palette. Having 16 colors and being able to show them all isn't that wonderful as having say 12 colors and being able to select them from 256. For general imagery, the probability that a scanline uses all 16 colors available to C64 is close to ZERO. But the probability that it uses 16 from 256 is high given shades most likely will show up (unless they are hand painted by C64 artists).

 

>This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

The thread has more to do with comparing hardware capability than belittling C64's software library. It does not rely ENTIRELY on shouting loudly nor random hardware performances. It's not based on ill founded opinions. You generalizing over the entire thread is your ill founded opinion. You're just slinging mud at something you haven't fully read/understood. You can't relate number of software titles available to hardware being superior.

Link to comment
Share on other sites

...

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

...

I think this was also related to color depth not just palette. Having 16 colors and being able to show them all isn't that wonderful as having say 12 colors and being able to select them from 256. For general imagery, the probability that a scanline uses all 16 colors available to C64 is close to ZERO. But the probability that it uses 16 from 256 is high given shades most likely will show up (unless they are hand painted by C64 artists).

 

>This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

The thread has more to do with comparing hardware capability than belittling C64's software library. It does not rely ENTIRELY on shouting loudly nor random hardware performances. It's not based on ill founded opinions. You generalizing over the entire thread is your ill founded opinion. You're just slinging mud at something you haven't fully read/understood. You can't relate number of software titles available to hardware being superior.

 

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from ;) The problem is realistically the Atari can't display more than 5 or so colours in a game with 50fps action and at a resolution of 160x200. The simple fact is for most games the C64 has an excellent selection of 16 colours to choose from. The only time you get an advantage is doing things like depth cueing or graduated skies like in say Elektraglide. On that kind of horizontal raster/Displaylist/Copperlist type effect the Atari does win because you can use the extra colours there, but in your average game say something like Bubble Bobble the Atari is backed into a corner as it just can't do any unique 16 colours everywhere on screen to replicate the look of the C64 version.

 

As I said BOTH machines were a compromise, Jay Miner fixed most of them in 1982/83 once the Amiga chipset prototypes were finished (although the sprite features were weak, a typical bugbear of Jay's work, at least he put in a really nice blitter solution) from the Atari A8.

Link to comment
Share on other sites

I always thought Atari in-game graphics sucks in comparism to most of the late 80s games for C64 (Last Ninja parts, uncountable Shooters and Jump'n'Runs I forgot the names of, etc.) but then I saw the newer Atari productions Crownland and Flowersmania and I have to admit that they look and sound pretty cool! Unfortunately they have been released nearly 20 years too late to have an impact to gaming industry ... but nevertheless many many kudos to the creators! Phantasic work guys!

 

It's interesting to see how people are still involved with developing/discussing stuff for obscure gaming/computer systems and keep the old (though useless ;)) A vs C vs Spectrum vs ... issues alive.

Edited by R4ngerM4n
Link to comment
Share on other sites

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from ;) The problem is realistically the Atari can't display more than 5 or so colours in a game with 50fps action and at a resolution of 160x200.

 

 

Popeye is one of the games written by totally unexperienced Coders. I guess, on the A8 you don't find many experienced ones. The most experienced coder it seems is Archer McLean. Then there is far nothing and then the Lucasfilm Guys appear. But they were also less experienced with resource saving coding and using optimisations for the A8.

 

It's similar to the 3D Games development. It started within the 70s and got broken almost for the timespan of 1983 to 1993, when the C64 dominated the home range.

You can bet to have good fps and colourful 3D games back in the 80s at home, if the A8 was the dominating machine and coders got more and more experienced with it.

 

And well 50Hz game.... popeye. You should have a look at the code, there are many loops for pausing. The whole game is more a wait state than a running code.

Link to comment
Share on other sites

To get an object to move around the entire screen using "OR" mode, one approach is that you can replicate the player (using 4X zoomed version) and just use 160*200*4 mode...... So you get a uniform 160*240*7 mode and have P0 and P2/P3/P4 still available with their own 4 colors.

...

If you use narrow mode, you can replicate P0 and P1 on top of each other and get close to full screen coverage and a lot more color combinations. For static images, you don't need to have uniform color selectability throughout the screen, you just optimize player positions/colors based on the image and thus end up with a lot more colors than 16/scanline (use GPRIOR optimally).

I don't need more than 16 colors... :)

Anything better than 5 colors means a game could be made better looking than 90% of atari's existing games....

 

160x240x7 looks interesting, and would love to see it...

But better to be in char mode... bitmap would slow things down...

Can you code it ?

 

Or make peace with limitations and make a great game like crownland with few DLIs, 5 colors per horizontal stripe, and more use of charbased software sprites....

 

Or what Rybeg said: "judicious level design such that horizontal reuse isn't required " ...

Link to comment
Share on other sites

On C64:

convert from Amiga like you but first: to Hires 320x200 - no interlace, and second this is real picture not "fake".

stormlord.png

 

But the tree is red, not brown, while on the A8 were more colours possible than you might see in the mockup.

 

Ok, now more brown:

stormlord2.png

 

Btw - Defects in your version: ;)

- you use 1x1 pixels

- you don't use real Atari colors

- simply: don't exist ;)

 

Very hard to compare pictures when one exist and other don't ;)

Link to comment
Share on other sites

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" ;) or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

Sorry, but this still misses the point.

 

It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

 

Perhaps an engine such as this shows promise... Two Moons and One Sun?

 

I don't agree with you. :P

First: In some games like adventures, rpg, others static screens games (like Elvira - see at bottom) , this converter would be very useful. And also to show what atari can do in gfx. C64 user in 30 seconds can convert any picture. On Atari this takes days and will never be like from convert-program. Easy to write: "look Atari can 23 colors in scanline..." and show only listing or "But the tree is red, not brown, while on the A8 were more colours possible" and show fake image (with in fact RGB colors - not Atari colors and 1x1 pixels btw. For me always red tree is better then NOTHING :) ) - but really hard to prove this and show truly great image. Computers invents to relieve us from very complex work. On AtariGfx there is no more complicated things then correct placed sprites, priorites, rasters (look in g2f - this is paint tool or assembly code ?)

 

Second: Imagine this: there is engine which allows you to place sprites on screen - in realtime on 8bit Atari. And this engine is very fast because it is only add-on to zx spectrum emulator and this emulator takes the most cpu time.

Look here: http://tiny.pl/36v2 (original in polish, translated via google)

When you looked on pictures maybe you think - not good - but this engine has a big potential. I ask author, great Atari Coder ;) - Mono - about PC version, he answer: Can be done and without Atari cpu limits, on PC can be check every possible sprites, colors combination, and other resolutions like 2x1 pixel - and in effect more accurate conversion.

 

Third: G2Font is very good gfx program but i know much better like Grafx2 or Cosmigo Pro Motion. Of course in this programs you can't save files in Atari formats - but when we have a converter, then we can paint in any program, final picture convert to *.g2f file and retouch and correct minor conversion errors. Overall, much easier way to produce pictures to games, demos instead fake pictures or famous "23 colors listing". Much easier way to show C64 user why Atari is better in gfx. :D

 

------

- sorry for my poor english.

- i am Atari user since 1986 and never bought C64

- others C64 30 seconds conversion:

elvira.png

 

utopia.png

Link to comment
Share on other sites

I don't think MacLean was experienced in the context of comparing him to the likes of some of the Synapse, Sirius and Broderbund programmers.

 

I think he excelled because he took the machine above the accepted limits of the time.

 

Another problem Atari had - in the early years it was hampered by "Lame Apple II ports". In the middle years, the good stuff came out. In the later years, it was forgotten against a background of ST, Amiga and emerging console wars by a bunch of new players.

Link to comment
Share on other sites

Btw - Defects in your version: ;)

- you use 1x1 pixels

 

The image is using 160 pixel. The pic is stored in double width for the correct aspect ratio.

 

- you don't use real Atari colors

 

Ofcourse they fit to the original palette.

 

- simply: don't exist ;)

 

That's right, it's a mockup as I already stated.

 

Very hard to compare pictures when one exist and other don't ;)

 

As well as red is not a brighter colour of brown. Except the tree is burning ;)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...