SPR_setVisibility issue

[mix256]

I can't get my head around this, so I'm posting a Q.

I've got a 88x88 sprite that should appear at the right on the screen. Putting it at x=320 will make the row get masked out (320+128 -> max 64 wide sprites to the right?) so I need to do SPR_setVisibility to AUTO_SLOW, right?

When I do that, the lower right part of the sprite has the wrong tiles:



Any clue to what is happening here? Looks like there isn't enough allocated tiles?

[Stef]

having a 88x88 sprite on pos x=320 can indeed lead to having sprite masking applied on the whole row as you can have a sprite at position X = 320+64+128 = 512 which is equal to 0 internally (and so masking happen).
To avoid it you indeed need to use VISIBILITY_SLOW so sprites outside screen while be ignored (they will be set at pos Y = 0 to discard them)
Still here the problem you observe look like incorrect VRAM allocation as you guessed (not enough VRAM ?) for that big sprite.
A tip : If you use the library in "debug" mode (the debug compiled one), you can see memory allocation error in the Gens KMod log windows message, can be useful when you meet weird error as this one

[mix256]

Thanks Stef!
There are no alert messages for the allocation.

It only seems to happen when the sprite is created outside (almost whole or partly) of the screen. When the sprite is created inside the screen this does not happen.

Code: Select all

SPR_addSpriteEx(.,x,.,SPR_FLAG_AUTO_VISIBILITY | SPR_FLAG_AUTO_VRAM_ALLOC | SPR_FLAG_AUTO_SPRITE_ALLOC | SPR_FLAG_AUTO_TILE_UPLOAD)

x=320-88 => not broken
x=320-80 => not broken
x=320-72 => not broken
x=320-64 => broken
Same thing if I only do SPR_addSprite() without the flags as well.

Do I need to do SPR_setVisibility() for each frame? Looking at the code it looks like that beacuse the "sprite->visibility" is destroyed after each update?
I tried that as well but it doesn't help.

What do help is if I do a SPR_setAnim() with a different animation after a few frames the sprite has been added (don't know exactly when, though).

Any more suggestion?

[Stef]

Ok, thanks for giving more details ! It seems to be a issue, someone reported me similar issue with large sprites (exactly in same situation as you). As i didn't had enough detail i couldn't really figure but now i believe i have enough information to reproduce and hopefully fix the issue. What happen if you try to create the sprite in X visible range but outside Y wise ?

[mix256]

Thanks!

Seems to be the same issue in Y.
y = 240-88 -> ok
y = 240-72 -> broken
Otherwise having y outside at sprite-add would have been a nice work-around.

[Stef]

Thanks again ! I will investigate the problem =)

[Stef]

I tried to change some stuff and i made some tests, i can't reproduce the problem so it may be fixed hopefully
Can you test using the last sprite_eng.c / sprite_eng.h directly from the github repository ? thanks !

[mix256]

Cool, will test asap.
Saw that you've added a SPR_defragVRAM() as well, which is just super!

[mix256]

Didn't help. I will try to make a small prg that reproduces it.

[mix256]

Here's a code snippet that will reproduce it for me:

Code: Select all

int main() {
  SPR_init(127, 768, 768);
  VDP_setPalette(PAL0, sprite88x88.palette->data);
  u16 x = 320;
  Sprite *spr = SPR_addSprite(&sprite88x88, x,100, TILE_ATTR(PAL0, TRUE, FALSE, FALSE));
  SPR_setVisibility(spr, AUTO_SLOW);

  while(TRUE) {
    SPR_setPosition(spr, x--, 100);
    SPR_update();
    VDP_waitVSync();
  }
  return (0);
}

Look at that sprite coming in all empty in the bottom right.
I've fiddled with when to do the SPR_update etc as well, but nothing seems to work to get a work-around.

[Stef]

Thanks, i was able to reproduce it with your code ! Really weird i wasn't reproducing it with a very close situation.. but ok now i can investigate it =)

[mix256]

Great! But I was kind of hoping I was doing something wrong, though.

[Stef]

Ok, i found the problem ! It was only the last hardware sprite attribute which wasn't correctly updated in some particular case. You can get the last sprite_eng.c, should fix your issue. Needed changes may have impacted a bit the performance, i hope it's not hurting too much on that side.

[mix256]

Worked on the small test I've got here!
Can't wait to get home and test it for real! Super thanks!

[Stef]

Good
Also can you report me if you see any performance difference or not ? honestly i don't think you can see the difference but i prefer to be sure