CV vs. 5200- on one thing.

[CV Gus]

If you haven't already seen Opcode & Company's fantastic CV Pac-Man Collection preview yet, here it is:

 

http://www.youtube.com/watch?v=4WrsIT1N1CM

 

The flickering is much worse here than on an actual television.

 

 

Normally a CV cannot show more than 4 sprites on a horizontal line without flickering- this is esp. clear on Burgertime (note- for some reason, I'd always thought it was 3- thanks, Vigo).

 

Since each character on this game is made of at least 2 sprites, in Pac-Man this would be (2X4)+1=9, at least. In Ms. Pac-Man, at at least 3 more (since the prizes are mobile).

 

That's 12.

 

Normally, this would constantly cause an intolerable amount of flickering and disappearance. The game would be unplayable.

 

But what Opcode did here was what was attempted with Atarisoft's CV Dig Dug: forming an image by first flashing one sprite (say, the eyes), and then the other (the body). The result is that far fewer sprites are actually on-screen at any one time. Since the human eye cannot detect changes faster than about 1/12 of a second, the result looks like a continuous single image. Some other technique must also be used, since the normal amount of flickering you'd expect even if all images just used one sprite and color (think 5200 Pac-Man) simply isn't here. A CV limitation has been better than 90% overcome.

 

As I was playing the just-great 5200 version of Ms. Pac-Man, I noticed the flickering (while never really BAD), when several objects line up. I also noticed the translucent look of the monkeys in Kangaroo.

 

 

So here's my question: if a really skilled 5200 programmer wanted to try this technique(s) to do the same thing on a 5200 Pac-Man Collection, could it be done (effectively, that is)? How about on a 7800 (assuming you had to)?

Edited November 29, 2008 by CV Gus

[kenfused]

As I was playing the just-great 5200 version of Ms. Pac-Man, I noticed the flickering (while never really BAD), when several objects line up. I also noticed the translucent look of the monkeys in Kangaroo.

 

 

So here's my question: if a really skilled 5200 programmer wanted to try this technique(s) to do the same thing on a 5200 Pac-Man Collection, could it be done (effectively, that is)? How about on a 7800 (assuming you had to)?

Ms. Pacman shouldn't flicker too much (at least no more than CV pacman collection) unless a lot of objects are on a line. Missiles are used for the white's in the eyes for instance so players are not wasted on that. Only when you have more than four objects in a row should they flicker. If we were willing to go to a one color maze in ms. pacman like in CV pacman collection (I think it was that way in one of the demos, don't know if it is still the case) there would be free colors and the background objects could be use to probably have no flicker.

 

Look at super pacman on the 5200 for a game with no flicker IIRC. Background is used for a ghost or two I think.

 

Kangaroo I think just flickers monkeys all the time with no intelligent flicker. I am sure it could be improved on some.

[Crazyace]

I'm using softsprites for my pacman demo - the aim is to have no flicker at all. ( I really hate flicker, even on 2600 games - where it's almost a staple diet for games )

[phonedork]

The CV version definately looks better then both the 7800 and 5200 version. But I think Pacman Collection for the 7800 has more game options.

[CV Gus]

As I was playing the just-great 5200 version of Ms. Pac-Man, I noticed the flickering (while never really BAD), when several objects line up. I also noticed the translucent look of the monkeys in Kangaroo.

 

 

So here's my question: if a really skilled 5200 programmer wanted to try this technique(s) to do the same thing on a 5200 Pac-Man Collection, could it be done (effectively, that is)? How about on a 7800 (assuming you had to)?

Ms. Pacman shouldn't flicker too much (at least no more than CV pacman collection) unless a lot of objects are on a line. Missiles are used for the white's in the eyes for instance so players are not wasted on that. Only when you have more than four objects in a row should they flicker. If we were willing to go to a one color maze in ms. pacman like in CV pacman collection (I think it was that way in one of the demos, don't know if it is still the case) there would be free colors and the background objects could be use to probably have no flicker.

 

Look at super pacman on the 5200 for a game with no flicker IIRC. Background is used for a ghost or two I think.

 

Kangaroo I think just flickers monkeys all the time with no intelligent flicker. I am sure it could be improved on some.

 

 

Well, the reason Opcode went with the one-color mazes was choice: multi-colored mazes were possible, but not if you wanted the exact shape and numbers of dots the arcade version had. In the case of the 5200, count the dots and measure the mazes, and they are by no means arcade-accurate, the way Opcode's are. Guess for the older systems, it was either one or the other. But the mazes are technically not one-color; the dots are not the same.

 

But I'm also considering other applications for the technique- a perfect example would be Q*Bert; now, all of the characters can be multi-colored, as they are in Q*Bert's Qubes. The characters are against multi-colored backgrounds. Could this be done for the 5200 version?

Edited December 2, 2008 by CV Gus

[kenfused]

Well, the reason Opcode went with the one-color mazes was choice: multi-colored mazes were possible, but not if you wanted the exact shape and numbers of dots the arcade version had. In the case of the 5200, count the dots and measure the mazes, and they are by no means arcade-accurate, the way Opcode's are. Guess for the older systems, it was either one or the other. But the mazes are technically not one-color; the dots are not the same.

 

But I'm also considering other applications for the technique- a perfect example would be Q*Bert; now, all of the characters can be multi-colored, as they are in Q*Bert's Qubes. The characters are against multi-colored backgrounds. Could this be done for the 5200 version?

 

I would like to port or see 7800 Pacman Collection ported to the 5200. I think it should be doable and 6 pixel high characters could be used today with vscroll techniques I think.

 

I have thought of porting b*nQ to the 8bit/5200. It isn't going to look like 7800 b*nQ but it should be possible to do something a lot better the PB's version. Goals would be non-dithered sides. I would like more colors on the sprites but that would introduce some flicker. I think the missiles could probably be used in some creative ways though.

 

I will probably try for another 7800 game first though.

[slampam]

How about combining the hacks already out there for a basic 5200 Pac-Man Collection? Pac-Man (Plus), Hangly-Man (Plus), Pac-Pollux (Plus), Hangly-Pollux (Plus), plus convert and add the original A8 animated character screen. At least it'd be compact.

This direct port idea is mind-blowing.

[CV Gus]

I started this post because of something at the AGH.

 

The simple number of a CV processor is roughly twice that of the 5200's. But they are different processors, so the number is not all there is to it.

 

In short, AGH implied that it was like two people unloading a truck: one moves twice as fast, but the other can carry twice as much. Thus, the same amount of work is done.

 

But for Opcode's (and Atarisoft's) "flicker" method, it would seem as though speed would be the main factor. The faster you can flicker-alternate the images, the better the composite character would look. For maze games, or games like Q*Bert or Mr. Do!, the CV would have a tremendous advantage, although I'd imagine that with scrolling games, like Moon Patrol or Snap Jack (esp. if you wanted smooth horizontal scrolling), where the processor would be slowed down due to the extra work, the method might not work as well.

 

Is this the case?

[kenfused]

I started this post because of something at the AGH.

 

The simple number of a CV processor is roughly twice that of the 5200's. But they are different processors, so the number is not all there is to it.

 

In short, AGH implied that it was like two people unloading a truck: one moves twice as fast, but the other can carry twice as much. Thus, the same amount of work is done.

 

But for Opcode's (and Atarisoft's) "flicker" method, it would seem as though speed would be the main factor. The faster you can flicker-alternate the images, the better the composite character would look. For maze games, or games like Q*Bert or Mr. Do!, the CV would have a tremendous advantage, although I'd imagine that with scrolling games, like Moon Patrol or Snap Jack (esp. if you wanted smooth horizontal scrolling), where the processor would be slowed down due to the extra work, the method might not work as well.

 

