New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: OpenGL video driver #7744
Conversation
And as usual when having done heavy rebasing earlier, the display order of the commits on GitHub is wrong. |
4b93d31
to
a27d651
Compare
Any chance you will continue this excellent work? Having an OpenGL driver might resolve problems towards the future too :) |
I will rebase this in the next days. Otherwise, it works on the hardware that I have access to. There were anecdotal comments that some other hardware/drivers didn't work, but there's nothing I can do about that if no reports/test are done. Somebody else will have to do the Linux-specific part. OSX, we'll have to see. |
524a249
to
0769193
Compare
(download link in PR description now) |
Run with This is crazy faster for me, I did not expect that honestly. I can normally get ~400fps with
With |
f2a9f6a
to
7a88c7a
Compare
#include "../safeguards.h" | ||
|
||
|
||
static PFNGLDEBUGMESSAGECONTROLPROC _glDebugMessageControl; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using autogenerated OpenGL loader such as https://github.com/Dav1dde/glad might be simpler than doing all that manually in our code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. And most people will say to just chuck in GLEW.
Doing this for OTTD was only my second motivation, primarily I wanted something to get more familiar with OpenGL. And for that goal, I chose the do-it-yourself way, also called the know-whats-happening-behind-the-curtain way.
It's certainly not set in stone, and if everybody else likes some kind of external dependency more, changing it is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GLEW doesn't support OpenGL ES though (which we presumably will want to add because of WebGL/Android).
Observations from trying out TrueBrain's "dirty" version for linux: Scrolling is very slow, adding overall, performance seems slightly better than non-opengl, although i haven't gathered any hard data on that.
glxinfo output
|
On
persistent buffer mapping yield very poor performance, it needs to be disabled. I tested with Mesa on Intel device, and persistent buffer mapping works fine there.
so it needs this patch:
|
9dd472b
to
fe8365f
Compare
I've tried a first go at disabling persistent mapping for AMD. @Milek7 Thanks, merged in that shader fix. |
I've also changed |
That likely shouldn't be accessed directly and instead use |
…w blending effects.
… palette values of the screen in addition to the colour buffer.
…ackend to speed up palette animation.
This makes it a bit easier to follow what is going on, and allow future subdrivers to hook into a few of these functions. Reworked the code slighly while at it, to return early where possible.
This increases readability, and allow future subdrivers to not use SDLSurface to draw.
This allows future subdrivers to override them.
This allows future subdrivers to use these to manage their own flow.
Current PR state:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works as I would expect, and the code looks sane to me. Did not really review opengl.cpp
because .. well .. I am not aspiring to become an OpenGL expert :P So I trust your judgement there.
Rest looks all in order to me, and the results are pretty nice. So yeah, I think we should go for it :)
This PR provides a video driver that uses OpenGL to transfer the video buffer to the screen, including palette animations.
Right now, the driver is Windows only and tested on hardware I have around (which is mainly recent nVidia). Results on other hardware may vary. Results on others operating systems need implementing first.
This is just a driver backend, NOT a re-implementation of the whole blitter stack, i.e. OpenGL is not used to draw single sprites to the screen. I did add a simple
40bpp-anim
blitter, which is basically a 32bpp blitter with "hardware" palette remap support. It could probably be optimised using SSE, just like the regular 32bpp blitters.Enable driver debug level 3 if you want to verify that you are in fact using the new OpenGL driver.
You can preview this on Windows by downloading a build from the following URL:
https://www.openttd.org/downloads/openttd-branches/pr7744/latest.html