|
On December 16 2008 23:01 tec27 wrote:I'm pretty sure whoever programmed that part of the patch jsut rolled some dice to pick the sleeping time. That's how all the good programmers do it, anyhow  Also, the reason its probably taking so long for 1.16.1 is that they are actually putting it through its QA paces this time, unlike last time Can't release two crappy patches in a row (or can they?)
Heh, well, Blizzard has never ceased to amaze me, so What do you know ;D:
|
well, obviously this was not tested in QA before pushing it live. At least this is just a game, same thing happened in the place I work, Production went down for half a day...do you know how much money is that? lol
|
I can't believe how straightforward this is. And like someone mentioned earlier in the thread, it seems exactly like something I would do as well, having zero experience in real time programming.
I'll bet a 1 ms delay never occurred to him/her, either.
Thought process:
"Huh. CPU overloaded. What happens if I introduce a 5 ms delay here?"
"Nice! It worked! I told my boss it'd take a week, so I think I'll get paid to play the D3 beta for a while."
|
so wait i dont understand. why did the devs put a random 10 msecond delay loop in the middle of their code? was that their solution to removing the 100% cpu usage? so if i understand correctly, their code is less efficient than CPU Savior which only adds 1 msecond delay?
|
On December 17 2008 02:14 Disastorm wrote:
so wait i dont understand. why did the devs put a random 10 msecond delay loop in the middle of their code? was that their solution to removing the 100% cpu usage? so if i understand correctly, their code is less efficient than CPU Savior which only adds 1 msecond delay?
I don't know any specifics, but my guess is that stuff is ten times as responsive if the sleep lasts only 1ms instead of 10ms. No sleeping at all results in busy waiting and thus 100% load.
|
Germany2896 Posts
Things are not that simple. The delay passed to sleep is a minimum delay. The function only returns at the next tick after the minimum delay has elapsed. On my comp the tick occurs every 16ms, on older comps/OS that interval can be up to 55ms.
The tick interval can be changed by a program at global level, affecting the whole system. Afaik CPU-Savior does that.
The mistakes blizzard made are not that noobish as some of you thought. The early CPU-Savior versions had similar problems. And the ingame lag does not occur on every comp (or atleast some people like me don't notice it).
The main problem is that it passed QA(or was not send to QA at all).
The /r bug is a real wtf on the other hand.
|
noobish or not
rich/you and not blizzard programmers fixed many of problems like this.
maybe you and him could be hired too,bet u would be successful breaking sc2 engine
|
R1CH BRINGING DOWN THE PAIN
|
wow rich i hope i'll be as good programmer as you someday :D
|
I understand how this could happen when CPU savior did the same thing. I even understand not having a ton of testing go into these patches since SC is really old and frankly for it to be updated at all anymore is surprising. What I don't like is that this patch has been out for how long now? There was feedback about how awful 1.16 runs on some peoples computers hours after the patch was released. There's even detailed explanations why from people like r1ch, so why has there not been a followup patch yet to fix this?
|
|
|
R1CH can see the matrix code... He Is The One!
|
lol I love ur language R1ch! It actually makes sense to me....but even if i tried i would never be able to apply it :D Still all very reasonable though and its easy to follow on.
|
R1ch, single handedly bitch slapping the man with each failed if statement
|
Bill307
Canada9103 Posts
On December 17 2008 02:52 MasterOfChaos wrote:
Things are not that simple. The delay passed to sleep is a minimum delay. The function only returns at the next tick after the minimum delay has elapsed. On my comp the tick occurs every 16ms, on older comps/OS that interval can be up to 55ms.
The tick interval can be changed by a program at global level, affecting the whole system. Afaik CPU-Savior does that.
The mistakes blizzard made are not that noobish as some of you thought. The early CPU-Savior versions had similar problems. And the ingame lag does not occur on every comp (or atleast some people like me don't notice it).
The main problem is that it passed QA(or was not send to QA at all).
The /r bug is a real wtf on the other hand.
The other main problem with this bug is that the programmer did not contact the developers of CPU-Savior to ask them how they implemented it and what kinds of problems they ran into during testing.
Whether this was the fault of the programmer for being ignorant or naive, or the fault of a ridiculous non-disclosure agreement that prohibited him from asking such a harmless question, we'll never know.
As for the /r bug, QA definitely deserves major blame for that one regardless of how WTF-ish the implementation was. Honestly, whoever was responsible for testing that feature is a mediocre tester at best, definitely not the kind of guy you'd expect to be working for Blizzard. A message like ".r test" should have been an obvious test case and it takes about 2 seconds to verify it.
|
On December 16 2008 20:06 freelander wrote:thx for the explanation. this is my 3rd semester studying c++, i am making (lame) games with SDL, so i am interested in this stuff where is the good places in the game loop to put delays. i have learnt some microcontroller programming meanwhile so I can understand some part of the assembly  i will check out this ollydbg stuff, I haven't heard about it yet but sounds great
if you're focused on making games, Assembly probably isn't THAT relevant to what you want to do. Assembly is probalby only helpful if you plan on making anti-hacks or something of that sort.
|
Awesome discovery, I been wondering why these problems were occuring however I have to agree with
On December 16 2008 19:23 Plexa wrote:
First step in making SC obsolete in preparation for SC2
i believe this is true :/
|
well if iccup adds that 3v3 ladder then screw bnet, don't need it for anything anymore
|
Yea, they really have a tester problem. I bet they don't even test it properly. Guy probably just makes the code and makes sure it works then passes it up (without checking for side effects).
They really need to consult outside programmers like MoC, Tec27(the adv loader guy, sorry i forget ur name :/), and you r1ch.
I was just discussing this with EchoOfRain on bnet yesterday. He said that they changed the ports or something too? I don't think he was right.
|
On December 17 2008 02:52 MasterOfChaos wrote:
Things are not that simple. The delay passed to sleep is a minimum delay. The function only returns at the next tick after the minimum delay has elapsed. On my comp the tick occurs every 16ms, on older comps/OS that interval can be up to 55ms.
This too was another wtf, they added sleeps without setting the timer resolution to 1ms! So every Sleep could be up to 16ms, however as my test program I posted on my previous blog showed, most people have high timer resolutions to begin with.
|
|
|
|
|
|
EPT
