Acceptable flicker?

[e1will]

Hello,

 

I'm toying with the idea of writing a Super Pac-Man conversion for the 2600. Can someone with a Harmony cartridge or similar setup give this a test on real hardware and tell me how bad the flicker is? It looks OK in Stella if the phosphor effect is enabled (Alt-P) but it looks horrible if it isn't.

 

Also, I'm doing some funky things with HMOVE timings to cut down on the HMOVE bars so I'm curious if that breaks anything on a real 2600. Here's what it SHOULD look like...

 

--Will

SUPERPAC.BIN

[cd-w]

Nice work - it looks great (with the phosphor option turned on). I haven't tested it on real hardware yet though. Drawing Pac-Man with the ball is a neat idea, but I'm not sure how you will make him face up/down? You could cut down on flicker a bit by using alternate yellow/blue lines for the playfield (switch between b/y/b/y/.. and y/b/y/b/... on alternative frames).

 

Chris

[e1will]

Thanks. Good idea on the playfield... I may do that once I get the kernel straightened out. That may also enable a way to patch together up and down sprites with the ball sprite using an alternate frame/venetian blind approach for the left and right halves.

 

--Will

[VectorGamer]

Hello,

 

I'm toying with the idea of writing a Super Pac-Man conversion for the 2600. Can someone with a Harmony cartridge or similar setup give this a test on real hardware and tell me how bad the flicker is? It looks OK in Stella if the phosphor effect is enabled (Alt-P) but it looks horrible if it isn't.

 

Also, I'm doing some funky things with HMOVE timings to cut down on the HMOVE bars so I'm curious if that breaks anything on a real 2600. Here's what it SHOULD look like...

 

--Will

 

Holy crap - I can't believe this is a 2600 title! Excellent job!

 

Get rid of the flicker and you got one hell of a home brew...

[+SpiceWare]

Looks just like your screenshot on a real Atari.

 

The flicker is pretty bad though because it's the entire screen flickering. I suggested taking a look at Ladybug which flickers 2 colors for the playfield. It works quite well. Ladybug also uses the right difficulty switch to select between darker or lighter playfield colors. Darker colors don't flicker as much.

 

This is one frame

 

this is the other frame

 

yielding this(note: the timer has changed, this would really be totally green on the top border):

 

The only issue I can foresee is getting yellow to blend with something else to yield a blue color.

Edited December 23, 2009 by SpiceWare

[e1will]

Looks just like your screenshot on a real Atari.

 

The flicker is pretty bad though because it's the entire screen flickering.

 

Thanks for testing that. Yeah, that's what I was afraid of... I'll have to play around with the playfield drawing some more, it seems.

 

As for Lady Bug, the fact that JohnnyWC was able to pull it off so brilliantly for the 2600 is my main encouragement for thing Super Pac-Man might be possible too. But as you point out, getting colors that blend the way they need to is going to be mighty tricky.

 

--Will

[ZylonBane]

It would probably be best to just present the doors as flickering playfield segments, a la Mousetrap.

[+stephena]

Hello,

 

I'm toying with the idea of writing a Super Pac-Man conversion for the 2600. Can someone with a Harmony cartridge or similar setup give this a test on real hardware and tell me how bad the flicker is? It looks OK in Stella if the phosphor effect is enabled (Alt-P) but it looks horrible if it isn't.

I suggest using Stella in OpenGL mode with vsync enabled and phosphor mode turned off. On my system at least, this more accurately simulates what you'll see on a real system (a quite irritating flicker, in this case). The phosphor effect is really meant to make things nicer on a computer monitor, and it has no relation to how things look on a real system (ie, it makes things look better than they really are).

[roland p]

It looks amazing. An amazing number of sprites too. But it flickers really bad. Especially when you follow the pacman with your eyes. I really wonder how it would look like when you use a b/y/b/y/... and y/b/y/b/... pattern like cd-w proposed.

keep up the good work!

[PacManPlus]

Holy Crap! That looks awesome! Great Job!

[Nerf Herder73]

This is amazing! Please don't let this project die.

[TrekMD]

It looks amazing! Keep at it, please!

[BDW]

I do believe that this is acceptable flicker, just enough that everything is displayed, but not enough to make my eyeballs spontaneously combust.

[Slingers]

Very good! Keep up the good work.

[e1will]

OK, here's (I hope) an improved version. I've rewritten the kernel so that the blue maze does not flicker at all. The doors (and everything else) flicker at 30Hz. I've included screenshots of the 2 alternating frames.

 

Is this better? Worse? Better but still too flickery?

 

--Will

SUPERPAC.BIN

[cd-w]

Is this better? Worse? Better but still too flickery?

 

It looks better than before, but it still rather flickery on a real TV. Also, I don't think you will be able to draw pac-man using the ball on the other rows?

 

I guess you are probably very low on kernel cycles? Do you know about the mid-kernel repositioning approach?

It requires a lot of ROM space, but instead of taking a whole line to reposition the sprites, you just do:

ldx XPOS
lda HmoveTable,X
sta HMP0
lda KernelTable,X 
sta JPTR
jmp (JPTR)
Continue
sta HMOVE
...

Kernel1
...
sta RESP0 ; This must happen on the correct cycle
...
jmp Continue

You need a separate bit of code for each coarse position (RESP0), and two tables (one of HMOVE values and another of jump values) with values for each X position.

 

Chris

Edited January 2, 2010 by cd-w

[e1will]

It looks better than before, but it still rather flickery on a real TV. Also, I don't think you will be able to draw pac-man using the ball on the other rows?

 

