Pages: 1
  Print  
Author Topic: AA Regression Discussion (Split from Git Proposal topic)  (Read 2361 times)
Offline (Unknown gender) TheExDeus
Posted on: June 05, 2013, 04:33:44 PM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
I want to mention that there have been other features removed by Robert like primitive AA, which, without anything in its place, also is regress. So you all do it.

And mouse_x/y is the MOST USED thing in GM/ENIGMA. I for one have it in EVERY game/program I have made in the past 10 years (yes, I used GM since 2002). If you make anything with mouse (and most people do) then it is used. So the 3rd point by poly was extremely weird as himself is quite experienced with GM and ENIGMA.
« Last Edit: June 07, 2013, 01:49:27 PM by IsmAvatar » Logged
Offline (Male) Goombert
Reply #1 Posted on: June 05, 2013, 04:44:25 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
Poly, all you hasta to do is calm down send the pull request and wait for one of us to finish it on another platform, and problem is solved. For one I could see if you had been doing something major by it was just a you pretty much just fucking everybodies game with extreme negligience, I have to play by the same rules you know and stricter for me but yet I get things done.

And Deus, thats not a bug dude, I did it on purpose. And after being around Josh as much I have very good reasoning why those AA functions should not be in the main engine, for one they were only rarely implemented by a few nVidia cards so for most people they do not even work, and second its not proper antialiasing and wont really create effects that good anyway. When I get to it I will reimplement MSAA and SSAA but it requires refactoring of our projection matrix in OGL3 which I am not ready to do yet. I hope you understand, it is just even for debugging purposes they are not even usefull really, and they would not be able to be implemented to the DX system either, and where possible we should try to avoid that.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #2 Posted on: June 06, 2013, 05:56:46 AM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
Quote
And Deus, thats not a bug dude, I did it on purpose. And after being around Josh as much I have very good reasoning why those AA functions should not be in the main engine, for one they were only rarely implemented by a few nVidia cards so for most people they do not even work, and second its not proper antialiasing and wont really create effects that good anyway. When I get to it I will reimplement MSAA and SSAA but it requires refactoring of our projection matrix in OGL3 which I am not ready to do yet. I hope you understand, it is just even for debugging purposes they are not even usefull really, and they would not be able to be implemented to the DX system either, and where possible we should try to avoid that.
But you didn't implement AA, that's what I was referring too. And you won't do it this week or possibly this month. Thus you removed a feature. You think it worked on some Nvidia cards, but that is your opinion and some random guy on SO. I have tested it on 2 Nvidia cards (one old and one new) and one laptop ATI card and it works fine on all of them. Thus, while deprecated, they are still wildly supported. If for some reason it isn't (like maybe some intel cards, but I am sure it worked there too) then it wouldn't break anything, it just wouldn't work. And the reason I am mentioning this is because I create a lot of programs without any use of sprites, I just draw everything with primitives (like Petri net simulator I am making now) and there I can add primitive AA to create virtually AA for the whole screen (because everything besides text will get it). So I had to add it back to my ENIGMA installation just to use it. And I think that is a problem when I have to manually readd everything that was once in ENIGMA but was removed without putting anything in place.

And I think SSAA and MSAA are the ones that will not be supported on many cards, that GL call was simple enough to be implemented everywhere.
Logged
Offline (Male) Goombert
Reply #3 Posted on: June 06, 2013, 08:20:36 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
Polygonz, do not forget you ruined the day of malkierman as well who was trying to use it, and you did effect me by it you immediately broke my Box2D game which stopped me from cleaning up our B2D extension and expanding it from the Studio compatible one, but again I did not say anything because I assumed you would immediately revert it and I just had not fetched updates. Point is, I ignored it for a fuckin week, and do not make the userbase an argument either the userbase is never going to grow if every time they come here something is broke, so you are not helping with that either.

Anyway, alright Deus...
http://lmgtfy.com/?q=opengl+polygon+aa

Why all the top answers asking why it does not work? It does not matter if it by fluke worked for you, it is guaranteed to be far less supported than even shaders or OpenGL3 compatibility. Lets not forget the hardware stats we ran about %80 of us have OpenGL3 and shader/vertex buffer capable graphics devices.

If that is not enough for you here is a U.C. Berkeley professor...
http://bankslab.berkeley.edu/members/chris/AntiAliasing/AntiAliasingInOpenGL.html
"* Never use OpenGL's Polygon Smoothing feature!  To do this properly you must depth sort the polygons yourself, draw them in front-to-back order with the correct blending settings.  See the Red Book for more information."

And the reason I have not done it yet is I am still thinking about it. We do not necessarily have to use the default OpenGL mutlisampling or accumulation buffer. There is the possibility of doing it the way Mike Dailly did and use internal surfaces to ensure maximum compatibility. There is also the possibility of doing it in a shader for optimization. But the point is, it does not work on two of my computers which are both OpenGL3 capable, and it is more than a deprecated function it is a legacy function from the first OpenGL, as far as I know they do not work in GLES either. But still you can easily, just add them to a branch or add them locally to your code, they just do not belong in the main repository that is all.

Edit: Ohh and btw, they are enabled by default anyway, so if you have them they will automatically be turned on.
http://www.cse.iitb.ac.in/~paragc/teaching/2009/cs475/notes/antialiasing_sumair.pdf

So again, no biggy, you still have it, its just not treated as main functionality that you should expect to work always.
« Last Edit: June 06, 2013, 08:24:20 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #4 Posted on: June 06, 2013, 09:45:21 AM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
Quote
Anyway, alright Deus...
http://lmgtfy.com/?q=opengl+polygon+aa

Why all the top answers asking why it does not work? It does not matter if it by fluke worked for you, it is guaranteed to be far less supported than even shaders or OpenGL3 compatibility. Lets not forget the hardware stats we ran about %80 of us have OpenGL3 and shader/vertex buffer capable graphics devices.
For me the top answer is where an idiot thinks AA will make rectangle have round corners. Actually none of the results google returned have info about that it doesn't work. Actually most people propose to use it.

Quote
If that is not enough for you here is a U.C. Berkeley professor...
http://bankslab.berkeley.edu/members/chris/AntiAliasing/AntiAliasingInOpenGL.html
"* Never use OpenGL's Polygon Smoothing feature!  To do this properly you must depth sort the polygons yourself, draw them in front-to-back order with the correct blending settings.  See the Red Book for more information."
1) Don't quote like Fox news. Two lines before he says: "Drawing points or lines, Random Dot Stereograms or Voronoi Patches:    Use OpenGL's Point Smooth and Line Smooth features. ", which I am referring too.
2) Not he, not anyone else says it doesn't work. They say polygon (filled polygon) AA should not be enabled, because it smooths even the inside triangles. So when you make a quad from 2 triangles, then there will be a line showing in the middle. That is supposed to happen (though I remember reading a way to fix it). It also didn't affect textured triangles, so the rest rendered fine.
3) I am more referring to the "glEnable(GL_LINE_SMOOTH);  glEnable(GL_POINT_SMOOTH);" which gave smooth lines. As lines are smooth then things like circles and curves were smooth too.

Quote
But the point is, it does not work on two of my computers which are both OpenGL3 capable
Are you sure you tested correctly? Here is screen from my laptop (ATI Mobility Radeon HD 5470), I just reimplemented it using the GIT code.
Without AA I get this: https://dl.dropboxusercontent.com/u/21117924/NO_AA.png
With AA: https://dl.dropboxusercontent.com/u/21117924/WITH_AA.png
And I just ran the same program on my work PC which has i5 integrated intel graphics card (HD graphics 2500).
Without AA (intel): https://dl.dropboxusercontent.com/u/21117924/intel_no_AA.png
With AA (intel): https://dl.dropboxusercontent.com/u/21117924/intel_AA.png
There is some weird bugs with circle drawing on the intel card which is actually FIXED by using the line AA. So really, I have tested 4 cards, different manufacturers, different generations, even different types (integrated, laptop, discreet) and it works on all of them. So I really doubt your claim it doesn't work on many cards. It is possible that it doesn't work on Linux though, which maybe is why you have these problems. Linux drivers are usually quite bad, so it possible that there is a driver issue.

Quote
Edit: Ohh and btw, they are enabled by default anyway, so if you have them they will automatically be turned on.
http://www.cse.iitb.ac.in/~paragc/teaching/2009/cs475/notes/antialiasing_sumair.pdf
It actually isn't. So dunno what that .pdf is about. The GL C standard says it isn't (http://www.opengl.org/sdk/docs/man/xhtml/glLineWidth.xml) and by my experimentation and by posts on the internet it can be deduced that it isn't.

Anyway, the point is that you removed a function based on anecdotal evidence and didn't put anything equivalent back. It wouldn't be as big as a problem if you removed them exactly the time you implemented AA (as that would make the function retired), now you just removed a feature. That's it. As lines are oftentimes very ugly I enjoy this AA which can be done without shaders or buffers, and most importantly, I can use it NOW.

edit: Also that Berkley link has good info on how to easily implement driver level MSAA. Seems just as easy as adding the mipmapping. Other ways (like shaders) can be added later as an option, but I think you could implement this one now. If it works then I will not request the line AA back (although options should always be available).
« Last Edit: June 06, 2013, 09:54:03 AM by TheExDeus » Logged
Offline (Male) Goombert
Reply #5 Posted on: June 06, 2013, 05:58:00 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
http://stackoverflow.com/questions/3512456/how-to-draw-smooth-line-with-antialias
"There is no guarantee the GL_LINE_SMOOTH or GL_POLYGON_SMOOTH will do anything."

Quote
For me the top answer is where an idiot thinks AA will make rectangle have round corners. Actually none of the results google returned have info about that it doesn't work. Actually most people propose to use it.

http://www.opengl.org/discussion_boards/showthread.php/165322-Polygon-antialiasing
"Even if you succeed in doing anti aliasing with GL_POLYGON_SMOOTH enabled you will be deceived... as Ilian Dinec said in your last thread. Furthermore it is not well supported."

http://www.opengl.org/discussion_boards/showthread.php/163971-Anti-Aliasing-Problem
"This didn't happen on my ATI card, since ATI does not support polygon and line-smoothing."

Also here...
http://www.opengl.org/archives/resources/faq/technical/rasterization.htm#rast0150
"Not all OpenGL implementations support antialiased polygons. According to the OpenGL spec, an implementation can render an aliased polygon when GL_POLYGON_SMOOTH is enabled."

Also...
http://www.opengl.org/discussion_boards/showthread.php/130487-Polygon-antialiasing-not-working
Quote
The big price you pay for saturate alpha rendering is the required front to back polygon sort. For that reason alone it is difficult to implement and has a significant performance cost.

    Almost nobody uses it for any kind of complex 3D scenes in 'real-time' AFAIK, but it is much higher quality than multisample because it uses fragment alpha for coverage blending giving you much better quality than any multisampel scheme. (Provided you gamma correct but that's another story)"
I am assuming then the reason those of us who do not notice it could also be because we are testing on large scenes, which it is not intended for, and again is not meant to be used really.

Quote
So I really doubt your claim it doesn't work on many cards. It is possible that it doesn't work on Linux though, which maybe is why you have these problems. Linux drivers are usually quite bad, so it possible that there is a driver issue.
polygonz for one has stated before that it does not appear to work for him either, and when I recall removing it, it nobody even really understood why we left it in there, and I informed Josh and everyone when I removed it and why I removed it. I still stick to my point, it does not belong in the main repositroy, there is no DX equivelant, it is not guaranteed to work, and in general shouldnt be used for large scenes anyway.

And besides I have better things to waste my time on like implementing the CG shader compiler when I get to it so we have a fast native cross platform shader implementation that will provide an optimized way of doing that is guaranteed to work and is the correct way.
For an extended look at how to do it properly...
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter22.html

http://www.codeproject.com/Articles/199525/Drawing-nearly-perfect-2D-line-segments-in-OpenGL
Quote
Hardware dependent. It does not necessarily look the same on different machines.
    Average quality. It does not give perfect quality on most hardware.
    Poor thickness control. Most drivers only support thickness of integer values. And the maximum thickness is 10.0 px.

Come on Deus, get real, no way in hell is anybody going to make a game using them, I was hesistant to add wireframe support if it was not useful for debugging and the fact I know DirectX can enable it easily the same way, otherwise I wouldn't have. It just serves no purpose, unless you think the purpose is for it to be slightly more visually appealing to you, working %50 of the time, and not being useful for debugging. Anyway, I am bored right now, I am just waiting on Ism to pull LGM commits by me and get game info fixed, so I'll grant you your wish and go take a look at MSAA again :P
« Last Edit: June 06, 2013, 06:01:26 PM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #6 Posted on: June 07, 2013, 01:35:51 AM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
This should really be split in another topic, as it is not connected to the guidelines, but is a reason to having them.
Quote
There is no guarantee the GL_LINE_SMOOTH or GL_POLYGON_SMOOTH will do anything.
Says the answer with 1 up, and no references (what the comment on that answer asks for).
Quote
"Even if you succeed in doing anti aliasing with GL_POLYGON_SMOOTH enabled you will be deceived... as Ilian Dinec said in your last thread. Furthermore it is not well supported."
This is not about not working. This is about the OP problem of having line in the quad. Something I already said.
Quote
"This didn't happen on my ATI card, since ATI does not support polygon and line-smoothing."
ATI cards DOES SUPPORT line and polygon smoothing. I even posted a picture. So this statement is clearly wrong (maybe in 2008 drivers sucked, as ATI has awful drivers as well).
Quote
Not all OpenGL implementations support antialiased polygons
Just like not all support mipmapping. So not really useful. On the other hand it implies line smoothing is supported everywhere.
Quote
Also...
http://www.opengl.org/discussion_boards/showthread.php/130487-Polygon-antialiasing-not-working
I wasn't even aware it could be used in 3D. But we are talking about 2D here.. you know.. the vast majority of games and programs made in GM and ENIGMA. And my suggestion is not even about games, as there 90% of things are sprite based. In those cases this AA doesn't help. I am talking purely about line drawing (which also extends to circles, rectangles, curves etc.), which is useful for effects, hud and vector graphics.

So my points still stand. 1) It DOES work. As it is glHint then of course it isn't SUPPOSED to work 100% on everything (as it is a hint (doh)), but it clearly is supported almost everywhere. At least on all hardware I can get my hands on. And your quoted links basically mentions the same. Only one person said it doesn't always work (without any reference) and another said it doesn't work on ATI (which it does). And I guess polygon smoothing can be unsupported, as it wasn't that useful (because of the mentioned quad problems). I specifically used and tested on lines though.
2) It was removed months ago so the point wasn't that I need it to have it back (would be nice though). The point was that you removed a working feature without putting something equivalent back and thus made ENIGMA regress. It could even be understood as a bug, as at least two examples in EDC broke because of it (and about 5 of my own programs/games I haven't published here).

