Atari v Commodore

[atariksi]

It's better to have a DL do the mode changes since it's only 1 cycle of DMA; and there are more options to change to on Atari.

1 cycle assuming you change the gfx mode all the time. But look at the average game: Most only change the mode 2 times per frame (playfield + scores), many others do not change the mode a single time. So it's ALL display list cycles of a frame vs ~2 mode changes via CPU.

It's not that many DMA cycles even if the mode repeats since for default text mode, the entire display list is 32 bytes and then Graphics 2 it's even less.

I know how much cycles/bytes a DL needs. But you were trying to make it a "look we change mode with 1 cycle and you need much more"-issue. What I was trying to explain to you: A "mode change" of the DL doesn't take 1 cycle because you don't change the mode every mode line. You repeat a mode line over and over again, and then somewhere at the bottom you start the same again repeating another mode line over and over again. So in the end you have the entire cycles of the DL for just 2 mode changes.

 

That's the average case as you see in a majority of games, often with DLIs at the mode changes to also change color registers. If you do those color register change DLIs and compare it to a similar case on C64 (2 mode change + color change raster IRQs) the mode changes eat 2x 6 clock cycles for 2x LDA STA. It's not as bad for C64 as you want it to be.

 

You are giving a biased analysis. First of all, it's your speculation that majority of games do 2 mode changes. Secondly, you don't want to look at majority of games but games people spend more time on. I mean there are millions of games but the popular ones which people spend time on are used more often so a computer DL helpful to those games is where the analysis should be. We do *DO* a mode change in 1 cycle/scanline whereas using register modification requires first a raster IRQ and then a LDA/STA and end of interrupt per scanline for a complex DL. You may know how many cycles a DL needs but you forget that a DL instruction also does other things besides change modes:

 

It sets hscroll enable/disable per scanline (bit 4)

It sets vscroll enable/disable per scanline (bit 5)

It sets LMS address ptr for video per scanline (bit 6)

It sets DLI on a per mode line (bit 7)

 

So you combine these and you see that a good game does indeed use the same DMAd DL byte for more things so the repeat isn't just the same old mode byte. An average game does use a DLI very often (just look at frogger which does many colors in 160*200) and also does scrolling. It's still superior to use DMA method over register change method even if sometimes there are repeats. In fact, I would prefer that the DMAs be done to more registers than currently that's doable-- currently you can DMA data to 53261..53265 but if we could set count value for DMA amount per scanline that would be even better. So instead of 5 bytes + DL instruciton we could do 53261..53275 and/or 53248..53255 we could DMA the palette, HPOS, etc. per scanline.

[atarian63]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

[emkay]

Just a simple mockup. Well, I have a problem with my hand, so it is hard to edit ...

 

It just may show that the A8 hardware is able to show coloured hires games.

Well, the possible res. may be 338v and the scrolling can be at the same res. The PM is using the half res. , but, hey, it is good! the parallax background can scroll with the half speed of the foreground.

And you can have hires objects with easily 8 colours ....

 

Thinking about some C64 Super CPU projects, where you can see still nothing more but some better floating gameplay, you could do a real 128 colour scrolling game with the A8's hardware.

Thinking about the fact that GTIA can change ALL registers every 2 byte on the screen.

 

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

Edited April 4, 2009 by emkay

[Rybags]

Err... regardless of the CPU speed, you can still only talk to Antic, GTIA and Pokey at the "slow mode" speed of 1.79 MHz.

 

But still, a quicker CPU opens up all sorts of ideas.

 

A full-screen Kernal can change colours, add extra PMGs etc, without impacting performance compared to a normal 6502.

Of course that also means you have a game that has virtually no hope of running on standard hardware.

[sack-c0s]

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

 

actually you're probably seeing 312 pixels because the border is expanded by one row to allow somewhere for smooth scrolling to come from. you can turn this off to have full 320 pixel wide scrolling, but because you've got nowhere for the new data to come from it just judders at the edges (unless you open the borders and use sprites as a continuation of the scroll to give an overscan effect)

[the maddestman]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

[oky2000]

Just a simple mockup. Well, I have a problem with my hand, so it is hard to edit ...

 

It just may show that the A8 hardware is able to show coloured hires games.

Well, the possible res. may be 338v and the scrolling can be at the same res. The PM is using the half res. , but, hey, it is good! the parallax background can scroll with the half speed of the foreground.

And you can have hires objects with easily 8 colours ....

 

