Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > C64 Coding > controlled sprite flickering
2017-10-01 19:22

Registered: Dec 2012
Posts: 23
controlled sprite flickering

I'm also currently working on a sprite multiplexer. I'm using hires overlays for multicolor sprites. So just 4 sprites per scan line and I'm working with 24 (6 x 4x2) virtual sprites.
Basically everything works - including sorting in Y-coords. The multiplexer switches to a new sprite if there is time. otherwise, the sprite is skipped. This decision is done on the fly without preprocessing. The problem is, that it's quite annoying when a sprite is skipped. I'd like to have some controlled flickering such that the missed sprites are shown in the next frame, for example. Has somebody experience with that?

I also tried this:
Use 4 zones. Each zone has support for 4x2 sprites. If two zones overlap: show one zone in every odd the other in every even frame.
If all four zones overlap, each zone is only displayed every fourth frame. This controlled flickering really doesn't look that bad. Problem here is that I can have flickering where the technique above wouldn't flicker at all. For example. Say you have 1 sprite and then a cluster of 4 sprites. The zones overlap but the first technique wouldn't flicker. Another problem is that this zone technique works best with powers of two. So 6 zones to support my 24 sprites is ugly. On the other hand, if contorlled flickering works nicely I could also use 8 zones...

So, any suggestions?

I'd also be fine with some heuristic which only works with two of those 4x2 clusters but not more.
2017-10-02 05:25

Registered: Apr 2002
Posts: 4255
"The multiplexer switches to a new sprite if there is time. otherwise, the sprite is skipped."

no experience here but imho some flag should be set on prvs / next sprite (middle skipped) that it should be skipped next time instead.
2017-10-02 11:44

Registered: Feb 2003
Posts: 671
I have a hard time to visualize how your sprites are moving around.. Do these "zones" somehow come natural from what you are displaying or is it just some sort of "divide and conquer" thinking?
2017-10-02 12:08

Registered: Oct 2014
Posts: 182
AKA the NES method.

What you do is you take your "buckets", and then flip the order each frame. So if you have 10 sprites in a "zone"
1 2 3 4 5 6 7 8 9 10
you do 1- 8 one frame than 10-2 the next frame.

If you just do it on the fly without buckets bit hard to do. You would need to have a priority field that you also sort, so you Y sort, then Priority sort. When a sprite gets dropped you boost its Priority for the next frame.
2017-10-02 12:14

Registered: Dec 2012
Posts: 23
The first approach doesn't use zones.

The second approach uses 16 virtual sprites with 4 zones - each zone having 4 x 2 sprites. All virtual sprites are sorted in y-direction. The first 4 sprites live in zone 1, the next 4 in zone 2 and so forth. So these are *not* natural areas. More some sort of divide & conquer thinking.
The zones are always like this:
As the zones are always like this:
1: 0123
2: 4567
3: 89ab
4: cdef

So, if the sprites happen to be like this on the screen:







zone 1 and 2 overlap causing controlled flickering. zones 3 and 4 are fine. However, the on-the-fly technique wouldn't flicker at all because after displaying sprite 0, it re-uses this sprite and is fine in displaying the sprite strip 1234 and so on.
2017-10-02 12:17

Registered: Dec 2012
Posts: 23
@oziphantom this sounds promising. But I didn't get the idea at 100%. What exactly do you mean with bucket?
2017-10-02 13:51

Registered: Apr 2002
Posts: 4255
if you have more than 4 virtual sprite in a zone you should rotate the order of the virtual sprites so always something else is last and gets dropped.

1234 displayable sprites

12345 virtual sprites rotated
2017-10-02 14:32

Registered: Oct 2014
Posts: 182
Buckets is a allocation concept. So you make N "buckets" that hold 8 sprites each, or 4 in your case. So you then fill the bucket with your sprites, when you overflow then you need to pour into the next bucket. To solve the problem with 1 then 4, you kind of need to make groups of near y sprites, then do a largest first fit allocation. So you make a "group" that has 4 and a group that has 1. So you put all 4 into a "bucket" first, then the 1, this way you don't get the should fit but doesn't problem. But yes it eats clocks, however you take the general case of once sorted sprites only move 1~4 pixels at a time so you only have to do 1~2 sprites moving between buckets . Unless your code is different and then you will need to make a special case for your special case ;)
2017-10-02 18:15

Registered: Mar 2005
Posts: 279
@knue: Would you mind posting a .prg of how it works now? (with flickering)?
2017-10-03 14:43

Registered: Dec 2012
Posts: 23
@Digger: Sources are here:
You can also grab the binary here:

This is the on-the-fly technique. If you are also interested in the zone technique, let me know - it's still somewhere around in the git repo but was never as mature as the current multiplexer.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Heavy Stylus/RGCD
Guests online: 42
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Comaland 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 Lunatico  (9.6)
8 We Come in Peace  (9.5)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Pandemoniac Part 2 o..  (9.5)
4 Treu Love [reu]  (9.5)
5 Merry Xmas 2017  (9.4)
6 Arok 20 Invitation  (9.4)
7 Dawnfall V1.1  (9.4)
8 In Memoriam BHF  (9.4)
9 Dawnfall  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.6)
2 Newscopy  (9.4)
3 Peter  (9.3)
4 A Life in Hell  (9.2)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.053 sec.