Atari v Commodore

[atarian63]

I think seriously the point is that there simply wasn't enough exceptional coders to replicate C64 standard hardware features using the more restrictive colour resolution of 160x192 displays and the smaller more restrictive PM graphics.

...

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8. 160*192 is restrictive if you don't learn how the rest of the hardware works.

 

But that is how you get 4 colours per 4x8 char block and then any colour within the Sprite system on top of that, which clearly produces some very colourful 16 colour games on the C64 as opposed to 4-7 colour games on the A8.

 

In the case of the A8 the majority of games look as you would expect of a machine that can do 4 colours total + basic horizontal colour graduations via DLIs. The problem simply is that there was no 3rd or 4th generation of games programmed for the A8 because the restrictions the hardware placed were very difficult to break and even then could only be used in certain situations etc.

 

No, the color changes are not limited to horizontal color graduations. GPRIOR mode 0 doesn't care if it's horizontal or vertical and GTIA modes allow vertical and horizontal color graduations. Most games did not use GTIA modes and even without resolution enhancement, the moving sprites would still be at 160*200 on GTIA graphics.

 

For fast action games you can't waste PM on colour underlays or start sapping CPU time just to equalize a deficiency in the hardware to try and replicate the more colourful look of a 16 colour on screen C64 game.

 

My problem is not with the movement resolution of the PMs, just the overall smaller size than the 24x21 x8 per scanline system in VIC-II plus the ability to mix sprite modes so you can have a hires sprite overlay and the colour for the character with an underlying sprite underneath. If you can get this into you multiplexing routine it provides sprite graphics as detailed as a Nintendo game in some ways.

 

Mixing modes and having any of the 16 colours within some basic restrictions gives you quite a lot of flexibility, the A8 Last Ninja project highlights these difficulties really that need to be worked around whereas on the C64 it's all down to an artists drawing ability and not much technical trickery to achieve the lush graphics of that game

 

However doing something like Rainbow Islands as well on the A8 as the C64 version would be difficult to say the least, simply a sign of the times.....the C64 chipset was designed for use as an arcade motherboard first and foremost and these game styles were the ones that lasted all the way up to Virtua Racer by SEGA with just bigger bobs/sprites more colours and faster movement...same basic game design though.

I believe arcade motherboards were superior at the time to what the C64 chipset had to offer.

 

The cost effective chipset was designed for Jack Tramiel by MOS in 1980-81 so in some cases I would beg to differ, plus there is an excellent versions of some of those early arcade games too like Rabbit Software's Skramble (different to Rockford's linked Skramble) and Ocean's Donkey Kong. Both damned close all things considered. You have to remember the R&D investment and changes in arcade chipsets could be measured on a monthly basis not yearly or half a decade like with Atari/Commodore home computers. What Jack was going for was similar to Nintendo's re-usable Playchoice 10 arcade board...profit <> cutting edge expensive monthly chipset designs.

maybe,but in 80-81 Atari ruled the arcades,it would have had little to no chance. Though the thought of commodore as a game system instead of atari seems kind of funny,like as in the companies changing places in the perception of the public. That would have been interesting.

 

Atari arcade chipsets had nothing to do with the limitations (PM graphics size/vertical unique colour resolution on screen) of the A8 chipset. Atari/Namco did make some good arcade games for sure...one of my all time favourite games Gauntlet is Atari after all

even that is a later title.Yep,gauntlet was revolutionary in it's time.I owned one for awhile.

[frogstar_robot]

 

...Majorly huge snip.

 

 

Atarian, you really really need to learn how to trim quotes or start doing it on the odd chance you don't. They nest like this

 

[Q]

Flamebait snarky post

[Q]

raging reply

[Q]

more snark

[slash Q]

[slash Q]

[slash Q]

 

 

Remove the lines that start with "quote" and get the matching closing tag on the same level. Repeat until your reply doesn't take up an entire page that consists of four other posts.

[atarian63]

 

...Majorly huge snip.

 

 

Atarian, you really really need to learn how to trim quotes or start doing it on the odd chance you don't. They nest like this

 

[Q]

Flamebait snarky post

[Q]

raging reply

[Q]

more snark

[slash Q]

[slash Q]

[slash Q]

 

 

Remove the lines that start with "quote" and get the matching closing tag on the same level. Repeat until your reply doesn't take up an entire page that consists of four other posts.

ok, Thanks!

[TMR]

The LMS commands can be set to result in a fully linear frame buffer for the screen. Why should there be a gap between both of the LMS parts?

 

