Ok, I think I'm onto something now.

I'm using a disabled group so I can enable it when I need the data worked on, and I'm using a variable to keep tabs on the x loops (1-500), and each x loop contains a real "Y For Loop" that runs 1-10000, with the group disabling itself when x has reached 501.

I've only done this in a test cap, and it runs fine without any "Not Responding" messages, enabling me to move the window about and everything.

The real test will be when I add it to the project tomorrow, but I'm optimistic.

I'll let you know how it goes.

Krush.

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

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

That doesn't seem to work.

The outer loop isn't a loop, if you know what I mean.

But I can see what you guys meant now by splitting it over many ticks.

But is this going to restrict my use of Functions?

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.

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.

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.

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.

Well, it appears that in one of the polls you've had, you were explaining workarounds to life without groups, using booleans, etc, and other people were saying how they'd still prefer groups.

Looking at it just now, it's clear that you were talking about how to do it "until" you got around to adding them, and I guess I read it as you explaining why you weren't going to.

Glad I'm wrong.

Groups are one of my favourite things in C1.

Now all you need to add is an .exe exporter.

lol

Krush.

> Last I heard, groups were going to be left out of C2

>

Where did you hear that?! We've always planned to put groups in, to match Classic's features!

Seriously, I remember the discussion, and some people were saying the same as I was thinking, and that was how powerful groups can be.

I'm sure I didn't dream it.

I'll have a quick look and see if I can find the thread.

Maybe it was when you were still brainstorming C2.

Krush.

Thanks for taking the time to do that test Dave.

I think we can conclude that, at least with it's current implementation in C1, Python is no match for Construct's events.

Thanks again guys.

Now I can concentrate on the next stage.

Krush.

Last I heard, groups were going to be left out of C2, so it's good to hear that you've changed your mind.

Still not enough to make me use C2, but a step in the right direction.

Krush.

Some interesting reading there.

Thanks guys.

Those FPSs are particularly interesting Lucid.

Especially the loops.

My data is manipulated within nested loops, with the arrays written to and read from a lot, based an several factors, so it's hard to say whether Python would be faster or not.

If I could have a definite answer as to whether arrays are directly accessible from Python or not, I could either test it in Python or just give up and be happy with the results I get from the events.

Krush.

I just send it to a friend and he still don't have sound

What else can be wrong?

Did you also send all the sound files to your friend?

Krush.