Hello everyone and devs.
As good etiquette requires, I'll begin by first thanking the hard work of every developer involved in the creation of this wonderful emulator for this great portable system that is the DS. It has given me (and still does) many hours of enjoyment.
Now, on to the issue: In Sands Of Destruction, there is a character customization submenu on the top screen where you are able to allocate points towards improving battle skills.
On the right side of the screen, you see an animated preview of the move you have selected, but on Desmume the sprite is obscured by GUI elements instead of being on top of them, as it does on the real DS.
I'm using 0.9.12 and none of the usual workarounds seem to help, as they have all been attempted (switching between graphical renderers, changing block size, disabling layer visibility, changing the depth comparison threshold).
It is not a destructive or show stopping bug, but still, I figured I'd report it.
test in latest builds posted on homepage in both 3d renderers
I tried the latest official nightly, if that's what you mean, but no dice, sadly.
I don't know how to compile the emulator myself so I couldn't try any of Orphis' automated ones either.
post an in-game save DSV file at a point where I can test this out
Is it okay if I post it somewhere like google drive? (if files can be attached directly here I'm not seeing it sorry).
doesnt matter where you post it, as long as you dont post it to the north pole, unless you want to wait for december to receive a bugfix
Nah, I definitely don't like such a cold place.
Not really google drive but should work https://1drv.ms/u/s!AoU_WziXoEEcg0Y_Kk_IjjFQDV44
To get to the menu in question, press X, choose party, (confirm with A), select a character and then customize.
Kyrie's "slice and dice" skill will produce the same output as the screenshot I showed.
Just looked into this issue. This particular status screen uses the 3D renderer running the less-than depth test, and this screen messes up when trying to render some (apparently) equal depth values.
To test: Change the depth test from a less-than test to a less-than-or-equal test (can be done on either renderer). You'll be able to see more of the status screen, most notably the character portrait on the left and the character animation on the right, but it can mess up other character animations, such as Morte's Sky Rend animation.
It doesn't seem like this is a depth accuracy issue -- it more seems like there is some unknown depth rule in the NDS that is messing up DeSmuME. Hmmmm.... I couldn't even begin to fathom what the unknown rule(s) would be. It's really strange.
Analysis without studying game:
There is a lot of logic in the gfx3d.cpp which is not correct (still a lot of floats around). See my commits of code with prefix GEM_ -- there needs to be a lot more about it.
Typically what's happening is the game is rendering two bits of geometry in a slightly different way which results (accidentally) on numbers working out just-right on the hardware, but which collapses to the same values when the numerical handling is not precise.
Now, the work I did in the GEM_ functions was related to an overflow. Probably not the case here. But there is a lot of room for the nds's u32s to contain values which the floats lose -- and there may even be intermediate results with larger precision.
I suggest we try solving this indirectly by forcing the graphics pipeline to have fewer floats. This will probably break a few other games, and evidence for the numerical aspects can then accumulate.
Oh yeah, now I see that there are multiple points in the pipeline where depth value precision is lost, causing barely unequal values on a hardware NDS to become "equal" values in DeSmuME. Well that sucks.
Unfortunately, changing the graphics pipeline to use purely integers instead of floats is more work than I'm willing to commit to in this current release cycle. But this will HAVE to be done at some point in the future. We'll treat Sands of Destruction as another test case.
Last edited by rogerman (2017-02-20 18:52:33)
Thanks for looking into it, guys.
I know it's probably going to be a big pain to solve, given it's one of those subtleties that the NDS hardware has, but
thanks for the feed back. Keep up the good work.