| |
knue
Registered: Dec 2012
Posts: 37 |
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. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"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. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
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? |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
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. |
| |
knue
Registered: Dec 2012
Posts: 37 |
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:
0
1234
5
6
7
89ab
cdef
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. |
| |
knue
Registered: Dec 2012
Posts: 37 |
@oziphantom this sounds promising. But I didn't get the idea at 100%. What exactly do you mean with bucket? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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
23451
34512 |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
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 ;) |
| |
Digger
Registered: Mar 2005
Posts: 437 |
@knue: Would you mind posting a .prg of how it works now? (with flickering)? |
| |
knue
Registered: Dec 2012
Posts: 37 |
@Digger: Sources are here:
https://github.com/leissa/c64engine.
You can also grab the binary here:
https://github.com/leissa/c64engine/blob/master/engine.prg
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. |
