I had asked about this in IRC a few times and I got an answer that seemed the most logical. Basically, the idea involved writing to different spots in the DMA each frame and writing $F8 to every sprite Y position beforehand to hide the unused ones.
The only downside to this method is having to use a full 256 bytes of RAM to do it in addition to the sprite RAM.
My memory is in this fashion: Approx 55% of $0200 for the music engine. Some more of it is for some backup variables and also for the player's shot variables. $0300 is set aside for anything enemy/object related. $0400 is sprite memory. $0500 holds the tile solidities (is that a word?) in the rooms. Uses 192 bytes. $0600 and $0700 are generally only used as temp space when a new room is to be drawn. I'm thinking of using $0600 for this flicker method and leaving $0700 open for any random stuff I might need during gameplay.
So what I would do is something like this:
-Allocate 4 sprites to the player
-Allocate 3 to the shots
-The rest for the enemies/objects. Each enemy has some info in it telling how many total sprite tiles are needed.
After the allocation is done and all enemy updates are okay, I do the write from $0600 into part of the sprite memory, but in a different order each frame. What I was thinking of doing was something like having the player and shots be written after the enemies in one frame and then before the enemies in the following and it alternates in this fashion.
As always: Does this sound reasonable?
Being the player in the game, if I start flickering, I'd probably be getting annoyed. I haven't had to do any sprite sorting yet, but I would give the player highest priority.
The easiest and most common method for oam cycling (fancy term for flickering), is to alternate between writing the sprites forwards and backwards each frame. This flickering just looks like stable flickering tiles, but you wouldn't be able to have more than 16 sprites per scanline. (not like it's usually a problem or anything
) Megaman uses this method.
Another method I've seen was to use the above method, but also write at an offset which changes each frame, the data wrapping around when it gets to the page boundary. This flickering looks more like a rippling effect, in addition to the alternating-every-frame flickering like the first method produces. It allows more than 16 sprites per scanline, but some sprites end up more transparent than others. Castle Excellent does this, so you could check that out for an example.
Your method seems like it'd be fine, so I'd say go for it.
Sivak wrote:
What I was thinking of doing was something like having the player and shots be written after the enemies in one frame and then before the enemies in the following and it alternates in this fashion.
This is exactly what I first considered doing in my game. The player and the HUD elements would be drawn before the other objects in one frame, and after them in the other. I never got to test this though, as I decided to assign dummy object slots to the player and HUD to have them take part in the random order of object processing, so that their sprites would be shuffled with everything else.
Memblers wrote:
Being the player in the game, if I start flickering, I'd probably be getting annoyed.
But doesn't it annoy you when the objects you interact with flicker like hell? Personally, I'm very annoyed when the player never flickers and that results in extra flickering for everything else. I'd rather give all the objects the same chance of being displayed, because when even the player flickers a little, the remaining objects won't flicker so much.
Here's what I do.
I have a dynamic sprite drawing routine, which takes the coordinates of an object (could be an enemy, a bullet, or basically any entity that requires sprites to be displayed), and it draws all of the enemy's sprites based off of that set of coordinates. First it draws all objects in first to last order, then it does last to first order in the next frame. This causes some flickering by itself, however, not enough for some cases. So then I draw a sprite at $300,x , where x is an 8 bit value that's a multiple of four. Then after I draw that sprite, I increase x by 12, so it draws a sprite every 3 sprite entries. But see, when x = 252, since x is 8 bits, it will do 252 + 12 = 8. It works out so that if you start from x = 0, and you increase by 12 64 times, all sprites will be filled in. This means if an object has a sprite drawn at x = 252, it's next sprite will have higher priority, causing priority shuffling.
But in order to make this really effective, start drawing at $300,x , where x =0, then the next frame start at $300, x, where x = 4, then start where x= 8, etc.
Quote:
I have a dynamic sprite drawing routine, which takes the coordinates of an object (could be an enemy, a bullet, or basically any entity that requires sprites to be displayed), and it draws all of the enemy's sprites based off of that set of coordinates. First it draws all objects in first to last order, then it does last to first order. This causes some flickering by itself, however, not enough for some cases. So then I draw a sprite at $300,x , where x is an 8 bit value that's a multiple of four. Then after I draw that sprite, I increase x by 12, so it draws a sprite every 3 sprite entries. But see, when x = 252, since x is 8 bits, it will do 252 + 12 = 8. It works out so that if you start from x = 0, and you increase by 12 64 times, all sprites will be filled in. This means if an object has a sprite drawn at x = 252, it's next sprite will have higher priority, causing priority shuffling.
Doesn't it look ugly when you have objects consisting of more then one sprite if the sprites doesn't flicker in unison?
I really don't think it's ugly. Since only a few of the sprites flicker, most of the object is visible, so it makes it rather unnoticeable. And I think that sprites flickering in unison might look annoying too, but it's possible that games do this and I haven't noticed. I do think I've played a lot of NES games though that use flickering with partial flickering of objects. I think though that flickering actually characterizes NES games, so whatever you do, it's fine. I think though that my method takes less CPU time to execute. You don't have to do any checks besides checking if you have used all 64 sprites. It creates a "natural" flicker.
Well, it depends how much you care about sprite priorities. In a game where the priorities doesn't matter a single bit, you'd want to do a method that maze sprites in a different pseudo-random order each frame, like what Celius describes or something different depending on what you want.
In my case I have a game engine where sprite priorities matters for the graphics, because it uses top-down perspective with variable sized sprites. So I'm forced to place the objects so that they are sorted by their Y coordinate, but the object themselves are mazed forwards or backwards depending on the frame parity. To achieve this, I use a code in RAM and do a few EOR each frame. This disallows me to use sprites that relies on priorities to show up correctly in game, but if for any reason I want priorities, I just call the ROM version of the routine, and it always draws sprites forwards.
If I were to programm a game where the priorities between sprites matters for each metasprites (becuase you use multi-layered sprites), but the priority between objects is not a matter (for example platform games), I'd do the other way arround : The sprite mazing routine would always draw forward, but the objects would be drawn on the screen in a pseudo-random order, so that we don't know which object has priority, and if there is too much they will flicker.
Oh, and everyone is talking about flickering like if it was a big annoyance. But remember that flicker is in itself a trick to avoid having sprites disapearing, with the 8 sprite per line trick. Having sprites disapearing definitely looks worse than flickering.
tokumaru wrote:
But doesn't it annoy you when the objects you interact with flicker like hell? Personally, I'm very annoyed when the player never flickers and that results in extra flickering for everything else. I'd rather give all the objects the same chance of being displayed, because when even the player flickers a little, the remaining objects won't flicker so much.
If you have to dodge bullets or jump over holes then good visibility is nice (even if it flickers some other stuff a bit more), I guess I'm thinking more along the lines of Contra. A flickering player makes me want to think of invincibility, but a lot of games used flashing colors instead.
Bregalad wrote:
Oh, and everyone is talking about flickering like if it was a big annoyance. But remember that flicker is in itself a trick to avoid having sprites disapearing, with the 8 sprite per line trick. Having sprites disapearing definitely looks worse than flickering.
Yes, definitely. And flickering is such a common thing that I've seen some websites inaccurately state that it's automatic. I think it'd be hard for any (non-developer) player find any faults in any particular method.
Another advantage to flickering (if you implement it correctly) is that you can have more than 64 sprites worth of objects on screen at once. Say there are a bunch of objects on screen, and it would take 70 sprites to draw them all. One frame, you can draw the first 64, then the next frame you can display 64-70 and 0-58, then the next frame 58-70 and 0-52, so the 6 sprites that aren't allowed to be displayed every frame are alternated. My engine can currently handle more than 64 sprites of objects being displayed to a certain extent. Since I will in one frame draw in the order of Object1, Object2, Object3 and in the next frame draw Object3, Object2, Object1, it kind of has the effect I was talking about, but not as good. So say again there are 70 sprites worth of objects that need to be drawn. One frame it will draw 0-64, then the next frame 70 to 6 (backwards), then the next frame it will draw 0-64, then 70-6, etc. So sprites 0-6 and 64-70 flicker, which might be really annoying.
Why does this suddenly sound like Atari 2600 Adventure?
I don't know. What does Adventure do that sounds like this? And I really don't think flickering for more than 64 sprites (occasionally when there's an overflow) is a bad idea, if that's what you're referring to.
Celius wrote:
What does Adventure do that sounds like this?
Lots of Atari 2600 games multiplex sprites horizontally through flickering. There are only 2 sprites really, and while they can easily be reused vertically, horizontal multiplexing basically requires flickering (except when hardware copies of it are requested, but there are many limitations in that).