I went ahead and also did a fresh install of version 1.0.0.9 and the issue still occurs. This also occurs with Blue Shift.

What do you mean by 'pause' the game? I know HL has a pause button (at least I seem to recall that it does), but whenever I play HL, it's two expansions, or any of the mods, I pause the game by just pressing 'ESC' to go to the main menu, I never use the pause key. Have you tried pausing the game this way?

Kerr Avon wrote on 2020-02-04, 21:02:

What do you mean by 'pause' the game? I know HL has a pause button (at least I seem to recall that it does), but whenever I play HL, it's two expansions, or any of the mods, I pause the game by just pressing 'ESC' to go to the main menu, I never use the pause key. Have you tried pausing the game this way?

By pause, I mean pressing the escape key to go to the main menu.

I see. I can't think of anything to fix it, sorry, but does it do it in all the renderers in the options screen, including software? If not, then that might be a clue towards the cause.

First of all, though, you might want to try the Windows Engine port, Xash3D, https://github.com/FWGS/xash3d-fwgs. Hopefully that will work without problems. If not, then all I can suggest is the the tedious job of looking on various Half-Life forums to see if anyone has a similar problem, and how they fixed it.

Kerr Avon wrote on 2020-02-09, 17:42:

I see. I can't think of anything to fix it, sorry, but does it do it in all the renderers in the options screen, including software? If not, then that might be a clue towards the cause.

First of all, though, you might want to try the Windows Engine port, Xash3D, https://github.com/FWGS/xash3d-fwgs. Hopefully that will work without problems. If not, then all I can suggest is the the tedious job of looking on various Half-Life forums to see if anyone has a similar problem, and how they fixed it.

Well, if I use software, in game I can only see my desktop, and with Direct3D, I can start a level (at a low FPS though) and if I hit escape, the menu comes up, but if I try to go back into the game I get the same issue with software where I can only see my desktop. OpenGL is the only one that works at the capped 72 FPS in game but I get the menu bug. I can use all three renderers in windowed mode and get the menu to come up, but not in fullscreen. I couldn't find anyone else with this issue online, and I can't play the version of the game that I'm currently using (1.0.1.6) with Xash. I also tried completely updating the game and this issue still occurred.

For what it's worth, Half-Life's menu being busted is normal behavior even on Win9x machines with proper era-appropriate hardware. Valve couldn't code a stable frontend for a long time. It'd corrupt itself a lot trying to maintain a buffer for 640x480x16.

There's registry keys about the menu in
\HKEY_CURRENT_USER\Software\Valve\Half-Life\Settings

Setting LauncherBPP 32 would probably do nothing though

leileilol wrote on 2020-02-10, 03:19:

For what it's worth, Half-Life's menu being busted is normal behavior even on Win9x machines with proper era-appropriate hardwar […]
Show full quote

For what it's worth, Half-Life's menu being busted is normal behavior even on Win9x machines with proper era-appropriate hardware. Valve couldn't code a stable frontend for a long time. It'd corrupt itself a lot trying to maintain a buffer for 640x480x16.

There's registry keys about the menu in
\HKEY_CURRENT_USER\Software\Valve\Half-Life\Settings

Setting LauncherBPP 32 would probably do nothing though

Do you know any settings there that would fix the menu?

It probably can't be fixed without modifying the code dealing with menus and transitions between game and menu windows. The menus are contained in separate GDI rendered windows (each submenu actually shows new window above the previous one) with some DirectDraw bits slapped in between.

You're not the only one noticing this behavior on Windows 10. The menu window is actually active when you press ESC, just obscured. Interestingly, it still works as intended on Windows 8.1.

I noticed with standalone Blue-Shift (could be the same for Half-Life 1.0.1.6, only have 1.1.1.0 for reference ATM), transitions magically start working properly if you change accent color in Settings app->Personalization->Color, but only if the checkbox Title bars and window borders is checked and you have already loaded the saved game or started the new one, just so the graphics stuff is initialized.

This is all in OpenGL mode. Can't see the menus in Direct3D after pause, unless I Win + Shift + Right arrow the window to the 2nd screen.

Blue-Shift also changes cursor shape a bit and for some reason, mouse movement while in main menu is really choppy. I don't remember this on older Windows 10 builds, though I don't exclude the possibility that there's something odd about my particular installation (or that it did happen, but forgot about it...).

Color depth setting shouldn't make difference on modern Windows in terms of transitions. From what I can tell, Windows exposes 16-bit color depth the fist time application or game is launched and pretends it's available on subsequent launches as well if app tried such color depth setting, otherwise it's unavailable on subsequent launches and API calls made on behalf of the app to change screen color depth to unsupported values fail.

If you use that patch, adding -32bpp parameter to the game's shortcut target field will also affect menu screens, which were hardcoded to always switch the screen to 16-bit color depth. Either way, since Windows 8, everything is always handled in 32-bit mode.

Half-Life's registry settings for menu resolution and color depth indeed don't do anything.

The observations I described were made on system running Windows 10 Build 18363.476. I mostly use Win key to make the menu appear normally.

UCyborg wrote on 2020-02-10, 21:57:

It probably can't be fixed without modifying the code dealing with menus and transitions between game and menu windows. The menus are contained in separate GDI rendered windows (each submenu actually shows new window above the previous one) with some DirectDraw bits slapped in between.

Well, damn 🙁

Despite WON version being weird with how it's put together, this strikes me as a bug in Windows 10. The game does call a function to hide the gameplay window and it's like Windows doesn't handle it entirely since it's still glued to the screen, and the fact that it's in full screen mode doesn't help.

Also, mouse wheel doesn't work on my end with Direct3D renderer in full screen, but works in windowed mode.

Who knows, maybe it'll start working again in the future Windows version.

MS was working on some tricks (fullscreen optimizations), at least when it comes to games using newer Direct3D runtime (9+ think). They don't mention OpenGL and there doesn't seem to be anything different with OpenGL games. I wonder if it would help in this case if it worked.

Just tested on Windows 7 on my desktop PC and the same thing, even with desktop composition disabled. So it's not something that changed in Windows in the recent years I suppose.

That other Windows 8.1 system where it worked has an AMD card, though now on Win10 (and different drivers) there is the same problem.

On VMware virtual machines, there was no issue with transition to menu on neither Windows 7 and 8.1. Don't have a Windows 10 virtual machine, but I'm not sure the result would say much anyway.

Last time I tried Xash3D it had an annoying audio stutter in loading screens and UI elements were flickering (I think it's because of a Nvidia bug that also seems to affect Cave Story+). It has had plenty of updates since then, but I think it was like half a year ago and left the impression that using Xash3D just wasn't a very polished experience.

That was after trying and failing getting the original Half-Life getting working decently on a modern computer (because of the menu issue). Well I got it working, it was just messy.

I think I'll just play the Steam version next time, pity it forces you to choose between music or subtitles (mod) and supposedly has some other issues as well. What are the remaining issues with the Steam version anyway?

ZellSF wrote on 2020-02-14, 08:31:

Last time I tried Xash3D it had an annoying audio stutter in loading screens and UI elements were flickering (I think it's because of a Nvidia bug that also seems to affect Cave Story+). It has had plenty of updates since then, but I think it was like half a year ago and left the impression that using Xash3D just wasn't a very polished experience.

That was after trying and failing getting the original Half-Life getting working decently on a modern computer (because of the menu issue). Well I got it working, it was just messy.

I think I'll just play the Steam version next time, pity it forces you to choose between music or subtitles (mod) and supposedly has some other issues as well. What are the remaining issues with the Steam version anyway?

Well, the menu issue isn’t a huge issue because all it does is require me to press Alt+Tab, but it’d be preferable to not have to do that, obviously. Otherwise, the game works great.

xash3d's that illegal source port that unfortunately gets smartypantsed around as blind 'this update fixes hl' advice...

leileilol wrote on 2020-02-15, 01:47:

xash3d's that illegal source port that unfortunately gets smartypantsed around as blind 'this update fixes hl' advice...

Yeah, I read about that and that's one of the reasons I'm not using it. It also doesn't support my version anyways.

Valve never fixed unstable physics, did they? Surprisingly, they supposedly fixed the NPC turn rate bug 2 decades after original release.

The thing when scientists just explode in the elevator in Blue-Shift is still hilarious. Illegal engine fixes that AFAIK, but I wonder if the bad Russians fixed other basic behaviors yet that the original gets right.

So maybe 60 FPS cap instead of default 72 FPS is better to workaround glitchy physics?

UCyborg wrote on 2020-02-16, 09:37:

Valve never fixed unstable physics, did they? Surprisingly, they supposedly fixed the NPC turn rate bug 2 decades after original release.

The thing when scientists just explode in the elevator in Blue-Shift is still hilarious. Illegal engine fixes that AFAIK, but I wonder if the bad Russians fixed other basic behaviors yet that the original gets right.

So maybe 60 FPS cap instead of default 72 FPS is better to workaround glitchy physics?

I never noticed that mentioned issue in Blue Shift nor any other physics issues (minus boxes being crazy fast when being pushed with use, think that's just how it works though) at 72 FPS.

Physics got wonkier with later patches to the engine, Blue-Shift elevator glitch doesn't occur in the original release of the game.

It happens if you use Blue-Shift: Unlocked, the installer that takes your old Blue-Shift installation and coverts it to a mod for Half-Life version 1.1.1.0 and later. Same with the official Steam version.

Though changing the FPS limit can also prevent scientists/player from getting hurt, or simply standing at the different spot inside the elevator. While the NPC twitching a lot while the elevator is moving seems like a consistent occurrence, them being killed isn't, even with the same settings. It may differ across different computer configurations, I guess there are small timing differences or something like that. On my machine, I can't reproduce it when running Windows 10, but it happens when running Windows 7 or XP.

MrEWhite wrote on 2020-02-15, 16:59:

leileilol wrote on 2020-02-15, 01:47:

xash3d's that illegal source port that unfortunately gets smartypantsed around as blind 'this update fixes hl' advice...

Yeah, I read about that and that's one of the reasons I'm not using it. It also doesn't support my version anyways.

That it's illegal? I think I've heard there's some other controversy surrounding Xash3D, but on a forum where a lot of players probably rely on no-cd cracks to make their games work still, being illegal by itself doesn't strike me as something negative.