So don't take away features (especially ones you don't have to maintain) unless you can immediately put something equivalent back. It would be like me removing surfaces (as FBO's are not supported everywhere, and I can find a voodoo3 with which I can see that and post here about it not working) and say that in about a year I will reimplement them using pbuffers.

So guidelines should have a point of not only breaking ENIGMA, but breaking compatibility or features, which can arise from removing something working without equivalent in place. I have no problems with recoding a small part (like replacing that AA function with a MSAA), but as I could not, then I had to degrade the look of my project without any reason.

edit: And wireframes serves a shit ton of purpose. If you wouldn't implement it then ENIGMA would be the only game engine which supports 3D and doesn't have wireframes in about past 15 years. Mostly used for debug of course, but very important for that.
« Last Edit: June 07, 2013, 01:39:45 AM by TheExDeus » Logged
Offline (Male) Goombert
Reply #7 Posted on: June 07, 2013, 05:32:45 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
Quote
The point was that you removed a working feature without putting something equivalent back and thus made ENIGMA regress.
A working feature which should have never been added especially because there was no OpenGL3 graphics system at the time, and that would not make well for compatibility it appears to only be on new implementations of OGL. And you keep forgetting there IS NO DIRECTX EQUIVELANT, which means it does not belong in the main engine, we are making a cross platform game engine, that means function specs should generally stay the same between systems.

And it is not just the quad problems either, you have to depth sort those on your own which is a pain in the ass and no modern game engine really cares about drawing objects in the correct order front to back, because we are not on DOS and the graphics pipeline gives 0 shits about bitblt'ing the screen anymore. Josh even agrees with me, it never should have been added to the main engine, it's not something that can always be guaranteed and used on all systems, which is the goal of the 3 main graphics systems, is to maintain consistency. And again Deus, not only is there very little on these polygon smoothing hints, but it not working appears to be at least half the google results, other than that there is not even any official documentation on it, which means they really don't give a shit about maintaining it anyway. And Deus, I might just leave it up to people to do themselves with surfaces because then we know for sure its always compatible but I will most likely provide a built in option for it.

In case you don't already know, GM does not have wireframe mode and they refuse to add it. Even in the cubes demo with studio, Mike Dailly had to hard code wireframe with a line list. As for those games on the EDC, I do not care if they were broke, they were written using a function, that should not have been in the main engine, and the functionality can easily be added back in an extended branch of the main repo. I would have rather broke those games earlier on to keep them from using those god awful functions than break thousands of peoples games down the road. Now polygonz on the other hand doesn't care about breaking the fucking mouse, which is the single most important thing to every game engine you will touch in your entire programming lives, whether a mouse or a touch screen or at least some kind of a fucking button.

Not to mention we would end up with dumbfucks you who try to use it with the correct AA implementation thinking to get 2x the effect and they will end up with 1/2 the speed because the line smoothing and polygon smoothing hints are quite expensive and ugly compared to real AA. And if that is not enough for you, I did find it on their official Wiki....
http://www.opengl.org/wiki/Common_Mistakes#glEnable.28GL_POLYGON_SMOOTH.29
Quote
glEnable(GL_POLYGON_SMOOTH)

This is not a recommended method for anti-aliasing. Use Multisampling instead.

Also to add, mipmapping is something more standard, and provides a great performance and quality increase, so it is not at all related to this.

Edit: Nevermind Deus, I got the multisampling working as you can see here 8x multisampling on my cube demo, I have to rewrite some of the OpenGL3 projection code first however before I will commit :P

These will most likely be the function names...
Code: [Select]
d3d_multisampling_generate
d3d_multisampling_destroy
d3d_multisampling_get_maxlevel
d3d_multisampling_get_supported
d3d_multisampling_set_enabled
« Last Edit: June 07, 2013, 07:41:46 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #8 Posted on: June 07, 2013, 07:56:56 AM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
There are features in both DX and GL that are not 1:1 equivalent. Same result can be achieved though. I doubt some AA lines would be any different. The point was also about lines, not triangles so no depth sorting on anything. You are just trying to find a excuse for the past decision, as the original reasoning was "They are not working on 95% of hardware" (or similar) which I argued was BS. And it is. That is all. Waiting for the MSAA, looking good. :) Though it doesn't improve 2D graphics does it? Well it will improve the lines and such just like the previous functions, but it won't do anything about rotated sprites right? Just thinking how to render rotated text nicely. Interpolation required. texture_set_interpolation() works, but does create some artifacts.

