Sprite DMA queue with size 0
Moderator: Stef
Sprite DMA queue with size 0
In a game, I hit a frame where no sprites were submitted, which caused
VDP_updateSprites(0, TRUE);
to be called. This then calls DMA_queueDma inside sgdk, passing the zero size on.
The effect of DMA with size zero was that the entire VRAM was overwritten. It was my bug, and I've added a check so that VDP_updateSprites doesn't get called in that case, but would it be useful for both of those two functions to check for zero size?
Or is there a legit use case for DMA with size zero?
VDP_updateSprites(0, TRUE);
to be called. This then calls DMA_queueDma inside sgdk, passing the zero size on.
The effect of DMA with size zero was that the entire VRAM was overwritten. It was my bug, and I've added a check so that VDP_updateSprites doesn't get called in that case, but would it be useful for both of those two functions to check for zero size?
Or is there a legit use case for DMA with size zero?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Sprite DMA queue with size 0
I think i should fix at least the spriteUpdate() method in fact. Normally the DMA method should do what the documentation say about but maybe we can see 0 as a special length value as it is on real hardware (so you could replicate the effect)
Re: Sprite DMA queue with size 0
Also for what's worth it, when there are no sprites on screen you still need to update the sprite table - more specifically, you need to put the first sprite off-screen and have it terminate the list, if you don't do that then the sprite table will remain untouched and displaying whatever sprites were there last time. So you have to handle the 0 sprites case explicitly either way.
Sik is pronounced as "seek", not as "sick".
Re: Sprite DMA queue with size 0
Yup. Though that wasn't an issue in this case, showing the previous frame's sprites was ok.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Sprite DMA queue with size 0
Yeah that's what the SPR_clear() method does. But for that matter we indeed use 1 sprite which is off screen with null pointing chain, and in this case i expect we use VDP_updateSprite(1) =)Sik wrote:Also for what's worth it, when there are no sprites on screen you still need to update the sprite table - more specifically, you need to put the first sprite off-screen and have it terminate the list, if you don't do that then the sprite table will remain untouched and displaying whatever sprites were there last time. So you have to handle the 0 sprites case explicitly either way.
Re: Sprite DMA queue with size 0
The issue here is that the programmer will be nonethewiser and assume that if there are no sprites to be shown, then it'd make sense to just pass 0 (since, after all, there are 0 sprites). They will think the parameter is the number of sprites to display, not the number of entries in the table. Really, all it'd take is to make VDP_updateSprite check if the value is 0 and change it to 1 if needed. No overhead from part of the programmer using the function.
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Sprite DMA queue with size 0
Hmm.. the problem is doing that is that i should not only replace 0 by 1 (not a big deal) but i should also change location of the first sprite to set it off screen *and* set its link field to 0 (exactly what the VDP_clearSprites() method is doing), since, as you mentioned, the programmer won't probably do that by itself and assume VDP_updateSprite(0) is enough to hide all sprites.Sik wrote:The issue here is that the programmer will be nonethewiser and assume that if there are no sprites to be shown, then it'd make sense to just pass 0 (since, after all, there are 0 sprites). They will think the parameter is the number of sprites to display, not the number of entries in the table. Really, all it'd take is to make VDP_updateSprite check if the value is 0 and change it to 1 if needed. No overhead from part of the programmer using the function.
Maybe what i can do is to indicate in documentation that VDP_updateSprite(0) has a special behavior and can be used to clear sprites (internally call VDP_clearSprites() and VDP_updateSprite(1)), so people should use it carefully (restore sprite #0 fields after it).
Re: Sprite DMA queue with size 0
Well, the 0 case never worked in the first place, so it's not like you have to worry about compatibility there...
Honestly I assumed you'd just clear always (if there are sprites on screen and want to show none then you're going to want to get rid of them, right?), but either way works I imagine. Or maybe I'm biased, my sprite code does reset on clear but the whole sprite API keeps track of how many sprites are in the table so the sprite update function doesn't even take an argument as it already knows the size of the table (also meaning that 0 sprites = have the table cleared).
Honestly I assumed you'd just clear always (if there are sprites on screen and want to show none then you're going to want to get rid of them, right?), but either way works I imagine. Or maybe I'm biased, my sprite code does reset on clear but the whole sprite API keeps track of how many sprites are in the table so the sprite update function doesn't even take an argument as it already knows the size of the table (also meaning that 0 sprites = have the table cleared).
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Sprite DMA queue with size 0
You said your sprite API does know the number of used sprites. In fact I tried to do that with the SGDK API but having dynamic sprite allocation make the feature a bit complicated to implement (in fact it's quite easy for allocation, but sprite release is a problem as I need to parse the whole sprite list to get correct value of last allocated hard sprite.. definitely a cpu hog it you do many sprite release operation). Maybe you sprite allocation method is more 'fixed' (no partial release ?) so you can always immediately now what is the last allocated hard sprite.
You are right about the 0 parameter, anyway it never worked so I can use it for a specific operation.
You are right about the 0 parameter, anyway it never worked so I can use it for a specific operation.
Re: Sprite DMA queue with size 0
Yeah, my method goes clear, add, add, add ... update. The whole table is rebuilt every frame and sprites are allocated in consecutive slots. Honestly much easier and less error prone than having to track down which sprites are used and which aren't. Maybe even faster since you avoid having to keep track of who owns which sprite in the first place =P
Sik is pronounced as "seek", not as "sick".