You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.



#1 2017-09-22 04:04:49

mgitkun
Member
Registered: 2017-06-06
Posts: 43

OpenGL rendering regressions in Mega Man ZX Advent

For both of the issues below I'll include a video and gif that show (from left to right) the last commit prior to the regression, the commit that introduced the regression, and the current master to show that the issue has not been fixed since then.


Regression 1:

I'll be referencing a number of old commits below, to prevent it from getting too confusing I've included the previous naming scheme so that you can see whether one commit came before or after another commit at a glance.

It seems that commit 2f473cd (r5372) caused certain sprites to be rendered at the wrong depth/order (I think) when using the OpenGL renderer.
The video below shows ZX Advent in 891fd01 (r5371), 2f473cd (r5372), and f521ab1 (master).
gif 1

Video (01:36)

*Note:
Since every build from commit 760b5a6 (r5259) through 2f473cd (r5372) doesn't display any sprites at all because of an issue from 760b5a6 (r5259) I ended up building 2f473cd (r5372) and several commits leading up to it with the change to MMU.cpp from commit 34ec6bb (r5373) to figure out which commit caused the regression in OpenGL.

As you can see in both 2f473cd (r5372) and f521ab1 (master) the sprites for the robot's hands seem to be hidden behind the sprites for its wrists/arms (the thumbs poke out partially). I would assume that the animations for the eyes and mouth are also being displayed at the wrong depth/order.


Regression 2:

After recording the video for this post I noticed another regression, near the end of the video linked above (not the gif) you see the rays of light and the final explosion clip through the robot in the master build but not in the two older builds.

I checked a number of builds and I found that commit eea54a7 was the one that introduced the clipping issue.
Below is a video of that section in f8ab45f, eea54a7, and f521ab1 (master).

gif 2

Video (00:14)

*Note:
Sprites are once again not displayed in builds 66b5da1 up until the fix in 759a039. Unlike the issue in the builds involved with regression 1, however, sprites appear once you enter a new stage/zone or die. The robot in the video above is at the end of the first level but has a separate stage/zone, once you load into this stage/zone the sprites appear.
   




Because the commits shown in the video for regression 1 (891fd01 and 2f473cd) had issues which prevented sprites from being shown altogether their videos had to be recorded on builds that utilized the fix/hack noted above.
The remaining builds shown (f8ab45f, eea54a7, and f521ab1 (master)) were downloaded off of appveyor.


Here are savestates you can use to get to this point in the game. I included two sets, one made on master and one made on 891fd01 (r5371). In each set there's two savestates, one right before the fight with the robot and one just as it's about to die.
There's also a similar DSM in each set that completes the first level entirely. There must be no save file present for it to work.
EDIT: Forgot to mention that I had Advanced Timing enabled and Recompiler disabled, not sure if any other options affect the sync for movies.

I used the NA release of ZX Advent and the area shown in the videos is at the end of the first level in Grey's (one of the two playable characters) story.

If there's any doubt as to what this scene should look like here's a video from GDQ.
The speedrun is on a different difficulty so you won't see a lot of the animations that you do in my gif/video but you do see the robot itself and its death animation.

Last edited by mgitkun (2017-09-22 05:28:47)


i5 2500K - CPU | GTX 480 - GPU | 8GB - RAM | TX650 - PSU | Windows 7 x64 - OS

Offline

#2 2017-09-23 01:17:00

rogerman
Member
Registered: 2011-06-04
Posts: 380

Re: OpenGL rendering regressions in Mega Man ZX Advent

mgitkun, thank you for your research and the efforts that you put into your bug reports. Good bug reports are quite rare from users, and I want you to know that your bug reports are very much appreciated!

With all that said, Regression #2 has been fixed in commit 1742114. Try that.

Regression #1 is related to issues #74 and #24. The NDS 3D renderer uses polygon IDs on transparent polygons in order to support a form of order-independent transparency. This is yet another case that demonstrates how DeSmuME's OpenGL 3D renderer doesn't support transparent polygon IDs. Coincidentally, this support was broken in r5372 when I made the decision to properly emulate shadow polygons, although this done by sacrificing an (at the time) imperfect transparent polygon ID implementation.

Of course, this is a very difficult problem to solve, and it really is the biggest regression that is holding up the entire v0.9.12 release. The problem is that the OpenGL renderer uses the stencil buffer to support shadow polygons or transparent polygon IDs. Unfortunately, the stencil buffer is incapable of emulating both features at the same time. Even worse, OpenGL can only use one stencil buffer at any given time. This situation creates a dilemma in which one must decide which feature do you emulate with OpenGL's single stencil buffer.

However...

With the recent rework in the OpenGL renderer to separate opaque polygon rendering and transparent polygon rendering into two separate steps, there is now hope that transparent polygon IDs can be emulated without sacrificing proper shadow polygon support. In fact, I'm glad Regression #2 came up, because it is directly related to that rework.

Offline

#3 2017-09-24 00:11:38

