R379 STABLE EXPORT NW.JS COMMAND IS INVALID

[kidfishy]

Problem description

When using version r379 to output the nw.js format, additional commands entered on the command line are invalid.

Attach a .c3p

timetest.zip

Steps to reproduce

1.Using r379, output the project as nw.js and add "--disable-raf-throttling" to the command line. 2.Run the output nwjs game program 3.Minimize the game window 4.Wait 10 seconds (not necessarily 10 seconds) 5.Restore the window and view the window timer text

Observed result

Much less than 10 seconds.

Expected result

When minimized, the game is played because of the "--disable-raf-throttling" command. After the window is restored, the timer in the program should be 10 seconds or more.

More details

This is valid in versions prior to r368-2. The error occurred after updating to r379. You can test that by outputting the nwjs program with the same Settings for r379 and r368-2 versions, you will get different results. This result shows that r379 and r368-2 are invalid when output in nwjs format.

Additional Notes：I just retested it. Add "--disable-raf-throttling" command output in r379, after the game window is minimized. The game is not a complete pause. It becomes very slow, almost stagnant. But it's still running at a very slow pace.

Affected browsers/platforms:

Windows（nw.js）

First affected release:

r379

System details

View details

Platform information Product: Construct 3 r379 (stable) Browser: Chrome 121.0.6167.86 Browser engine: Chromium Context: browser Operating system: Windows Vista Device type: desktop Device pixel ratio: 1 Logical CPU cores: 8 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Language setting: en-US Local storage Storage quota (approx): 71 gb Storage usage (approx): 2.2 gb (3.1%) Persistant storage: Yes Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported. Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: no Supports highp precision: yes Vendor: Google Inc. (NVIDIA) Renderer: ANGLE (NVIDIA, NVIDIA GeForce GTX 1070 (0x00001B81) Direct3D11 vs_5_0 ps_5_0, D3D11) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions: EXT_color_buffer_float EXT_color_buffer_half_float EXT_depth_clamp EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_norm16 KHR_parallel_shader_compile OES_draw_buffers_indexed OES_texture_float_linear OVR_multiview2 WEBGL_clip_cull_distance WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw WEBGL_polygon_mode WEBGL_provoking_vertex Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats: WebM Opus (audio/webm;codecs=opus) WebM Vorbis (audio/webm;codecs=vorbis) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav;codecs=1) Supported encode formats: WebM Opus (audio/webm;codecs=opus) Video information Supported decode formats: WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034) Supported encode formats: WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) WebM H.264 (video/webm;codecs=avc1.420034)

[AshleyScirra]

Construct is specifically coded to suspend the game when you minimize the window. So it ought to stop counting in your example when minimized - that's by design. I would assume you were previously depending on a combination of a bug in Construct and a Chromium command-line flag to keep the engine running while minimized. That's not supported and so we won't fix bugs reported for that case.

You should not do this, anyway - it's really wasteful to system resources (including wasting power on battery-powered devices) to try to keep the app alive when not actively used. If you want to do something like measure the time passed while the app is closed, you can do that by saving the time when suspended, and comparing the time passed when resuming, and then simulating that much time passing. Or if you just want a timer display like in this project, use the Date object to measure the passage of actual time, rather than in-game time.

[kidfishy]

You as game engine designers should understand that there are different types of games. I'm a hang-up placement game developer. Hang-up games need to be kept running at a minimum in order to generate hang-up revenue. This is a characteristic of a type of game. You can't deny them. In fact, in your version r368-2, everything is fine. Since version r379, this issue has had inconsistent results. That's a fact, and if you don't think of it as a bug, what's going to change that?

------------------ 原始邮件 ------------------ 发件人: "Ashley @.>; 发送时间: 2024年2月19日(星期一) 晚上7:53 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [Scirra/Construct-bugs] R379 STABLE EXPORT NW.JS COMMAND IS INVALID (Issue #7842)