Thanks for testing it out. My plan was to turn off PF0-2 in Frame 1 for the rows where the ball was enabled, and to possibly increase the luminance of those rows in Frame 2 to compensate somewhat (if I could find the cycles.) That would of course increase the flicker on those rows, but I wanted to get an idea if the "best-case" flicker was good enough before coding that, since there wouldn't be much point in coding it if even the best-case was unacceptable.

 

Do you know about the mid-kernel repositioning approach?

 

That looks very handy! I'll give that a try if the consensus is to go forward.

 

As best I can tell, the only way to further reduce flicker would be to run the Frame 1 logic on those rows where there isn't either a ghost or Pac-Man, and possibly tamp down the luminance on the fruits and doors that are being drawn on both frames. I wonder if that would be an improvement, or if it would be a more distracting visual artifact than a consistent 30Hz flicker on those elements?

 

--Will

[Corby]

hi e1will

 

the flicker is alot better. but I noticed after about a minute, I get this slow screen roll. and It repeats itself. I'm using stella 3.0

[e1will]

hi e1will

 

the flicker is alot better. but I noticed after about a minute, I get this slow screen roll. and It repeats itself. I'm using stella 3.0

 

Is it rolling, or just flickering? If turning on phosphor mode makes it stop, it's probably the CPU not having enough cycles to update every frame.

 

--Will

[cd-w]

As best I can tell, the only way to further reduce flicker would be to run the Frame 1 logic on those rows where there isn't either a ghost or Pac-Man, and possibly tamp down the luminance on the fruits and doors that are being drawn on both frames. I wonder if that would be an improvement, or if it would be a more distracting visual artifact than a consistent 30Hz flicker on those elements?

--Will

The best way to minimise the flicker is probably the venetian blind effect (drawing alternate rows on each frame), although it can be difficult to reduce the flicker this way. Reducing the luminance can help, but going below 30Hz is probably a bad idea. Have you got a Harmony cart to test on real hardware?

 

Chris

[e1will]

The best way to minimise the flicker is probably the venetian blind effect (drawing alternate rows on each frame), although it can be difficult to reduce the flicker this way. Reducing the luminance can help, but going below 30Hz is probably a bad idea. Have you got a Harmony cart to test on real hardware?

 

Chris

 

Hmm... would that even be possible with Super Pac-Man? I'm trying to think of how to reposition (for example) the P0 sprite from the arbitrary Blinky location to the fruit location and back within 2 lines. Are there any examples of games that do something similar? If so I can look through the debugger and see how they do it.

 

Unfortunately I don't have a Harmony cart yet... it's on my wishlist, though.

 

--Will

[Corby]

hi e1will

 

the flicker is alot better. but I noticed after about a minute, I get this slow screen roll. and It repeats itself. I'm using stella 3.0

 

Is it rolling, or just flickering? If turning on phosphor mode makes it stop, it's probably the CPU not having enough cycles to update every frame.

 

--Will

 

it does both! as it rolls it flickers

[cd-w]

The best way to minimise the flicker is probably the venetian blind effect (drawing alternate rows on each frame), although it can be difficult to reduce the flicker this way. Reducing the luminance can help, but going below 30Hz is probably a bad idea. Have you got a Harmony cart to test on real hardware?

Hmm... would that even be possible with Super Pac-Man? I'm trying to think of how to reposition (for example) the P0 sprite from the arbitrary Blinky location to the fruit location and back within 2 lines. Are there any examples of games that do something similar? If so I can look through the debugger and see how they do it.

 

Yes, that will be difficult with your kernel, particularly as you probably have to reposition both P0 and P1? This technique is used in the 24 character text routines, but the distance for repositioning is fixed. Is the sprite position for the fruit always the same? It might be possible to draw the fruit using a single sprite by hitting RESP0 mid line? In any case, your kernel looks very nice!

 

Chris

[e1will]

Yes, that will be difficult with your kernel, particularly as you probably have to reposition both P0 and P1? This technique is used in the 24 character text routines, but the distance for repositioning is fixed. Is the sprite position for the fruit always the same? It might be possible to draw the fruit using a single sprite by hitting RESP0 mid line? In any case, your kernel looks very nice!

 

Chris

 

Thanks. The fruit/key/pill position does change between zones. Right now I'm doing all the repositioning in the 2-line gap between fruits.

 

The problem with firing RESP0 midline is that in about half the cases it's fruits + something else (keys, power pills, super pills), and I don't think there's enough time to both switch graphics and reposition. The super-pill line, for example, takes 72 cycles to do this:

1. Load fruit graphic/color into P0

2. Load pill graphic/color into P1

3. Load pill graphic/color into P0 (now that the P0 fruit has been written)

4. Set left vertical door color (on or off) in PF

4. Set right vertical door color (on or off) in PF

5. Restore normal maze color in PF

6. Load fruit graphic/color into P1

7. Increment/loop to step 1

 

Squeezing anything else in there will be tricky.

 

I may have to resign myself to making this an emulator-only game if non-interlaced 30Hz won't look decent on real hardware. Finding enough cycles to interlace might be beyond my programming capabilities. :/

 

--Will

[e1will]

I suggest using Stella in OpenGL mode with vsync enabled and phosphor mode turned off. On my system at least, this more accurately simulates what you'll see on a real system (a quite irritating flicker, in this case). The phosphor effect is really meant to make things nicer on a computer monitor, and it has no relation to how things look on a real system (ie, it makes things look better than they really are).

 

I meant to reply to this earlier... Thank you for that tip, I will give that a try. My development computer doesn't have OpenGL, unfortunately, so I'll have to find one that does.

 

--Will