Thinking about some C64 Super CPU projects, where you can see still nothing more but some better floating gameplay, you could do a real 128 colour scrolling game with the A8's hardware.

Thinking about the fact that GTIA can change ALL registers every 2 byte on the screen.

 

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

Ignoring the troll like comments (SCPU for C64 makes NO CHANGE to VIC-II or SID graphics which is why it is a waste of money for gamers like I always said and mainly to run a graphical OS like GEOS which makes it like an ST with GEM to use in lo-res with at least 512k ram, using the full screen scrolling feature found in VIC-II you can scroll the entire screen memory from any width to 320....it is in many demos and also used in the game Mayhem I.M but the feature you are talking about is already explained it is the border controls to hide the screen redrawing which is optionally set by a single register., and 128 colour Atari games yeah right what using 1 or 2 colours per line like rasters? You can't make a game with 16 colour graphics per line in 160x200 AND run it as smooth and fast as uridium on C64 dude...if it was possible it would have been done already but all I see is DL colours in background like Attack of the Mutant Camels FAIL)

 

Right back to your post ......In 1986 I drew an arcade perfect version of level one of Nemesis/Gradius in Neochrome on the Atari ST...nobody could make it move like the original arcade game which is the problem you will have and why a STATIC PICTURE means NOTHING unless you can multiplex about 200 player missile graphics in 4 colour mode

 

Just so I don't get accused of trolling I will explain in detail your picture is meaningless even though I posted videos of

NOT LEVEL ONE which is what you have drawn a picture of (with about 150 sprites/bullets/scenery objects missing from your scene...maybe like the first 3 seconds of the first level of the C64 game)

 

Just so everyone else reading knows what you are trying to replicate here is a

This is a better quality video of the same level.

 

Anyway looking at your piture let's break down the actual engine you are trying to show with a single static picture NOT a piece of code running at super slick 50 frames per second all pixel scroll quality so was a bit of a waste of time for you to do shame.

 

 

1. Your asteroids are only 2 colours, on the C64 game they are in Multicolour mode and can be anything upto 2+1 to 12 colours. because they are made up of upto 4x3 multiplexed sprites of 24x21 pixels and each sprite can have 1 unique colour and 2 global multicolour colours assigned so 2+4 = 6 colours. So you will need to produce a player graphic in at least 3 colour and at least 96x84 pixels.

 

2. You need to put 6 of those asteroids in atleast 3 colours on the screen OVER a Yellow AND white background not just 1 colour as you have drawn. The asteroids are all transparent and mask over the background perfectly so they must be player/missile graphics only no rubbish soft sprites as they are in different colours.

 

1 & 2 need to be done 50 fps with NO GLITCHES and single pixel resolution movement so no character blocks or rubbish like that.

 

3. Each asteroid also has additional sprites connecting as they have lines of pipes connecting them, about another 8 on screen minimum so thats another 8 sprite sized graphics you need to add too in 3 colours again.

 

that is just the parallax scrolling background and transparent hmmmm and the top layer with asteroids/rocks going over the starfield can almost cover two thirds of the whole screen...thats way too much PM graphics to be multiplexing, never seen anything like that on an A8 EVER not even the most sophisticated games use that amount of pixel coverage via PM graphics multiplexing

 

4. Your ship is only 2 colours but is atleast 3 colours on the C64 minimum and dont forget when you upgrade your ship new sprites are overlaid onto it for shields and bigger weapons so even more 3 colour player graphics. Your ship can fire upto 20 bullets and 4 diagonal missiles so that's 20+4 missile graphics you need to multiplex ontop of the asteroids/rocks foreground layer you are already multiplexing so they appear over and above them, easy enough on C64 with sprite/char graphics priority PER INDIVIDUAL SPRITE but you need to do the same and the PM system and Atari screen modes mean you will just have to do it the hard way via PM multiplex or it wont look the same.

 

5. The enemies are something like a total of 10-15 together on the screen with one missiles each and EACH enemy is too large for a missile graphic so that's 10-15 players multiplexed and upto 10-15 missile graphics multiplexed so 30 MORE objects for you to multiplex.

 

We are almost at well over 200 objects needed to be multiplexed in various combinations of player and missile already and so your picture doesn't even begin to explain the simple level one demo you are trying to copy!

 

So when you have written a demo code to show it properly exactly like the video for me then we can talk about LEVEL TWO which is even technically more impossible for you to do with its THREE PARALLAX OVERLAPING LAYERS thats THREE 320x200 sized screens that have three layers of actions (arranged as follows .... background, foreground, ship+enemy ships+ bullets+obstacles) and all are complete transparent and overlapping and still about 100 free moving objects or sprites on the top layer via sprite multiplexing/sprite priority and char graphics.

 

Drawing pictures is easy but I KNOW enough about the A8 that you picture doesn't prove much sorry mate

[Gorf]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

 

 

My opinion, is though any windows OS is the worst of the worst, Im not so sure the Amiga OS would be the best.

I still would love to see Linux with XWindows(or whatever GUI) be the dominating OS of choice someday. I'm

not holding my breath though.

[Gorf]

Drawing pictures is easy but I KNOW enough about the A8 that you picture doesn't prove much sorry mate

 

Neither does most of what is conjecture on your part concerning the hardware of the two. It comes across much

more as fanboyism and has little to do with reality.

[oky2000]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

 

Sure the first set of icons were a bit simple looking on 1.x Workbench but they are just .info files for every file you want to show up in the window and every directory and you can make your own anyway it's not like they are in ROM or anything. I think the blue/white thing looks fine to me and the disk full/empty gauge on each disks top level window is a fantastic idea that no other OS bothered to put on there. You couldn't change the ST icons really, exe/folder/datafile/trash that was it all burned into the TOS/GEM roms forever. Looks nice in hires sure but there was no variety or animation on icons just negative/positive image of same monochrome graphics of icon when you select it too.

 

Anyway it multitasks very efficiently, and it ran graphically faster than the ST's clumsy GEM A-Line routines...did you see the colour clash/scroll effect as you scrolled black text on a white background in GEM word processors full screen? Without a software blitter running GEM was pretty poor on the eyes used with serious software because of this weird colour scroll/clash effect

[atarian63]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

Oh I am with you there. Anything but Windows. We used to sell Amiga back in the day. All the way to the end. The hardware was great(jay miner) but I always hated that comic o/s. powerful yes, but just didn't care for it. just my personal opinion. I much preferred the Falcon/ST o/s.

To each his own.

Edited April 4, 2009 by atarian63

[atarian63]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

 

 

My opinion, is though any windows OS is the worst of the worst, Im not so sure the Amiga OS would be the best.

I still would love to see Linux with XWindows(or whatever GUI) be the dominating OS of choice someday. I'm

not holding my breath though.

Wouldn't that be great! Have some hope, linux is coming along nicely on pc's and already has made great inroads in the server area.

Hopefully it will continue. Heck even ps3 has a linux MM o/s now.

[Crazyace]

Just a simple mockup. Well, I have a problem with my hand, so it is hard to edit ...

 

It just may show that the A8 hardware is able to show coloured hires games.

Well, the possible res. may be 338v and the scrolling can be at the same res. The PM is using the half res. , but, hey, it is good! the parallax background can scroll with the half speed of the foreground.

And you can have hires objects with easily 8 colours ....

 

Thinking about some C64 Super CPU projects, where you can see still nothing more but some better floating gameplay, you could do a real 128 colour scrolling game with the A8's hardware.

Thinking about the fact that GTIA can change ALL registers every 2 byte on the screen.

 

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

 

I think the biggest problem with scrolling highres games is the artifacting on NTSC ( and PAL to a certain extent )

Enforcer is showing 320pixel scrolling/graphics , something not supported on the a8 - rather than trying to simulate the 320pixel screen it would be interesting to see how much of the basic gameplay can be reproduced. Maybe just use highres with softsprites - and save the PM's for extra colours

[TMR]

Sorry, had to disappear for a few days to meet the deadline on a writing job... can't write that and be here at the same time. Now, where was i? =-)

 

There's a difference between two sprites producing two colors vs. 3. They do work together but they can also work together as monochrome sprites and NOT be a multicolor sprites. See my previous post.

 

As you've just said, it's two sprites producing two or three colours and not one sprite - that's precisely what the site you linked to was saying as well, it refers to multicolour objects when they're working together. So essentially the comparison is two sprites (or half the sprites) on the A8 versus one (or one eigth of the sprites) on the C64 and unfair.

 

Don't make it sound like I stated "it doesn't work". I stated the color is not retained due to NTSC.

 

But the games all rely in the fact it is retained otherwise those thousands of fixed speed horizontally scrolling games would be distorted as they moved. Which they're not.

 

320 resolution scroll works great on Atari as far as luminance goes, but it doesn't retain the color either. Perhaps, you have been running in an emulator. I know one guy previously was posting C64 interlaced images captured with emulator because they look better than when viewed on real C64.

 

Sorry no, i'm talking about experience based on over fifteen different C64s of varying ages and models, three C128s including a C128D and my NTSC C64 because i used to do some fixing work; as i said, a large number of fixed speed horizontal scrollers move at that resolution and are being used on PAL and NTSC machines.

 

Hideous? I clearly stated overscan in msg #3013 and Frohn stated the same by claiming he can do sprites full height of screen like Atari does.

 

Ah... sorry, i just read back properly and it wasn't about enhancement layers but merely putting sprites there. Yes, full screen height including upper and lower borders is incredibly easy and what i said about two data pointers holds.

[TMR]

My opinion, is though any windows OS is the worst of the worst, Im not so sure the Amiga OS would be the best.

I still would love to see Linux with XWindows(or whatever GUI) be the dominating OS of choice someday. I'm

not holding my breath though.

Wouldn't that be great! Have some hope, linux is coming along nicely on pc's and already has made great inroads in the server area.

 

Y'know... we may be at odds over 8-bits but it's nice to have something to agree on. =-)

