You're saying the "-no_texture_stream" launch option affected performance for you by over 25%?
Account Details | |
---|---|
SteamID64 | 76561198374045865 |
SteamID3 | [U:1:413780137] |
SteamID32 | STEAM_0:1:206890068 |
Country | Pirate |
Signed Up | March 20, 2020 |
Last Posted | April 28, 2024 at 8:10 PM |
Posts | 302 (0.2 per day) |
Game Settings | |
---|---|
In-game Sensitivity | 5.2 |
Windows Sensitivity | no |
Raw Input | yes |
DPI |
no |
Resolution |
1024 768 |
Refresh Rate |
120 |
Hardware Peripherals | |
---|---|
Mouse | no |
Keyboard | yes |
Mousepad | no |
Headphones | no |
Monitor | yes |
Next time it happens, try to get a screenshot/recording of net_graph 4, whether or not it's a network issue should be readily apparent from that.
It's hard to imagine it being a network issue when chat still works while you're frozen, voice chat still works while you're frozen, and you can connect to other servers fine. It's possible that large packets aren't making it somewhere along the way due to MTU issues or similar, but that point is definitely not at your wireless card.
NeoTenicwe've narrowed it down to likely having something to do with the wireless card
Nope, certainly not that.
It's most likely an issue with the server you're playing on (perhaps caused by plugins), unless you experience it on all servers.
Of course. I'm really not sure what changed. If you have a specific demo file that should work, send it and I can try playing it back.
BoistopmotionTo clarify, Pre 07-25-23 demos are working for you now?
Seemingly so, the only things I would have changed was I tried killing steam after starting tf2 to see if demos would play then (they didn't, it crashed), and I also tried replacing steam_api.dll and steamnetworkingsockets.dll in the old version with the versions from the latest release of tf2.
I reverted everything I did, yet somehow demos play back fine now without crashing tf2. The demos I tested were the mastercomfig benchmark_test.dem and benchmark1.dem from the tftv benchmarks thread, as I knew both of those are supposed to be able to play in this version of tf2.
You're right, same for me, yet another crash when trying to actually start playing a demo. Probably also Steam related, no clue how to get around it though.
Edit: demos started to play back fine for me now, I don't know what changed
It seems to work still, but as before you continue to need Steam in offline mode. Steam in online mode -> crashes.
Steam not running at all -> crashes.
BvPS: If someone can tell me what the mac executable got renamed to that'd be great! (Currently figuring out the linux one)
Mac executable has been presently removed, it's likely done.
"DefaultFixedOutline" font in resource/sourcescheme.res
Quikgame doesn't start with -dxlevel 80 / -dxlevel 81 and forces itself to dxlevel 9
RIP
never liked how the rockets feel at dx9
tobiasif anyone knows how to make dx8 work after this update pls lmk
shaysukieAny workaround to make dxlevel 81 work?
dxlevel 81 works fine but I guess it looks like the launch option is messed up, you can change dxlevel by navigating to HKCU\Software\Valve\Source\tf\Settings in regedit and simply setting DXLevel_V1 to your preference.
jp_Does anyone else get a black screen with the launch option -vulkan?
the dxvk garbage only works on dxlevel 90 / 95 / 100, black screen on 80 or 81. honestly wouldn't recommend using dxvk on windows anyways.
GrapeJuiceIIIlooooool of course this update comes out the day im making an RJWeekly video and need both these programs looooool im so happy
You should be able to download the old version (manifest ids can be found here) using depotdownloader / steamcmd / steam console.
I'm sure you've already tried restarting steam (fully exit and relaunch, or reboot your pc) but in case not, that's certainly something worth trying
Well it's hard to say anything too definitive without knowing more about your setup but usually to display the output of an egpu on the internal screen of a laptop you have to copy the framebuffer back off of the egpu over whatever interface it's connected via (ExpressCard in your case, which isn't really that fast, basically a single PCIe 2.0 lane at best) and onto the gpu attached to the internal display so it can be displayed there. There's overhead in doing that, in multiple stages of the process, and also when using a slow interface like ExpressCard it could cut significantly into the PCIe bandwidth that you would otherwise be using for everything else the gpu has to do, lowering performance in your game.
It's hard to imagine that the limit for how fast you could copy the framebuffer would be as low as 60-ish fps for normal resolutions on any somewhat recent (past decade or so) hardware, so maybe it's worth going through the display settings for the gpu to which the laptop screen is connected and making sure there's no vsync forced in there or something, but ExpressCard bandwidth is very low so it's possible you're just really running into that limit.
The best test you could do would be to just try a monitor plugged directly into the egpu if at all possible and to check whether the issue is still occuring or whether it's remedied by doing that. You could also try a very small resolution like 640x480 with your current setup and see if that has any effect, as it would require much less bandwidth to copy than a larger resolution.