EPTWithout it, and setting mouse speed to 30% above normal in Windows, almost allows micro in Window mode. Almost.
[H] Windows 7 still freezes BW - Page 8
| Forum Index > Tech Support |
|
Metaspace
Austria670 Posts
Without it, and setting mouse speed to 30% above normal in Windows, almost allows micro in Window mode. Almost. | ||
|
Metaspace
Austria670 Posts
| ||
2Pacalypse-
Croatia9530 Posts
To summarize the current situation we're in with freezing problem: - All suggested solutions in this and various other threads that supposedly fixes the freezing issues are simply false. - Suggested solutions like end tasking explorer, changing affinity settings, process prioritizing etc., are as stated above, false. Some of these solutions does fix the color problem, which some people, strangely enough, find more important than freezing problem. Also, a lot of people seem to think that because simply they didn't have any crash/freeze, that they are unaffected with this issue. This is also false, which I can't really support with hard facts because I have no real idea in what environment and circumstances these freezes happen. I can just state my own personal experience, where when I installed Windows 7, I didn't have a single crash for like a month and half and then suddenly game started crashing every 10-20 minutes (I didn't change anything important on my computer to cause this). - User Squall_Leonhart69r from this site reported that the real problem lies within DirectDraw emulation under Windows 7, something that's not simply fixed by end tasking explorer.exe - The step to the REAL solution came with a DirectDraw hack, made by some finish fella, who funnily enough didn't even make this fix with BW in mind. Thread about DirectDraw hack: http://www.teamliquid.net/forum/viewmessage.php?topic_id=151063 - After some testing, it became public that DirectDraw hack indeed works well with BW, with some minor modifications. Squall_Leonhart69r again reported that DDhack works fine with Starcraft as long as you set Vertical synch (vsync) to Force off in Video card control panel. Also, you must add altwinpos option in config.ini file of DDhack. - Supposedly (I haven't tested it), DDhack with these modifications works like a charm. And now comes a but. But, apparently this DDhack doesn't emulate DirectDraw enough to pass the Battle.net checks, thus making it unavailable to play with it on official Battle.net servers. - Good side of this, is that you can play normally on private servers, ie. iCCup. After that summary, I have few questions if someone wishes/knows to answer them. 1. How big of a task would be to "complete" DDhack so that it does emulate DirectDraw enough to pass Battle.net checks, thus making it available to use at official servers as well? 2. If someone DO make the complete fix, would it be possible to make it as some kind of Chaoslauncher plugin so computer illiterate people doesn't have to change their Video card settings and changing config.ini file? 3. Will anyone rise to the challenge? -.- Come'n, I'm sure BW community is still strong community to make this a worthwhile project. If we had this problem few years ago, I'm sure there would be dozens of people working on this and FIX would be featured in no time etc... | ||
|
2Pacalypse-
Croatia9530 Posts
| ||
|
Metaspace
Austria670 Posts
On October 22 2010 01:12 2Pacalypse- wrote: - After some testing, it became public that DirectDraw hack indeed works well with BW, with some minor modifications. Squall_Leonhart69r again reported that DDhack works fine with Starcraft as long as you set Vertical synch (vsync) to Force off in Video card control panel. Also, you must add altwinpos option in config.ini file of DDhack. Correction: At least for my machine, you either use the "altwinpos" option in the DDHack config, or you force vsync off. The former does not allow me to attempt to connect to Bnet or ICCup etc., but the latter does (SCBW switches to another resolution for the connect window, I assume, which is messed up ba altwinpos on my machine). | ||
|
Metaspace
Austria670 Posts
Assumption: SCBW calculates a checksum over it's loaded code (including loaded DLLs), then transmits this to the server upon connect - the server then checks this number, and disconnects you if not correct. If my hypothesis is right, one would either have to know how the checksum (or whatever) is calculated, and get DDHack to behave identical in context of this check (might not be possible as it has different code), or hack SCBW to always send the code Bnet expects. The latter method is surely easier, requires a packet sniffer, transmission anaylsis, and finally a plugin which hijacks data sending during connect. My best bet is that people like the ChaosLauncher devs might have the skills to do so! | ||
|
zingmars
Latvia189 Posts
Have you guys tried using the registry fix instead of taskilling explorer.exe every time you play SC? Just curious. + Show Spoiler + Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw\Compatibility\Starcraft116] "Flags"=hex:00,08,00,00 "Name"="Starcraft.exe" "ID"=hex:ca,89,65,49 What you're supposed to do is to save this (The part inside the spoiler part) as a *.reg file, then launch it, click yes and it should save this info in registry (you can do it manually too). I've gotten 2 PCs with Windows 7 (with Aero and such) to run Starcraft: BW without any problem at all (not even weird colors. well unless you alt+tabbed a few times. Then it will display weird colors, just as it used to do with Windows XP), and I didn't need to use these lame kill explorer.exe *.bat files. Lemme know if this worked for ya. EDIT: On October 22 2010 17:19 Metaspace wrote: I wonder how SCBW checks it's own integrity when connecting to Bnet; interestingly enough, this does not happen when connecting to ICCup. Assumption: SCBW calculates a checksum over it's loaded code (including loaded DLLs), then transmits this to the server upon connect - the server then checks this number, and disconnects you if not correct. If my hypothesis is right, one would either have to know how the checksum (or whatever) is calculated, and get DDHack to behave identical in context of this check (might not be possible as it has different code), or hack SCBW to always send the code Bnet expects. The latter method is surely easier, requires a packet sniffer, transmission anaylsis, and finally a plugin which hijacks data sending during connect. My best bet is that people like the ChaosLauncher devs might have the skills to do so! I think it's actually Warden (SC's Anti-Cheat). It checks for the dlls loaded, and if it finds something unpleasant it just doesn't let you connect. As for Iccup - Iccup is a private server, and it just doesn't know how to handle Wardens calls, so it drops these packets therefore ignoring Warden, and since Warden doesn't receive any response it just assumes that it's okay to connect, and connects. Basically my idea is similar to yours, but instead of server-side checksum check, my version does it client side. I too might be wrong tho, and it might be something else. | ||
|
Metaspace
Austria670 Posts
I use it. It has no influence on the crash problem. Aha, Warden. Any way to patch this thing? | ||
|
zingmars
Latvia189 Posts
There is another way - playing SC through Virtual machine with Windows XP installed xD | ||
|
Metaspace
Austria670 Posts
The other disadvantage is you need to maintain/admin a second (virtual) machine, with all it's windows updates, software, internet security suite and the lot :-( | ||
|
Metaspace
Austria670 Posts
Very often within the game, my mouse will become trapped at the top edge of the screen, where I can move it right/left, but not downwards anymore. Using alt+tab to switch to the desktop and back alleviates this, but you can imagine that this does not really help my micro. Any experience with this? | ||
|
vek
Australia936 Posts
On November 02 2010 17:07 Metaspace wrote: Update: SCBW will not run (using DDHack.dll) on ICCup for me (I cannot connect to battle.net at all this way, see above). Very often within the game, my mouse will become trapped at the top edge of the screen, where I can move it right/left, but not downwards anymore. Using alt+tab to switch to the desktop and back alleviates this, but you can imagine that this does not really help my micro. Any experience with this? Have you changed to contents of your ddhack.cfg to only contain "altwinpos"? Doing this solved the problems you mentioned for me. | ||
|
Joefish
Germany314 Posts
(have a déjà vu... think that I already posted my solution in this thread... whatever.) I'd recommend you playing in window mode. That solved all my problems + the psychodelic color bug. If the size is too small for you then just double it (1280*960). That's the easiest and most comfortable solution in my opinion. | ||
|
Metaspace
Austria670 Posts
On November 02 2010 18:34 vek wrote: Have you changed to contents of your ddhack.cfg to only contain "altwinpos"? Doing this solved the problems you mentioned for me. (As posted somewhere above) This does not work for me, as if I use the "altwinpos" switch instead of forcing vsync off for SCBW, I will not be able to connect to a server. SCBW then leaves full screen mode, I am on the desktop with 640x480, have a SCBW ICCup Bnet window with a quarter of the screen size (i.e., not the whole window contents visible, just the top left part) and cannot log in. | ||
|
squall leonhart
Australia44 Posts
On October 22 2010 17:10 Metaspace wrote: Correction: At least for my machine, you either use the "altwinpos" option in the DDHack config, or you force vsync off. The former does not allow me to attempt to connect to Bnet or ICCup etc., but the latter does (SCBW switches to another resolution for the connect window, I assume, which is messed up ba altwinpos on my machine). Your mistaking the issues. Vsync off prevents the mouse stuttering, which was a side effect of the frames polling higher then the refresh rate. altwinpos prevents the mouse from being locked to the top of the screen from start, a alt+tab fixes this for some, but for others it does not. This has the side effect of causing certain backgrounds to be black and especially the battlenet text and buttons. As for its effects on servers, most BNE's allow you to connect and login fine, if anything iccup is doing more checks then others and failing due to the load order of the dll's? The freeze is most definitely an issue with DirectDraw on Windows 7, though for what reason im still trying to find out, the person i was working on this with got bored and so did i for awhile there (just wanted to play some games). The strange thing is, while the freeze occurs in most DirectDraw only titles as a full system lock, titles which support DirectDraw and Direct3D7 (MS Starlancer), only occurs as a application lockup and can be end tasked, though task manager can only be raised from the ctrl+alt+delete task screen. I also reproduced a full application hang right from start in Eduke32 in classic renderer, which happens to use DirectDraw, which was unlike both the Starcraft, and starlancer issue, and again found that Age of Empires 2 will not freeze at all once you get into a game. | ||
|
squall leonhart
Australia44 Posts
http://support.microsoft.com/kb/980731 | ||
|
2Pacalypse-
Croatia9530 Posts
On November 16 2010 20:56 squall leonhart wrote: I came across this, this is something i have not spotted nor tried before http://support.microsoft.com/kb/980731 Oh, that looks promising. Anyone tested it yet? | ||
|
squall leonhart
Australia44 Posts
| ||
|
Metaspace
Austria670 Posts
On November 16 2010 01:06 squall leonhart wrote: Your mistaking the issues. Vsync off prevents the mouse stuttering, which was a side effect of the frames polling higher then the refresh rate. altwinpos prevents the mouse from being locked to the top of the screen from start, a alt+tab fixes this for some, but for others it does not. This has the side effect of causing certain backgrounds to be black and especially the battlenet text and buttons. As for its effects on servers, most BNE's allow you to connect and login fine, if anything iccup is doing more checks then others and failing due to the load order of the dll's? The freeze is most definitely an issue with DirectDraw on Windows 7, though for what reason im still trying to find out, the person i was working on this with got bored and so did i for awhile there (just wanted to play some games). The strange thing is, while the freeze occurs in most DirectDraw only titles as a full system lock, titles which support DirectDraw and Direct3D7 (MS Starlancer), only occurs as a application lockup and can be end tasked, though task manager can only be raised from the ctrl+alt+delete task screen. I also reproduced a full application hang right from start in Eduke32 in classic renderer, which happens to use DirectDraw, which was unlike both the Starcraft, and starlancer issue, and again found that Age of Empires 2 will not freeze at all once you get into a game. Thank you for pointing this out. The thing is, with "altwinpos", I am not able to see the Bnet (or ICCup) connect screen (SCBW transforms itself into a desktop window, only partly visible, desktop at 640x320, I cannot click buttons or see login edit fields). If I do not use altwinpos, I get a black screen, if I remember correctly. Setting vsync=off alleviated that. On November 16 2010 20:56 squall leonhart wrote: I came across this, this is something i have not spotted nor tried before http://support.microsoft.com/kb/980731 Will try that tomorrow! Thanks for all your work BTW. Highly appreciated. | ||
|
squall leonhart
Australia44 Posts
i was able to start and play Escape from Aiur 3-5 times however i then opened msn and firefox and the following startin SC froze. in this case, i think it might be a GDI+Directdraw deadlock in the WDDM driver, that the XDDM hotfix does not address. I also tried running SC without Audiodg running and starcraft froze almost immediately, so i can rule audio drivers out. | ||
| ||
