vid_renderer

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

vid_renderer

Post by dpJudas »

To help try fix the vid_renderer problem I've ported the ZDoom Direct3D 9 hardware acceleration over to OpenGL. The work is mostly done, except that there might be some minor issues with LB modes and hardware gamma (haven't tested either yet). I'm also not 100% sure if the burn effect is looking as it should - seems rather ugly up to me, but I haven't booted ZDoom or GZDoom to check if it really should look this way.

I've merged in what I have right now into QZDoom master. Hope that's alright. Hopefully this should make it possible to make vid_renderer change without a restart sometime in the near future. Note that if you decide to do any bug fixes on this, then its probably best to branch off gl_swframebuffer from my repository as I think this feature might be of interest to GZDoom as well. ZDoom itself could also use it for the Linux/Mac targets, but with all the OpenGL initialization code in GZDoom I decided it was too boring/difficult to get it running there.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

dpJudas wrote:I've merged in what I have right now into QZDoom master. Hope that's alright.
That's fine. :) Thank you.
dpJudas wrote:Hopefully this should make it possible to make vid_renderer change without a restart sometime in the near future. Note that if you decide to do any bug fixes on this, then its probably best to branch off gl_swframebuffer from my repository as I think this feature might be of interest to GZDoom as well. ZDoom itself could also use it for the Linux/Mac targets, but with all the OpenGL initialization code in GZDoom I decided it was too boring/difficult to get it running there.
When I switched to DirectDraw it had problems then, too, so I am not sure. I am hoping it does, though.

I can probably get the Linux part running if/when I get a computer that doesn't fight with me when I try to install it bare-metal.

I have my Raspberry Pi but I don't have a monitor that does HDMI inputs, sadly. :( (Something I thought would be standard for all HD monitors and displays... I was wrong...) But someday - eventually - I will get Linux working on *something*. I am hoping my laptop, as that would be convenient.

The reason why I don't like VirtualBox is because Linux is a bit glitchy on there.

With all that said though, I'll give this a whirl, and possibly even import my live switcher branch to see if it continues to work. I am also going to post this for Randi to see, as I think she might be interested. Having ZDoom running on OpenGL will standardize the interface a bit on all platforms and allow Linux and Mac to take advantage of the Truecolor HUD/Weapons.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

Not completely sure if it was due to Direct3D either, but I figured porting the code over to OpenGL was the easiest way to completely rule out any such possibilities.

I have Linux as a dual boot on my computer that I can test with. I'm just not that keen on booting it unless I absolutely have to because the hi-dpi support in Linux Mint is so broken my eyes begin to hurt. So I'll only do that once vid_renderer works elsewhere and I just need to see if what I coded in Windows compiles or not. :)

What do you use your Raspberry for? Kinda always liked the idea of such a device, but never found a practical use/excuse for buying one. From what I understand on the Pi and Linux, it isn't the best platform to test general desktop stuff on because I think its very stripped down.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

About ZDoom, I think that the Windows target is probably better off using Direct3D as the project seems to want to support for Windows XP age computers. The more recent hardware has good OpenGL support, but in the past Intel in particular was absolutely terrible when it comes to OpenGL.

The Linux and Mac targets in ZDoom on the other hand would really like this feature, but the showstopper here is that all the OpenGL initialization/binding code is in GZDoom. I deliberately ported it in a way that made it use as few dependencies from GZDoom as possible. All it uses is FGLDebug, which can be commented out, and then it inherits from the GL platform specific DFrameBuffer base class. It doesn't rely on anything in the GL renderer itself.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

One problem I am noticing right away is that the pixel scaling is a bit off. For example, the console is not rendering correctly and is a bit messy.

Image
dpJudas wrote:What do you use your Raspberry for? Kinda always liked the idea of such a device, but never found a practical use/excuse for buying one. From what I understand on the Pi and Linux, it isn't the best platform to test general desktop stuff on because I think its very stripped down.
Right now - nothing. It literally just sits in a box until I can afford a monitor that can do HDMI inputs. >_< I was going to just play around with it though, possibly even experiment with it, doing things like installing a router onto it, to see if it could be converted into a wifi router, stuff like that. It's basically just a computer with less power and a different CPU architecture, and that's enough to get me curious.
dpJudas wrote:The Linux and Mac targets in ZDoom on the other hand would really like this feature, but the showstopper here is that all the OpenGL initialization/binding code is in GZDoom. I deliberately ported it in a way that made it use as few dependencies from GZDoom as possible. All it uses is FGLDebug, which can be commented out, and then it inherits from the GL platform specific DFrameBuffer base class. It doesn't rely on anything in the GL renderer itself.
I realize that. I am sorry if I am getting ahead of myself. I am just excited. ;)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

