30hz flicker examples

[boutell]

Can anyone point to some clear examples of games that use 30hz flicker extensively? As opposed to the vastly worse 20hz or 15hz? I'm trying to get a handle on how appalling 30hz really is. In Stella it's either OMG TOTALLY APPALLING (without phosphor mode) or totally fine (in phosphor mode). While Pac-Man and Football still look awful even in phosphor mode (because they are 15hz games).

 

I'm trying to get a sense of what 30hz is like on an actual TV.

 

I'm thinking it may be acceptable to use 30hz, especially if I avoid it for those segments of the screen in which I don't currently have three independently positioned objects to worry about. Opinions on that are welcome.

 

Thanks!

[DEBRO]

Can anyone point to some clear examples of games that use 30hz flicker extensively? As opposed to the vastly worse 20hz or 15hz? I'm trying to get a handle on how appalling 30hz really is. In Stella it's either OMG TOTALLY APPALLING (without phosphor mode) or totally fine (in phosphor mode). While Pac-Man and Football still look awful even in phosphor mode (because they are 15hz games).

 

I'm trying to get a sense of what 30hz is like on an actual TV.

 

I'm thinking it may be acceptable to use 30hz, especially if I avoid it for those segments of the screen in which I don't currently have three independently positioned objects to worry about. Opinions on that are welcome.

 

Thanks!

Yar's Revenge uses 30Hz flicker for the shield.

[Nukey Shay]

IIRC, the shield in Yar's is made of playfield pixels.

 

There are a number of things that can make the effect look better or worse. Sprite size, for example. Or "solid" vs. "outline" shapes. Background color vs. foregound color vs. sprite color as well. The only way to know for sure is to write or edit a demo kernal of what you have in mind...but the most common cartridge example would probably be something like Frogger (for small sprites) or Asteroids (for large sprites) to see the effect on a television.

 

BTW I've never heard of 30hz flicker regarded as "appalling" back in the day.

 

Do you have a means of viewing a demo running on real hardware (ala Supercharger or Krokocart)?

[SeaGtGruff]

Can anyone point to some clear examples of games that use 30hz flicker extensively? As opposed to the vastly worse 20hz or 15hz? I'm trying to get a handle on how appalling 30hz really is. In Stella it's either OMG TOTALLY APPALLING (without phosphor mode) or totally fine (in phosphor mode). While Pac-Man and Football still look awful even in phosphor mode (because they are 15hz games).

 

I'm trying to get a sense of what 30hz is like on an actual TV.

 

I'm thinking it may be acceptable to use 30hz, especially if I avoid it for those segments of the screen in which I don't currently have three independently positioned objects to worry about. Opinions on that are welcome.

 

Thanks!

That depends on what kinds of examples you're looking for-- flickering the players to get additional players, or flickering to get additional colors! I can give you some examples of flickering to get additional players or colors, but not using an "intelligent multi-sprite flickering" routine, because I've never tried to write one, nor have I studied any such routines that other people have written.

 

Flickering does look different on a TV than on the emulators-- especially when the phosphor mode is enabled-- because the combined colors will look different on a TV. In general, the difference in the luminance values of the flickered colors will have the biggest effect on how noticeable the flickering is. For example, if you flicker between $00 (black) and $0E (white), the flickering will be extremely obvious. Keep in mind that when you flicker players, you're also flickering the colors, because the player color will be combined with the color of whatever is behind the player (i.e., the background, playfield, other player, ball, or either of the missiles).

 

I'm actually working on a flickering demo that draws a four-color playfield for an adventure game, but I'm nowhere near ready to post it yet! And once I get my demo up and running, there's still the "little" matters of how to store the map, as well as how to deal with "collisions." So doing a demo is one thing, and having something that could actually be used in a game is another thing.

 

Michael

[boutell]

IIRC, the shield in Yar's is made of playfield pixels.

 

There are a number of things that can make the effect look better or worse. Sprite size, for example. Or "solid" vs. "outline" shapes. Background color vs. foregound color vs. sprite color as well. The only way to know for sure is to write or edit a demo kernal of what you have in mind...but the most common cartridge example would probably be something like Frogger (for small sprites) or Asteroids (for large sprites) to see the effect on a television.

 

BTW I've never heard of 30hz flicker regarded as "appalling" back in the day.

 

Do you have a means of viewing a demo running on real hardware (ala Supercharger or Krokocart)?

This is very helpful, thank you.

 

Although the shield in Yar's is made of big pixels, it sure does look like it's flickering at 30hz. I'm guessing it alternates with the mystery zone in the middle.

 

