| Forum Index > BW General |
|
LG)Sabbath
Argentina3022 Posts
We’re standing up the PTR again and asking for your help to test some big changes coming down the pipe. Here’s the TLDR: we’re changing how graphics work in SCR. Please test on the PTR to make sure your video card doesn’t run into any problems. https://us.forums.blizzard.com/en/starcraft/t/return-of-the-ptr/1434 | ||
|
onlystar
United States971 Posts
guys please sign up i dont want another debacle where the launcher just freezes every time and game freeze or crash like we had in the past with that google chrome like blizzard app launcher patch that Fd everyone over | ||
|
KameZerg
Sweden1762 Posts
| ||
|
outscar
2832 Posts
| ||
|
castleeMg
Canada760 Posts
https://imgur.com/a/4QmzwqW https://imgur.com/a/CMbf0aX | ||
|
blabber
United States4448 Posts
| ||
|
tec27
United States3696 Posts
On May 16 2020 04:50 outscar wrote: Lol, we've been waiting for months with no answer, and they make it look like they're going to make massive changes, but instead it's just them trying to make sure game supports some browser shit (probably has to do with in-game login/password screen). And they're pushing it because deadline is over because of their incomptency and now they're obliged and forced to do it. Blah blah blah. Don't care. If you break it fully we're all going back to 1.16.1. CEF is used for the majority of UIs in the game (all the menu stuff, bnet, and also for the ingame observer UI). It's an embedded version of Chrome, so it is indeed pretty bad for them to be shipping significantly outdated versions of it, given how many potential known security vulnerabilities it can contain. The fact that it's taken them this long to fix the "CEF spawns 5+ memory-hungry processes for every single piece of UI on the screen" problem is pretty perplexing though. What is even more perplexing is that they've seemingly spent the last few months writing a brand new rendering backend for Windows users (who was asking for that or even complaining about performance outside of the CEF bug and other things that have nothing to do with the rendering technology?), and even more perplexing is that they wrote one for macOS too. They probably spent more hours working on that than they have mac users. On May 16 2020 05:00 blabber wrote: from the message it seems like they need to do it for compliance reasons. I'm guessing the older technologies are no longer supported. hopefully we can do our part and help test the changes and make sure it works so it goes smoothly. The "compliance reasons" part is specifically about CEF (the thing they had to roll back before), it does not apply to the new rendering stack. I don't know why they combined those two pieces so closely (or maybe the community person just didn't understand what the devs told them). | ||
|
TelecoM
United States10669 Posts
| ||
|
tec27
United States3696 Posts
On May 16 2020 08:09 GGzerG wrote: I noticed this yesterday as well and they had some patch but it didn't display any notes. I am hoping this fixes the FPS drops at certain points in games and that is why they mentioned the Graphics cards. Notes for yesterday's patch are here: https://us.forums.blizzard.com/en/starcraft/t/maintenance-patch-notes-may-12th-2020/1427/19 | ||
|
srj
Canada134 Posts
On May 16 2020 05:14 tec27 wrote: CEF is used for the majority of UIs in the game (all the menu stuff, bnet, and also for the ingame observer UI). It's an embedded version of Chrome, so it is indeed pretty bad for them to be shipping significantly outdated versions of it, given how many potential known security vulnerabilities it can contain. The fact that it's taken them this long to fix the "CEF spawns 5+ memory-hungry processes for every single piece of UI on the screen" problem is pretty perplexing though. What is even more perplexing is that they've seemingly spent the last few months writing a brand new rendering backend for Windows users (who was asking for that or even complaining about performance outside of the CEF bug and other things that have nothing to do with the rendering technology?), and even more perplexing is that they wrote one for macOS too. They probably spent more hours working on that than they have mac users. The "compliance reasons" part is specifically about CEF (the thing they had to roll back before), it does not apply to the new rendering stack. I don't know why they combined those two pieces so closely (or maybe the community person just didn't understand what the devs told them). The macOS one makes sense. DirectX isn't available there and OpenGL is being deprecated. They needed to rewrite the backend in Metal. | ||
|
Lorch
Germany3679 Posts
As for the render backend: Why not go for vulkan if you're gonna rewrite it in metal anyway? Available on any OS so you can throw directX out of the window as well. Either way I'd rather have them invest their time into fixing bugs + improving their anti-cheat tbh. Or hell atleast bring OG graphics up to par with a 1.16 client. Though I guess if you are shipping with an outdated version and using a depreciated API like openGL, you really have no choice. | ||
|
tec27
United States3696 Posts
On May 16 2020 10:27 Lorch wrote: I wish they would rewrite the UI and do it in-engine like people used to. I have played many games with these HTML/Chrome menus and it's always laggy and awful. As for the render backend: Why not go for vulkan if you're gonna rewrite it in metal anyway? Available on any OS so you can throw directX out of the window as well. Either way I'd rather have them invest their time into fixing bugs + improving their anti-cheat tbh. Or hell atleast bring OG graphics up to par with a 1.16 client. Though I guess if you are shipping with an outdated version and using a depreciated API like openGL, you really have no choice. I very much imagine that all of the cards that need the DX9 renderer currently also don't support Vulkan (or have showstopping bugs with it). I don't get how moving to DX11/DX12 really removes the need for a DX9 renderer though, given that there are a number of cards they claim to support that are DX10.1 or below. Perhaps they're just stealthily trying to cut support for those cards again and going to see how many people complain? As far as the original graphics go, they mostly look terrible at this point because they decided to compress all of them like they did with HD graphics. The savings for SD-sized sprites end up being quite minimal (especially compared to how much memory they use up through other bad decisions), but the loss in fidelity is quite immense. Fortunately they still ship the original sprites in the game data (likely because SCMDraft doesn't support the compressed versions), so someone could feasibly write a renderer that used them and actually looked decent given enough time. I definitely don't think there's any reason a browser-based UI *has* to be non-performant, and a number of games do it well. SCR's, however, has a lot of really questionable decisions. Every little piece of their UI is loaded up in an isolated frame, every page has a separate HTML file (that all follow the exact same, very simple template), every piece has its own isolated javascript file that has been compiled for very, very old browsers and thus includes a ton of code to implement stuff the game's browser obviously supports. Every javascript file bundles all of its own dependencies (the vast majority of which are common between every piece, but have to be parsed and executed without any shared caching because of this setup). The pieces communicate between each other and the game using a WebSocket, but the protocol used is often incredibly chatty and wasteful. For instance, the Observer UI sends an update for every mineral count change containing the player's name and all of their resource state (that is, if a player spends 50 minerals from 100 minerals, an update is sent not just for 100 minerals and then 50 minerals, but every step of the animation along the way: 100 -> 97 -> 94 -> 91 -> ... -> 50). Each of those state updates then re-renders the entire UI, and mostly happens far faster than the game can actually render a frame in general. Yeah, you can get away with these kind of things when all the communication is happening locally, but god that has to be eating up so many resources and making things perform so much worse. But instead of fixing this kind of low hanging fruit, they're rewriting the whole rendering backend? Truly baffling. | ||
|
TelecoM
United States10669 Posts
| ||
HaN-
France1919 Posts
we’re changing how graphics work in SCR. Do you think it can mean improvement for SD graphics? | ||
|
fazek42
Hungary438 Posts
| ||
|
Bakuryu
Germany1065 Posts
| ||
|
fazek42
Hungary438 Posts
| ||
|
LG)Sabbath
Argentina3022 Posts
| ||
|
TelecoM
United States10669 Posts
On May 17 2020 09:32 LG)Sabbath wrote: I've just spent a full 5 minutes opening/closing my match list to try to get it to pop up, so it's really impressive that they only now found out about UI issues, and tbh I would also just scrap the entire thing and do it over given how bad it's working, hopefully the next iteration won't be as bad, but right now it works pretty much like beta software How could they just find out about it ? Do they not play the game? lol >_< | ||
|
dM-White
Chile340 Posts
On May 16 2020 21:49 Bakuryu wrote: can we just get tec27 to get hired by blizzard to work on SCR? this would be a win-win situation for everybody. THIS ^, the guy seems to know a lot hahahaha | ||
| ||
StarCraft 2 StarCraft: Brood War Dota 2 League of Legends Counter-Strike Super Smash Bros Other Games |
|
Sparkling Tuna Cup
WardiTV European League
MaNa vs sebesdes
Mixu vs Fjant
ByuN vs HeRoMaRinE
ShoWTimE vs goblin
Gerald vs Babymarine
Krystianer vs YoungYakov
PiGosaur Monday
The PondCast
WardiTV European League
Jumy vs NightPhoenix
Percival vs Nicoract
ArT vs HiGhDrA
MaxPax vs Harstem
Scarlett vs Shameless
SKillous vs uThermal
uThermal 2v2 Circuit
Replay Cast
RSL Revival
ByuN vs SHIN
Clem vs Reynor
Replay Cast
RSL Revival
Classic vs Cure
[ Show More ] |
|
|
EPT