Eruanna wrote:I realize that. I am sorry if I am getting ahead of myself. I am just excited. ;)
Sorry, I forgot I had already mentioned half of what I said there in the first post. Anyway, what I wanted to say was that getting this into ZDoom should be possible without pulling in all of GZDoom. :)
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

If it does go into ZDoom, you're definitely going to need CVars, instead of #ifdefs. I know it's so tempting and convenient, though. XD
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

Actually - I've gone ahead and done it. :)

The new CVAR is vid_used3d. I am now working on making a special menu for this stuff.

EDIT: And now the menu is done.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

The ifdef thing was actually mostly intended as a form of documentation/reminder on where in the code this was controlled. If Direct3D really is the reason it can't switch renderer without a restart, then having Direct3D as an option at all is problematic.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

That is true - but there is a global variable that will control that. As long as QZDoom starts with vid_used3d == true, then you will not be able to switch the renderer on the fly.

The biggest reason I did it, though, was because of exactly what you mentioned before - with some video cards having poorer support for OpenGL than Direct3D. To me, it seems like having a software renderer is more beneficial to those who benefit from using Direct3D, and the implementation is already there. Those people really are not going to care about switching to GZDoom on-the-fly like the people who are like you and I would, who can use the OpenGL backend with no loss in performance whatsoever, and also no glitches.

For QZDoom, obviously this value defaults to being false. For good reason. It should stay that way in GZDoom, too, but inevitably remain an option. In ZDoom - it should actually default to being true. OpenGL is great, but there's no reason to use that when Direct3D is more widely compatible on older Windows machines and ZDoom lacks any real reason to use OpenGL except as a canvas. Obviously, ZDoom on Mac and Linux would be using the OpenGL backend no matter what - because Direct3D doesn't exist on those platforms.

As far as I am concerned, we could hide this option for all I care, or make it enable only on older ATI or Intel controllers, but if this isn't a user-controlled option, I think it really can be problematic.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

Good point. I'd say that even for QZDoom it should probably default to Direct3D unless we truly do find a compatibility issue.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

Since QZDoom embeds the GZDoom renderer, I think it makes more sense to start on an OpenGL canvas. Ultimately, it's still a user option - if a user needs to use Direct3D, they can still enable it themselves. In a sense, I am deprecating the Direct3D backend - but still keeping it available for as long as it is feasible to.

I saw what HazeBandicoot posted in the ZDoom thread - all he has to do is "set vid_used3d true" once, bam, problem solved.

Also - I don't know why GZDoom is still checking to see if the driver is hardware accelerated - I thought that was removed. I thought that all it checks for is to see if the available extensions match its requirements.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

Well - your OpenGL canvas wasn't for nothing. This will certainly be useful for Linux and Mac in the short-term.

However it does not seem to have solved our problem - which I am starting to suspect has to do with pointers more than anything - also the Direct3D backend not being the only (if at all) problem was also proven by when I implemented the live switcher on the Direct3D code, switching it instead to DirectDraw and OpenGL still crashed it.

I left my work so far in here: https://github.com/raa-eruanna/qzdoom/t ... der-switch

I was extremely careful to document my code thoroughly and down to the last detail. Just search for "dragons" to find out just how much I knew about what I was doing. >_> Or - this might work, too.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: vid_renderer

Post by dpJudas »

I've fixed the scaling issue you reported. Apparently there was some difference in between how Direct3D 9 and OpenGL (and Direct3D 11) calculates pixel centers. If you see any stretching again please let me know.

Thanks for the dragon link - it is a good reminder of where in the code I should start looking for this. :)
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: vid_renderer

Post by Rachael »

That's interesting, I didn't even know about pixel centers. XD I will let you know if there are any more problems.

And as for the dragons - you're welcome.
Locked

Return to “QZDoom”