I've made some music that contains an intro sequence and then a loopable part. The idea is that I'll start by playing the intro and as soon as it ends I'll play the loopable part and repeat that indefinitely.

My attempt so far plays the loopable part during an "On Ended" trigger (I figured that a fraction of a frame's lag before it plays the loopable part won't be noticeable). The problem is that it takes longer than a frame to play the loopable part, and there's a noticeable pause in between.

Any ideas on how to queue the second track so that it plays immediately after the first?

NOTE: The loopable part loops perfectly. It's just this intro-to-loop that needs fixing.

This seems to be an issue with particular devices, especially Samsung devices. On my phone, for example, I've tried some AAA sort of games that also have this delay. There are also some, like Cut The Rope, that don't have this delay, which means they used Android audio a different way either intentionally (to avoid the delay) or it just happen that way.

Unfortunately, I don't think this is ever going to be resolved for our phones, so we'll have to accept it. Don't worry, half the people I've tested my game on don't even notice that anything's delayed

Glad to hear that I'm not the only victim! I guess that warrants a bug report.

Problem Description

When a Construct 2 window is shrunk to a small width (which might even happen unconsciously and unintentionally by the user by habitually clicking the maximize/restore button, or double-clicking the header), the events of all open event sheets shrink down to a size where the object names are no longer visible. The issue is that when the window is restored to its original size, the events remain shrunk, and it becomes a pain to have to re-adjust them to become readable again (and it must be done for separately for each event sheet).

Though not a normal occurence, the same effect can be seen with the toolbars, such as Project and Properties. Shrink the window width down to a small size to where the toolbars (especially ones docked to the right) virtually disappear, then scale it back up to its original size. Now to get the toolbars back to normal you'll have to manually resize them, because they have remained in their shrunken state.

How It Looks

Steps to Reproduce

• Start a new Construct 2 project and make some events.
• Set the unmaximized size of the window to a small enough width to shrink the events.
• Restore (maximize) the window back to its full size.

Observed Result

The events remain shrunk, and if the width is small enough, the object names can no longer be seen. In order to get them back to normal, one must first drag the handle to show the name of the action object, then drag the handle at the condition-action divider, then finally drag the handle to show the name of the condition object. If there are sub-events, the condition handle for the sub-events must also be re-adjusted separately. This process must be repeated for all event sheets that were open at the time the window was shrunk.

Expected Result

The user set size of all the handles for each event sheet should be remembered. If there is enough available width to show the event size set by the user, show it, otherwise shrink as per the current logic. This should apply to all handles, including those of toolbars and any other interface elements that have this issue.

Operating System and Service Pack

Windows 7 Home Premium SP1

Construct 2 Version ID

r206

ludei, were any changes made to Canvas+, such as performance improvements or anything of the sort? Or is it the same Canvas+ as before?

As I work, I'll suddenly notice that my events have resized to where I can't see the object names anymore. Then it takes three or more click-drags to get my events looking how I want them. Once they are fixed, I'll navigate to another event sheet to find that the the same problem exists there, so I have to fix it again, and so forth for EVERY event sheet that was open when the events first got affected. This feels like it happens at least once per hour as I work, and over the last few weeks, it's been bothering me a lot, breaking my workflow.

I've found that the issue occurs when I unwittingly shrink a window and then maximize it later. The same effect occurs with the toolbars and other elements, though I care less about those. At least keep my events readable!

Is there any setting I can change in Construct 2 so that this stops happening? If not, I would really appreciate it if it was fixed in a future release.

What's a reasonable way to search for something across all event sheets? Currently, I have to go through each event sheet individually and that just doesn't seem right.

EDIT: One approach I've been using is to export as a project and then use Notepad++ to search the Event Sheet folder. This sort of works, but obviously this isn't the ideal solution. The option to search globally needs to be added!

Perhaps this is simpler?

This will give a signed angle diff between two angles.

angle(0,0,cos(a-b),sin(a-b))

It's in the range of -180 to 180. It always picks the shortest distance but it's negative if CCW and positive if CW.

from:

That is a good answer. Knowing someone else is doing it this way definitely gives me something to work off of. I think I'm inclined to doing it the way you suggested. It seems to make the most sense all around. Thanks.

Very cool. Thanks for the ideas guys!

Since this thread is about Crosswalk experiences, I'd like to share mine. I had given up on Crosswalk almost a year ago for mobile development, but just yesterday I gave it a chance, just to see if it might work better than CocoonJS Canvas+ now that it's been some time. I was impressed with how far the Intel XDK had come. The interface seemed a little more intuitive and it was easier to get a build. But once I tested the .apk, I immediately started laughing, in a cynical, horrible way.

My first thoughts were: What a joke! Not only did my compiled game stay stuck for 5 minutes with the C2 loader, but once it loaded, the game was pixely. It was rendering at a lower resolution. On top of that, it was slow and janky. So not only did it fail to perform as well as Canvas+ fps-wise, but it introduced new graphical and loading issues that made it far worse. It was laughable. It did even worse than it had done when I tested it a year or so ago.

Now that it's a been a day or two and I've recovered from the agony of the situation, and considering that people have claimed to use Crosswalk successfully for their games, I'm going to give it the benefit of the doubt and assume I screwed up the configuration somewhere. But yeah, that's my story. I'm going to stick to CJS Canvas+ for now.

To preserve proper gameplay in the event of framerate jank, I've implemented various safeguards, such as movement stepping and all that jazz.

What's a good way to induce dropped frames in a controlled fashion, so I can test this? Ideally, I'd want to be able to say: If 'D' is Pressed: Drop the next 2 frames.

Then I can press 'D' before a critical moment in my game and see how well my game deals with it.

Any ideas?