DEMO - Impossible Mission (not WIP or Game)

[rsiddall]

**Updated** to preface this as a demo and not a game in progress. Had a few people inquire and wanted to address.

I'll try to post as "demo" if it's something that I'm not able to follow to completion. Possibly including .bas/.txt files for others.

 

 

So this is similar to what was happening with color choices on my LCP screensaver.

I had to swap out colors for others because of the amount of flickering or vibrating the choices made when using multisprites in DPC+.

 

I'm attaching an example here to illustrate what I'm referring to:

If you look at the robot on the second floor (original photo), he's almost invisible due to the green background.

If I change the background to black (recolored), he's almost solid and very easy to see.

 

I've messed around with changing the robot colors to see if I could fix this problem going as far as just having 1 sprite/1 color to see if it made a difference (it did not).

If you notice the elevator/platform on the left, it isn't affected by the different color choices...it's solid and remains unchanged.

 

Is this something that could easily be solved (possibly a coding issue where I'm confusing colors with my poor programming) or is this just how it is?

Edited June 21, 2022 by rsiddall
Renaming of post for clarification.

[+ZeroPage Homebrew]

Oh my... I'll have to show Tanya these screenshots, they look great!

 

Impossible Mission is one of her favourite games!

 

- James

[rsiddall]

5 minutes ago, ZeroPage Homebrew said:

Oh my... I'll have to show Tanya these screenshots, they look great!

 

Impossible Mission is one of her favourite games!

 

- James

I'm in over my head but thanks for the support!

I'd prefer to drop the puzzle solving and just have the levels to play. 

[orange808]

I would abandon the idea of using both sprites to draw your on screen assets. Try exploiting the Atari's colors (no pallete restrictions) and the background color (black really is easier sometimes).

 

 

 

 

[rsiddall]

When you say "Atari's colors" is there an approved/accepted list?

I've been using the one here: TIA COLOR NTSC as well as this one: PlayerPal.

 

Color-clashing seems to happen frequently. Or what appears on the emulator is not what I get on the real hardware.

 

I realize some concessions have to be made...but I still like the level of detail overlapping sprites give.

 

Edited May 25, 2022 by rsiddall

[+Karl G]

When you flicker a sprite against the background, you are effectively mixing colors with the background. I am personally a big fan of black backgrounds because of things standing out better. One thing that can help is having a background that is the lowest possible brightness, and having your sprite colors have a high brightness for contrast. Vice versa would probably work as well. Another trick that some homebrews use is increasing the brightness of colors on a Sprite only when it is flickering, but I don't know of a way to detect when those kernels are doing their automatic flicker.

[rsiddall]

15 minutes ago, Karl G said:

When you flicker a sprite against the background, you are effectively mixing colors with the background. I am personally a big fan of black backgrounds because of things standing out better. One thing that can help is having a background that is the lowest possible brightness, and having your sprite colors have a high brightness for contrast. Vice versa would probably work as well. Another trick that some homebrews use is increasing the brightness of colors on a Sprite only when it is flickering, but I don't know of a way to detect when those kernels are doing their automatic flicker.

I'm with you on the darker backgrounds, and believe the vice-versa you mentioned should work as well: A darker robot (even if it's built with 2 sprites) should show up better on a lighter background - correct?

 

I changed the red/pink robot to darker colors, even changed it to a one-colored/single sprite (black) and it still appeared "transparent". There shouldn't be flickering that apparent unless there's sprite "overlap".

 

But when I change the background to black, this all resolves itself. So it's a little perplexing when things don't seem to follow logic.

[rsiddall]

If I hang things from the ceiling (i.e. searchable computer), I can get at least 2 items on each floor without a lot of flicker.

[Thomas Jentzsch]

5 hours ago, Karl G said:

One thing that can help is having a background that is the lowest possible brightness, and having your sprite colors have a high brightness for contrast. Vice versa would probably work as well.

Regarding the latter: I don't think so, at least on CRTs. That's because of the phosphor effect.

 

So bright flickering objects over a dark background works, the opposite does not do that well.

[Erik Zimmermann]