Because there's got to be allowance for travel distance at the back end of each chunk of the screen if you're changing LMS addresses; you can't just set the first LMS to say $8100 so that the last byte of the first block of screen data is $8fff, when you bump that LMS to $8101 that last byte wraps to $8000 and makes things even more complicated. The most efficient way i can see of doing it is have the first LMS at $8000 and the second at $9000, the gap between the two slides on at bottom right as the existing screen goes off at top left.The gap that creates is the one i was talking about that has to be accounted for in the sprite plotting, column writing and so on.

 

i worked it out that a 48 byte wide screen at 80 pixels high has about five screens of travel distance on a single LMS... if i go down to 40 bytes wide there's about eighteen screens of travel.

 

you could use the Analmux MWP technique but I would first use LMS "gameboy style"... maybe would vote for 128 bytes scanlines? does it simplify calculations?

 

That simplifies the calculations greatly but takes quite a few resources away with it; you have to write off the cycles for those extra LMS commands to produce the long lines, there's the impact on RAM to consider (160 scanlines at 128 bytes a scanline is 20K!) and so on... my old character scroll routine was based on the same idea and i was quite surprised by how much pulling up an LMS on every eighth scanline took. MWP i still can't get my head around...

Edited September 12, 2009 by TMR

[TMR]

 

A beautiful vivid purple that burns your eyes. I'd rather stay with the C64 colour scheme

 

Matter of taste.

 

Exactly the same applies to the C64 palette, so now the Atarian's can stop going on about it can't they? =-)

[TMR]

Resampling introduces distortions and won't sound like it does on PC for sure (since frequency and bit depth is distorted). I already tried playing with 40+ consecutive DMA cycle latency and it's too much of a loss in quality not just some jitter of a few cycles.

 

How are you getting around the cycles being taken on LMS lines for the Atari version...?

[atariksi]

 

A beautiful vivid purple that burns your eyes. I'd rather stay with the C64 colour scheme

 

Matter of taste.

 

Exactly the same applies to the C64 palette, so now the Atarian's can stop going on about it can't they? =-)

 

No, he was talking about his opinion about colors for this game. Bigger palette is always OBJECTIVELY better. Some games may get away with it without having to rely on shades, but in this case the shading helps improve the image. If you got used to it with the colors instead of the shading, that's a subjective matter.

[atariksi]

Resampling introduces distortions and won't sound like it does on PC for sure (since frequency and bit depth is distorted). I already tried playing with 40+ consecutive DMA cycle latency and it's too much of a loss in quality not just some jitter of a few cycles.

 

How are you getting around the cycles being taken on LMS lines for the Atari version...?

 

Atari has pretty much uniform DMA cycles in graphics modes (including GTIA modes) so if the audio IRQ takes the similar amount of extra cycles due to DMA, then the latency is still pretty close to zero. The LMS, DL, and P/M DMAs actually help average things out since otherwise you have HBlanking with NO DMA cycles whereas screen area has every other cycle going to graphics DMA.

[Lazarus]

Matter of taste.

Exactly the same applies to the C64 palette, so now the Atarian's can stop going on about it can't they? =-)

No, he was talking about his opinion about colors for this game. Bigger palette is always OBJECTIVELY better.

But nobody was talking about a "bigger palette". We talked about the colors used in Draconus background gfx and despite the bigger palette they might be picked from, even the A8 version only shows 4 of them.

[emkay]

 

But nobody was talking about a "bigger palette". We talked about the colors used in Draconus background gfx and despite the bigger palette they might be picked from, even the A8 version only shows 4 of them.

 

Per screen, yes. The variation from screen to screen is where the game benefits from.

[emkay]

 

A beautiful vivid purple that burns your eyes. I'd rather stay with the C64 colour scheme

 

Matter of taste.

 

Exactly the same applies to the C64 palette, so now the Atarian's can stop going on about it can't they? =-)

 

Hm... But C64ers still write their profiling stuff in an A8 forum, not accepting any bit of other taste. I hope you see where the point of balance has moved

[Lazarus]

But nobody was talking about a "bigger palette". We talked about the colors used in Draconus background gfx and despite the bigger palette they might be picked from, even the A8 version only shows 4 of them.

Per screen, yes. The variation from screen to screen is where the game benefits from.

No it doesn't.

[emkay]

 

 

Because there's got to be allowance for travel distance at the back end of each chunk of the screen if you're changing LMS addresses; you can't just set the first LMS to say $8100 so that the last byte of the first block of screen data is $8fff, when you bump that LMS to $8101 that last byte wraps to $8000 and makes things even more complicated. The most efficient way i can see of doing it is have the first LMS at $8000 and the second at $9000, the gap between the two slides on at bottom right as the existing screen goes off at top left.The gap that creates is the one i was talking about that has to be accounted for in the sprite plotting, column writing and so on.

 

 

