Sands Of Destruction minor layering issue

Red_Soul · 2017-02-05 07:35:29

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.

zeromus · 2017-02-05 07:42:45

test in latest builds posted on homepage in both 3d renderers

Red_Soul · 2017-02-05 08:03:14

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.

zeromus · 2017-02-05 08:22:06

post an in-game save DSV file at a point where I can test this out

Red_Soul · 2017-02-05 08:36:18

Is it okay if I post it somewhere like google drive? (if files can be attached directly here I'm not seeing it sorry).

zeromus · 2017-02-05 08:40:25

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

Red_Soul · 2017-02-05 08:52:30

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.

rogerman · 2017-02-20 05:24:25

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.

zeromus · 2017-02-20 09:06:23

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.

rogerman · 2017-02-20 18:47:57

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)

Red_Soul · 2017-02-24 07:08: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.

Luigi__ · 2018-08-01 10:58:04

Pretty late, but I figured I'd give pointers on this.

From what I understand:

Z values have nothing to do with this. Those of the concerned polygons are all zero. So even with an all-integer pipeline, they come out the same.

However, there's a depth-test edge case acting up. Apparently, when the incoming pixel is from a front-facing polygon, and the existing pixel is opaque and from a back-facing polygon, depth test uses function 'less than or equal' instead of 'less than'.

There are a few other cases that trigger this too, namely some cases of overlapping wireframe polygon borders, but this needs extensive testing to find all the cases.

Also, it is required that the viewport transform be accurate. They tweak their polygon positions slightly to influence Y-sorting.

Last edited by Luigi__ (2018-08-01 11:00:59)

zeromus · 2018-08-01 11:51:37

That's weird. Why would it store whether the existing pixel is front or back facing? Unless it's for shadows, I can't see any reasonable use for that. I don't see how it would be useful for shadows, but it seems possible--an the behaviour here would be a side effect of some hack meant specifically for the shadows

rogerman · 2018-08-01 19:48:05

I can confirm that Luigi's fix does work. I modified SoftRasterizer to perform a LEQUAL depth test based on the polygon facing conditions, and Sands of Destruction seems to be rendering the status screens correctly now.

I will submit a commit for this fix later, after I've cleaned up the code a bit to be less confusing.

Now... getting this same fix to work in OpenGL will be the real trick. Unfortunately, this fix only works by reading and writing to the destination framebuffer, which is a big no-no in OpenGL. I'm gonna have to take a real deep think about this.

rogerman · 2018-08-01 20:48:54

Fixed in commit git#36ee247, but for SoftRasterizer only. Applying the same fix for OpenGL is still being researched.

#1 2017-02-05 07:35:29

Sands Of Destruction minor layering issue

#2 2017-02-05 07:42:45

Re: Sands Of Destruction minor layering issue

#3 2017-02-05 08:03:14

Re: Sands Of Destruction minor layering issue

#4 2017-02-05 08:22:06

Re: Sands Of Destruction minor layering issue

#5 2017-02-05 08:36:18

Re: Sands Of Destruction minor layering issue

#6 2017-02-05 08:40:25

Re: Sands Of Destruction minor layering issue

#7 2017-02-05 08:52:30

Re: Sands Of Destruction minor layering issue

#8 2017-02-20 05:24:25

Re: Sands Of Destruction minor layering issue

#9 2017-02-20 09:06:23

Re: Sands Of Destruction minor layering issue

#10 2017-02-20 18:47:57

Re: Sands Of Destruction minor layering issue

#11 2017-02-24 07:08:33

Re: Sands Of Destruction minor layering issue

#12 2018-08-01 10:58:04

Re: Sands Of Destruction minor layering issue

#13 2018-08-01 11:51:37

Re: Sands Of Destruction minor layering issue

#14 2018-08-01 19:48:05

Re: Sands Of Destruction minor layering issue

#15 2018-08-01 20:48:54

Re: Sands Of Destruction minor layering issue

Board footer