The wonderfulness of SQF

[moricky 211]

It's all question of optimization.

I changed some values (of sleep commands) in your test with targets and result is that FPS is same, but with SQF movement is smoother. Creating targets is continuous in both ways.

Kronzky's test ver2

BTW: If you want to execute more SQF scripts at once, it's good to add sleep with random value to start, so cycles in all scripts won't be processed at once.

EDIT: Link fixed.

[kronzky 5]

Quote[/b] ]BTW: If you want to execute more SQF scripts at once, it's good to add sleep with random value to start, so cycles in all scripts won't be processed at once.

I had tried that too, but since the scripts are still all invoked at the same time, and the delay only becomes active after they've started, it didn't really help with the initial lock up.

[crashdome 3]

Quote[/b] ]Mind you, I would *love* to use SQF (as probably any programmer would), but not at the cost of playability. That always has to come first. Not my preferences as a programmer.

I hate to say this because it sounds like I am berating you... which I am not... but as the others have pointed out, you cannot have a 1-to-1 comparison of SQS vs SQF when comparing code.

When you program in SQF, you need to refine your approach a bit also.

As Gaia pointed out, simply by applying better practice he's managed to eliminate the problem and increase playability. All the good practice in the world can't save many an SQS from being slow and clunky...

Quote[/b] ]My point is: SQF is extremely greedy...

So what? Under the right conditions everything can be considered extremely greedy or have problems in some way. It's what gives you the flexibility to overcome the inherent problems and SQS just doesn't have it anymore.

Its not entirely a bad way to code... it's just getting a bit more out-dated.

[kronzky 5]

Ok, I've revised the test setup a bit to make it more realistic:

100 objects, placed in the editor, are calling a script that does 1,000 tests every .1 second.

The results:

SQF: Load time: 8.5 seconds, performance: 7 FPS

SQS: Load time: 3.6 seconds, performance: 23 FPS

What am I doing wrong?

[crashdome 3]

IMO you are doing nothing wrong. You are doing exactly what you are intending to do. You are hogging up CPU cycles.

You are running code to perform 1000 tests but yet you measure the FPS rather than the result of the tests. How many tests get executed in a time frame? How many get executed that are incorrect. Statistically, this is bad test. What are your goals? To acheive reliable and quick test results? or bog down the CPU?

My point: If SQS took 10mins versus SQF which took 1 minute, then you need to equalize the time frame if you are using FPS as a measurement tool. make it so that the same number of tests run within the same period of time and then you can look at FPS. <s>The only way you are going to do that is leave the SQS at 0.1 and bump up the SQF to 0.3 or something until total time taken is equal.</s> nevermind that was a stupid mistake on my part... you still cannot measure using FPS with your method IMO

[raedor 8]

The results were pretty clear-cut:

SQF is faster, but only because it grabs so much of the CPU power that everything else will have to suffer.

During the object generation the whole system will be locked up, but then, when it's done, all the objects are there instantaneously. Whereas with an SQS script it will take a while to generate those 1000 objects, but the system runs quite fine with that happening in the background.

The same with the movements: The objects move more very nicely, and in-synch, when I use SQF, but the FPS drop down to 4-5. With SQS the movement is a bit more staggered, but the FPS stay at around 17/18.

Two more points to make:

1. If you want to have x objects created instantly, then don't wonder about a lockup.

2. If you don't want to have them instantly ("will take a while") then design your script that way. 0.0001s delay means that your code has to be executed 10000 times per second; better leave the delay out then or make it so long that it "will take a while".

3. preprocess and compile the function, don't use execVM if you're starting it 1000 times...

[cain2001 0]

Are "for" and "while" used in SQF?

I dont think theres any difference (atleast not worth flaming about). SQF is for those who already know basic scripting and SQS is for the beginners who uses easy scripting.

There!

[kronzky 5]

What am I doing wrong?

I guess what I did wrong was not realizing that the SQS script doesn't actually finish the 1,000 tests in .1 second (it takes it about .2 seconds, as opposed to less than .001 seconds in SQF).

Once I adjust for that performance (FPS & distance covered) is very similar.

I would still rather have a script that lags behind a bit, and gives priority to the playability, instead of something super-fast, but with the FPS suffering, but it looks like some more research is needed... ;)

(I may just have to sprinkle my code with generous sleep statements every few lines.)

[UNN 0]

Quote[/b] ]I would still rather have a script that lags behind a bit, and gives priority to the playability, instead of something super-fast, but with the FPS suffering, but it looks like some more research is needed...

It's a legitimate question to ask and one that can only lead to us all having a better understanding of what goes on.

Quote[/b] ](I may just have to sprinkle my code with generous sleep statements every few lines.)

Yeah, I think thats the way to go if your using a lot of heavy commands in a single sqf script. They don't even have to be to generous, aslong as they help spread the load.

[kronzky 5]

Looks like plenty of "sleep" is the answer after all...

I put a bunch of brief sleep commands into strategic positions in my patrol script, and all of a sudden the SQF version behaves quite nicely.

I just watched a nice city fight (100 East officers vs. 100 West), and except for situations where I had too many of them on the screen at the same time, FPS never dropped below the mid 20s. When I stayed out of sight altogether it got into the 30s. Whereas before, without the sleep statements, it was unplayable. (And these are loops that run once every 5 seconds! )

[-DirTyDeeDs--Ziggy- 0]

although I am glad to know that somehow a 100 vs 100 AI battle can take place, I don't think the difference between sqs and sqf is so groundbreaking as to influence the majority of the communitys map makers to switch any time soon.

but thanks for the discussion, I learned more.

[raedor 8]

I would still rather have a script that lags behind a bit, and gives priority to the playability, instead of something super-fast, but with the FPS suffering, but it looks like some more research is needed...

(I may just have to sprinkle my code with generous sleep statements every few lines.)

Well here again: The script designer has to write his script that way, that it does not lag. He can use "super-fast" functions, but he has to take care of his code and he has to check what he is doing.

It's like it is in all other branches of Poseidon modding: The modeler can produce models with way too many polys, the texturer can make textures with way too high resoltuion, island makers can use too many objects; all this will necessarily lead to lag (if you use eg too many high-poly models; a single bad-style script also doesn't lag, but many scripts do).

People who care about their product, just don't do that. Scripters, modelers, texturers and island makers.