Atari v Commodore

[emkay]

 

 

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.

 

 

hm 16 colours ... huh?

 

 

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.

 

 

 

On the real A8 it looks ok. And the different colours were benefitful to view the game.

A good coder may have used charmode instead of "Gr. 7" .

[STE'86]

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 ....

 

what a great idea! make it look even more bloody mono than it does already.

 

thank god u dont do graphics, u would set the a8 back further than a 2600

 

Steve

[TMR]

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.

 

In the case of Draconus i'm starting to think that the drop in resolution was more to conserve memory than for the software sprites; the A8 version has to use a bitmap of some kind for the soft sprites but for a full res bitmap it'd be throwing seven or eight times the memory at the job as the C64 and the game is going down from a 64K to a 48K machine in the process.

 

At most i think it needs to handle six software sprites, the CPU overhead would double for 160x192 resolution but at the moment i can't see that being an issue for a (relatively) small number of moving objects. There are ways it could have been redesigned to use characters but it involves changing some of the attackers quite radically and those darkened background tiles would probably need removing too so you lose detail.

[TMR]

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 ....

 

It hasn't got enough colours to start working at that level, so it's pointless to even talk about it really. These are 8-bit games we're discussing, the "realism" and thinking about the lightsources in a scene went out of the window before the conversation started on both machines.

 

hm 16 colours ... huh?

 

In multicolour character mode (as has been explained a few times previously in these threads), the top bit of the colour nybble is used to say if multicolour mode is enabled or not (that's how the C64 can mix high resolution characters and multicolour horizontally on the same screen with no CPU overhead). Since there are only three bits left in the nybble, they can only represent eight of the sixteen colour values, so character colour is limited to the first eight (black, white, dark red, cyan, purple, dark green, dark blue and yellow in order); the multicolours and background all have the full sixteen.

 

Bitmap mode works differently, any 4 by 8 pixel cell gets to choose three colours from the sixteen as needed.

 

On the real A8 it looks ok. And the different colours were benefitful to view the game.

 

But it's still just as unrealistic having purple mountains or cyan brickwork as you were accusing the C64 version of being.

[popmilo]

...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.

...

Yes, they shoud have used bitmap mode and get much more color details out of it... Like cybernoid did...

And waves in water wouldn't be problematic... they can be done with sprites... Animation wouldn't take any cpu time. Thanks to c64, it has enough of them even for details like that

[emkay]

what a great idea! make it look even more bloody mono than it does already.

 

thank god u dont do graphics, u would set the a8 back further than a 2600

 

 

 

There's quite a difference between monochrome and coloured light. Just have a look at the artistic and just added lighting FX in the picture below. I could have chosen other colours, but I wanted to keep it most possible to the Amiga original.

 

 

The sky is pink toned, the water is blue based, and you find different hue steps for a better floating in the effect.

[TMR]

There's quite a difference between monochrome and coloured light. Just have a look at the artistic and just added lighting FX in the picture below. I could have chosen other colours, but I wanted to keep it most possible to the Amiga original.

 

And that's got precisely bugger all to do with what Draconus is doing on the C64 or A8; cyan highlights and purple mountains when nothing else is affected by the coloured light in the scene are caused by people making the best of what they have to hand, not

 

But just for you, i've "done an emkay" and made a mock-up of what the C64 version of Draconus could've looked like if the game used bitmap mode...

 

 

...although i did break with your tradition in that it doesn't add any CPU load to what the game is already doing during play for this apart from where there's water in the screens (which now i think about it is only going to at most quadruple what it's already taking) and the memory overheads are an extra 8K of screen and half a K of colour tables. i haven't changed any of the graphics data, merely simulated drawing them into a bitmap and setting attributes. There's nothing to stop the entire thing being in three greys either, i just liked the brown tiles in the distance and brighter spikes.

[STE'86]

what a great idea! make it look even more bloody mono than it does already.

 

thank god u dont do graphics, u would set the a8 back further than a 2600

 

 

 

There's quite a difference between monochrome and coloured light. Just have a look at the artistic and just added lighting FX in the picture below. I could have chosen other colours, but I wanted to keep it most possible to the Amiga original.

 

 

The sky is pink toned, the water is blue based, and you find different hue steps for a better floating in the effect.

 

right ok. so u think that looks good?

 

if indeed u were actually drawing that "for real" based on real life lighting effects, then see those grey sails? they would be a glowy pink colour due to their translucency and their original daylight white colour. and those green trees? not green anymore i'm afraid tinted with pink too.

 

u see its not just a case of whacking some colour on as lightsourcing, it all has to be reconsidered when u do that. daylight colours cannot be left unaffected by new light.

 

when u add coloured light, it usually does mean that everything else goes monochrome as all your colour perceptions in daylight go completely tits up with sunset.

 

 

and in watery winter light

 

 

i am really hoping at some point u will realise that i have done this for 25 years and do have a "vague" idea how it happens and stop making yourself look like a tit. (and no these aren't scans they are hand drawn on an st before u even start typing)

 

Steve

Edited September 13, 2009 by STE'86

[Rockford]

PLEASE stop posting screenshots of games from "www.shitc64andatarigames.com"

 

if u cant post something decent just give it up.

 

i think most of us have no real enthusiasm for comparing an abortion of a 64 game with an even bigger abortion of an atari one (or vice versa)

 

Steve

 

 

PLEASE stop posting screenshots of games from "www.shitc64andatarigames.com"

 

if u cant post something decent just give it up.

 

i think most of us have no real enthusiasm for comparing an abortion of a 64 game with an even bigger abortion of an atari one (or vice versa)

 

Steve

Problem is that he can not find any of the good c64 games on a8, to compare with

Steve, I'd like to compare only quality games like Cybernoid or The Last Ninja but I simply cannot. Popmilo is right (again ), since the Atari games library is very thin (especially when compared to C64) it limits me a lot. Anyway, there are still some quality games to come, but you know, I have my schedule and I want to stick to it. Even when a game is bad or boring, it usually looks and plays better on C64. That's why I show it. Pretty soon I am going to present a game that is connected with you As for Trolls and Tribulations it's not a bad game by any means. On Lemon it's got a very respectable score of 8.4, and for some people (like me) it's a classic - of course the C64 version, because on Atari it su..s some serious balls

Cheers

Edited September 13, 2009 by Rockford

[emkay]

 

i am really hoping at some point u will realise that i have done this for 25 years and do have a "vague" idea how it happens and stop making yourself look like a tit. (and no these aren't scans they are hand drawn on an st before u even start typing)

 

 

Well, this picture below was drawn in 1843 on the Abacus ....

 

I'm interested for your next joke. We're talking about C64 and A8... And, even IF you don't like my picture, C64 is not nearly able to do something like this graphics.

[emkay]

if indeed u were actually drawing that "for real" based on real life lighting effects, then see those grey sails? they would be a glowy pink colour due to their translucency and their original daylight white colour. and those green trees? not green anymore i'm afraid tinted with pink too.

 

 

Just to fulfill your nonsense, here the AMIGA original... The sails are grey there also...

Gras is even green...

[emkay]

An well, Powrooz is clearly the better artist on the A8, he did a good job for some lightsourced image:

Edited September 13, 2009 by emkay

[atariksi]

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.

 

Actually, that is the TOPIC I was talking about. That if someone keeps repeating examples of wider sprites, I'll keep saying inaccurate colors, slower, etc. So bigger palette is what decides whether colors are inaccurate or more accurate. You are actually changing the subject by talking about number of colors now. And it's not always good to substitute inaccurate colors for shades and claim "it has more colors". And your use of the word "monochrome" is misleading and vauge. Atari can do 16 shades (monochrome), 4 shades (monochrome), 5 shades (monochrome), and 2 shades, but the point is if picture looks better with the shades or without the inaccurate color, then it's better to have less colors.

[Rockford]

14 - 180

 

C64

C64

C64

 

The C64 version has better music, graphics and more colours. The throwing animation looks more natural too. C64 wins again

 

ATARI

ATARI

ATARI

[atariksi]

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.

 

It doesn't show the difference between the two systems, but shows a difference in implementation of the game.

[atariksi]

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.

 

If you were using a 4K buffer per line, you can re-use the same data on other lines and strip-update the part that wraps around. I don't see your point even if your example is unique-- LMS is better than having no LMS support.

[TMR]

Just to fulfill your nonsense, here the AMIGA original... The sails are grey there also...

Gras is even green...

 

He's not talking nonsense, you're using an Amiga original for your picture that makes similar mistakes to what you were talking about Draconus doing on the C64.

 

An well, Powrooz is clearly the better artist on the A8, he did a good job for some lightsourced image:

 

Oh look! Those grey bits in the bottom left hand corner are using a shade of cyan for their highlight, just like Draconus on the C64! Seems Powrooz, the better artist on the A8, agrees with Mick Owens where you didn't... tell you what, i'll say it again since you obviously missed or willfully ignored it the first time; these are 8-bit computers and the realism went out the window before the conversation started.

[atariksi]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

 

It's not realistically going to happen on the 64.. The 11Khz just sits badly against the badlines that occur.. And there's nothing you can do about that unless you want to get really messy You can abort the badlines, which means in text mode that you'll have the same character line and colour ram repeated down the screen, which isn't so useful since you run of out character sets very quickly.. In bitmap mode, it's a bit different, you can abort the DMA on each bad line, and the graphics fetches still take place, just no new colour fetches, so you end up with a 320x200 or 160x200 with no badlines, just in interrupts every 8 lines to abort the DMA.. You can have more colours, since you can allow a one off fetch of colour data, which is then held for every line of the screen, so in bitmap mode, you could have a vertical scrolling game with nice colour graduations going our horizontally, and still no bad lines.. This really isn't used very often and it's a royal bugger to setup

 

Practically, 7.8Khz is your limit.. The 64s CPU is just to slow to go to 15.6Khz using IRQs and having the screen on, *AND* having zero cycle jitter on the interrupt.. We have only 23 spare cycles on a bad line, which just doesn't cut it.. and the interrupt overhead is too much for a 1Mhz processor.. 7 cycles to enter, 6 cycles to preserve a register, then 9 to ACK + RTI from the interrupt (assuming your using the jmp $DD0C[1].. That's not including the jitter from the previous instruction, so add another possible 7 onto that, and we've got a minimum of 29 cycles, and that's before we've done anything.. There's just no practical way to deliver 15.6Khz audio on the 64, we just don't have the cycles for it.. And if you want to go for 8bit playback you can stick an extra 24 cycles onto each sample outputted, 30cycles if you go for 12bit playback, though the crappy 4bit volume stuff is of course only 4 cycles..

 

One option to do it though, is to have the sample playback in 8 line kernel chunks[3], but then you burn too much CPU time, and then you'll have to do whatever computation you need in the IRQs to make up for raping the CPU like that.. And the interrupt code on the last line to get the sample out, and to bail from the irq is critical to how much time you get left with because there's a big angry bad-line coming for your arse just cycles away.. But then you could squeeze 15.6Khz out of it, but (if I remember rightly the last time I tried this) I ended up with 12 (maybe 11) spare cycles per 8 lines of display, which isn't particularly useful to do anything with.. Lol, 468 cycles per frame left, enough to run a very minimal music driver for the task in question but fecking useless for anything else..

 

I know I've just handed a nice arsenal of ammunition to the hostiles, but that's life, and we all know we've got a crappy CPU on the 64, that's what actually makes life fun in some ways.. Already in the short few days that I've been playing on the A8, I'm feeling like I've got more CPU power than I know what to do with[4]

 

So there you go.. 11Khz (which to be fair doesn't sit nicely on the A8 either), just shouldn't be done, unless you switch the screen off.. There's far to much jitter you'll be fighting against.. 3.9Khz, 7.8Khz, 15.6Khz are your best options... And doing the bad line aborts[2], with samples playing (at non-scanline ratios) I don't think has even been done before, so maybe you'll be the first

...

Well, the 11Khz works fine on A8 with screen on. And there's no way to change the rate now as data is already done (2GB) and compressed into CD format and not all PCs support <11Khz.

 

>Another option is to disable screen DMA completely, and put the VIC into a state whereby it will only display sprites[5], then there's no badlines, and what you want is doable, but again the sprite DMA will cause jitter with you 11Khz desire, but with 15.6Khz it's very doable, especially if you fill the screen with sprites since it'll provide you with the interrupt stabilisation source you need through the 19cycle sprite dma block..

 

I wasn't really looking for cycle-exact coding just no badlines. I can live with a few cycles here and there from interrupt. Perhaps, if I set up a 160*200 sprite layer w/screen off.

[atariksi]

The audio is 11Khz+ digitized samples (it's already done so can't be resampled to fit to 7.9Khz or 8Khz that your SID sample player does) and Windows standard is 11Khz, 22Khz, and 44Khz. DAC Playback would interfere bad lines in this case.

It can always be resampled. But I'd suggest you simply set up a 11 kHz timer IRQ and live with the badline jitter.

 

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. You should try resampling 11Khz to 7.9Khz and see what it sounds like. Integer divisors work okay.

My professor at colege tought me to try to do it properly, and if it is not possible then cheat!

So I have two possible solutions for you

 

1. Proper method:

Use C64 routines discovered last year...

Example:

 

Easiest would be to make it play at 7.9KHz (It can be resampled... anything can be resampled...)

If not then we should try to make it play at 11KHz using sort of kernel routine ...

Badline Jitter doesn't influence sound much because technics involved are not simple "Put sample value in volume register every X microseconds...".

Sample values get "antialiased" and filters remove high pitch carrier...

 

2. Cheating

C64 has Audio in pin on Audio/video connector !

(A8 does not have one ? Does it count as C64 adventage ? )

 

Take the sound from PC directly to c64 and let it play it on TV

 

-----------------------------------------------------

Maybe you should open new topic about this with more details about it ?

I would love to help, and others would probably have some ideas...

 

Can't use the audio-in line. Can't change sampling rate without introducing distortions in the audio. Yeah, if you had scanline rate audio frequency, you can avoid badline jitter.

[TMR]

If you were using a 4K buffer per line, you can re-use the same data on other lines and strip-update the part that wraps around.

 

i'm not talking about one buffer per line, i'm trying to get just shy of half the bitmapped playfield (or in 160x96, the entire playfield) into a single LMS. i'll try one more time...

 

Assuming a single LMS, set to $8000 on a playfied that is 128 pixels across by 80 down; to scroll that to the left, i bump the LMS to $8001 and write in a column of data over $8028, $8050, $8078 and so forth down to $8c80 which have all just "arrived" on the right hand side of the screen. The next shift of the scrolling bumps the LMS value again to $8002 and the write in moves over a byte to $8029, $8051, $8079 etc. to $8c81.

 

Now double the vertical resolution of that example to the point where it needs two LMS commads for the two halves of the bitmap; in my case they're at $8000 and $9000 and after the first shift the write ins are $8028, $8050, $8078 and so forth down to $8c80, then it has to skip to $9028, $9050, $9078... if i set the screen up so the entire area is linear (set the first LMS to $8380 in this case) as emkay suggested, the last byte of screen for the first LMS command wraps to $8000 and y'have to start doing some truly hideous condition checks rather than the fixed distance step-overs i've come across.

 

I don't see your point even if your example is unique-- LMS is better than having no LMS support.

 

i've not been arguing for or against LMS for a while now, i'm trying to work out which method is the most efficient on resources to use them to scroll a playfield for what might turn into a game. At the moment, even with the special exceptions required for the two step-overs in the column and sprite draws, i think the system i'm playing with is the most efficient.

 

i've just had a peek under the hood of Zybex and its forcing 44 byte long lines (LMS per line, $2c apart) and keeping two buffers, i think for when the travel distance is exceeded. The 128 by 80 byte play area i was theorising above leaves enough space in the 4K block for a further 18 lines of data, so that's eighteen screens it can travel before the display wraps at the bottom right; assuming speeds of a pixel every other frame (same as Zybex, since that's a nice speed for a scrolling shoot 'em up) that'll take about a minute and a half to scroll past on a PAL machine, a reasonable length for a level.

[TMR]

I wasn't really looking for cycle-exact coding just no badlines. I can live with a few cycles here and there from interrupt. Perhaps, if I set up a 160*200 sprite layer w/screen off.

 

That still gets you ten chunks of sprite handling interrupt and an eleventh to jiggle the lower border to enable hyperscreen (just having the screen turned off will also hide the sprites, the border has the highest priority of anything on the C64), but if you run the sample player on NMI it'll take priority in those cases.

[STE'86]

if indeed u were actually drawing that "for real" based on real life lighting effects, then see those grey sails? they would be a glowy pink colour due to their translucency and their original daylight white colour. and those green trees? not green anymore i'm afraid tinted with pink too.

 

 

Just to fulfill your nonsense, here the AMIGA original... The sails are grey there also...

Gras is even green...

 

your point being?

 

mate YOU used it to ilustrate your point. i was asking YOU if you thought it was good.

I think its complete TAT that serveral of us could have done far better than on a 64. technically its very childish and it use of colour is rubbish, as i have posted before, ALL objects in that image should be affected by that coloured sky whereas NONE are. so to me its a piece of amateur rubbish.

 

so please dont try and turn your use of it back on me.

 

Steve

[atariksi]

@Atariksi:

Correct me, but do you do something else while playing samples and displaying pictures ?

Are you grabing sound and image info from data streamed on serial port ?

How much data is it and how does it work ?

That would make it even more difficult on C64...

 

Yeah, I am buffering the data from joystick port into a queue in the background. It's not a serial port, although that is also used during boot-up. It's 11025 nibbles/second for audio and 8000 bytes per picture. Pictures are lower priority so maintain audio playback continuously and put up images in the background as fast as possible.

[emkay]

mate YOU used it to ilustrate your point. i was asking YOU if you thought it was good.

I think its complete TAT that serveral of us could have done far better than on a 64. technically its very childish and it use of colour is rubbish, as i have posted before, ALL objects in that image should be affected by that coloured sky whereas NONE are. so to me its a piece of amateur rubbish.

 

LMAO

 

You think that any picture, you have done on the C64 does not look childish?

Particular your Lethal Weapon avatar shows two mature people in a childish style the kids of the kindergarden will recognize it.

 

It's apparent that the low limited fetures of that old machines always will look somehow "childish" ... except some scans shown in gr. 9 on the a8.

And, well,if graphics on the C64 don't look childish, it looks like some lsd driven crazy Amok-runner has drawn them.

 

...

Edited September 13, 2009 by emkay

[STE'86]

mate YOU used it to ilustrate your point. i was asking YOU if you thought it was good.

I think its complete TAT that serveral of us could have done far better than on a 64. technically its very childish and it use of colour is rubbish, as i have posted before, ALL objects in that image should be affected by that coloured sky whereas NONE are. so to me its a piece of amateur rubbish.

 

LMAO

 

You think that any picture, you have done on the C64 does not look childish?

Particular your Lethal Weapon avatar shows two mature people in a childish style the kids of the kindergarden will recognize it.

 

It's apparent that the low limited fetures of that old machines always will look somehow "childish" ... except some scans shown in gr. 9 on the a8.

And, well,if graphics on the C64 don't look childish, it looks like some lsd driven crazy Amok-runner has drawn them.

 

...

 

by technically childish, i mean the composition is childish, the execution is childish and amateur,any pro artist will know that to make that picture hang together as a whole u would have had to flow the sky colour into all the other elements on that screen. which is the the point i have been making for 3 posts and which u are being deliberately obtuse and ignoring because its indefencible.

 

such technical aspects are required to make a good image regardless of what media u use to paint in. ow u get the "cut out and stuck on" look that ship has

 

did i say anything about the technical specs of the machine? NO.

 

and for someone who it appears has done fck all on their super machine of choice (with the exception of a truly fcking awful Fist tune?) in the last 25 years it does make me smile that u can criticize anyone elses efforts

 

Steve