You are not logged in.

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



#26 2016-07-29 22:06:13

JJJ
Member
Registered: 2016-05-13
Posts: 27

Re: Transparancey or layer error on openGL & Screenshot crash

Detail..., people won't download it anyway.
You know the real fix is only a few lines of code that doesn't need messing arround with any other code and it will work for most games and i understand perfectly what you are trying to say "You are dumb".

Offline

#27 2016-07-29 22:16:55

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Transparancey or layer error on openGL & Screenshot crash

I don't know which lines of code it is. Would you mind telling me?

And I'm saying you applied a lot of creative work to solve your problems in a way that works for you, and those ways don't always work for us.  These are far from the worst diffs I've seen for desmume.

Offline

#28 2016-07-29 22:29:49

JJJ
Member
Registered: 2016-05-13
Posts: 27

Re: Transparancey or layer error on openGL & Screenshot crash

find "lists.flush()" and then track back from that, you will find that it's an easy problem, i add some bug fix to the gui because some game needs them.

Offline

#29 2016-07-29 23:46:33

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Transparancey or layer error on openGL & Screenshot crash

That code immediately leads me to a "mountain" of changes to the basic operations of the 3d engine. I'm not sure how much of that is improved functionality and how much of it was part of speedup attempts. But from there I arrive at code which seems to forcibly depth-sort the translucent polygons. The NDS hardware has no mechanism for depth-sorting. I'm pretty sure based on my memory of the sensitivity of the y-sorting that depending on a z-sort would break some things.  It is nice that you do the view culling earlier. I'd have to check again but I'm pretty sure we should be doing that earlier (the sorting, in any event, should be applied after view culling and clipping)

Offline

#30 2016-07-30 18:18:03

JJJ
Member
Registered: 2016-05-13
Posts: 27

Re: Transparancey or layer error on openGL & Screenshot crash

I give up then, just do your not working crap .
just do it and then zsort the resulting transparent poly, trust me it's fantastically how ds does it.

Last edited by JJJ (2016-07-30 18:48:47)

Offline

#31 2017-10-05 11:27:02

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 346
Website

Re: Transparancey or layer error on openGL & Screenshot crash

So what is fine Z ordering anyways and why isnt it an easy fix?

Offline

#32 2017-10-05 15:28:50

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Transparancey or layer error on openGL & Screenshot crash

It's sorting, and it's because it depends on exact math and desmume's math is not exact

Offline

#33 2017-10-06 08:52:48

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 346
Website

Re: Transparancey or layer error on openGL & Screenshot crash

Well could it be improved to be exact?  it works fine with softrasterizer but not open gl. but open gl is generally faster than softrasterizer I know im not a programmer but it looks like the layers just need to be reordered for the textures to look correct.  I know rogerman has been cranking out updates on improvements to the GFX engine. so could this be added to the list?

Error example.
https://imgur.com/a/VvODb

Offline

#34 2017-10-06 16:00:33

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

Re: Transparancey or layer error on openGL & Screenshot crash

fintogive wrote:

Well could it be improved to be exact?  it works fine with softrasterizer but not open gl. but open gl is generally faster than softrasterizer I know im not a programmer but it looks like the layers just need to be reordered for the textures to look correct.  I know rogerman has been cranking out updates on improvements to the GFX engine. so could this be added to the list?

Error example.
https://imgur.com/a/VvODb

I never saw the original image from your OP in 2016 which zeromus said was an issue with fine z ordering........
As for this new image where you showed the sea and floor being rendered incorrectly in MKDS, it was working fine up until r5372 as far as I can tell. That was the commit where order independent transparency broke.
image1
image2

Rogerman made a detailed reply in my thread about order independent transparency.


Interested to know if fine z ordering/sorting is the same thing as order independent transparency or if it's something else.....it sounds similar

Last edited by mgitkun (2017-10-06 16:32:19)


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

Offline

#35 2017-10-06 17:48:00

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Transparancey or layer error on openGL & Screenshot crash

They have nothing to do with one another, except that they can both cause things to get rendered in the wrong order.

It can be improved to be exact. It will not be any time in the near future. And we probably can't guarantee that will ever be exact in opengl.

Offline

#36 2017-10-06 18:33:47

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

Re: Transparancey or layer error on openGL & Screenshot crash

zeromus wrote:

They have nothing to do with one another, except that they can both cause things to get rendered in the wrong order.

Got it, thanks.


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

Offline

#37 2017-10-07 09:50:15

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 346
Website

Re: Transparancey or layer error on openGL & Screenshot crash

mgitkun wrote:
zeromus wrote:

They have nothing to do with one another, except that they can both cause things to get rendered in the wrong order.

Got it, thanks.




Interesting so it did work at one time. I remember the shadow bug issue.  Well that sucks...  Hopefully one day it will get fixed.  i actually bumped this  topic cause i noticed the issue were fixed with mega man zx advent so i was hoping that the issue was similar to the fine z ordering bug and that since it had been sometime since i make this topic perhaps it was fixable at this point.  but i guess not...  oh well. like i said. one day. maybe.

Offline

#38 2017-10-07 17:19:17

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

Re: Transparancey or layer error on openGL & Screenshot crash

fintogive wrote:

Interesting so it did work at one time.

