Your distance implementation is severely lacking in oversight, none of the players will see each-other and so have nothing to calculate distance with. Hence interest groups. For instance groups, you can send your location to rounding your position to the nearest like 256 multiple or seomthing , and then choosing the nearest 8 cells, looking up the cell's interest zone in a dictionary that you made by indexing all of the possible cells, putting those interest zones when you send your event.

Then comes the hard part of creating and deleting players when you enter new interest zones and leave them and looking up their player data and appearance without having everyone pop in and out of existence and making sure someone isn't out of another player'S interest zone and attempting to shoot at them offscreen but not creating any bullets or things like that

None of that's really necessary if the only important variable for gameplay is the distance of other players from the local player. Whether or not they can "see" each other can be handled locally.

ThePhotons i would also like a little more insight into interest groups,the example capx are good and they cover about everything except interest groups

digitalsoapbox Yea that's exactly what i meant,selecting only the players within a certain area around the player to send information too

Then just compare the distance of the players from the distance of the player you're checking against. Look up distance() in the C2 manual to see how it works, it's pretty straightforward.

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.