OK... Let's say I don't get what you are writing about, because you can set every LMS to every single byte of the 64K memory. You can even cross the whole screen by always setting LMS every line to the same memory location. So where is the "benefit" when NOT setting the screen to one linear framebuffer?

[emkay]

But nobody was talking about a "bigger palette". We talked about the colors used in Draconus background gfx and despite the bigger palette they might be picked from, even the A8 version only shows 4 of them.

Per screen, yes. The variation from screen to screen is where the game benefits from.

No it doesn't.

 

Ofcourse it does, ecxept you're colourblind.

[Lazarus]

But nobody was talking about a "bigger palette". We talked about the colors used in Draconus background gfx and despite the bigger palette they might be picked from, even the A8 version only shows 4 of them.

Per screen, yes. The variation from screen to screen is where the game benefits from.

No it doesn't.

Ofcourse it does, ecxept you're colourblind.

I'm not colorblind. I just don't see how "monochrome on every screen" and "monochrome purple" improves anything.

[emkay]

 

 

I'm not colorblind. I just don't see how "monochrome on every screen" and "monochrome purple" improves anything.

 

Well, and I have problems with grey stones reflecting green, where no green light source appears.

 

Having the stones in one colour, at least suggests subtl some coloured light source.

Edited September 13, 2009 by emkay

[TMR]

Atari has pretty much uniform DMA cycles in graphics modes (including GTIA modes) so if the audio IRQ takes the similar amount of extra cycles due to DMA, then the latency is still pretty close to zero. The LMS, DL, and P/M DMAs actually help average things out since otherwise you have HBlanking with NO DMA cycles whereas screen area has every other cycle going to graphics DMA.

 

i've only dabbled with samples, but would've thought that would be quite a distinct difference in timing between the two, hows it balanced?

[TMR]

Hm... But C64ers still write their profiling stuff in an A8 forum, not accepting any bit of other taste. I hope you see where the point of balance has moved

 

i think you'll find that most of the C64 guys are trying to code stuff on the A8... how bloody accepting do you want us to be?! How many times have i said i prefer Elektraglide or Mercenary or Attack of the Mutant Camels on the A8, how many hours have PeteD, Ste or i put into working on projects for the A8? We're not just turning up and taking the mickey here, in fact i think we're probably putting more effort into the A8 than some of the Atarians (that wasn't a dig at atarian, by the way)

 

Well, and I have problems with grey stones reflecting green, where no green light source appears.

 

Those graphics are bright friggin' purple, either the mountains are actually bright friggin' purple or there's a huge, bright friggin' purple lightsource that doesn't appear to be affecting the player's character!

 

Having the stones in one colour, at least suggests subtl some coloured light source.

 

Subtle?! It's bright friggin' purple!! (And green on a grey stone... could be moss or something. =-)

[emkay]

i think you'll find that most of the C64 guys are trying to code stuff on the A8... how bloody accepting do you want us to be?! How many times have i said i prefer Elektraglide or Mercenary or Attack of the Mutant Camels on the A8, how many hours have PeteD, Ste or i put into working on projects for the A8? We're not just turning up and taking the mickey here, in fact i think we're probably putting more effort into the A8 than some of the Atarians (that wasn't a dig at atarian, by the way)

 

 

You name yourself the magic roundabout, but that doesn't imply the world is rotating around you

There were several guys like Oswald or Rockford doing what I was writing about.

 

 

Subtle?! It's bright friggin' purple!! (And green on a grey stone... could be moss or something. =-)

 

The "friggin' purple is the result of a purple light source reflected by grey stones

And the moss seems to be a very stone one

[TMR]

OK... Let's say I don't get what you are writing about, because you can set every LMS to every single byte of the 64K memory.

 

You can't realistically use any byte because of the wrap arounds, the start of the line'd be fine but the back end would be somewhere else entirely.

 

