rsiddall Posted May 24, 2022 Share Posted May 24, 2022 (edited) **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. 5 Quote Link to comment Share on other sites More sharing options...
+ZeroPage Homebrew Posted May 24, 2022 Share Posted May 24, 2022 Oh my... I'll have to show Tanya these screenshots, they look great! Impossible Mission is one of her favourite games! - James 1 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 24, 2022 Author Share Posted May 24, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
orange808 Posted May 24, 2022 Share Posted May 24, 2022 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). 2 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 25, 2022 Author Share Posted May 25, 2022 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted May 25, 2022 Share Posted May 25, 2022 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. 2 1 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 25, 2022 Author Share Posted May 25, 2022 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. Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 25, 2022 Author Share Posted May 25, 2022 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. 5 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 25, 2022 Share Posted May 25, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Erik Zimmermann Posted May 25, 2022 Share Posted May 25, 2022 (edited) very good sprites! i use this example in my games. 4_multicolor_sprite_flicker.bas Edited May 25, 2022 by Erik Zimmermann 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted May 25, 2022 Share Posted May 25, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 25, 2022 Share Posted May 25, 2022 (edited) 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 2 2 Quote Link to comment Share on other sites More sharing options...
orange808 Posted May 25, 2022 Share Posted May 25, 2022 It's a perception thing. Here's a good video of a CRT in action. 1 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 25, 2022 Author Share Posted May 25, 2022 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! 1 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 25, 2022 Author Share Posted May 25, 2022 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. ? 1 Quote Link to comment Share on other sites More sharing options...
Trip2018 Posted May 25, 2022 Share Posted May 25, 2022 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
Sohl Posted May 26, 2022 Share Posted May 26, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 26, 2022 Author Share Posted May 26, 2022 (edited) 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. Flicker.mov Edited May 26, 2022 by rsiddall 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 26, 2022 Share Posted May 26, 2022 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. 3 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 26, 2022 Author Share Posted May 26, 2022 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 26, 2022 Share Posted May 26, 2022 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 1 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 26, 2022 Author Share Posted May 26, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
orange808 Posted May 26, 2022 Share Posted May 26, 2022 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
rsiddall Posted May 26, 2022 Author Share Posted May 26, 2022 (edited) 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 Quote Link to comment Share on other sites More sharing options...
orange808 Posted May 26, 2022 Share Posted May 26, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.