"Not Responding" windows reaction to intense calculations

New releases and general discussions.

Post » Sat Jun 11, 2011 1:47 pm

Hi guys.

This one has needed solving my end for a long time, but while I was testing the core of my engine, I was prepared to put up with it.

When computing large amounts of data, whether by nested loops or other means, including generating noise via a plugin for instance, the game window becomes inaccessible, with the message "Not Responding" in the title.

Now, I know it hasn't crashed (it obviously goes back to normal when the computations are done) and that it's just Windows not being able to get any cycles from the processor because Construct is hogging them, but is there a way to avoid this?

Is there a setting in the applications properties I'm missing.

To give a clearer picture of how it's affecting me, at first, I was concentrating on the main game level, and I'd set up the splash screens and title screen to just jump straight to the main game screen (layout), which meant that when running the game, I got that "Not Responding" for a while and then the game would start.

Now I've started to tidy up the splash screens and title screen, I'm using them, and as expected, I get the "Not Responding" message as soon as I select start game from the title menu, with no sign of the game screen until all the calculations are done.

Is there any way of forcing Construct not to hog all the CPU?

It just looks unprofessional to have the game window freeze like that.

Hope you can help.

Cheers,
Krush.
B
2
S
2
G
3
Posts: 406
Reputation: 2,062

Post » Sat Jun 11, 2011 2:22 pm

i don't think it's the only game that doesn't respond while loading or generating levels.
windowed games look unprofessional to begin with, but getting rid of the caption at all would be good, also, maybe a screen that says "loading..."
or don't make it do all the calculations at once. make it pause every few seconds to respond to user input
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Jun 11, 2011 2:33 pm

Hey Krush!

I was annoyed by this as well when I was testing the Python calculation times as I got the not responding message and thought Construct was frozen.

The problem is that Construct is not responding to Windows messages while in the calculation loop. You need some type of "Windows Pump", an action that can be called in the loop to look for and handle windows messages OR to spawn off the calculations in a separate worker thread.

I think the worker thread solution would be better. Somebody would have to create a plugin that spawned off a thread that could run the calculations...not sure how hard that would be.

The Windows Pump solution would be easier to implement in a Plugin, but not as efficient. You would need to create an action "Process messages" that would have code like:

