|
|
|
This thread is locked; no one can reply to it.
|
| OpenGL Shader Performance with Primitives Add-on |
|
Rodolfo Lam
Member #16,045
August 2015
|
So I finally decided I would use Shaders on my Allegro programs to have access to more advanced effects (will try to eventually implement 2D lightning with dynamic shadows). To test if this would be a good decision, I made a small test program that involves moving a magenta square (made with the Primitives Addon via al_draw_filled_rectangle())through the screen using the keyboard or a joystick. I am currently using the NuGet version of the library for VS2015 Community, version 5.1.13. I am running this on Windows 10 Pro 64-bit (albeit Allegro is the 32-bit version). My graphics card is an Nvidia GT 610 2GB VRAM (Don't buy this one by the way, but that is another topic), 4GB RAM, Intel Core i3 2100 3.1Ghz. The first version was done as one would normally go on Allegro, and it outputs a constant and smooth 60fps (I have the updates limited by the timer and also VSYNC forced ON to prevent any tearing). The second version that I just finished is not that different to the first one, it just uses the default Shaders provided by Allegro to achieve the same effect. However, for some unknown reason, this version has severe stuttering and jittery movement with both the keyboard and the joystick. I am totally sure it is not even running at 60FPS. I would like to know if someone else also experiences this issue and mostly, if there is any solution to it or anything I can do to prevent this from happening. Attached is the code that I use to make this example, joystick functionality is removed on this version to keep it simple. Shader code used is the one given by Allegro if you used al_get_default_shader_source(). Here it is as found on the repository. Replace the MACROS with the correct values to use them with the program as-is. Additionally, if you want to see the full code, not the simplified version, it is located here at BitBucket. Note that the Shader support is on the Awesomium_integration branch.
|
|
Kris Asick
Member #1,424
July 2001
|
If your own shader code is working better than Allegro's built-in shader capabilities then just stick with your own code. Just a note though: Something I noticed with A5 and OpenGL on Windows 8 was that the first display created by Allegro would stutter every so often, while subsequent displays created would function perfectly fine. If this problem has carried over to Windows 10 as well, the solution is to have a video configuration box or SOMETHING that requires user input come up before starting your program proper, and make sure to destroy that display and create a new one following. I have my video configuration stuff show up this way and have the "Start" button highlighted by default. --- Kris Asick (Gemini) |
|
SiegeLord
Member #7,827
October 2006
 |
I'm confused what two conditions are you comparing. Are you comparing displays without the programmable pipeline to those with programmable pipeline and default shaders? Or both programmable pipeline but one without manual shader calls, and one with manual shader calls? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Rodolfo Lam
Member #16,045
August 2015
|
Oh, sorry about that... I'm comparing a no shader/no programmable pipeline approach with a shader approach/programmable pipeline that uses the default shaders provided by Allegro. The only thing I'm doing different is that I manually copied the default shaders to a new location so that I can build my own in the future using those as a base. The program loads this file at runtime, but it is essentially a copy-paste of the built-in ones I will test tomorrow the tip Kris said. Create a second display while the program is running to see if that is the cause of this sudden erratic frames.
|
|
Elias
Member #358
May 2000
|
So we have these three cases: A. Allegro without the PROGRAMMABLE_PIPELINE flag and no shaders You say A is fast and C is slow - but what about B? -- |
|
gameovera
Member #15,340
October 2013
|
Allegro5's default shader using branch(if-statement) in fragment shader. |
|
Chris Katko
Member #1,881
January 2002
 |
gameovera said: Allegro5's default shader using branch(if-statement) in fragment shader. Good lord, it does?! -----sig: |
|
Kris Asick
Member #1,424
July 2001
|
Word of caution on creating additional displays though: There's something weird going on internally with Allegro in that if you create a display, remove it, then create another, and do NOT have user input on the first one, IE: everything happens automatically and in sequence, the second one won't be created properly... in fact, you're liable to crash your entire system. So, make sure the first display has some sort of input, like requiring the user to hit a button or click something or whatnot. I discussed this stuttering thing here on the forums awhile back but I don't think any progress was made on narrowing it down. Also, it had to do with the 5.0.x branch, so if you're on 5.1.x it may not be an issue at all as I have no experience with it. And again, NONE of this may be related to what you're experiencing as there could be lots of reasons why you're getting stuttering... especially on a GPU as weak as a GeForce _10 card. (In three-digit GeForce chipsets, the first digit is the generation and the next two digits can be thought of as the raw power of the card.) --- Kris Asick (Gemini) |
|
Rodolfo Lam
Member #16,045
August 2015
|
Hey guys I think I'm starting to understand what is happening. To avoid confusion I'm sticking to identifying the versions of the program as A, B and C as Elias mentioned some posts above this one. It's Windows OpenGL implementations fault. The original "A" version I classified as fast (no jittery movement) was using DirectX, when I was trying to build a "B" version I discovered this fact. The A version displays the same issues as the "C" version when run under OpenGL. I haven't yet tested an OpenGL B version yet. I assume the results will be again jittery movement. Will do that now and then try to implement Kris' workaround and see if it can solve this issue. Removing the if-statements from the Shader code also did not give any noticeable impact. However is something I'll keep in mind when coding custom Shaders. Edit: As expected, the B version also shows stuttering under OpenGL. Neither version shows this when running under DirectX. The workaround involving creating a first display, receiving input then destroying it also did not solve the issue under OpenGL. Well... it looks I'll go the DirectX way because of this. Time to learn HLSL. I'll leave the splash screen there as I ended up linking it and will probably find some use for it later on. Thanks for all the help and tips!
|
|
Kris Asick
Member #1,424
July 2001
|
Rodolfo Lam said: It's Windows OpenGL implementations fault. Or an oversight in how Allegro creates an OpenGL window, considering there's plenty of OpenGL-using games which don't have this problem under Windows 8 or 10. As I originally suggested here on the forums, something which Allegro is doing between running I/O, closing an OpenGL display and creating a new one, is likely leading to a properly created OpenGL display. Again though, this might be a non-issue in the 5.1.x branch. I haven't done any work with 5.1.x because I always run into very mysterious problems trying to compile Allegro myself. (Last time it was because I was having problems with full-pathname files not being found by the compiler... despite those files existing. The last time before that the compiler wasn't able to call the linker despite proper paths set up and the linker program definitely being there.) EDIT: One other thing to keep in mind is that you have such an underpowered GPU it may simply not be able to handle custom shaders. The difference in power between a 610 and a more common 650 is MASSIVE. Heck, I have a 660 GTX and even it is substantially more powerful than a 650! --- Kris Asick (Gemini) |
|
Rodolfo Lam
Member #16,045
August 2015
|
Yes that also makes total sense. The 610 is simply just too slow to handle this. I'll get a new one soon. A combination of this and the OpenGL instantiation of Allegro 5.1.13 could be the cause. Looking at the bright side, since Direct3D is giving me more performance on this specific issue, I'll use this opportunity to look into it finally.
|
|
|
