BUG: 3.6 on No HUD rendering, corrupt sprites (AMD Radeon HD 6690M) #416
Comments
|
Hi @Pulseczar1 Would be good if we could get to the bottom of this - can you (in ezQuake 3.2.2 is fine):
Also can you Can you also try (using the 3.6 mingw executable to start with), creating the most basic quake directory and test to see if that has the same problem: ./ezquake.exe My suspicion is that it's an issue when building the 2d atlas, but I've tested on Windows 10 laptop I have here using Intel and it doesn't have this problem unfortunately, but it's very old now. Thanks, Can you also |
|
I used ezquake-glsl-vs-x86.exe, which came from the bottom of this page, to generate bug416.cfg, since the console does accept and act on input even though I can't see any text on it. I took the screenshot using ezQuake 3.2.2. |
|
That's interesting that ezQuake says it's using an ATI/AMD graphics processor. I reopened dxdiag and found that both graphics processors are listed. The Intel one, that I reported before, is on the "Display" tab. The ATI Radeon device is on the "Render" tab. I didn't realize there was a Render tab there, when I checked before. So, it looks like this probably isn't a problem with Intel graphics, but rather, AMD. |
Okay. Did exactly what you asked. ezquake-multi-mingw-x32.exe ezquake-std-vs-x86.exe ezquake-std-vs-x64.exe ezquake-glsl-vs-x86.exe ezquake-glsl-vs-x64.exe It's odd that "STD" (is that software renderer?) is crashing on me now, because it didn't do that the first time I tried it, but that was in my normal Quake directory where I was trying it. I just tried ezquake-std-vs-x64.exe with it running in my normal Quake directory, and it did not crash. I noticed I had newer looking menu and conback, as well. So, the old-looking ones are probably due to using nothing but pak0.pak, which you probably knew. |
|
Hi Thanks for this, it's really interesting & useful. I managed to get integrated graphics on my AMD-cpu but unfortunately using the same config and following same instructions, it's still rendering fine. I'm wondering if There are some logging options we could try but they're more snapshots, I think the best thing I can do is probably add a crap-ton of logging to the OpenGL calls to a debug build, and then we could take it from there and hopefully narrow it right down. I'll work on that this weekend. Am really keen to get to the bottom of this. Thanks again, |
|
Just out of curiosity, has anyone else complained about this problem, or am I the only one? |
|
My rather frustrating experience of 3.6 is that someone will report something like this, then go deathly quiet on it and then 6 months go by and whether it's fixed or not is questionable. It would be really good to get to the bottom of this as it's these kind of random reports that keep 3.6 in alpha for such a long time, even though it's the main client version now for a lot of people. Appreciate debugging isn't much fun when you just want it to be your pastime, but if we could stick with it and get to the bottom of it it would be much appreciated. (Ideally I could replicate the problem here but no luck) |
meag
changed the title
|
I can't reproduce this on 18553fe on Linux (GeForce GTX 1080, NVIDIA 455.28). I have access to a Windows 10 laptop with an Intel HD 620 IGP, I'll try running ezQuake there later. |
|
Hi there Sorry for the delay - I broke the rendering on -std in a subtle way while doing this and it took me ages to find. Can you try downloading the visual studio .zip from latest build and then run:
It should generate files in ./qw/trace/ directory:
As you can see the first one is where all the textures are being loaded (you'll see another couple of big files when loading a map for the first time) It will also completely destroy your fps as it checks for errors after major API calls, but that's okay for the moment. If you can give this a go and then zip & upload the contents of the Thanks, |
|
Hi, meag. I downloaded https://github.com/ezQuake/ezquake-source/releases/download/latest/ezquake-latest-windows-vstudio.zip. I ran ezquake-std-vs-x86-debug, by itself, in the same very basic Quake directory that I used in the last test. I got the same debug assertion error that I got before, when running the STD version. It is at a different line number this time (974). Next, I ran in Command Prompt: I then click "Ignore" on the debug assertion. ezQuake went to the blank console. I found that it just kept generating TXT files in the trace directory, about one every second. I was up to 45 files, so I figured it was good to go ahead and exit the game and give you what I have. I now realize those are date and time stamps on the files. So, you are generating one file every second. Here are all of the text files in the qw/trace directory after exiting the game: I then restarted the game, after realizing I should record data after loading a New Game. I ignored the assertion and loaded a new game on map, "start". I walked over to the bouncing lava ball and shot my shotgun a few times to generate the weird graphical particle connection between the two. Shot the wall up close with the shotgun, and exited the game. Here are all the log files from this run: Here is SysPrintf.log from the Quake directory, if that's of any value to you. It should be of the last run, corresponding with the previous zip ("LOADED_NEW_GAME"): |
To help with QW-Group#416
|
Brilliant, thanks very much for this. This is working: This is yours: because the VAO is not being configured, which is the debug assertion... which explains why you have no hud. What I can't see from the trace is why not, as there should be a check when drawing the hud that should lead to it being created for the first time. Azure Pipelines seems to be having trouble uploading images to the release tonight, but hopefully it'll be there soon - it's an updated version that hopefully gives more detail (and saves more traces than once per second, so we're not missing anything) Thanks again, |
|
I should be able to get you new logs on Thursday. |
|
Thanks - apologies again for delay, I had to delete the 'latest' release and re-create it for some reason :( New versions should be there now, for whenever you're ready |
|
I'm glad to help. This file won't open on my Ubuntu 18.04.5: https://github.com/ezQuake/ezquake-source/releases/download/latest/ezquake-latest-linux64.zip This file opens for me: https://github.com/ezQuake/ezquake-source/archive/latest.tar.gz |
|
Thanks for reporting that - I think maybe it's a .tar.gz instead of of a .zip file, I'll get that checked out I haven't tested the tracing in Linux, I think it will still have the problem of writing one frame per second, rather than writing out every frame. Other things to try:
|
|
Compiling and running on my Ubuntu 18 installation was super easy, thanks to the great instructions. I played on my server on 2fort5r for almost an hour without any problems. However, when the server went to map, z7, I found that when standing in certain positions, the sky would show through walls. At times, the problem would go away. It happens in both the red and blue base. At one point, I had to reload the map to get it to happen again, so that I could take this screenshot of it: Startup-renderer text on this machine: Bottom of startup text, showing version of ezQuake: The |
|
Thanks again. Have created #426 for the z7 problem as it seems quite different. I didn't have an example map for sky surfaces on instanced bmodels, so that will be something else scored off when it's fixed. |
|
Hi, meag. I downloaded the current https://github.com/ezQuake/ezquake-source/releases/download/latest/ezquake-latest-windows-vstudio.zip. I ran in Command Prompt: I got the same debug assertion error that I have been getting. It was still at line 974. I clicked "Ignore". ezQuake went to the main menu. I checked that the console was still blank. It was. I loaded a New Game and shot the shotgun a few times near lava ball and shot a nearby wall, and exited the game. No HUD and no crosshair was visible. I am getting a lot more "frame" files now. I would guess one per execution frame. Here are the files: Here is the SysPrintf.log from the Quake directory, corresponding with this run, if that's of any value to you:
You suggested these commands to me, but I wasn't clear on the context of your suggestion, and when I should try the commands, and what to look for. I also can't see console text in this version of ezQuake. So, I didn't use the commands. |
Sampler # stored in z texture coordinate Need to just pass the (s,t) and let OpenGL add (0,1) Might be related to #416
|
... Okay I'm typing this reply out for the 3rd time now, not sure if github is having a moment or I've managed to lose it twice... Thanks again - managed to detect what was happening with the debug assertion (the first frame had 4 lines for the mouse cursor but no images, and initialisation was in the image draw rather than the prepare stage), am hoping that in the latest version that has gone away. I've also fixed a non-GLSL hud rendering problem in classic, but don't know if that will actually help out or not as I don't think it should have been an issue. You could have typed those commands at the console (even though you can't see the console) but if you want you can type them in the command line as well. So some other things to try: // #423 shows the world rendering textures not being set but r_drawflat working, might be interesting if that works for your situation too That last one in particular would be useful to know, as it would identify if the textures aren't being loaded, or if they are being loaded but not rendered correctly. The output directory should be in your qw folder. Thanks, |
That's so frustrating. I usually Ctrl+A, Ctrl+C anything I type more than 5 sentences. Anything I spend over a half hour or so typing gets saved to a text file.
Tried the latest STD version. Console is blank. Options menu is blank. No HUD, crosshair, or "death message" at the top of the screen. No discernible difference in weird particle effects described before.
STD doesn't seem to give me a problem with texture drawing. I have weird stuff with only particles, it seems.
No discernible effect.
No discernible effect. HUD was still blank, even after
This restores my console text. Menus are restored, as well. I still don't have a mouse cursor, but the mouse does work in the menus. HUD, crosshairs, and Escape menu are now working in the game. I still have the same weird particle effects, which I wouldn't expect this to affect.
|
|
This post is going to be about the GLSL latest version. (ezquake-glsl-vs-x86-debug.exe)
Tried the latest GLSL version. Console is blank. Options menu is blank. Game starts dark. (See screenshot.) No HUD, crosshair, or "death message" at the top of the screen. Moving around causes all the lights to turn on and for the game to look normal.
Particles are worse than in STD version, because they look just as weird, but are also all black. (See screenshot.)
This makes dark image at startup look like this:
No discernible effect even while dark, even after
No discernible effect. HUD was still blank, even after
(Same results as STD version) This restores my console text. Menus are restored, as well. I still don't have a mouse cursor, but the mouse does work in the menus. HUD, crosshairs, and Escape menu are now working in the game. I still have the same weird particle effects, which I wouldn't expect this to affect.
Executed |
Brilliant, that really narrows it down then. Can you confirm if you ran |
|
Using:
I compiled and went to New Game. It had me in the game as a spectator, for some reason, as I could fly around, and I don't think my gun was visible. I entered I added the following to the end of This resulted in everything that uses a glyph having a black background. I saw a bunch of black boxes in the console, where text likely is. Everything on the HUD and the crosshairs were just a black box. If you took my yellow boxes screenshot from before and made the yellow black, instead, you would have the same image. The text is not visible. I just have black boxes. I added the following to the end of HUD and console text are invisible again. Black boxes are gone. I replaced the last code addition with this one: It looks the same as I replaced the last code addition with this one: Here is what it looks like when you first start the game and you're in the main menu: Here is in a New Game with the console pulled down: |
|
Hi there Thanks again - this is actually narrowing it down quite a bit, as we can see from the colours that the texture coordinates are changing with each glyph, and that it is returning transparent black rather than solid black, which is what I'd expect if there was an error binding the textures. We're still left with the texture() call returning solid black rather than the texture when the texture coordinates seem to match up to the dumped image though. Instead of using these traces - I think you've got the same problem with the -GLSL version? If so, can we try a RenderDoc trace instead, on the dbg-modern version rather than dbg-classic? You can install it here, then try launching Quake through it (my settings are below)
You should have an overlay in the top left when running Quake, you can press F12 to capture the next frame. Then quit Quake and the capture should be sitting there waiting for you. Then save the capture, zip the .rdc file and upload it here, hopefully I can replay it and see what was happening on your machine. The OpenGL calls that the -classic renderer uses won't work but the new one should be fine. Hopefully this will stop me having to bug you with 20 different versions with more and more logging :( Thanks, |
|
I switched the Visual Studio project to
Performed a Rebuild. Ran the game. The only difference in this version (GLSL) seems to be that the game starts with black textures in a lot of places, as I showed you before, and particles from shooting, and the lavaball trail, are all black. I quit the game and started up RenderDoc v1.11. I set my settings to what you have, other than paths, used
My overlay is gibberish. It doesn't matter what size I make the screen. I then hit F12 to capture a frame. The black textures by then had straightened out, because I had moved the mouse around some (changing look angle). I have a question for you. Does the Classic renderer use GLSL? I would think it doesn't. Yet, we were changing glc_hud_images.fragment.glsl and it was clearly being used, and having an effect in the classic renderer. Why? |
|
I just noticed that this machine marks my zip file as a virus when I try to download it. It looks like it's Firefox making that declaration, but I'm not sure. It lets me open it after I download it. I checked it again after a few minutes, and it's no longer telling me it's a virus, when I click the down-arrow in Firefox to view the downloads. Strange. |
|
Thanks @Pulseczar1 Exasperation intensifies unfortunately, RenderDoc's simulation thinks HUD rendering is fine here:
Can you try opening it up in RenderDoc, going to event 206, then clicking Texture viewer and then Outputs on the right hand side? I'm interested if RenderDoc on your system is giving different output on the same trace.
Really really hoped this would show the same problem on my machine. That your RenderDoc overlay is corrupt is interesting in itself. I can see that your AMD drivers report 4.5.13399, do you know what the release date of that was? I'd like to be using the same version here but the AMD website doesn't go back that far - I've gone from 4.6.14736 to 4.6.13587 but no luck, everything still works. Yours in misery, |
|
I asked you this before, but do you think I should just try updating my graphics drivers? Maybe it's just a problem with my graphics processor, rather than with ezQuake. It will be a few days before I can try some of the things you requested. |
|
Hi @Pulseczar1 Progress at last! Was looking through 3.5's outstanding issues log and noticed fgh also reported a similar but different problem in February 2019 (in his case the menu options didn't appear, but he said he also got black textures when starting map). Asked him today what drivers it was running, so he fired up his now-old machine and ... they matched your driver version. Managed to hunt down my old AMD card (rather than on-chip) and put it in old PC - default Windows 10 drivers for me didn't exhibit this bug but I downloaded the version you are running, forced a downgrade, started ezquake and ... no text :) I've never been so happy to see ezquake not working Version: 4.5.13399 Compatibility Profile Context 15.200.1062.1004 (broken - Catalyst?) I don't know enough about AMD to know if the difference is between Catalyst & Radeon (it seems that might just be an interface thing) or just bugs in .13399 version of the drivers. The bad news is that now I've downgraded the drivers, I can't get RenderDoc to even run :( But at least I've got a machine to debug this problem on. Thanks, |
|
So, should I just update the drivers on the machine that has the problem?? |
|
I've found the lack-of-text bug: So updating drivers would seem to help a lot - I'll leave my machine on the older versions and will keep looking into it though. |
|
If you would like me to not update my drivers, so that you can continue investigating the problems, I can do that. |
Here's what mine looks like. There are a lot of odd things about the rendered images. I'm not sure whether it should look like that in RenderDoc. I don't really have a reason to update the graphics drivers on this machine, other than to have the latest in-development ezQuake look right. I don't need to use the latest just yet. So, I'm going to leave my drivers alone for right now, so that if you are still interested in having me check anything for you, with the current setup, I can do that. If you would like me to update my drivers, and tell you whether problems go away, I can do that, too. For now, I will leave them alone, though. |
|
I also want to let you know that I pulled:
I compiled in
It sounds like updating my drivers would fix the particles. I think the only thing left is the black textures, unless new drivers also fix that.
Current state at start of New Game: |
|
Excellent, that's great news - although in fixing it I created another bug that was hiding away waiting to bite people who didn't have that texture extension in their drivers (hopefully fixed tonight). On my own config at home (still on the broken drivers) I sit at the start position with no angle movement, and the texture for 'Quake' and around the teleporter for 'normal' skill appear when the fireball is active (so entity rendering has an effect) and disabling fastsky gives me textures again. So there's definitely something state-related that we can fix there. And particle drawing is still invalid, like the indexes are incorrect. Getting there though, finally.... thanks for all your patience with this. |
|
Just to say that I haven't completely given up with this, but on the particles, it seems on the broken drivers |
|
So, are these problems the fault of the drivers or of ezQuake? If newer drivers fix the problems, I'm curious why you choose to keep working on it. |
|
Something like it, almost same problem here with mesa-21.1.4 / llvm 12.0.0, affects both nouveau and amdgpu Anyone with debian wanna try latest llvm 12.x and mesa-21.x with amdgpu/nouveau drivers? (already asked ciscon)
|
Caused problems on AMD Core Profile Fixes one issue in QW-Group#416
See github bug QW-Group#416 Can find workarounds for a lot of the issues but not solutions as to why the originals don't work - could be these drivers are just a lot stricter but some things seem very strange
|
Current state of this (various bugs related to this driver): Wall textures not appearing in AMD core profile: tracked this down to alignment of attributes in VBO, specifically a single unsigned byte for the per-surface flags. No errors returned but changing this to a bigger type (and making everything align on 4-byte boundaries) seems to have fixed it. Can put this down to a straight-up bug as the alignment can be corrected. On GLSL renderer, half the screen is rendered (first triangle in triangle strip is ignored)... adding an extra vertex to the start and rendering vertices 1=>4 works but 0=>4 don't. OR, use glBindTextures() also seems to cause problems... have downloaded and checked bound textures before and after (all seemed to check out) but sampled textures are messed up after using it. Have given up on this and am now detecting this driver version and falling back to older functions, but feels cheap - the state is corrected (momentarily) while particles on the screen, as the binding of a different array fixes it. Am still not ruling out that these drivers are simply stricter, but this bug has been open nearly a year and while it feels like defeat, am just going with workaround route for the moment. |
|
You do the best you can and that's all you can do. Keep the problem on the back burner (or in the freezer) until you get another idea or something changes. |
Another bug found in AMD .13399 drivers... (QW-Group#416)
### Changes from alpha8=>alpha9 (July 13th => November 14th, 2021) - Fixed/worked around some classic renderer bugs on version x.y.13399 AMD drivers (QW-Group#416) - Fixed bug causing off-by-one error when drawing rectangle outlines (3.5 bug, reported by Matrix, QW-Group#536) - Fixed `/in_raw 0` behaviour on MacOS (QW-Group#489) - Fixed `/r_drawflat 1`, `/r_drawflat_mode 0` affecting ammo boxes etc in classic renderer - Fixed match logging not working when using competitive rulesets - Fixed incomplete rendering when gibbed or dead in shallow water (reported by Matrix, QW-Group#568) - Fixed tab key not switching tabs on serverinfo popup (reported by Hangtime, QW-Group#555) - Fixed `/demo_jump_mark` not working if `/demo_jump_rewind` not set - Fixed coping with 1x1 ibar.png (reported by Matrix, QW-Group#571) - Fixed powerupshells when using `/r_viewmodelsize` (reported by timbergeron, QW-Group#573) - Fixed crouch adjustment staying disabled after teleport/respawn when `/cl_nopred` enabled (reported by Matrix, QW-Group#572) - Added `/gl_smoothmodels` back in (modern renderer only), (requested by Repast via [quakeworld.nu](https://www.quakeworld.nu/forum/topic/7508/why-is-the-command-glsmoothmodels-r)) - Added `/demo_jump_skip_messages` to determine if messages should be printed to console during demo jump - Added `/demo_jump_end` to jump to next intermission point or end of demo (requested by Hangtime, QW-Group#564) - Added `/sb_info_filter` to allow filtering of servers in server-browser based on serverinfo (requested by Matrix, QW-Group#537) - On startup (after `autoexec.cfg` executed), a `vid_restart`/`s_restart` will be issued if any latched variables were changed (reported by Dusty, QW-Group#458) - Multiview will be disabled when watching a solo demo and no powerup cams are active (requested by mmavova, QW-Group#126) - MacOS: sets SDL flag to stop touch events being translated into mouse events (might help with QW-Group#354) - `/status` command will be ignored if an alias with the same name is found, use `/sv_status` instead (fixes QW-Group#532) - qw:// urls in command line will be opened even if not preceded by `+qwurl` (thanks to ciscon) - Linux: register_qwurl_protocol will register protocol with xdg (thanks to ciscon) - Added `/v_dlightcolor` to control if being inside flashblend light affects palette by color of light - Added `/v_dlightcshiftpercent` to control strength of palette shift effect when inside flashblend light - Changed `/v_dlightcshift` to be enum of when being inside flashblend light affects palette (requested by HangTime, QW-Group#542) - Added `/vid_framebuffer_multisample` to control multi-sampling level of the framebuffer (reported by Matrix, QW-Group#367) - Translucent models are first drawn with a z-pass, to stop overdraw affecting level of translucency - Fixed explosion effects on md3 viewmodels (additive blending was being lost) - Removed server-side weapon switching 'support' in client - Removed debugging messages when using `+fire_ar` - Commands that search by regular expression (`/cvarlist_re` etc) are now case-insensitive (reported by HangTime, QW-Group#599) - Added `/fs_savegame_home` to control if games are saved to home directory (default) or game directory (reported by githubtefo, QW-Group#586) - Fixed `/gl_no24bit` not taking effect after `/vid_restart` (reported by hemostx, QW-Group#601) - Fixed `/gl_no24bit` not disabling loading external textures (3.5 bug, kind of reported by hemostx, QW-Group#601) - Fixed bug causing `/gl_scaleskytextures` to not affect external textures (reported & fixed by hemostx, QW-Group#606)
Please search for existing issues and check for potential duplicates before filing yours.
ezQuake version:
3.6-alpha3
OS/device including version:
OS is Windows 10. The graphics device on this machine is Intel HD Graphics 4600.
Describe the bug
See #412
The text was updated successfully, but these errors were encountered: