Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

Announcements / Re: LateralGM Update
« on: June 08, 2013, 03:16:50 PM »
I have fixed the game information bug and game settings bug, they now load and save properly as of my latest commit...

Gra, we need to figure out a new preferences system, I found out the Java ones can not be overriden, rest assured we are going to add preferences for the code editor. But I will announce something big very very soon, that will solve everyones problems.

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.


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.

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

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....

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]

"There is no guarantee the GL_LINE_SMOOTH or GL_POLYGON_SMOOTH will do anything."

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.
"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 didn't happen on my ATI card, since ATI does not support polygon and line-smoothing."

Also here...
"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."

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.

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...
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

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...

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...
"* 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.

So again, no biggy, you still have it, its just not treated as main functionality that you should expect to work always.

Ha Ism, try [ ] not <>

Ya polygonz and we got enough bugs already without you implementing ones for the fuck of it.

@forthevin, no I was not aware I must not have payed attention to the website post, didnt really interest I am fine with the site except these forum bugs like the PM stuff.

Of course polygonz, you are right all of our bugs are fixed STRAIGHT AWAY amirite? Thats why we have sooo fuckin many unaddressed tickets on the tracker, isn't it? And no I am not thick headed I listen when Josh and Ism explain this stuff about how to properly be commiting and ensuring there are no regressions etc.

Polygonz you are way too thick headed, if you see nothing wrong with your statement about people releasing games, then I am afraid there is nothing more to discuss. I do not understand what part of people need the mouse functionality locally in order to make a game or even test/program/develop and all of our source code check out systems including the Windows installer go for the latest revision. And it was a week I first had it when you were doing the stuff to speed up the fps rate and did not say anything until a week later when whats his face reported it to me, and I did not say anything to you because I assumed you were just commenting shit out temp. I did not know you were purposely breaking it indefinitely.

Lol, it was a week polygonz, in fact I haven't pulled yet and it is still screwed up on my system.

Off-Topic / Re: Introductions
« on: June 05, 2013, 04:45:39 PM »
Thank you that is very nice  :D

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.

Announcements / Re: LateralGM Update
« on: June 05, 2013, 11:00:45 AM »
There you go Deus redownload I have added it to both the object and timeline editors. As for the icons with exe's I guess nobody just really found it important to do yet, I just fixed the compile button on Linux not that long ago. Not to mention Linux does not even put icons on Exe's you only see them in the task launcher and the majority of us are of course on Linux, it is a sort of preventive measure because a lot of Windows viruses will disguise trojans as regular executable files.