If by "it," you mean the order-independent-transparency of rendered polygons... it did "work" in a way at one time. However, in that particular implementation, polygons would still sometimes render out of their intended order, and worse, cause other polygons to end up completely missing. The missing polygon issue was so bad that it made certain games unplayable. It was a buggy and hackish implementation that caused a bunch of rendering issues overall.

When it comes to OIT, this isn't a feature of the NDS per se, but an application to the NDS feature known as transparent polygon IDs. An NDS game can achieve OIT through the clever usage of its transparent polygon IDs. Other applications for transparent polygon IDs are preventing self-shadowing and masking out specific fragments. In other words, transparent polygon IDs are used only for the purposes of preventing fragments from drawing.

When you guys are referring to "fine z-ordering," like zeromus has said, this has absolutely nothing to do with how transparent polygon IDs work. Z-sorting is used to control the order in which polygons are drawn. This is especially important for transparent polygons, which can appear different depending on the order in which they are drawn. The biggest difference between Z-ordering and transparent polygon IDs is that Z-ordering of transparent polygons MIGHT prevent the drawing of fragments if later drawn fragments occlude previously drawn fragments (and only under very certain conditions), while translucent polygon IDs alone can ALWAYS prevent the drawing of fragments regardless of the draw order.

Z-sorting transparent polygons to draw in a particular order, as far as anyone knows, only happens at buffer swap time, and only when such an automatic sort is requested. AFAIK, every game I've encountered does not request the transparent polygon auto-sort. This is why transparent polygon IDs are such an important feature on the NDS -- it allows for OIT because whenever a game tries to draw its transparent polygons, it has to draw them all in whatever arbitrary order they came in. JJJ's statement about Z-sorting the transparent polygons because "it's fantastically how the ds does it" is false -- not only is auto-sorting conditional, but no game I've seen so far actually auto-sorts in practice.

I was extremely skeptical of JJJ's previous posts to the point where I was convinced that this guy was either trolling or severely deluded about his own accomplishments. This was the same guy who made a claim that he had increased DeSmuME's performance by 300%, which is simply impossible to do within the span of a single round of code changes. And then whenever pressed for actual code, he would evade by claiming that it would take him two weeks to get the code to us. Then when pressed for why it would take so long to share the code, he would claim that he lives on a mountain with nothing but dial-up. Seriously? A computer programmer that lives with nothing but dial-up??!!! Uh huh, give me a break.

So to sum up:

Q: Can this "fine z-ordering" stuff get fixed?
A: Eventually, yes, but it is not a priority for this release cycle. This "fine z-ordering" stuff has everything to do with the fact that our 3D rendering system is float-based instead of integer-based, which causes very subtle inaccuracies in the Z values of polygons, which then causes very subtle unintended changes to the polygon sort order. Fixing this will require a major rework of our 3D rendering systems to be integer-based instead of float-based.

Q: Will support for transparent polygon IDs come back?
A: Yes, and this is a priority in this release cycle. Many games have been affected by no longer supporting this, and so I'm making efforts to come up with a solution that works solidly in for all cases, without having to compromise other features like the old implementation did. This is extremely difficult to do in OpenGL, given its major limitations in how it allows programs to interact with the GPU. If you really want transparent polygon ID support right now, then SoftRasterizer is there for you to use.

Offline

#39 2017-10-07 18:55:04

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Transparancey or layer error on openGL & Screenshot crash

It would be Y-sorting anyway, not Z-sorting. the Y-sorting is useless even for opaque polygons. It's only built in the first place because the hardare's rasterizer uses it somehow for improving performance. It's not an optional feature for translucent polys so much as it is a nuisance, with the option provided to turn it OFF--which everyone does because it's a nuisance.

Offline

#40 2017-10-07 20:20:00

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

Re: Transparancey or layer error on openGL & Screenshot crash

zeromus wrote:

It would be Y-sorting anyway, not Z-sorting. the Y-sorting is useless even for opaque polygons. It's only built in the first place because the hardare's rasterizer uses it somehow for improving performance. It's not an optional feature for translucent polys so much as it is a nuisance, with the option provided to turn it OFF--which everyone does because it's a nuisance.

Oh yeah, you're right, is is Y-sorting, not Z-sorting. Yeah, I agree that it's pretty useless in terms of the final rendered framebuffer. I stand corrected.

But that makes transparent polygon IDs even more important then, since there is no way to do a Z-sort outside of the game itself sending the polygons in a pre-sorted fashion.

Offline

#41 2017-10-14 03:07:39

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

Re: Transparancey or layer error on openGL & Screenshot crash

Okay, commit git#73b5074 brings back support for transparent polygon IDs in the OpenGL renderer, thus bringing back order-independent transparency. This fixes those graphical glitches in Mario Kart.

This fix will require quite a bit of testing, since OpenGL's transparent polygon ID support works differently than that of SoftRasterizer. But... of the many many many games I have tried so far, it does seem to produce the same results as SoftRasterizer... so far.

Offline

#42 2017-10-14 07:25:15

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 346
Website

Re: Transparancey or layer error on openGL & Screenshot crash

I just check it. its working well now! I applaud you my man tongue  that bug has been bugging me for awhile (no pun intended)

Offline

Board footer

Powered by FluxBB