"Not Responding" windows reaction to intense calculations

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.

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

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:

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.

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.

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

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.

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.

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....

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.

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

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.

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

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

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.

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

Yes, it was a hack, but it was an option.

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.

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

Edit: Lucid, you posted while I was posting. I'll download it and take a look.

For nested loops just break up the top level loop across multiple ticks. That still cuts up the entire job in to smaller pieces.

For nested loops just break up the top level loop across multiple ticks. That still cuts up the entire job in to smaller pieces.

oh yeah, that's way easier than my suggestion, but I already made it, so here ya go:

http://dl.dropbox.com/u/1013446/splitsplits.cap

splits em up into chunks of 10,000 regardless of nested loop position

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

I wasn't able to get either threading or multiprocessing to fully work with Python. For some reason, I can't seem to populate the entire Construct array inside the thread (only the first element). It is like it runs the loop once then just stops.... also can't set globalvars from inside the thread, etc... For multiprocessing I get an error "AttributeError: 'module' object has no attribute 'argv'...perhaps related to running the program via the Construct IDE and not commandline.

Ok, plenty of food for thought.

While I try some of the suggestions, here's the most basic way I could find of making the "Not Responding" message happen using 2 nested loops, with minimum reading and writing to an array.

http://www.smileydesign.co.uk/FreezeMe.cap

How would you go about stopping that from freezing?

Krush.

Ok, plenty of food for thought.

While I try some of the suggestions, here's the most basic way I could find of making the "Not Responding" message happen using 2 nested loops, with minimum reading and writing to an array.

http://www.smileydesign.co.uk/FreezeMe.cap

How would you go about stopping that from freezing?

Krush.

The simplest way would be to split the x over 100 ticks, like this:

http://dl.dropbox.com/u/326175/freezemeunfreezed.cap