Construct is specifically coded to suspend the game when you minimize the window. So it ought to stop counting in your example when minimized - that's by design. I would assume you were previously depending on a combination of a bug in Construct and a Chromium command-line flag to keep the engine running while minimized. That's not supported and so we won't fix bugs reported for that case.

You should not do this, anyway - it's really wasteful to system resources (including wasting power on battery-powered devices) to try to keep the app alive when not actively used. If you want to do something like measure the time passed while the app is closed, you can do that by saving the time when suspended, and comparing the time passed when resuming, and then simulating that much time passing. Or if you just want a timer display like in this project, use the Date object to measure the passage of actual time, rather than in-game time.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[XHXIAIEIN]

Why is this not a bug. The --disable-raf-throttling option should be work in NW.js. http://docs.nwjs.io/en/latest/References/Command%20Line%20Options/#-disable-raf-throttling

so, Is it possible that requestAnimationFrame() of nw.js cannot correctly obtain the callback due to the update of Chromium?

[kidfishy]

idle game don't think too much about power and memory, They are more concerned that after the game is minimized, he can do other things and then check the results of the game in his spare time. This is the fun of hanging up games. I hope you understand the needs of developers and players of different types of games.

[kidfishy]

I made a hang-up game. It's not just about counting the passage of time. It requires continuous simulation of combat, such as a continuous tower defense game. It's not just time hanging up. Requires real-time operation. It may not be a bug, but I hope you can restore the Settings in this area to before version r368-2. At least until then, everything was going well.

[kidfishy]

Not all idle games count only offline or idle time. Many idle games run continuously in the background to simulate the running of the game.

There's a huge audience for this type of game on steam, and I'll give you a few examples of games that have been developed for c3, as well as other engines:

https://store.steampowered.com/app/758190/_/ https://store.steampowered.com/app/1863750/_/ https://store.steampowered.com/app/1649730/_/ https://store.steampowered.com/app/2226700/_IDLE_DEVILS/

Again, I hope you will pay attention to the needs of different types of gamers and writers. If you can't fix this problem, then you have reduced the number of gameplay types supported by c3.

[kidfishy]

Construct is specifically coded to suspend the game when you minimize the window. So it ought to stop counting in your example when minimized - that's by design. I would assume you were previously depending on a combination of a bug in Construct and a Chromium command-line flag to keep the engine running while minimized. That's not supported and so we won't fix bugs reported for that case.

You should not do this, anyway - it's really wasteful to system resources (including wasting power on battery-powered devices) to try to keep the app alive when not actively used. If you want to do something like measure the time passed while the app is closed, you can do that by saving the time when suspended, and comparing the time passed when resuming, and then simulating that much time passing. Or if you just want a timer display like in this project, use the Date object to measure the passage of actual time, rather than in-game time.

Hope for your reply

[XHXIAIEIN]

i use this example to test --disable-raf-throttling, It does have 2 different results.

Steps to reproduce

1. open https://editor.construct.net/r368-2#open=template-race-track
2. Export using NW.js.

ps. You can set the layout scale to 0.25, it will make it easier to observe.

{"is-c3-clipboard-data":true,"type":"events","items":[{"eventType":"block","conditions":[{"id":"on-start-of-layout","objectClass":"System"}],"actions":[{"id":"set-layout-scale","objectClass":"System","parameters":{"scale":"0.25"}}]}]}

Observed result

r368-2: When minimized, the game will still run, Observed the car will continue to move.

r379: When minimized, the game will pause.

[AshleyScirra]

Construct does not support this. It does not support it on any other platform. You were using custom Chromium command-line arguments to try to work around something Construct does not support; now it doesn't work, and Construct still is not designed to support that, and we don't investigate bugs in features that are not supported.

As I said, you don't need to keep the app alive running in the background. In fact, the app does not need to be running at all, as the Offline Builder example demonstrates. You can simulate the amount of time passing upon the app being resumed. This is what any other well-designed app of this design would do.