mgitkun
Member
Registered: 2017-06-06
Posts: 43

Re: OpenGL rendering regressions in Mega Man ZX Advent

rogerman wrote:

mgitkun, thank you for your research and the efforts that you put into your bug reports. Good bug reports are quite rare from users, and I want you to know that your bug reports are very much appreciated!

With all that said, Regression #2 has been fixed in commit 1742114. Try that.

Glad to help.

I tried the new build and like you said it fixed regression #2.
Apart from that it also fixed a similar issue in an earlier part of the level where the windowpane appeared in the foreground and obscured sprites (enemies' upper bodies were entirely obscured while the sprite of the main character was visible through the window).
gif 1




There does seem to be a new issue though. The sprite of the main character (the guy in the pod), which should appear in the background, now appears in the foreground.
gif 2
This scene is at the very start of that same level.

rogerman wrote:

Regression #1 is related to issues #74 and #24. The NDS 3D renderer uses polygon IDs on transparent polygons in order to support a form of order-independent transparency. This is yet another case that demonstrates how DeSmuME's OpenGL 3D renderer doesn't support transparent polygon IDs. Coincidentally, this support was broken in r5372 when I made the decision to properly emulate shadow polygons, although this done by sacrificing an (at the time) imperfect transparent polygon ID implementation.

Of course, this is a very difficult problem to solve, and it really is the biggest regression that is holding up the entire v0.9.12 release. The problem is that the OpenGL renderer uses the stencil buffer to support shadow polygons or transparent polygon IDs. Unfortunately, the stencil buffer is incapable of emulating both features at the same time. Even worse, OpenGL can only use one stencil buffer at any given time. This situation creates a dilemma in which one must decide which feature do you emulate with OpenGL's single stencil buffer.

However...

With the recent rework in the OpenGL renderer to separate opaque polygon rendering and transparent polygon rendering into two separate steps, there is now hope that transparent polygon IDs can be emulated without sacrificing proper shadow polygon support. In fact, I'm glad Regression #2 came up, because it is directly related to that rework.

I vaguely recall seeing those tickets at some point and with your explanation it makes sense how they're all related.
The funny part is that I searched for issues with 2f473cd but despite having included the previous naming scheme in the post it somehow didn't occur to me to search for it as r5372 on github, haha. Brainfart lol

Is there an actual comprehensive list of things that need to be fixed and/or features that need to be implemented before the next stable release?

Last edited by mgitkun (2017-09-24 23:13:03)


i5 2500K - CPU | GTX 480 - GPU | 8GB - RAM | TX650 - PSU | Windows 7 x64 - OS

Offline

#4 2017-09-24 04:55:30

mgitkun
Member
Registered: 2017-06-06
Posts: 43

Re: OpenGL rendering regressions in Mega Man ZX Advent

I just tried 70c69a4 and can confirm that it fixed the issue during the first scene in Grey's story.

No new issues as far as I can tell.

Last edited by mgitkun (2017-09-24 04:56:54)


i5 2500K - CPU | GTX 480 - GPU | 8GB - RAM | TX650 - PSU | Windows 7 x64 - OS

Offline

#5 2017-09-24 05:06:10

rogerman
Member
Registered: 2011-06-04
Posts: 380

Re: OpenGL rendering regressions in Mega Man ZX Advent

Okay... try commit 70c69a4. This should address the graphical glitch in Grey's intro scene.

mgitkun wrote:

I just tried 70c69a4 and can confirm that it fixed the issue during the first scene in Grey's story.

No new issues as far as I can tell.

Ahhhh, you beat me to the post there. But I'm glad that it's working out for you now and that there are no new glitches.

As for the "comprehensive list of things that need to be fixed and/or features that need to be implemented before the next stable release", there is no actual list for this. But if I were to think of some things that HAVE to be done off the top of my head, it would be these things:

1. Core - As mentioned before, translucent polygon IDs really need to be supported in the OpenGL renderer. Testing and user reports are revealing that there are too many games affected by not supporting this.
2. Core - We need much additional testing on the effects of zeromus' matrix stack and geometry power register rework. In addition, there is currently a regression that needs to be fixed that is related to this rework.
3. Windows Port - In commit e6d5a8f, we increased the maximum GPU scaling factor from 5x to 16x. Much additional testing needs to be done to determine if we can keep 16x or if we have to revert back to 5x. This will be dependent on the number of difficult-to-fix bugs in relation to this.
4. Linux (GTK) Port - For some unknown reason, the GTK build crashes on startup. However, the Glade build works just fine. I haven't actually researched why the GTK port crashes, but it's probably due to some of the recent commits to the GTK port.
5. Cocoa Port - I want to rework Copy to Clipboard and Screenshot to File operations in the Cocoa port to take advantage of the newest tech that I've recently added. This is more of an icing-on-the-cake feature than anything else, but it is something I've really wanted to do for a while now, and I would feel bad if the v0.9.12 release didn't include the newest tech for these operations.

And that's it. I don't know if zeromus would want to add anything to this list, but these are the most important things I could think of that is blocking the v0.9.12 release.

Last edited by rogerman (2017-09-24 05:08:09)

Offline

#6 2017-09-25 02:38:43

mgitkun
Member
Registered: 2017-06-06
Posts: 43

Re: OpenGL rendering regressions in Mega Man ZX Advent

rogerman wrote:

As for the "comprehensive list of things that need to be fixed and/or features that need to be implemented before the next stable release", there is no actual list for this. But if I were to think of some things that HAVE to be done off the top of my head, it would be these things:

1. Core - As mentioned before, translucent polygon IDs really need to be supported in the OpenGL renderer. Testing and user reports are revealing that there are too many games affected by not supporting this.
2. Core - We need much additional testing on the effects of zeromus' matrix stack and geometry power register rework. In addition, there is currently a regression that needs to be fixed that is related to this rework.
3. Windows Port - In commit e6d5a8f, we increased the maximum GPU scaling factor from 5x to 16x. Much additional testing needs to be done to determine if we can keep 16x or if we have to revert back to 5x. This will be dependent on the number of difficult-to-fix bugs in relation to this.
4. Linux (GTK) Port - For some unknown reason, the GTK build crashes on startup. However, the Glade build works just fine. I haven't actually researched why the GTK port crashes, but it's probably due to some of the recent commits to the GTK port.
5. Cocoa Port - I want to rework Copy to Clipboard and Screenshot to File operations in the Cocoa port to take advantage of the newest tech that I've recently added. This is more of an icing-on-the-cake feature than anything else, but it is something I've really wanted to do for a while now, and I would feel bad if the v0.9.12 release didn't include the newest tech for these operations.

And that's it. I don't know if zeromus would want to add anything to this list, but these are the most important things I could think of that is blocking the v0.9.12 release.

Thanks, I actually expected the list to be a lot longer; not to make light of how difficult or time consuming it will probably be to work everything out but this makes it seem like 0.9.12 is actually happening.


----
Edit: I apologize for my sarcasm which brought on the weird troll, it was not my intent.
I've edited this post to remove the joke which was included below.

Last edited by mgitkun (2017-09-25 18:23:46)


i5 2500K - CPU | GTX 480 - GPU | 8GB - RAM | TX650 - PSU | Windows 7 x64 - OS

Offline

#7 2017-09-25 07:54:08

AsPoke3172
Member
Registered: 2010-04-21
Posts: 205

Re: OpenGL rendering regressions in Mega Man ZX Advent

Yeah! It take more longest ever for upcoming version 0.9.12 very SOON™! How you to do is make all 8000 games (or more or less) are works perfectly. Then, any features for nice graphics which look likes a real DS. Finally, AR Codes must to be proper working just likes a real DS.

EDIT:- Never mind! I hope next version will have more functions and more better than other emulators! big_smile

Last edited by AsPoke3172 (2017-09-25 23:54:05)

Offline

#8 2017-10-14 03:12:32

rogerman
Member
Registered: 2011-06-04
Posts: 380

Re: OpenGL rendering regressions in Mega Man ZX Advent

Regression #1 has been fixed as of commit git#73b5074, which brings back support for transparent polygon IDs in the OpenGL renderer, thus bringing back order-independent transparency. This fixes those graphical glitches in Mega Man ZX Advent.

This fix will require quite a bit of testing, since OpenGL's transparent polygon ID support works differently than that of SoftRasterizer's. Specifically, SoftRasterizer uses two separate buffers for recording the opaque and transparent polygon IDs. However, OpenGL uses only a single buffer to record the polygon ID of the last polygon drawn, and then uses a single bit flag to designate whether the polygon ID of the drawn fragments should be treated as opaque or translucent.

But... of the many many many games I have tried so far, OpenGL does seem to produce the same results as SoftRasterizer... so far.

Offline

#9 2017-10-14 05:09:08

mgitkun
Member
Registered: 2017-06-06
Posts: 43

Re: OpenGL rendering regressions in Mega Man ZX Advent

rogerman wrote:

Regression #1 has been fixed as of commit git#73b5074, which brings back support for transparent polygon IDs in the OpenGL renderer, thus bringing back order-independent transparency. This fixes those graphical glitches in Mega Man ZX Advent.

This fix will require quite a bit of testing, since OpenGL's transparent polygon ID support works differently than that of SoftRasterizer's. Specifically, SoftRasterizer uses two separate buffers for recording the opaque and transparent polygon IDs. However, OpenGL uses only a single buffer to record the polygon ID of the last polygon drawn, and then uses a single bit flag to designate whether the polygon ID of the drawn fragments should be treated as opaque or translucent.

But... of the many many many games I have tried so far, OpenGL does seem to produce the same results as SoftRasterizer... so far.

That's awesome!


i5 2500K - CPU | GTX 480 - GPU | 8GB - RAM | TX650 - PSU | Windows 7 x64 - OS

Offline

Board footer

Powered by FluxBB