Dalal's Forum Posts

  • 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?

  • You could try an API like TimeAPI, using the AJAX object to fetch the data you need.

  • I think a simple Like or Thank You system would definitely enhance this forum. Among other features, it could do things like adding reputation to the authors of posts that receive likes or allowing thread posts to be sorted by likes. Such a system would have the following benefits:

    • One could show their appreciation for a quality forum post without having to bump the thread.
    • Posters would be incentivized to leave quality responses.
    • Reputation would more accurately reflect one's value in this forum rather than simply one's participation.
    • It would be easy to sift through the most important posts in a thread, because they'd have the most likes.
    • It could make the forum even more fun!

    I'm sure a similar idea has been considered in the past, which is why I'm surprised it doesn't exist here. I can see how a comment rating system might make things competitive and infuriate people when they're downvoted, but we are only talking about happy, pleasant, warm Likes. It still keeps up the positive vibe!

  • My game is pretty basic. When you lose, there's a minimalistic Game Over screen that shows both your score for the current round and your best score.

    [That's Flappy Bird, not my game]

    The predicament rests in the fact that my game allows players to use Google Play leaderboards if they so choose. This creates a complication for me if I want to preserve the minimalistic look of the Game Over screen. Which score should I show as their "Best"? The high score stored on the device, or the high score fetched from Google Play?

    If I show the Google Play score, it will appear to disregard any high scores the player had achieved on their device before logging in. If I show the device score, it will disregard any higher Google Play scores. If I show the highest of the two scores (what I'm currently doing), it could confuse the player. If I sync up the two scores, it will cause issues if two people want to play on the same device but with different accounts.

    I'm now starting to feel like I should only work with the device score, and let Google Play handle the rest. They can click the Leaderboards button to open the Google Play interface, and then they can see their high scores, weekly high scores, and what not. So let them go to Google for that. I'll deal with the local stuff.

    I'm not sure what the "standard" is in these situations because I don't play a lot of mobile games. What do you think I should do?

  • shinkan,

    Hmmm, for some reason I thought it was easier to get fillrate limited, but now that you made me think about it, perhaps it isn't a fillrate issue. My game is 1920x1080, so assuming a flat layout, in a second it would write 147 MPixels, and my device apparently can do around 800. So unless there's something majorly wrong going on with my graphics, it should be a lot harder to reach that limit. But I'm still not sure if I understand all this stuff completely.

    I will go ahead and try yours and Aurel 's approach and see if it works. It is what I would have done, but I didn't since I figured that having an "Overlay" layer dedicated to transitions was somehow a neater approach. I didn't think it would make a difference.

  • Aurel, shinkan:

    Thanks for the ideas, but now I'm not sure they would be very different from my original approach in terms of rendering performance. What seems to be happening in my game is that the so-called fillrate capacity of my GPU is being reached. This is because I'm drawing a lot on screen already, and having to draw a white object on top of all the entire screen maxes out the device's rendering capacity for a frame, so it drops in framerate during fades.

    if my understanding is correct, the new approach I use should strive to limit the number of pixels the GPU has to draw, so I don't use up my device's fillrate capacity. The approach Colludium suggested did this by 'flattening' the rest of the game content by taking a snapshot and then hiding the other layers. This could work, but I'm afraid of the huge image size and it sounds like a slight headache to implement.

    So now I feel that a shader may be the best overall approach for fading. The other approach that comes to my mind now is to somehow "flatten" my game content to reduce overdraw, but I feel that the real culprit is a poor fade implementation. Clearly, games with reasonably complex scenes would have the same issue with using a sprite to fade. There must be a better way!

    But yeah, thanks again for the help guys! I'm still open to new ideas, but I'm pretty sure fillrate is the issue here, so anything that uses sprites over the whole layer will likely not work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Interesting, thanks for the idea. However, that snapshot might be too large (1080x1920) to be considered safe on mobile, let alone compatible with CocoonJS Canvas+, which has a maximum size for textures. Since my game is designed for mobile, I probably wouldn't want to use this approach.

    I feel like a shader that does this properly would be my best bet. Doesn't seem too hard to write one since it's just basic alpha blending, right? Then again, I don't know enough about writing shaders to be able to say

    Any more ideas you have are always appreciated!