TheDoc

700!

I wanted to explore some ideas on improving the flickering mechanism of games that require heavy use of objects. There were several ideas I wanted to incorporate into the solution. The first idea was reserving a range of objects that have a higher priority, which should always be solid and never flicker. High priority objects might include the player character sprite, the most dire projectiles, etc. The second idea was to draw objects non-sequentially, so that their flickering happens in a less noticeable pattern. Even when cycling a starting offset, as long as several objects are drawn in the same order, there is a noticeable wave pattern that moves across the screen. Having a starting offset that jumps around the range of available objects may make this less noticeable. The OAM index selection should be fast and require very little logic to remain consistent. To help determine a suitable index selection routine, I wrote a JavaScript function that takes an array range, and finds the possible value increments that will fill the entire array and wrap back around to the first index when it's full. For base 2 numbers, this happens to be every odd number. Evens are always ruled out. With a high-priority reserved set of objects, the remainder can be used to determine valid increments, which can then be tested in a game to find the most pleasing result. I have been calling this a "skipterate" strategy, for skip-iteration. I've created a demo that tests a range of skip values with a reserved player sprite, with non-player sprites that can display in several different patterns. For each object movement and placement pattern, skipterate values will make a very noticeable impact. The example patterns are definitely impractical for real games, but the overkill is intentional to test out the effectiveness of the idea. The plot of many martial arts movies involves an idea that can be paraphrased as: "Now that you've spent all this time learning this subject, you must never use it." Similarly, this wouldn't be a proper NES dev article without a list of reasons not to use this technique. Some things to consider before implementing this approach: Is there a way to achieve your goal without using more than 8 objects per scanline? The ideal method is to have no flicker at all. If you can replace sprite activity with buffered nametable updates, that would have a better looking result. If you are able to consolidate objects or reduce the width of sprites, that would also help. With more than eight objects per line, is your flicker not producing a wave effect? If there is no noticeable gap panning across your objects, then it may be fine as-is. Be sure to prototype your idea, and you may find the result is already acceptable. Could your level layout or sprite movement behaviors be altered to reduce the chance of accumulating sprites on a single scanline? This may be more difficult to cope with for certain games, but if sprites can span more vertical space, it could greatly improve visuals. I've attached the JS functions and the sample project here. Does this have a practical application? Will it make a bullet-hell game bearable? Is it utterly useless? Was I too vague without example code? Let me know your opinions on the matter. skipterate.js flicker-test.nes