Is this the case?

I would think the ONLY advantage the Colecovision has over the 5200 is its ability to display higher resolution in color (256 wide vs 160 wide). You can only flicker as fast as 1/60th of a second and both system can display 4 sprites per row in one color without flickering (not counting missiles on the 5200).

[unhuman]

My speculation is that he's just keeping track of the number of sprites on a row. The TI graphics chip, as others alluded to can only display 4 sprites per row. The higher number sprites disappear, rather than just flicker. What they must be doing is swapping the sprites around so that sprites take turns being the lowest # sprites.

 

This work would be done in the "NMI" (Non Maskable Interrupt) that occurs while the screen is refreshing... Which would manage the timing concerns "for free". Thus, we have a relatively low expense to the coder - since the cycling always occurs - and would ordinarily have no visible impact unless the feature is required. The only real side effect is that you wouldn't be able to tell which ghost is "on top".

 

-H

 

I started this post because of something at the AGH.

 

The simple number of a CV processor is roughly twice that of the 5200's. But they are different processors, so the number is not all there is to it.

 

In short, AGH implied that it was like two people unloading a truck: one moves twice as fast, but the other can carry twice as much. Thus, the same amount of work is done.

 

But for Opcode's (and Atarisoft's) "flicker" method, it would seem as though speed would be the main factor. The faster you can flicker-alternate the images, the better the composite character would look. For maze games, or games like Q*Bert or Mr. Do!, the CV would have a tremendous advantage, although I'd imagine that with scrolling games, like Moon Patrol or Snap Jack (esp. if you wanted smooth horizontal scrolling), where the processor would be slowed down due to the extra work, the method might not work as well.

 

Is this the case?

[segasaturn]

I think they might....