[TMR]

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

 

People are saying "320 resolution" rather than width, it's just an easier reference for the mode that at least gives a rough idea which we're talking about; i may have written two A8 games and a couple of intros but i can never remember which Antic mode is which so i refer to those by resolution as well.

 

actually you're probably seeing 312 pixels because the border is expanded by one row to allow somewhere for smooth scrolling to come from.

 

The border is expanded by a column at each side so the window itself is 304 pixels, but the amount of area visible in total as the hardware scroll moves through it's cycle is 311.

[Heaven/TQA]

Just a simple mockup. Well, I have a problem with my hand, so it is hard to edit ...

 

It just may show that the A8 hardware is able to show coloured hires games.

Well, the possible res. may be 338v and the scrolling can be at the same res. The PM is using the half res. , but, hey, it is good! the parallax background can scroll with the half speed of the foreground.

And you can have hires objects with easily 8 colours ....

 

Thinking about some C64 Super CPU projects, where you can see still nothing more but some better floating gameplay, you could do a real 128 colour scrolling game with the A8's hardware.

Thinking about the fact that GTIA can change ALL registers every 2 byte on the screen.

 

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

Ignoring the troll like comments (SCPU for C64 makes NO CHANGE to VIC-II or SID graphics which is why it is a waste of money for gamers like I always said and mainly to run a graphical OS like GEOS which makes it like an ST with GEM to use in lo-res with at least 512k ram, using the full screen scrolling feature found in VIC-II you can scroll the entire screen memory from any width to 320....it is in many demos and also used in the game Mayhem I.M but the feature you are talking about is already explained it is the border controls to hide the screen redrawing which is optionally set by a single register., and 128 colour Atari games yeah right what using 1 or 2 colours per line like rasters? You can't make a game with 16 colour graphics per line in 160x200 AND run it as smooth and fast as uridium on C64 dude...if it was possible it would have been done already but all I see is DL colours in background like Attack of the Mutant Camels FAIL)

 

Right back to your post ......In 1986 I drew an arcade perfect version of level one of Nemesis/Gradius in Neochrome on the Atari ST...nobody could make it move like the original arcade game which is the problem you will have and why a STATIC PICTURE means NOTHING unless you can multiplex about 200 player missile graphics in 4 colour mode

 

Just so I don't get accused of trolling I will explain in detail your picture is meaningless even though I posted videos of

NOT LEVEL ONE which is what you have drawn a picture of (with about 150 sprites/bullets/scenery objects missing from your scene...maybe like the first 3 seconds of the first level of the C64 game)

 

Just so everyone else reading knows what you are trying to replicate here is a

This is a better quality video of the same level.

 

Anyway looking at your piture let's break down the actual engine you are trying to show with a single static picture NOT a piece of code running at super slick 50 frames per second all pixel scroll quality so was a bit of a waste of time for you to do shame.

 

 

1. Your asteroids are only 2 colours, on the C64 game they are in Multicolour mode and can be anything upto 2+1 to 12 colours. because they are made up of upto 4x3 multiplexed sprites of 24x21 pixels and each sprite can have 1 unique colour and 2 global multicolour colours assigned so 2+4 = 6 colours. So you will need to produce a player graphic in at least 3 colour and at least 96x84 pixels.

 

2. You need to put 6 of those asteroids in atleast 3 colours on the screen OVER a Yellow AND white background not just 1 colour as you have drawn. The asteroids are all transparent and mask over the background perfectly so they must be player/missile graphics only no rubbish soft sprites as they are in different colours.

 

1 & 2 need to be done 50 fps with NO GLITCHES and single pixel resolution movement so no character blocks or rubbish like that.

 

3. Each asteroid also has additional sprites connecting as they have lines of pipes connecting them, about another 8 on screen minimum so thats another 8 sprite sized graphics you need to add too in 3 colours again.

 

that is just the parallax scrolling background and transparent hmmmm and the top layer with asteroids/rocks going over the starfield can almost cover two thirds of the whole screen...thats way too much PM graphics to be multiplexing, never seen anything like that on an A8 EVER not even the most sophisticated games use that amount of pixel coverage via PM graphics multiplexing

 

4. Your ship is only 2 colours but is atleast 3 colours on the C64 minimum and dont forget when you upgrade your ship new sprites are overlaid onto it for shields and bigger weapons so even more 3 colour player graphics. Your ship can fire upto 20 bullets and 4 diagonal missiles so that's 20+4 missile graphics you need to multiplex ontop of the asteroids/rocks foreground layer you are already multiplexing so they appear over and above them, easy enough on C64 with sprite/char graphics priority PER INDIVIDUAL SPRITE but you need to do the same and the PM system and Atari screen modes mean you will just have to do it the hard way via PM multiplex or it wont look the same.

 

5. The enemies are something like a total of 10-15 together on the screen with one missiles each and EACH enemy is too large for a missile graphic so that's 10-15 players multiplexed and upto 10-15 missile graphics multiplexed so 30 MORE objects for you to multiplex.

 

We are almost at well over 200 objects needed to be multiplexed in various combinations of player and missile already and so your picture doesn't even begin to explain the simple level one demo you are trying to copy!

 

So when you have written a demo code to show it properly exactly like the video for me then we can talk about LEVEL TWO which is even technically more impossible for you to do with its THREE PARALLAX OVERLAPING LAYERS thats THREE 320x200 sized screens that have three layers of actions (arranged as follows .... background, foreground, ship+enemy ships+ bullets+obstacles) and all are complete transparent and overlapping and still about 100 free moving objects or sprites on the top layer via sprite multiplexing/sprite priority and char graphics.

 

Drawing pictures is easy but I KNOW enough about the A8 that you picture doesn't prove much sorry mate

 

O, I first mixed EF2 up with Metal Dust which uses the turbo-board... it is plain 64k c64? Very impressive I have to admit...

 

and I would not call level 2 three parallax layers as there are "only" 2... I guess we never counted sprites on any platform as separate background layer??? btw...is there a HD video in 50 fps or a c64 demo already?

Edited April 4, 2009 by Heaven/TQA

[Heaven/TQA]

ok. ok...

 

here are the demo levels...

 

http://www.protovision-previews.de/preview...2/enforcer2.php

[Allas]

A little reminder of workareas on both computers on real widescreen TVs

 

 

On C64 you have the best minimal pixel on screen for detailed draws, but on overall you fell on borders too much free space (At least you use a zoom on your TV). On Atari, you could gently use all the area vertical or horizontal, but course, pixels are bigs. What is better? who knows? a matter of taste.

[atariksi]

Sorry, had to disappear for a few days to meet the deadline on a writing job... can't write that and be here at the same time. Now, where was i? =-)

 

There's a difference between two sprites producing two colors vs. 3. They do work together but they can also work together as monochrome sprites and NOT be a multicolor sprites. See my previous post.

 

As you've just said, it's two sprites producing two or three colours and not one sprite - that's precisely what the site you linked to was saying as well, it refers to multicolour objects when they're working together. So essentially the comparison is two sprites (or half the sprites) on the A8 versus one (or one eigth of the sprites) on the C64 and unfair.

...

 

You still don't get it. Better off if you took a vacation and thought about it. It's two monochrome sprites working together to produce one multicolor sprite like I gave example of Amiga bitplanes which you conveniently cut off. You misread and/or misunderstood what I wrote. You don't know the difference between bitplane method and chunky method and prefer that we compare a monochrome sprite with a multicolor sprite on c64. The link I gave agrees with me that you enable bit 5 to enable multicolor sprite otherwise it's two monochrome sprites.

 

>But the games all rely in the fact it is retained otherwise those thousands of fixed speed horizontally scrolling games would be distorted as they moved. Which they're not.

 

Colors distort as you move-- try a one pixel color red and then start scrolling it by half a color clock.

 

>Ah... sorry, i just read back properly and it wasn't about enhancement layers but merely putting sprites there. Yes, full screen height including upper and lower borders is incredibly easy and what i said about two data pointers holds.

 

You misunderstood again. It's about both. You can put up sprites full height and use them for enhancement.

[atariksi]

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

 

actually you're probably seeing 312 pixels because the border is expanded by one row to allow somewhere for smooth scrolling to come from. you can turn this off to have full 320 pixel wide scrolling, but because you've got nowhere for the new data to come from it just judders at the edges (unless you open the borders and use sprites as a continuation of the scroll to give an overscan effect)

 

This is where you have more flexibility with A8 since the LMS can used to make a line wider than displayed on a per scan line basis. C64 is more of a superficial imposition of scrolling (requires more software support) whereas A8 is well integrated into its hardware design. Most software on both systems does not use 320 pixel wide resolution.

[atariksi]

Just a simple mockup. Well, I have a problem with my hand, so it is hard to edit ...

 

It just may show that the A8 hardware is able to show coloured hires games.

Well, the possible res. may be 338v and the scrolling can be at the same res. The PM is using the half res. , but, hey, it is good! the parallax background can scroll with the half speed of the foreground.

And you can have hires objects with easily 8 colours ....

 

Thinking about some C64 Super CPU projects, where you can see still nothing more but some better floating gameplay, you could do a real 128 colour scrolling game with the A8's hardware.

Thinking about the fact that GTIA can change ALL registers every 2 byte on the screen.

 

And, btw. What scrolling game on the C64 is REALLY using 320 pixel width?

I always see 304 pixel games....

 

I think the biggest problem with scrolling highres games is the artifacting on NTSC ( and PAL to a certain extent )

Enforcer is showing 320pixel scrolling/graphics , something not supported on the a8 - rather than trying to simulate the 320pixel screen it would be interesting to see how much of the basic gameplay can be reproduced. Maybe just use highres with softsprites - and save the PM's for extra colours

 

320pixel screen is supported; I guess you meant simulate the half color clock scroll. It's quite easy to have a graphic in 320 pixel mode say at the bottom and have it scroll at half a color clock using double buffered lines (not screens). You can move/scroll the graphic at the bottom at 1/320 width accuracy whereas the top half of the screen can be GTIA or 160*200*4+.

[atariksi]

...Now, where was i? =-)

 