Also someone split this from this topic. The discussion is over so you can almost delete it, though archiving would be best (so split and close).
« Last Edit: June 07, 2013, 08:08:26 AM by TheExDeus » Logged
Offline (Male) Goombert
Reply #9 Posted on: June 07, 2013, 08:06:02 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
Yes it will it is just that Deus, mutliple sampling, so anywhere there is a sprite drawn the color copied and the color destination will be averaged causing all edges to smooth for everything, you see this is why I told you it would be better. Then there is also supersampling, that just means you draw the picture at a higher resolution then scale it down to the screen with interpolation, some people like that method as well because it provides more contrast, but in case you couldn't tell I am having trouble attaching a depth buffer :P Now as for fonts, multisampling is always, always the prefered technique for antialiased fonts, so those need completely rewritten I am afraid, I would remove the supersampling from them in the old graphics system but there is no need to I guess, none of the advanced stuff belongs in the old graphics system though.

Here is a comparison...

Left is 1x and right is 8x, you can clearly see the lines smoother in the 8x one :P
« Last Edit: June 07, 2013, 08:25:15 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Josh @ Dreamland
Reply #10 Posted on: June 08, 2013, 09:00:36 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2954

View Profile Email
Let me weigh in, here. Bear in mind my opinion on this matter is not final, but I believe some third-party perspective in this argument will help.

I am not opposed to having HaRRi's AA in the engine, but I wish that we could mark these functions in a way that made it exceedingly clear that they are not available in other graphics systems. OpenGL is portable; this means that you can at least compile your code on each platform, even if the function ultimately fails out. If you try to switch to DX, though, the function will either have to be implemented to do nothing, be emulated using similar DirectX offerings (which I believe has been stated to not be possible). If neither of those are options, then the function call will simply cause compile failure, pissing people off.

One of the best concepts of ENIGMA is the ability to switch systems out and compile your game, regardless of platform. Having a lot of empty functions does not create an environment wherein people feel secure in doing that. Letting a function that works in one system fail in another also is not conducive to that. It would be good if we could provide warnings for functions that do that, at very least, or maybe pack them into extensions so users have to consciously make the decision to use that extension, even though that isn't what I originally intended the extension system to be used for. Originally, the extension system was for functions requiring additional libraries (ie, more dependencies than the user may have already met), or functions which require local variables to be added to objects.

