Jump to content

Photo

Fighting the flicker in DPC+

dpc+

3 replies to this topic

#1 bjbest60 OFFLINE  

bjbest60

    Space Invader

  • 33 posts
  • Location:Space Cactus Canyon

Posted Sat Jan 28, 2017 11:45 AM

Hello all,

 

I'm wondering if there are any clever workarounds to the flicker that occurs when two virtual sprites overlap in the DPC+ kernel.

 

For some parts of my game, I have the sprites on separate rows, so that's not a problem.  But on several stages, the player (player0) needs to touch a goal sprite (player2) that's fixed in position while player1, an enemy, can chase player0 all over the playfield.  So inevitably player1 and player2 will overlap at times.

 

I tried alternating drawing player1 and player2 each frame, but that only induced a perma-flicker. (Is that what bB is doing to make the flicker in the first place?)

 

My guess is that there's no way around this, but I thought I'd ask.  Thanks for any advice!



#2 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,851 posts

Posted Wed Feb 1, 2017 11:05 AM

Virtual sprites are literally one sprite.  The best the 2600 can do is alternate sprite graphics and position between frames.  The underlying DPC+ kernel is doing this as fast as possible.  If we use bB functions to do the same thing it would never be as optimal.

 

So, short answer is no.

 

Long answer is you can try to use other resources to mitigate this.  Say, make part of the playfield look like the second sprite.  You can stack multiple character graphics vertically in one sprite to appear to have more objects on screen.  Also, using flicker you can change the size and shape of missiles and the ball to make more sprite like objects - say, the ball is the sword hilt one frame and the sword body the other frame.

 

There is also the technique of just never allowing gameplay to require more than two sprites to share the same horizontal space.  I do this in my game Conjoined.  On constrained systems like the 2600 it's easier to find neat things it can do and build a game around that then force it to do things it can't.



#3 bjbest60 OFFLINE  

bjbest60

    Space Invader

  • Topic Starter
  • 33 posts
  • Location:Space Cactus Canyon

Posted Fri Feb 3, 2017 12:41 PM

Thanks for the reply.  Kind of a bummer, but it's pretty much what I figured.  Thanks for some alternate possibilities.  This is my first game with bB, so I'm definitely learning about what works well and doesn't.  I'll live with the flicker for this one.  (Hope to have a beta version out reasonably soon.)  I've already got ideas for new games that work with the constraints!



#4 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,402 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Fri Mar 31, 2017 6:42 PM

Also, even having the same rate of flicker, 

colors and how bright the objects of background, playfield and sprites

affect flicker perceived as okay or terrible. 

 

Some combinations are less noticeable,

and some really seem to strobe terribly. 

Complimentary colors & darker it is less noticeable. 

Contrasting colors and brightness are more annoying. 

 

If you want flicker to be less noticeable, when the sprites flicker make them one step brighter. 

That goes against what I wrote above, but sometimes it is better to 

not have the darkening / dimming. 

A flickered value $44 is darker than a solid value $44. 







Also tagged with one or more of these keywords: dpc+

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users