very good sprites!

i use this example in my games. 

 

4_multicolor_sprite_flicker.bas

Edited May 25, 2022 by Erik Zimmermann

[Lillapojkenpåön]

11 hours ago, rsiddall said:

But when I change the background to black, this all resolves itself. So it's a little perplexing when things don't seem to follow logic.

It does if you think about it.

If the sprite is only on screen every other frame and your background is black it's like you're mixing the spritecolors with 50% black, so they just become darker.

But if you mix them with yellow, they become another color, in your case allmost invisible since the spritecolors are warm colors not far from yellow.

 

It's the same as having the sprite layer on top of the bg layer in photoshop and putting the opacity of the sprite to 50%

Flickering is how you create transparency on the 2600.

Black looks awesome.

[Thomas Jentzsch]

The different hues are not so much a problem. What you see is the result of how CRTs (and Stella's emulation) react to value (brightness) changes. A raise in level is (almost) immediate, a decay takes much longer.

 

So, assuming 30Hz flicker, when you combine a fully bright sprite with a fully dark background, the sprite will be fully displayed when it is enabled and ~50% displayed when disabled. Vice versa you will have fully display background when the sprite is disabled and an ~50% displayed sprite when it is enabled.

 

On average that's 75% vs. 25% sprite display. BIG difference.

Edited May 25, 2022 by Thomas Jentzsch

[orange808]

It's a perception thing. Here's a good video of a CRT in action.

 

 

[rsiddall]

2 hours ago, Thomas Jentzsch said:

The different hues are not so much a problem. What you see is the result of how CRTs (and Stella's emulation) react to value (brightness) changes. A raise in level is (almost) immediate, a decay takes much longer.

 

So, assuming 30Hz flicker, when you combine a fully bright sprite with a fully dark background, the sprite will be fully displayed when it is enabled and ~50% displayed when disabled. Vice versa you will have fully display background when the sprite is disabled and an ~50% displayed sprite when it is enabled.

 

On average that's 75% vs. 25% sprite display. BIG difference.

I mentioned in another post (LCP) dropping my monitor refresh rate to 60Hz to achieve a more acceptable flicker (versus the 75Hz) and pushing phosphor to 60% on Stella. I think it was the color combos that were throwing me...but your explanation covers it nicely. Thank you!

[rsiddall]

3 hours ago, Lillapojkenpåön said:

It does if you think about it.

If the sprite is only on screen every other frame and your background is black it's like you're mixing the spritecolors with 50% black, so they just become darker.

But if you mix them with yellow, they become another color, in your case allmost invisible since the spritecolors are warm colors not far from yellow.

 

It's the same as having the sprite layer on top of the bg layer in photoshop and putting the opacity of the sprite to 50%

Flickering is how you create transparency on the 2600.

Black looks awesome.

Black does look better...I just wanted something more authentic to the C64 version. ?

 

[Trip2018]

Flickering is, in a sense, a blending of colors. What I would recommend, is overlapping the first layer with the second, that way those areas blend with each other instead of the background. While the first sprite will still blend with the background, both will blend each other and make the sprites more obvious.

Edited May 25, 2022 by Trip2018

[Sohl]

7 hours ago, Trip2018 said:

Flickering is, in a sense, a blending of colors. What I would recommend, is overlapping the first layer with the second, that way those areas blend with each other instead of the background. While the first sprite will still blend with the background, both will blend each other and make the sprites more obvious.

If I understand what you're saying, I tried that but didn't like the overall look for my work-in-progress game.  In one section of the game that I want to use only one sprite for the game object but make it appear to have two colors per scanline.  I tried it with one version of the sprite as a sort of a silhouette , with the other frame having the "accent" color sprite with transparent pixels, but it made the accent color rather washed out and not the right color I wanted:

 

Alternatively, if I separate the two sprites so that the pixels of accent color are transparent in the other sprite, it mixes uniformly with the background, which works better I think in my case:

 

It's a bit muted but I think it looks OK and I can explain it away as as a "fluid immersion" effect!  Maybe I'll revisit this before final release, but I have a whole lot of other things I want to work on, so it won't be a high priority now that I think it works decently well in my game.

 

 

[rsiddall]

Here's a quicktime movie showing the flickering after I've adjusted some of the colors.

I've updated the running, too. I think it's a little more accurate to the original game.

Edited May 26, 2022 by rsiddall

[Thomas Jentzsch]

Looks good, but you should not rely on that high phosphor settings. These will not be reproducible on real hardware. Using only one sprite and changing color per line will work much better.

[rsiddall]

On 5/26/2022 at 1:20 AM, Thomas Jentzsch said:

Looks good, but you should not rely on that high phosphor settings. These will not be reproducible on real hardware. Using only one sprite and changing color per line will work much better.

Cool. Actually, I didn't bump the phosphor up (I've got it at 60% where it's been since the get-go).

 

My running man is set-up as player0 and player2. I was messing around with the order of the numbers in the animation (i.e. had player0 graphics first with player2 graphics second) and noticed that if I reassigned the number (player0 --> player2) it caused less flickering and brighter colors.

 

Edited June 1, 2022 by rsiddall

[+Gemintronic]

Player seems to glitch out and disappear when I hold FIRE and move left or right.

 

That being said I'm super impressed!  I'm not brave enough to tackle DPC+ yet

 

 

[rsiddall]

8 minutes ago, Gemintronic said:

Player seems to glitch out and disappear when I hold FIRE and move left or right.

 

That being said I'm super impressed!  I'm not brave enough to tackle DPC+ yet

 

 

Sorry, yes...I disabled the jump animation for now. In the real versions, it's more of a tuck-and-roll and my pitiful "Pitfall Harry" jump didn't look good. ?

 

I'm more of a tinkerer and DPC+ seems to be an extension of the standard kernel with some exceptions. Most of what you are doing in the standard kernel carries over. 

 

My biggest problem is I get bored or want to move on after the graphics get to the point where I'm happy with them.

[orange808]

No. bB DPC+ is not really an extension of the standard kernel. The standard kernel isn't limited because it's primitive or it was poorly written. bB DPC+ isn't an optimization of the standard kernel; it does more because Harmony cart hardware adds additional processing power. DPC+ also leverages a different HMOVE technique.

 

It's only an extension in spirit. Both kernels try to provide a general purpose display for making games.

 

bB DPC+ updates both the state and color of:  the players, background, and most of the playfield (playfield 0 is blank) every single scanline. The missiles are every other scanline. I don't remember if the ball is every scanline; I think it's every other scanline. Additionally, the DPC+ kernel includes "built in" flicker handling for player 1 and repositions player 1 after six scanlines. Pretty good.

 

bB DPC+ uses a technique called cycle 73/74 HMOVE to reposition player 1 sprites. The standard kernel hits HMOVE in the standard fashion. Otherwise, it would have required eight blank scanlines or a symmetrical playfield for bB DPC+ to do its "virtual sprite" work. The 73/74 HMOVES also prevent the signature small horizontal lines that manifest inside playfield 0 on the left side of the screen when you hit HMOVE during the kernel, but playfield 0 is blank (doesn't matter much). You give up the theoretical ability to draw slanted vertical lines with the missiles or ball and compatibility with the 2600 Jr to reduce flicker.

Edited May 26, 2022 by orange808
clarity

[rsiddall]

59 minutes ago, orange808 said:

It's only an extension in spirit. Both kernels try to provide a general purpose display for making games.

Would it be fair to say if you're comfortable in the standard kernel, making the transition to DPC+ wouldn't/shouldn't be as intimidating as one might think?

 

That was the point I was trying to make.

Edited May 26, 2022 by rsiddall

[orange808]

22 minutes ago, rsiddall said:

Would it be fair to say if you're comfortable in the standard kernel, making the transition to DPC+ wouldn't/shouldn't be as intimidating as one might think?

 

That was the point I was trying to make.

The development experience is going to be similar between all the flavors of bB kernels. Each particular kernel has unique trade-offs, so switching between them will always require a little adjustment, but I can't see why any one kernel would be significantly more intimidating than another.