Colludium's Forum Posts

  • It's as if is-overlapping uses collision cells but on-collision does a brute force check of the objects....

  • ...Just to add - the main difference is that a second or subsequent overlap condition will not be registered by using overlap/trigger once, whereas the On Collision does detect multiple occurrences of collisions between multiple objects.

  • — - I had about the same - the On-Collision has a massive and surprising overhead to it. I would certainly use Overlap / Trigger Once if the situation allows; however, if you need to know whenever a collision happens to a new object, while another similar object is overlapping, the On Collision trigger seems to be the simple way to go (although I'm sure that you could use Overlap with an array for a much better result in situations like this). I'm pretty sure that Ashley said in another thread that the two methods in that example are essentially identical - but that clearly isn't the case!

  • This is quite an interesting finding but there is a marked differences between using "is-overlapping" with a "trigger once" compared to using the "on-collision" trigger. I've messed around with the example above to demonstrate this. This version includes drag and drop behavior, so you can select a green or purple square and drag it over the squares of the other color. Because of the squares' dimensions, if you drag a square to the other side of the screen it never stops overlapping at least one of the other types of object. Give it a try and you'll see different results for testing for an overlap and testing for a collision trigger. I added a text object to show the cpu time and fps, in case the debugger added some overhead that muddled the findings.

    So, never say never use on-collision - just be aware of what you are asking the engine to test for.

  • Weird - I had only bubbles where squiddy should be.... It took a couple of hard refreshes and clicks on the link to get it to work properly. For comparison then, here's a screen shot of the v2 running - no difference to v1 as far as I could see.

    [attachment=0:1ey8zjsa][/attachment:1ey8zjsa]

  • I'm wandering if you're using a lot of a 3rd party plugin... Not sure if that sort of thing could make the editor crash, although not that long ago a small text object memory leak was fixed - which gave similar symptoms. It's possible that a 3rd party plugin could be causing a memory leak - does this happen when you work on a new project as well? Also, thinking as I type, do you save your backups in the same folder as the main caproj file (so the backups contain archives of themselves)? Also, I once found that saving microsoft office word documents in the root of the c2 project would cause c2 to crash on save (when the word doc was open). I've now run out of ideas....

  • I'm not sure if this is a useful comparison because v1 of the demo allowed me to zoom around and force lots of graphics work of my gpu, whereas v2 of the demo doesn't move around (so should be 60 fps, right?). I took these screen shots of chrome developer tools showing the javascript work being done per frame and, where there are gaps, the dropped frames. Version 1 dropped something like 1/5 and version 2 dropped something like 1/10. It would be interesting to make a comparison with a version made with r198 that allows for zooming around. If there's no difference between v3 and v1 then the problem is more likely to be of chrome's making. Such a comparison might show a difference in dropped frame rates - and if there is a discernible difference in dropped frame rates under similar loads then that would indicate that some of the problem could be down to the c2 engine. I have just reached the limit of my understanding...

    [attachment=1:264w5cbi][/attachment:264w5cbi]

    [attachment=0:264w5cbi][/attachment:264w5cbi]

  • I did some testing to see what triggers the janking on my laptop. My earlier result of 1280, the design resolution, being the cut off was probably just a fluke / caused by the slight loss of performance associated with rendering at higher resolutions, and it might have been influenced by my having developer tools running...

    The jank seems to be only dependent on the number of pixels that need to be rendered each tick - lots of large area overlapping objects or large objects that move quickly seem to be the culprit.

    It seems like my GPU can only handle a certain amount of pixel drawing work when drawing the canvas before frame drops start. Thus if I draw 2k moving large sprites the frame rate is poor, even though only 100 of them might be visible due to z order. Make the sprites small, so the overall pixel area they cover is reduced, and performance goes up - that seems to not be a function of the sprite original image resolution but just related to its draw size.

    Not sure if this helps though because it just seems that there an upper limit to the number of pixels that can be smoothly drawn, a number that is different for each piece of hardware. If you allow nw window scaling then the player can at least select a window size that is playable on their machine, and perhaps the forthcoming jank fixes in chrome will also help.

  • Just guessing about the possible gpu loading with upscaling an image from a lower resolution compared to effectively downscaling a HD image at all game resolutions. Having just read through the other thread, my suspicions as to the cause are the same as yours.

  • Squidster - I like the demo! So, I tinkered around with the developer tools in Chrome, IE and Firefox and, due to my ignorance I couldn't find anything that stood out as a cause for the janking... at first. As you posted already there are lots of frame drops and janks aplenty in full screen. I'm running i7 16 gb with 2gb vram (intel hd4600) - heck, it's a gaming laptop and should eat this sort of game!

    I did spot something of interest when I was using the developer console - I re-sized the game window to see at what size caused the janking to start (I also found small windows were rendered very well, no missed frames etc). I noted that the game was scaled from 1280x720 and, as soon as the game window width exceeded 1280, even by a couple of pixels, the frame drops and janks started (the dt diff went from 3 to 18). With a window width less than or equal to 1280 then everything was good. So, this jank problem is, in part at least caused by some sort of up-scaling problem with c2.... A thought - are all of your images designed to give high quality at full HD or are they just up-scaled from the 1280x resolution?

  • Add the following condition under the on-collision trigger event:

    Text : Pick nearest to PlatformB.X , PlatformB.Y

  • It's not intuitive - check out the Touch object's acceleration values.

  • Did you have a look at the capx that comes with the tutorial? It's all in the big loop that captured the date from the CSS data string. You might be trying to do something that isn't supported - you can only CSS certain objects.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • The button and text box objects can be edited using standard css like in my tutorial here. However, the progress bar and slide bar have elements that don't seem accessible by this method (it seems better to use sprites in those cases).

  • Voted for you on Green Light - good luck!