Massive FPS drops during explosions with cl_lights 1 #147
Comments
|
I've had this problem with integrated video cards. Are you using an Frank On 8/1/2016 10:04 PM, iButane wrote:
|
|
Holy shit, 54fps instead of 250 is a massive drop. I thought maybe I've never noticed because I always use vsync so I never have more than 60fps anyway, but without vsync and cl_maxfps 300 I have stable 250fps, also in that scene. But I'm using a nvidia Geforce 770 on Linux, so /maybe/ the AMD driver handles YQ2's ancient OpenGL code worse than nvidias driver. Frank: he said he uses an AMD R9 270x, so probably not integrated.. but maybe make double sure and check the startup messages (open console after startup and scroll up to "OpenGL settings:" - what GL_VENDOR and GL_RENDERER does it use?). |
|
cl_maxfps is wrong. I never reported this as a bug to any Quake related Frank On 8/1/2016 10:32 PM, Daniel Gibson wrote:
|
|
For some reason it seems that with cl_maxfps at high values I get 250fps or 500 or 1000, no idea whose fault that is, maybe nvidia linux driver or something? I'll test on Win7 with a Radeon HD 6950 tomorrow. |
|
GL_VENDOR: ATI Technologies Inc. Sounds like an AMD issue... I usually have my cl_maxfps set to 144 (got a 144hz monitor). I just maxed it out to 999 or whatever for those screenshots. |
|
Ok, on Win7 with AMD Radeon HD 6950 I get about the same FPS numbers as you, including drops during those first explosions. Not sure what exactly makes it go slow there and what the other Quake2 ports changed in the renderer so you don't have the same issues there. |
|
@iButane Can you try setting the |
|
on my Win7/AMD machine, setting I think we already set gl_ext_multitexture to 0 by default in the last release, but if you have an older config it might still be set to 1 there. |
|
Funny, multitexturing in q2 being slow, especially with explosions, has been known at least since 2002: http://icculus.org/pipermail/quake2/2002-August/000431.html http://icculus.org/pipermail/quake2/2002-August/000433.html |
|
Ah! yes! That was the culprit! Everything works smoothly now; no drops in FPS whatsoever! I though it was set to 0 as well but nope, was 1. I installed Yamagi on my son's PC yesterday (prebuilt windows binaries) and it also had the same issue (AMD card as well) so I'm guessing gl_ext_multitexture was also still set to 1. Just d/led the prebuilt binaries and the generated CFG file now has it set to 0. Damn, I notice quite a big different with multitexture on and off though. The game looks much darker now. It was so much more vibrant (the colors/detailts) and upping the vid_gamma doesn't help very much. it does brighten it up but looks a bit dull. Dang! Might just have to suck it up with the slower FPS. |
|
Not sure.. it somehow handles textures differently, which was supposed to be faster on some ancient hardware. Or something like that. Also, pretty cool you introduce your son to Quake2! I hope you'll have some fun playing coop :-) |
|
Just edited my above post. Did some testing and I noticed a difference =/ Yeah, he wasn't really into at first but now all of the sudden he is for some reason. hehe.. Will be fin co-oping, that's for sure. |
|
WTF, that is strange, I don't think gl_ext_multitexture should make any difference regarding brightness.. can you make screenshots for comparison? |
|
Yup.. Some screen's showing it on and off:
Not very accurate since they are BOTH darker than what it actually is. I'll try playing with intensity a bit.. I know i've spent hours in the past in other ports trying to find the perfect balance for intensity, gl_modulate and vid_gamma.. hopefully that doesn't happen here, lol.. |
|
Sweeeeeet! Played with intensity.. default was 1.75, Bringing it up to 3 makes it almost identical to before with multitexturing on. Thank you very much for the tip. Those screenshots are horrible btw. The game looks much better (brighter) than that. Could also be my 144hz monitor (notorious for making colors look off/washed out) but only Q2, regardless of port, has this issue of non accurate screenshots. Then again I haven't compared SiN's screenshots. Could be the engine. |
|
Yeah, I noticed that with the DK 1.3 port we work on that the screenshots themselves always seem a lot darker for some reason. But in most of my q2 engine games I set intensity to 2 or 3 typically. |
|
I think the reason is Gamma: if the brightness is increased with gamma, and "hardware gamma" is used like Daikatana 1.3 and YQ2 do by default, then the brightness of the whole screen is changed, but that doesn't change the pixel values in the game. The gamma is applied afterwards by the OS/GPU/whatever. |
Isn't that what this would be? Notice the little lamp/light on the ceiling:
^ that's using: gl_ext_multitexture 1, intensity 1.75
^ this is using gl_ext_multitexture 0, intensity 3.5 |
|
i think it just looks different because of the intensity values and that On 8/3/2016 11:08 PM, Butane wrote:
|
|
Yeah.. Probably.. Damn, I noticed with increased intensity my lava looks green.. hah.. What a pain! Will have to play around more with this tomorrow.. But as it stands I think I'm willing to suck it up and play with the fps drops/ multitexturing on. I can only imagine the difference in more detailed, more colourful environments like the city1+ etc maps. |
|
Before you dismiss... can you try my Quake 2 port and see if the same https://bitbucket.org/neozeed/q2dos/downloads/q2dos_20160205_win32.7z This will overwrite your ref_gl and gamex86.dlls so youll need to On 8/3/2016 11:26 PM, Butane wrote:
|
|
hi all, On Wed, Aug 3, 2016 at 11:29 PM, Frank Sapone notifications@github.com
|
|
maraakate, appears exactly the same/no difference with multitexturing on and off.. Fresh Q2 install with your files, multitexturing on:
and now multitexturing off:
intensity (2) and gamma (1) are all defaults and I did a vid_restart on both. I used the unofficial 3.24 patch for along time. Was my fav until I discovered Yamagi. I wasn't a big fan of the dull, dark contrast look of 3.24's GL render but I did like how it make Q2 look a bit more "realistic" coz of that. I tried to make the colours more vibrant but I don't think there is anything (settings) that can do that on that gl render. EDIT: Oh yeah, and no FPS drops at all in the base1 intro with the explosion, multitexturing on or off. |
|
@Pickle: I've created a new branch version6 with all generic parts of your OpenGL ES patch (the vertex arrays and the texture stuff) and my asynchronous client stuff. We may that use as a base for a slightly incompatible version 6.0 sometime in the future. The details have to be decided yet. |
|
@Yamagi, glad to hear that. On Thu, Aug 4, 2016 at 3:35 PM, Yamagi notifications@github.com wrote:
|
Out of curiosity, why was multitexturing disabled by default after this release? --nevermind, found my answer: 6f64efb -- Curious now about that render glitch on city3; guess I'll see it when I get there on my campaign run. I guess multitexturing is not really important today.. but just because I did notice visual and performance differences in Yamagi, I did some more comparisons and testing. This time on the very last official release, 3.21. gl_ext_multitexturing on or off here does absolutely NOTHING visually and also there are no frame rate drops whatosever when it is on with cl_lights 1. Anyway, I guess I could play with it off to avoid the FPS drops, but my question is, how come the colors/brightness darken when I set it to 0? Can you guys fix that so it doesn't? and if not, is there a way I can increase my intensity without making the lava greenish looking? Sorry.. I know, so many questions and shit over something so small and irrelevant in today's rigs. I just like having my Q2 looking the best it can in its vanilla form 😃 |
|
After some code reading I'm quite sure that I understand what's wrong:
|
This is a slighty revised version of id Software original code. Icculus code may have some advantages on broken drivers or underpowered GPUs. Today it's just a performance hook. This is a first step in fixing #147.
That would explain why there's no issues or frame rate drops with gl_ext_multitexture 1 on Q2 version 3.20 and why issues only started being reported in 2002 with Icculus. |
|
@butane: multitexture is still relevant, its part of the standard API now. @Yamagi: Have you thought to replace the old On Fri, Aug 5, 2016 at 2:52 PM, Butane notifications@github.com wrote:
|
I think / guess / *fingers crossed* that this fixes the different brightness levels between normal and multitexturing mode reported in #147.
|
Okay. I think that the version6 branch fixes all theses problems. It would be nice if you could test it. Windows binaries can be found here: http://deponie.yamagi.org/quake2/windows/quake2-6.00-test1.zip Changes to the 'master' branch are:
|
|
I've pushed some more fixes to gl_overbrightbits and rebuild the Windows binaries. Please redownload them before you test. I think that overbright bits now look exactly the same in both code paths. |
|
Ok.. I tested this very briefly. The default gl_overbrightbits 2 looks a bit broken: But with gl_overbrightbits 1:
And then the default gl_multitexture 0:
And with it on, still makes a huge difference:
Also gl_overbrightbits 1 gives these dark squares (only 1 seen here on the right): But with gl_overbrightbits 2 it's fine:
|
|
ignore my results i tested master by mistake On Sun, Aug 7, 2016 at 2:17 PM, Pickle136 . pickle136@gmail.com wrote:
|
|
I reran on the correct branch the rendering issue i saw before is On Sun, Aug 7, 2016 at 4:44 PM, Pickle136 . pickle136@gmail.com wrote:
|
|
@Pickle You sure you tested on the right one? Because gl_ext_multitexture is now gl_multitexture. |
|
yeah is was gl_multitexture, i just copied it from the last email, but i On Mon, Aug 8, 2016 at 5:45 PM, Butane notifications@github.com wrote:
|
|
Okay, another test version. Again the version6 branch or these Windows binaries: http://deponie.yamagi.org/quake2/misc/quake2-6.00-overbright2.zip Daniel and I had a long discussion last night if this is really okay, because there are some differences between gl_overbrightbits with and without multitexturing:
|
|
@Pickle: 30 FPS seems much to low. This may be caused by wrong cvar settings. With the version6 Branch cl_maxfps limits the client / network framerate and should be set to 30. gl_maxfps determines the render framerate. Is that cvar set 30 by chance? |
|
@Yamagi both cl_maxfps and gl_maxfps ar set to 95. I turned it off but the On Tue, Aug 9, 2016 at 3:18 AM, Yamagi notifications@github.com wrote:
|
|
Hrmm.. tested the windows binaries.. I think gl_overbrightbits 2 makes the colors too bright and greenish: But with gl_overbrightbits 1 it looks decent, just a little too dark:
Still, nothing beats the look of gl_multitexture 1 look with gl_overbrightbits 1 if it weren't for the fps drops. At the moment, the current 5.34 windows build looks best with gl_overbrightbits 2 and gl_multitexture 0: |
|
Since gl_overbrightbits is working now for the non multitexturing path (even if the look is slightly different) and a full fix for the multitexturing performance problems requires refactoring the whole render path I'm considering this as solved. Maybe we'll come back at the renderer and implement a modern OpenGL or even Vulkan render path. |
|
A modern GL renderer implementation is something I'd be interested in helping on, assuming I had time (I wish). However, at this point it would really make more sense just to go directly for Vulkan. |
|
@DanielGibson has some plans for a new renderer. I don't know what exactly and if there's a time schedule. |
|
My rough idea is to first put the renderer in a lib (dll) again and then starting to create an alternative renderer using OpenGL3, mainly as an exercise for me to learn OpenGL. Vulkan doesn't make that much sense IMHO, because it's totally overkill for Quake2 and Apple doesn't support it. Of course, once we support renderer libs, we could have a Vulkan renderer as an alternative too, if anyone wants to write one - but I personally don't plan on writing one in the foreseeable future. |
|
I'm on Arch Linux with an Nvidia card and the latest proprietary drivers. There's seems to be no difference between gl_overbrightbits "0" and "1". Using a value of "2" makes everything way too bright and does have that greenish tint iButane was talking about. I have multitexturing disabled and overbrightbits disable and im pleased with how it looks. I do use max digital vibrance because it makes everything look more colorful, so that may give a similar effect to overbrightbits. I'm using the latest git build by the way. |
I get significant FPS drops during explosions with cl_lights 1. It's mostly noticeable during DM matches where you've got multiple rockets being fired etc. I know Yamagi is primarily a single player port but this issue is also in SP mode even though it's more of a concern in multiplayer.
Also, there have been some user maps I've played which also have massive drops in FPS without any explosions. I don't get these FPS drops in any other Q2 port I've used (q2pro and unofficial 3.24 patch for example).
Anyway, I'm currently running through the SP campaign and if I find a specific area where these FPS drops happen significantly without any action/explosions I'll post it here. So far I can show you the FPS drops at the very beginning of the game, base1 explosions:
cl_lights 1:
and cl_lights 0:
My system specs are: Windows 7 64 bit, i5-2500 3.3ghz, 12GB RAM, AMD r9 270x
The text was updated successfully, but these errors were encountered: