Ashley's Forum Posts

  • What crashes, Construct 2 or the browser? What's your OS and setup? You haven't given us much info to go on.

  • It's not a bug, it's a limitation in WebGL mode. See the note on WebGL in the manual entry for Text.

  • Can you post a .capx showing the problem?

    The problem with small objects, especially at low framerates, is often they can simply step entirely past a barrier. For example an object travelling at 600 pixels/sec at 30 fps is travelling 20 px per frame. If it is only 5x5, it's actually "teleporting" in steps 4 times bigger than itself every frame, and this means it could entirely jump over another 5x5 object without registering a collision.

    However, this is no reason for objects to be floating above other objects, so a .capx would be useful.

  • You do not have permission to view this post

  • Thanks for the ideas - the Platform behavior is definitely still missing some important things, and I guess this is a good reminder what's left to do.

    However I think a Sonic-like movement is quite a tall order... it would involve significant changes to how the Platform behavior works, and it's already an extremely complicated behavior (try figuring out the algorithms for jump-thrus at arbitrary gravity angles...) Still, I'll have a play at some point and see if I can figure out how a Sonic-type movement works, but it's a pretty clever movement type, I'm not sure I'll be able to figure it out!

  • Schoening, I think you're possibly confusing the speed on your screen vs. the speed in the "game world" (layout co-ordinates). The size of the window has no effect on how fast objects are moving in layout co-ordinates. If you play a game on an iPhone, then get some super-powered mega-laser and project the entire game on to the surface of the moon (how cool would that be?) - possibly the biggest screen imaginable - you'd still be moving at exactly the same speed in the game. It's just displayed bigger!

  • If most of the visual novel is images, it should be really easy to set up in C2.

  • Ah, interesting bug. Fixed for next build, thanks. It turned out not to be to do with local variables, it was actually 'While' didn't work with system conditions after it.

  • I don't think this is a bug - the Button object is floating above the canvas and handles the click before the Mouse object gets it. You just need to swap the Mouse 'clicked on object' event for the Button object's 'On clicked' event.

  • This is not a bug, just a common mistake. Follow the events from top to bottom.

    On clicked and mute equals 0: set mute to 1 and set silent

    On clicked and mute equals 1: yep, just did that in the previous event, so set mute to 0 and set not silent.

    So each time you click the button it instantly mutes then unmutes.

    Just use the 'toggle mute' option instead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • Hmm, if it doesn't work in Android 2.2 or iOS 4.x, and works in newer versions of Android or iOS, maybe they're just out of date and broken browsers. Might be best just to forget them.

  • delgado, I believe you are talking about a different bug, possibly this one. The bug umbra reported if I understand correctly is only about the undo action. It should be fixed for the next build, anyway.

  • What is the content of base64string? If it's a URL what URL is it and where does it point? Maybe just using a new Image() and assigning that will work, but I don't know, just a guess.

    There are a few mistakes/issues with the code you pasted:

    • there's no need to assign src to '' first
    • onload should be set before src, otherwise there's a slim chance src could finish loading before the next line (since browsers are asynchronous), then your onload event is never fired because it's set after the event has already fired.
    • however it's likely to take at least 2-3 ticks to load the image even if cached. Drawing an image before it has loaded is likely to cause an error
    • cr.runtime.redraw = true does nothing, I think it was intended to write self.runtime.redraw = true.

  • According to this:

    http://code.google.com/p/chromium/issues/detail?id=36415

    ...Chrome for desktop simply does not support touch events. I presume this is because there are relatively few touch-enabled desktops out there. Maybe star the issue or nudge them to get back on it.