Employing chewbacca defense to confuse a simple point. First you waited a few months and then claim the same point again without refuting last year's stated point and then you go away for a few days and state the same thing ignoring the refutation hoping people will have forgotten exactly what was stated; essentially shove the facts under the rug and make a straw-man argument.

[atariksi]

...

found in VIC-II you can scroll the entire screen memory from any width to 320....it is in many demos and also used in the game Mayhem I.M but the feature you are talking about is already explained it is the border controls to hide the screen redrawing which is optionally set by a single register., and 128 colour Atari games yeah right what using 1 or 2 colours per line like rasters? You can't make a game with 16 colour graphics per line in 160x200 AND run it as smooth and fast as uridium on C64 dude...if it was possible it would have been done already but all I see is DL colours in background like Attack of the Mutant Camels FAIL)

...

You did exactly what I stated previously-- come back every few days and blurt out whatever's on top your head without addressing the points made to you by various people. You can get 16 colors/scanline on atari at 160*200. You can get 256 colors in a frame and they are not just shades in the background. Perhaps your participation in too many topics has you so busy you can't address the points that are being made to you.

[atariksi]

A little reminder of workareas on both computers on real widescreen TVs

 

 

On C64 you have the best minimal pixel on screen for detailed draws, but on overall you fell on borders too much free space (At least you use a zoom on your TV). On Atari, you could gently use all the area vertical or horizontal, but course, pixels are bigs. What is better? who knows? a matter of taste.

 

It's just a lame excuse to keep repeating 320 scroll mode-- their games also mainly use 160 mode. And there are many other modes which even if less used allow you to save on CPU cycles and memory by inserting them anywhere along the display. And then there's the GPRIOR 0 mode which does allow you to increase number of colors in 320 mode as well.