I need to nail down a real 2600 (all I have in the house at the moment is a Flashback II - hey, it was a gift, at least it's an emulation of the original machine, unlike the awful Flashback I)... and I need a way to load games to it, yes. My understanding is that the old-school supercharger is an ebay item, the cuttle cart is sold out forever, and the krokocart... I'd never heard of that before and it's very interesting. But I haven't found a home page for it, just some tantalizing references. Got more information?

 

My game ideally calls for ten fully independent player sprites. Har har har. In the real world, what I have so far is:

 

1. A set of three sprites which are independent except that they can't share scanlines (that works for my purposes).

 

2. A set of three additional sprites which are "slaved" to the first three in that they must share Y coordinates with the first three - but their X coordinates are independent.

 

3. Two "extra" sprites that are faked with NUSIZ0 but don't have any independent behavior. That's a viable compromise for me too.

 

4. The hard part: two truly independent sprites above and beyond all that. This is where I punted and went to 30hz flicker - the independent sprites are P0 and P1 of the second 30hz "phase," the other sprites are displayed in the first 30hz "phase."

 

Unfortunately missile or ball graphics wouldn't cut it for my purposes.

 

What I have now works, but I'm thinking I need to do some optimization of flicker to better justify using 30hz when it is truly needed. There are two independent sprites which could conceivably overlap the other sprite types, and that is the only time 30hz is needed. I'm pretty sure there are a maximum of five changes between the flickering and nonflickering behavior. So with subkernels...

 

I'm probably going into too much detail here, but yeah, I've got ideas. (:

 

Thanks again!

[boutell]

Do you have a means of viewing a demo running on real hardware (ala Supercharger or Krokocart)?

 

I found some Kroko Cart info. Looks like there is an... impressive backlog of orders. (: I'm thinking I'll push to get the game working very well indeed and possibly beg a few test runs by owners of such hardware before forking over $100+, though I'd love to!

[Nukey Shay]

Although the shield in Yar's is made of big pixels, it sure does look like it's flickering at 30hz. I'm guessing it alternates with the mystery zone in the middle.

Nono...I just meant that it wasn't a sprite. It is alternating at 30hz (due to it sharing time with the "random" playfield pixels at the center of the screen). The enemy and the Yar are made of the 2 8-bit sprites and therefore don't need flicker.

 

I need to nail down a real 2600 (all I have in the house at the moment is a Flashback II - hey, it was a gift, at least it's an emulation of the original machine, unlike the awful Flashback I)... and I need a way to load games to it, yes. My understanding is that the old-school supercharger is an ebay item, the cuttle cart is sold out forever, and the krokocart... I'd never heard of that before and it's very interesting. But I haven't found a home page for it, just some tantalizing references. Got more information?

A search here would return more than I could give at the moment...I dunno offhand if the cartridge is still being sold either. I was just wondering what drew you to the word of choice, and you just answered it (it's based on emulation experience only...don't let that scare you).

 

My game ideally calls for ten fully independent player sprites. Har har har. In the real world, what I have so far is:

 

1. A set of three sprites which are independent except that they can't share scanlines (that works for my purposes).

 

2. A set of three additional sprites which are "slaved" to the first three in that they must share Y coordinates with the first three - but their X coordinates are independent.

 

3. Two "extra" sprites that are faked with NUSIZ0 but don't have any independent behavior. That's a viable compromise for me too.

 

4. The hard part: two truly independent sprites above and beyond all that. This is where I punted and went to 30hz flicker - the independent sprites are P0 and P1 of the second 30hz "phase," the other sprites are displayed in the first 30hz "phase."

 

Unfortunately missile or ball graphics wouldn't cut it for my purposes.

Game kernals rarely run from top-to-bottom regarding how they are coded (except for very old games, maybe). A game kernal is normally broken down into sub-kernals that handle specific needs for a given scanline. This makes the display less flexible, but ram requirements are minimized (based on it's complexity). Sounds like Frogger's display method should work for you...seperate "bands" of display for objects that are imprisoned on certain scanlines, while 2 independant objects share time with the band it's on at 30hz. Flicker is only needed in this case on the shared band (a simple counter can be used to instruct the kernal when to branch off and use this routine opposed to the regular non-flickering band...like comparing the current scanline count held in Ram with the Y-axis of the new objects' also held in Ram).

 

What I have now works, but I'm thinking I need to do some optimization of flicker to better justify using 30hz when it is truly needed. There are two independent sprites which could conceivably overlap the other sprite types, and that is the only time 30hz is needed. I'm pretty sure there are a maximum of five changes between the flickering and nonflickering behavior. So with subkernels...

Depends on where they are and sprite spacing. Common 6-digit score routines have enough cycle time to do 6 changes with a bit of spare cycle time (the tradeoff being sprite positioning, of course). If ram were used as a self-modifying routine, more time could be saved...$absolute loading instead of ($indirect). But pulling off more than 6 sprites on a scanline is more complexity than I could help with. Edited January 29, 2007 by Nukey Shay

[boutell]

Game kernals rarely run from top-to-bottom regarding how they are coded (except for very old games, maybe). A game kernal is normally broken down into sub-kernals that handle specific needs for a given scanline. This makes the display less flexible, but ram requirements are minimized (based on it's complexity). Sounds like Frogger's display method should work for you...seperate "bands" of display for objects that are imprisoned on certain scanlines, while 2 independant objects share time with the band it's on at 30hz. Flicker is only needed in this case on the shared band (a simple counter can be used to instruct the kernal when to branch off and use this routine opposed to the regular non-flickering band...like comparing the current scanline count held in Ram with the Y-axis of the new objects' also held in Ram).

Sure, I've seen a lot of this. Unfortunately I can't completely imprison anything to a particular scanline, it really wouldn't work for the game I have in mind (although I'll try to question that assumption some more). But I can at least impose some limitations that will allow me to do something *like* that but have some vertical liberty in some situations that will add much more verisimilitude.