There are two classifications of "correct," here. Mathematically correct, or "True" anti-aliasing, is extremely computationally intensive. Trying to support it software side would be fallacy, and so despite being mathematically correct, is not implementation-correct.

MSAA is the implementation-correct way to do anti-aliasing. From what I gather, NVidia thought that cards would one day provide AA for users. NVidia and other vendors have succeeded in setting graphical precedents in the past; even the new C++ ISO is based largely on features of existing C++ implementations that people came to rely on over time. Apparently, that is not what ended up happening, this time. I guess it was too expensive in terms of hardware density to offer AA on top of existing features. I don't have a figure for actual support, but MSAA is not implementation specific; it uses only standard methodologies.

That said, HaRRi, I wish you'd embrace MSAA over the mostly NVidia functions currently implemented, unless you can show that support for them is still large and that DX offers some way of simulating that function.

If, however, HaRRi's functions incorporate mathematically correct AA hardware-side, they are invaluable; it would be worth offering them (and preferably a function to test if they are supported) JUST to have it on a handful of cards. On DirectX, the supported check function could just return false, and the AA functions could do nothing. This wouldn't bother me a fucking bit, as it would mean that user games could have mathematically correct, true anti-aliasing for dirt cheap on some cards, and then make it a point to use MSAA on cards that do not support those functions.
« Last Edit: June 08, 2013, 09:09:33 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #11 Posted on: June 08, 2013, 09:29:49 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
http://books.google.com/books?id=bmv2HRpG1bUC&pg=PA178&lpg=PA178&dq=mathematically+corr

Mathematically correct antialiasing would involve testing the fragments against all possible interpolations, basically extreme multisampling. Since those require you to depth sort on your own, I'm guessing no they are not mathematically correct.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #12 Posted on: June 08, 2013, 10:15:03 AM

Developer
Joined: Apr 2008
Posts: 1863

View Profile
Well you could implement them DX using shaders or something. Everything is portable, the question is how well. I don't know about mathematically correct AA, but they are not supposed to work in 3D (in which case you MUST manually depth sort). In 2D case when you draw vector graphics I think they are mathematically correct AA as any. I also don't think MSAA can really replace them (though I haven't played with them as Robert has not commit yet). At least SSAA which does supersampling just renders something bigger, then scales down. It works great for triangles and models, but I am not sure how that works in 2D case. It certainly doesn't work on sprites, almost nothing does (as sprites are the ones who must be aliased, not invisible quad edges they are on). Not sure about lines and points though. Maybe it does render a thick line and then scales down and the line is correct, but by itself GL doesn't render thick lines. So I am not sure.
Logged
Offline (Male) Goombert
Reply #13 Posted on: June 08, 2013, 10:34:52 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3017

View Profile
Well thats another thing I was saying Deus, there is also Morphological Antialiasing which is done in the shader. There is no such as mathmatically correct antialiasing, I really don't where Josh is coming from with this. It depends on your definition of antialiasing and a perfect algorithm would test the fragments against all interpolations, but that is not possible with today's computing power. And I can assure you Deus MSAA will look much better for 2D as well, all it does it take the pixel and interpolate with the destination pixels, it does the same thing except can hold more accumulations of pixels making it look better and does not require you to do any depth sorting. The reason I have not comitted yet is I started talking to Josh about how we would recreate the texture for each view, and given GM's poor display_reset() implementation because DirectX enables it throuh the swap chain, I have decided to create multisampler surfaces.

For instance, you will create a surface with surface_multisampler_create(width, height, samples); then when draw anything you want to have antialiasing to that surface then draw the surface on the screen. This will give you complete control over it, and also GM:Studio added binding a surface to a view, so when we add that functionality you can just bind the multisampler surface to a view, and bam your done. Now some games like Battlefield 3 will do MSAA and SSAA at the same time, this is why I will also provide an surface_supersampler_* series of functions in the future as well and you will just combine the two surfaces together using your preferred technique of blending/interpolation.

I have to reprogram what I started to surfaces though, and I got sidetracked fixing Game Information and Game Settings for LGM, we got her down to only 11 bugs now. As soon as IsmAvatar comes and merges my pull request, I will go get those surface functions done for you, I also have more surprises coming up for everyone soon.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Pages: 1
  Print