Jump to content

Photo

Acceptable flicker?


57 replies to this topic

#1 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Wed Dec 23, 2009 3:29 AM

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

Attached Thumbnails

  • superpac.PNG

Attached Files



#2 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Wed Dec 23, 2009 4:47 AM

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

#3 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Wed Dec 23, 2009 10:24 AM

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

#4 VectorGamer OFFLINE  

VectorGamer

    Go Sleep In the Cold

  • 12,901 posts
  • \m/
  • Location:Retrocade, USA

Posted Wed Dec 23, 2009 10:40 AM

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

#5 SpiceWare OFFLINE  

SpiceWare

    Quadrunner

  • 10,733 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Dec 23, 2009 11:11 AM

Looks just like your screenshot on a real Atari. :thumbsup:

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
ladybug_FINAL_NTSC.bin_3.png

this is the other frame
ladybug_FINAL_NTSC.bin_4.png

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

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

Edited by SpiceWare, Wed Dec 23, 2009 11:11 AM.


#6 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Wed Dec 23, 2009 11:24 AM

Looks just like your screenshot on a real Atari. :thumbsup:

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

#7 ZylonBane OFFLINE  

ZylonBane

    River Patroller

  • 3,686 posts
  • Location:KC, KS, USA

Posted Wed Dec 23, 2009 3:38 PM

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

#8 stephena OFFLINE  

stephena

    River Patroller

  • 2,735 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Wed Dec 23, 2009 6:04 PM

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

#9 roland p ONLINE  

roland p

    River Patroller

  • 2,394 posts
  • $23
  • Location:The Netherlands

Posted Thu Dec 24, 2009 6:20 AM

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!

#10 PacManPlus OFFLINE  

PacManPlus

    River Patroller

  • 4,551 posts
  • Atari 7800 Developer
  • Location:Florida

Posted Thu Dec 24, 2009 7:58 AM

Holy Crap! That looks awesome! Great Job!

#11 Nerf Herder73 OFFLINE  

Nerf Herder73

    Chopper Commander

  • 148 posts
  • Location:Los Angeles, CA

Posted Thu Dec 24, 2009 10:26 AM

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

#12 TrekMD OFFLINE  

TrekMD

    River Patroller

  • 3,153 posts
  • Location:Coral Gables, FL

Posted Thu Dec 24, 2009 10:32 AM

It looks amazing! Keep at it, please!

#13 BDW OFFLINE  

BDW

    River Patroller

  • 2,880 posts
  • Location:Somewhere in a corn field

Posted Thu Dec 24, 2009 2:43 PM

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

#14 Slingers OFFLINE  

Slingers

    Space Invader

  • 10 posts

Posted Thu Dec 24, 2009 2:48 PM

Very good! Keep up the good work.

#15 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Sat Jan 2, 2010 1:50 AM

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

Attached Thumbnails

  • frame1.PNG
  • frame2.PNG

Attached Files



#16 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Jan 2, 2010 7:28 AM

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 by cd-w, Sat Jan 2, 2010 7:32 AM.


#17 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Sat Jan 2, 2010 10:33 AM

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

#18 Corby OFFLINE  

Corby

    Dragonstomper

  • 821 posts
  • I'm really not that interesting
  • Location:Winterpeg, CANADA

Posted Sat Jan 2, 2010 11:26 AM

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

#19 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Sat Jan 2, 2010 12:46 PM

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

#20 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Jan 2, 2010 5:39 PM

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

#21 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Sat Jan 2, 2010 7:13 PM

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

#22 Corby OFFLINE  

Corby

    Dragonstomper

  • 821 posts
  • I'm really not that interesting
  • Location:Winterpeg, CANADA

Posted Sat Jan 2, 2010 7:15 PM

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

#23 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sun Jan 3, 2010 3:47 AM

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

#24 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Wed Jan 6, 2010 11:00 PM

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

#25 e1will OFFLINE  

e1will

    Moonsweeper

  • Topic Starter
  • 347 posts

Posted Wed Jan 6, 2010 11:02 PM

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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users