Charge!

[SeaGtGruff]

when flickering, objects are half as bright, so increasing their brightness evens out similar objects not flickering overall.

Not necessarily-- it depends on the two colors involved. If you're flickering an object (playfield, ball, player, or missile) against a black background, then yes-- the object's perceived color will be about half as bright as normal. But if you're flickering that same object against a *white* background, it will be *brighter* than normal.

 

However, the suggestion of increasing the brightness is a good one, although it should be phrased in terms of adjusting the object's hue and luminance as needed to try to maintain a more consistent appearance (color) for the object whether it's flickering or not flickering. For example, if the unflickered object is orange, and is displayed against a red backdrop, then you might want to change its color to yellow when you're flickering it, so the result will be orange (yellow plus red).

 

Generally speaking, flickering can give inconsistent results depending on the display device (as pointed out by theloon), and some people are more sensitive to it than others ("Aaaahhh! My eyes! My eyes!"), which makes it tricky to use in a game. But getting back to what I'd intended to say in my first post, tweaking the hues and/or luminances of the colors that are being flickered together (whether it's changing the color of a sprite between frames, or alternating between the sprite's color and the background color between frames) could significantly reduce the amount of flashing or "strobing" that's perceived by the viewer.

 

Another consideration is what the intent is-- using flicker to create the appearance of more colors, or more sprites. If you're trying to get more sprites, then you might want to keep the hues closer to each other on the YIQ/YUV color wheel, as hues that are directly opposite each other will create a shade of gray when flickered together. But if you're trying to get more colors, then it doesn't really matter where on the color wheel the two hues are in relation to each other-- in fact, you might even *want* them to create a shade of gray. And even if you're going for more sprites, you still might want the two colors to make gray. For example, I was designing a hi-res 96-pixel bitmapped title screen for a Christmas-themed game that I may or may not ever make, and I wanted the text to be white on red-- so I used red (or really more of a dark pink) for the background and light green for the letters (players), which produced text that was as close to white as I could get it.

[DT Kofoed]

Will there be more work on this one, or should we all consider it finished at this point?

[Mountain King]

This game is so much fun. What happened this it?

[+atari2600land]

I doubt there will be more. jrok disappeared.

Edited May 3, 2015 by atari2600land

[+ZeroPage Homebrew]

We'll be featuring Charge! LIVE on tomorrow's (Sunday) ZeroPage Homebrew stream on Twitch at 12PM PT | 3PM ET | 8PM GMT! Hope everyone can watch!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

Games:

• UFO LCD (Exclusive Premiere!) (2020) by Scott Dayton @neotokeo2001 / NEOGames
• Charge! (2011 WIP) by Jarod D. Kitchen aka @jrok
• Star Crusade (2012 WIP) by Jarod D. Kitchen aka @jrok
• Armageddon Complex (2009 WIP) by Jarod D. Kitchen aka @jrok
• Circus Galacticus (2011 WIP) by Jarod D. Kitchen aka @jrok

 

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

Edited March 16, 2020 by ZeroPage Homebrew

[Legend]

Sorry for the necrobump, but I just got a Harmony encore cart and really wanted to play Charge! On it as it was one of my favorite homebrews of Jrok's. I can't seem to get it to run though.

 

The yin yang just keeps spinning when I try to start. 

 

Is there a Harmony cart compatible version that I am not aware of?

 

Thanks.