-
Notifications
You must be signed in to change notification settings - Fork 257
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
Unable to initialize OpenGL, render device is null #844
Comments
It is good that you got it compiled so we can figure it out together why it fails. It would be great if you can figure out why the creation of DeviceManager_DX12::m_NvrhiDevice fails. |
well devicemanager is not null where the null seems to come into play is when So far the only thing i can come up with is that Which in turn means that this line
is never called |
tried this idea
which seemed to make it want to behave for a short bit tho i think it fails here
|
Quick question: does your console log report "Unable to initialize OpenGL" on failure/exit? If so, this typically means the game cannot find a working display resolution or video mode for the display you have selected. This would also align with your theory that swap chain creation is failing. Are you starting up in windowed mode or fullscreen mode? You could try forcing windowed mode by setting r_fullscreen -1 in your D3BFGConfig.cfg file or autoexec.cfg file. I have also seen startup failures when trying to start up on multi-display setups where the window is trying to open on a display which is not turned on, and fails. There is detection logic in the startup code which tries to avoid this problem, but there may be edge cases still. If you see the console message: "WARNING: Window position out of bounds, falling back to primary display" something like this may be happening and the code is trying to recover by forcing the window back to your primary monitor. One other possibility - I notice you have multiple graphics adaptors. Which one is being used for the game? Your 1050 has only 2GB of graphics memory which may be insufficient for supporting both your desktop and the game (which takes 1-2GB of graphics memory on its own, depending on window resolution). For DX12, you can force the game to use your 2080 (4 GB) by setting |
well for the graphics adapter the only display connected is currently connected to the rtx card.
logfile output:
|
Some users reported that renaming the home RBDOOM-3-BFG folder helps them if they ran older versions of RBDoom before. Try to change C:\Users\yourname\Saved Games\id Software\RBDOOM 3 BFG but don't delete it so we can hunt that bug. |
Yes, we want to find that bug for sure. Your log output seems to indicate a problem with window position and monitors/display adaptors. The game is trying to start on what it thinks is the primary display on the first non-integrated graphics adaptor, which is likely your disconnected, no-monitor 1050. The line in the log that says "r_graphicsAdapter is write protected and can only be set from the cmdline (or autoexec.cfg)." is important and means the option is not successfully set. Does your autoexec.cfg look exactly like (sorry I meant 0 and not -1 for r_fullscreen):
Your log output should look like:
|
tested adding set the options and now my autoexec.cfg file is this
code still runs and the only thing in the RBDOOM save folder is the qconsole.log file. new trimmed log file
|
Just to rule things out can you either plug a second monitor into your 1050 or pull it from your system and try again? |
I will try plugging in a second monitor (tbh the 1050s whole job was to simply run firefox so i could consult a guide while playing games or such). Same error with 2nd montor installed. |
Thanks for trying that. Darn - this is a tricky one. I have one more request for now: Please set the following in win_glimp.cpp, recompile and run: line 220: And report back with the log info. Happy New Year! If you want to step through in the VS debugger and think it's failing on: DeviceManager_DX12.cpp line 426: Put a breakpoint on line 427: |
first the verbose code never seems to be run because this returns false
and the only way it seems to reach 427 is if i add something like
but if i do add it the values are
this is using the autoexec contents of
|
Interesting, this info is saying you don't have any monitors attached to your display card and you are trying to create a swap chain of 0 x 0 dimensions, which will fail. The next step is to find out why. Put a breakpoint at line 241 inside I am interested in the values of the following variables:
Alternatively, you can paste the following code into
|
After looking deeper into this, I think I have found the problem: On Windows the numbering of desktop-connected displays returned by I had to reconfigure my PC with multiple adaptors and monitors to see it - it is not evident if you have a single adaptor with multiple monitors attached. For instance, if you have a discrete card the display numbers correspond to the number of outputs, and if you combine this with an internal (or other external adaptor), there can be gaps in display numbering that correspond to the unused outputs of the various cards in your system. Fortunately, most of the code in RBDoom3BFG is tolerant of this, but there were some paths in the startup code that assumed the first display was always 0 (or fullscreen = 1), which may not be correct in these multi-adaptor, multi-monitor setups. In addition, there was another code path in the monitor/resolution selection menu that assumed contiguous display numbering, which again was not correct. It also likely explains why querying for monitors sometimes returned false in your example above, and hopefully explains your startup failures (even after falling back to the primary display and safe mode). I have a test branch (that is up to date with @RobertBeckebans current master) with the required changes added. See: https://github.com/SRSaunders/RBDOOM-3-BFG/tree/init-shutdown-fixes I would appreciate it if @jfmherokiller would test this branch to see if it addresses your problem. If it does, I will create a pull request to submit into master. Please test windowed and fullscreen modes at startup as well as in-game to make sure things are working properly. Note the one weird side-effect of this fix is that on Windows you may see odd numberings for the Monitors listed in the resolution selection menu when multiple display adaptors are being used. For instance, in my setup I can see Monitors numbered 1 (or 2 if a cable is hot-unplugged) and 7 corresponding to my discrete card and my internal iGPU respectively. Here are some screenshots of my setup on Windows 10 showing Monitor 2 (6600XT) and Monitor 7 (Intel iGPU): |
Thank you @SRSaunders for looking into this. If @jfmherokiller could test this and it fixes the bug then this could be merged into master. |
@RobertBeckebans while we wait for @jfmherokiller to test this, I have a question about initial window placement behaviour. At startup in non-fullscreen mode (r_fullscreen = 0), the current behaviour is to centre the window on the primary display, independent of which display was being used when the game last exited. The rationale for this was to ensure you always have a valid display to start on. However, when making the changes in this branch I considered changing this to centre the window on the last display used (from previous exit). The argument being if you prefer a certain display for the game, would it be preferable to startup on that same screen again. And if this screen is no longer available (unplugged or off), I could then fall back to primary as before. Would this be a useful change for non-fullscreen mode? If so I could add it to this branch. Note this would not change behaviour when starting up in fullscreen mode on your preferred display - that works today and would not change. |
I started documenting this on discord but It seems that on my system the game will not start regardless if i choose vulkan or dx12.
under my system it seems that the function
void idRenderProgManager::Init( nvrhi::IDevice* device )
is passed a nullptr.system info:
error observed in visual studio using current master commit f9f256c
The text was updated successfully, but these errors were encountered: