A better way to scramble the sprites for flickering

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Sivak
Posts: 323
Joined: Tue Jul 17, 2007 9:04 am
Location: Somewhere

A better way to scramble the sprites for flickering

Post by Sivak »

So, I'm wanting to put enemies into the game soon. In BK1, the way I did the flickering was like this:

Had a thing that got EOR'd each frame. Basically, it made it go like this in terms of sprite order:
0 - Timmy, Timmy's shots, all enemies in sequential order
1 - All enemies, Timmy, Timmy's shots

The main problem with the sequential order is if things get stacked, something will always be invisible.

I was thinking of keeping the routines for drawing stored in memory and then using the EOR'd memory to go to a secondary routine that'd read them in in a different order... for instance, it might go like this:
0 - Timmy, shots, enemies #1-16
1 - Enemies 16-1, Timmy, shots

Does this approach sound reasonable? Thanks.
-Sivak
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I process all my objects (including the main character) in (pseudo)random order. I get a number from my PRNG and use it to make the index of the first object to process, and then I add some odd number to it (like 7) after each object is done (wrapping back when necessary). It is simple and has worked well so far, but I don't know if that would work well for everybody.

I decided to "randomize" objects rather than individual sprites because I need to be able to stack sprites, I must have some control over their priorities, and this way I full control of the priorities of each object's sprites.

For controlling the priority between different objects I have created 2 virtual layers, and objects that must be on top are rendered to the lower end of the OAM (closer to 0) and low priority ones are rendered to the upper end of the OAM (closer to 63). The OAM gets full when/if both lists meet (although I should let high priority sprites overwrite low priority ones I guess).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Having the player see the most recent shot at all times is important for visual feedback to reinforce the connection between the fire button and the shots. So I'd recommend always putting Timmy and the first shot first, and then mixing the other two shots with enemies. Skip through enemies by threes or fives, and cycle through them starting at 0, 1, and 2, or 0, 2, 4, 1, 3.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

The really easy way to do OAM cycling:
Whenever you add a sprite to the list, advance 9 sprites (36 bytes).
If after adding a sprite, you end up at the start position, you have transferred 64 sprites, so that's a good time to stop. That's just an 8 bit comparison.
You can also advance the start position by one sprite (4 bytes) every frame.

Only downside to this method is that you lose any form of sprite priority.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Post by Drag »

Split your OAM into two partitions, where one partition has the OAM shuffling performed on it, and the other partition doesn't.

Have the non-shuffling OAM have priority over the shuffling OAM.

With this method, you can maintain a little more control over sprite priority.
Wave
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave »

I do object reversing + random OAM start address + advance OAM in 7 entries each frame
Post Reply