And i'm trying to keep the thing as resource efficient as possible (partly because i need two screen buffers for what i want to do, probably assigning about 10K for each by the look of things); assuming a 160 pixel high playfield, my system needs three LMS lines and writes in 160 bytes of graphics data each coarse scroll, you're talking about 160 LMS commands (and since we're talking about scrolling by changing the LMS commands, all 160 will need updating each coarse scroll compared to the three i have) and that system uses long lines to do NES-like scrolling, which doubles the write in to 320 bytes per coarse scroll. Using long lines will also take more memory and those extra LMS commands take cycles, even my character-based long line scroller ate a startling amount of extra time compared to the single LMS one i'm currently experimenting with.

 

So where is the "benefit" when NOT setting the screen to one linear framebuffer?

 

Again, assume a 160 pixel high bitmapped play area, with two LMS commands for lines 1 and 81 (and yes, for the people who understand i know that isn't really practical but this is just theory). With horizontal scrolling enabled and in 40 column display, so 48 bytes per line for eighty lines makes each half of that play area $0f00 bytes long; to get a linear screen RAM, the first LMS is therefore set to something like $8100 and the second to $9000.

 

Fine and dandy for a still screen, but as i've been saying i'm doing the scrolling by changing the LMS values and that screen layout will totally break the moment that scrolling starts to happen; at the coarse scroll, the first LMS changes to $8101 and the second to $9001 but the last byte of that first chunk is now coming from $8000 and by the time the scrolling has travelled a screen in distance there are seventy nine pixel lines from $8130 to $8fff and one from $8000 to $802f before the second chunk starts at $9130. That'll make working out where the start of each scanline is a nightmare since some of them will be split between the end and start of the 4K block!

 

The only way to actually use a linear block of screen RAM is to not use the LMS at all and instead soft scroll all the bitmap data, but that's a vast chunk of CPU resources (granted it can probably be spread out over about thirty two frames on a pixel-per-frame scroller, but it's still a significant overhead) and requires two buffers so it doubles the RAM use as well.

[TMR]

You name yourself the magic roundabout, but that doesn't imply the world is rotating around you

 

No, it's the name of a television series.

 

There were several guys like Oswald or Rockford doing what I was writing about.

 

And you were replying to me rather than them.

 

The "friggin' purple is the result of a purple light source reflected by grey stones

 

Except it can't be because the player sprite isn't a green-ish purple for those screens, the player is a constant colour throughout meaning that the light source doesn't change either and the rocks in that screen must indeed be bright friggin' purple.

[STE'86]

ok this draconus thing is getting boring now.

 

THIS is why they are using cyan as highlight to the greys, it got nothing to do with moss, or light sourcing its because they are using CHARACTER COLOUR as the highlight colour as follows:

 

character color: CYAN

Multi 1: mid grey

Multi 2: dark grey

background : black

 

now on the c64 as anyone on here who has ever coded anything should know, the character colour can only be the first 8 colours. so they have NO light grey available so had to make do with cyan or white. and i absolutely guarantee u that the luminosity of white would have blown that screen right out.

 

HOWEVER. if anyone with alot of experience would have done these graphics, what we would have done is this:

 

Character colour: BLACK

multi 1: mid grey

multi 2: dark grey

Background: LIGHT GREY

 

then the graphics could have been created in slightly "negative" mode but the highlights drawn with background colour instead to give the full colour range. and the black background area filled in with character color (black).

 

NOW the Atari one in disgustly metallic purple does NOT look good either regardless of what u fanboys insist on. all they have done is tried to inject some vivid colour into a game that was going to look a bit mono in greys. and they have used the usual half arsed lazy way of doing it by picking a single colour and then generating the others by moving a luminosity slider up or down. they COULD have varied the colour mix for each tonal value to create a more colourful look but they havent. they were bone idle so it does look bloody MONO and nothing u can say will make anyone who looks at it think otherwise.

 

thank u

 

Steve

Edited September 13, 2009 by STE'86

[Crazyace]

Isn't the biggest problem with Draconus the drop in resolution - rather than the colour choice. Having to run software sprites rather than H/W shows the difference between the two systems more than anything else.

[TMR]

HOWEVER. if anyone with alot of experience would have done these graphics, what we would have done is this:

 

Character colour: BLACK

multi 1: mid grey

multi 2: dark grey

Background: LIGHT GREY

 

Or the "Uridium approach", as i thought of it for years... =-)

 

then the graphics could have been created in slightly "negative" mode but the highlights drawn with background colour instead to give the full colour range. and the black background area filled in with character color (black).

 

Or alternatively, design the thing to run in bitmap mode, then y'can go absolutely bonkers on the colour use and have white for the highlight on spikes to make them more... erm, pointy and so on; the only issue would be the pools of water would suddenly need a bigger overhead to animate but they could have more detail too so swings an' roundabouts.

 

The funny thing is, for all the atarians saying about how the A8 version of Draconus was done on the cheap, the C64 one really isn't a technical tour de force; it's something of an an idle boast, but i suspect i could do it without trying particularly hard whilst the soft sprites used for the A8 port are considerably more complex to deal with.

Edited September 13, 2009 by TMR

[emkay]

Except it can't be because the player sprite isn't a green-ish purple for those screens, the player is a constant colour throughout meaning that the light source doesn't change either and the rocks in that screen must indeed be bright friggin' purple.

 

 

You're right here. that would be the dot of the I . Playing with the colours, depending on the lightsource. The atari has enough colours to chose from ....