Phacanu digitalsoapbox

Another option may be dividing game field in interest areas and assigning interest group to each. Subscribe player to interest group as he enters and unsubscribe as he leaves the area ("Change groups" action). In event, specify interest group which area better matches player position.

That seems like it would be more useful for something like a board game where interest groups would be more likely to remain static than what was being asked about, which is more about selecting remote Player objects around the local Player's position. Unless I'm missing something? Does dividing the playfield by interest areas also work dynamically? I haven't spent much time w/ interest areas so any additional insight would be appreciated.

ThePhotons I was watching a video by the cto behind Albion online and he mentioned

Is the current c2 plugin capable of doing such a thing,I know that the current ways of sending data are

but could we somehow use the Others option along with a array to send data to things only within a certain range?

You can use built-in C2 features to select the players that are nearby, set the Receivers dropdown to "Others" and supply the Photon ActorIDs of the selected players in the TargetActors field.

Looking forward to this one!

For Ashley and anyone else who's interested, here's a document from Intel on how they handle additive & alpha blending and potential rendering pipeline quirks than can cause visual corruption and potential performance issues:

https://www.dropbox.com/s/rkjolm5bpc3s1 ... .docx?dl=0

Still waiting to hear back from nVidia & Qualcomm to see if they have any quirks that could affect performance or rendering on mobile GPU devices.

Additive blend simply comes down to gl.blendFunc(gl.ONE, gl.ONE). The results of this are implemented by the native GPU driver. This call does not involve a shader, and has much less overhead than a shader. Third-party shaders will almost certainly be less efficient. My best guess is some GPUs are optimised for alpha blending, and using additive blend uses a less-optimised path (perhaps because it has to clip the output - you can add pixels which go beyond the pixel value range, whereas you can't with alpha blending, so additive blending probably involves an extra clamp operation).

I've reached out to a contact on Intel's embedded gpu team to get more info on this. What you've posted above definitely shouldn't cause what I'm seeing on every Intel chip I've tested on (and it only happens in C2/3), but I've also seen the same performance and graphical issues on a Shield TV/Tegra, so it's probably not GPU-specific. Based on the way C2's renderer works, should this work the same whether or not the blend is applied to a layer vs. a sprite, assuming both are set to have no opacity and backgrounds are solid 0,0,0 black?

Ashley Yes one would think so, but I find it a bit strange that the framerate isn't struggling more. If I was overloading it I would see regular spikes down to the sub 30 range right? I also don't have a way to measure the GPU usage in C2? I can't open my project in C3 due to some missing plugins. Is there some checks or some ways to force a draw even at the cost of framerate? It's a shame I can't record or document this issue so easily.

I've had the same issue occur on intel embedded GPUs when using C2/3. It seems to be an issue with the native Additive shader on lower-end/mobile GPUs. You could try using one of the third-party effects shaders which may not have the same issues. Generally speaking, there are a number of fairly significant performance issues w/ the native Construct shaders that affect blending mode.

Ashley Please providing a clear road map for new features of construct 3.

+100000000

I put together a little test that shows the issue pretty clearly. It's not connected to any gamepad/keyboard input (or at least, that's not the only issue), collision checks are minimal, etc. Testing in the Edge browser on XB1 is comparable to performance when exporting to UWP.

Just drag the slider to make sprites move faster/slower as they spawn in.

http://site.pixelmetal.com/temp/Project3/

It seems like even a stripped-down simple endless runner has performance issues that are Construct-specific on a platform that has more than enough power to run them. That's...disappointing. Note that performance is exactly the same w/ the shadows turned off, so that's not the issue. Despite claims to the contrary, the dropped frames are very obvious and are likely to cause gameplay issues in anything approaching a fast-paced game.

Based on other tests, it seems to be something in Construct itself, as similar issues do not occur with phaser and a few other html5-based engines that can be tested through Edge on XB1. Wouldn't hurt if someone at Scirra took a look at the built-in profiler in Edge, there are obvious spikes in canvas compositing causing the hitches to occur, especially if they're going to claim XB1 as a supported platform...it has a much bigger install base than the Wii U ever did, so more people are more likely to see how well it's supported as a platform. Would be a shame if Construct got a rep as a continually shoddy engine for consoles, assuming they're looking for more developers to use the engine.

^ Addition to this:

I've gotten my game to the point where it runs very well for the most part. During real-time combat with enemies it might be between 45-50 fps but any other time it's steady 60 fps. The only issue is I get a little stutter every few seconds, and it will drop from say 60fps to 52fps for just a split second, but the stutter is pretty noticeable. This even happens in the main menu which has very little code/objects. It has done this not only on the Xbox but also in Edge sometimes on my PC. Anybody else experience this?

Yes, I mentioned this exact issue that seems to be Edge-related earlier in the thread. It's hard to know if the root of the issue is the C2/3 engine or Edge, but so far has seemed (to me) C2/3-specific.

digitalsoapbox

Any news on tis?

by the way... link to test is not working

Don't count on any news. This is dead due to inherent limitations in C2 that have not been corrected in C3 and likely won't be any time soon, if ever.

digitalsoapbox What kind of numbers are you guys talking about? In Crystal Brawl, on player input (so characters start moving) it drops maybe 2-5fps. I figure this is normal due to the extra physics and animations kicking in. No particularly noticeable hitch to me. Are you guys seeing much greater frame drops?

It occurs where there are no physics at all, where there are no animations, and with no objects responding to player input. As soon as player input occurs, every second or so, even after input has stopped, there is an obvious hitch.

For example:

Spawn a small sprite with no animations (just a green square, for example), behaviors, or shaders off-screen to the right every second or so, and move them across screen to the left (self.X = self.X - 100*dt), deleting them when X position < 0 + self.Width/2. Make sure the Gamepad object is in the project. As soon as there is player input, repeated hitching will start. With so little going on, it's had to justify any framerate dip at all, and because it only happens after player input, it's unlikely that it's connected to anything going on in-game outside of the input.

The issue, as I said earlier, is also noticeable on desktop Edge, though it takes a heavier load to become more pronounced that I'm fairly certain is not connected to anything that has to do with physics. In Sombrero, which is much heavier than the above example, all physics run fine and there are no hitches in framerate until player input starts (though performance is overall much lower than in NW.js).

UPDATE 11/13/2017: The latest Dev Beta OS released to Devkits over the weekend reduces the issue somewhat, but it's still there. Seems Microsoft is working on the gamepad issue.

One thing I've discovered today is that any time the game tries to read an input from the controller, it causes a hiccup in performance. Whenever I press a button, move the joystick, or whatever. It is unclear if this is something in my game's code or something else - for example, if I spin the right joystick around rapidly (which in my game, the right stick does not control anything), performance drops to the point where the game looks completely frozen. Same thing if I keep pressing left or up on the d-pad (also, no code in my game that references these inputs). But, if I stand still with enemies coming at me and dont press any buttons, performance is actually okay for the most part.

Also unrelated to performance but also weird, pressing the B button suspends the application. Anyone else run into this?

I've been having the exact same issue with performance hiccups based on user input. It happens on desktop Edge as well, in both public & preview releases. I've been putting together a simple endless runner to test XB1 performance specifically, and the hiccup on any user input causes a noticeable hitch that isn't acceptable, and I had/have the same issue with my previous C2 project but hadn't traced it back to player input. Based upon testing after I read this, that does seem to be the issue there as well. Not sure if it's an Edge issue or a C2 in Edge issue, but it's there.