[code:2xej045l]
void DoEvents()
{
MSG msg;
long sts;
do {
if (sts = PeekMessage(&msg, (HWND) NULL, 0, 0, PM_REMOVE)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
} while (sts);
}

[/code:2xej045l]

I probably could make a plugin like this pretty easily for testing, but the thread solution is better.
B
8
S
3
G
7
Posts: 835
Reputation: 5,313

Post » Sat Jun 11, 2011 2:44 pm

Yeah, years ago if you didn't use a "DoEvents" in a VB program, it was very easy to lock up even the tamest of programs.

I'm also aware of the C++ equivalent using PeekMessage, but I was sure that Construct would have something built-in, and that I must have missed it.

@Lucid; The window frame will be hidden when the game is finished, but it's not just the message that's annoying.
Even hiding the message, it's clear that the program isn't responding (not letting Windows do anything in the background while the calculations are being done) as it loses focus and you get the spinning cursor.
And without pausing the process first, the "loading Screen" won't show up, because Windows isn't allowed to draw it.

I even locked up a Train Simulator years ago with one of my busy scripts, and people were complaining that they had to restart their computers to get out of it, lol.

I'll look into this a bit more.
Please feel free to add to your comments if you have further ideas, as I'm quite disappointed that Construct doesn't handle this for us. :(

Krush.
B
2
S
2
G
3
Posts: 406
Reputation: 2,062

Post » Sat Jun 11, 2011 4:00 pm

Construct ought to use a multithreaded runtime, but it doesn't. It's a design flaw and fixing it would require some level of refactoring. It's also a problem in the editor - saving or loading huge projects sends the editor in to "not responding" as well. It's solved in Construct 2 - the editor does heavy lifting on a separate thread, and most browsers run javascript in a separate thread too.

But why does your game need to do such an extraordinary amount of processing that the window is locked up? It seems unusual.

The "DoEvents" type function that was in VB is widely regarded as an ugly hack, but I guess that wouldn't be out of place in Classic :P

The only other solution is to break up the work over multiple ticks. For example, instead of doing a million loop iterations which takes ten seconds and goes in to "not responding" mode, break it up in to 10,000 iterations per tick over 100 ticks. Not only does this keep the app responding during the processing, but it also gives you the opportunity to update the screen with the progress. That's probably your best bet for the time being.
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,564

Post » Sat Jun 11, 2011 4:26 pm

[quote="Ashley":1l07lv5y]Not only does this keep the app responding during the processing, but it also gives you the opportunity to update the screen with the progress. That's probably your best bet for the time being.[/quote:1l07lv5y]

Yeah, this does sound like the best solution overall. It is messy handling all the different Windows messages and it wouldn't update the screen. It can be done right, but isn't as simple as what I posted....
B
8
S
3
G
7
Posts: 835
Reputation: 5,313

Post » Sat Jun 11, 2011 4:48 pm

A function would make it fairly simple, and you can add parameters to reuse loops.
Honestly though it depends on what your doing. Like if this is a process you will be doing throughout the game, or if it's just a bunch of data you can crunch at one time.
Image Image
B
161
S
48
G
90
Posts: 7,349
Reputation: 66,753

Post » Sat Jun 11, 2011 4:50 pm

Also, Python may be an alternative. The standard library, starting with v2.6, supports threading/multiprocessing:

http://docs.python.org/release/2.6.7/li ... ading.html
http://docs.python.org/release/2.6.7/li ... ssing.html
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Sat Jun 11, 2011 6:14 pm

[quote="Ashley":2yfdazwm]
The only other solution is to break up the work over multiple ticks. For example, instead of doing a million loop iterations which takes ten seconds and goes in to "not responding" mode, break it up in to 10,000 iterations per tick over 100 ticks. Not only does this keep the app responding during the processing, but it also gives you the opportunity to update the screen with the progress. That's probably your best bet for the time being.[/quote:2yfdazwm]
here's a sample implementation:
http://dl.dropbox.com/u/1013446/splitting.cap

all the cap does is move the red box around the screen 1 billion times.

press space to do it all at once. click no when it gives you the 1000000 loop iteration warning, so you have a chance to try to interact with the window, and drag the drag-n-drop blue box.

right click to see it run 10,000 at a time, you can interact with the window and the blue box as expected
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Jun 11, 2011 6:42 pm

[quote="Ashley":1i65rapg]But why does your game need to do such an extraordinary amount of processing that the window is locked up? It seems unusual.[/quote:1i65rapg]

Well, as SciDave has also pointed out when he did his speed tests in Python, this is just manipulating data in loops, which also gave him the Not Responding window.

Ok, it's a lot of data, manipulated in nested FOR loops, with data being read and written to an array, with several conditions in each loop.

There's nothing more than that.
Nothing graphical or audible.
Nothing.

[quote="Ashley":1i65rapg]The "DoEvents" type function that was in VB is widely regarded as an ugly hack, but I guess that wouldn't be out of place in Classic :P[/quote:1i65rapg]
Yes, it was a hack, but it was an option. :)

[quote="Ashley":1i65rapg]The only other solution is to break up the work over multiple ticks. For example, instead of doing a million loop iterations which takes ten seconds and goes in to "not responding" mode, break it up in to 10,000 iterations per tick over 100 ticks. Not only does this keep the app responding during the processing, but it also gives you the opportunity to update the screen with the progress. That's probably your best bet for the time being.[/quote:1i65rapg]
Yes this sounds fine for what I want, but I am wondering how best to go about it.
As I said, it's 2 nested loops manipulating the whole array (well, most of it), with conditions as to what is written back into the array for each loop.

Now, if Construct is trying to do all this at once, what's the best practice to slow it down?

@Newt; No, this process is only required at the start of the level, and only the first time it's played.

Thanks again guys.

Krush

[color=#BF0000:1i65rapg]Edit: Lucid, you posted while I was posting. :) I'll download it and take a look.[/color:1i65rapg]
B
2
S
2
G
3
Posts: 406
Reputation: 2,062

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 6 guests