Ashley's Forum Posts

  • Please file a bug report following all the guidelines or the problem will not be investigated. Note this thread was originally from 2013, it could well be a completely different issue.

  • It could well be a problem with Steam and the way it shows its own overlay, in which case it's a Steam bug and not something we can do much about.

  • I don't know, it worked the last time I tested it. There is very little I can do to help without a .capx or fully including everything from the bug report guidelines.

  • It's blocked by design on the Arcade, since the action would clear all storage used by the other games too.

    • Post link icon

    I definitely think it would be wise to have a couple of developers that you trust and use construct on serious projects give you solid feedback based on their experience shipping games using the engine.

    We have been doing this routinely for years now. For example even just in the last build r228, the new AJAX triggers, the "on save failed", and all the bug fixes were made based on feedback from users with real-world problems. For example some users were struggling with a problem with handling dynamic AJAX requests, and it was established on the forum that these triggers would help, so we added them. That's been the bedrock of how we develop C2 for a long time!

  • There isn't a method called GetBoundingRect(), so I'm not sure how that code even ran? Nor is that quote in the documentation. What exactly are you looking at?

  • If this really happened, it would amount to shutting down a large section of the web and there would be severe damage that would last for years. The web would never be the same again. I think it would be so bad that what happens to Scirra would not even be that important. In other words, I'd say its so unlikely as to not warrant any concern at all.

    • Post link icon

    I read that a lot of people didn't expect it to be this difficult.

    Yes, but I anticipated that, and specifically warned people to assume that multiplayer would be very difficult to use, and only to vote for it if they were prepared to use a difficult feature. Everyone voted for it anyway.

    • Post link icon

    We don't want to announce anything that isn't 100% guaranteed yet, and everything is still subject to change.

    I am also very skeptical of users voting on features since we did multiplayer based on that. The multiplayer feature won all feature votes by a significant margin, we spent months implementing it, and then saw pretty low usage of it after that. It's also stayed pretty flat and has not grown much. Its usage is nowhere near as much as the votes would have suggested. So while I think user feedback is essential in general, voting systems aren't always helpful. They represent hype and people's imaginations of what would be good more than how many people will really use it.

  • In terms of the Javascript language, object.property and object["property"] are identical.

    In terms of the minifier, when exporting with "minify script" enabled, object.property will be renamed to something shorter by the minifier, e.g. object.q. However object["property"] will not be renamed. So you should use object["property"] syntax for anything that should not be renamed by the minifier.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You also need cordova-plugin-file in WKWebView mode. How exactly are you building? Is there a reason you excluded it? Construct 2 should specify it automatically when exporting for Cordova.

  • I think the alternate tick system will still work on a 120Hz monitor - at least in my example, it still uses dt on alternate ticks, which means it is moving in half-as-big steps at 60 Hz instead of normal size steps at 30 Hz. If you force dt to be constant, you are making a game design choice that breaks this, and the game will run double-speed on a 120Hz monitor.

    As for varying the logic update rate, I can't see it working for a general purpose engine like Construct 2. There are two options:

    • run logic at a lower rate than the display rate: this is fiddly to do in a way which doesn't just look like it's running at the lower framerate. Moving objects can be stepped, but they still have to be collision tested every step, and collisions can run events that have other consequences in general, so by then you may as well just run all your logic every step. I think this can work for custom-coded games with specific requirements, but I really doubt this is something you can just turn on for most games in general and have it "just work" - I think a lot of the time, the result would be the game just looks like it updates at the lower rate as well. Or you'll get really terrible collision skips where objects basically pass through other objects without registering a collision, because they only overlapped briefly and there wasn't a "real" tick during that time.
    • run logic at a higher framerate than the display rate: this basically multiplies your CPU usage and hammers performance. Say you run logic at 120 Hz and display at 60 FPS. That doubles your CPU usage. People complain enough about performance as it is, I don't think we should add features to make that worse. Also if the logic rate is not a multiple of the display rate, e.g. 90 Hz logic and 60 FPS display, this creates the uneven-stepping problem you've already seen in this thread. If an object is moving 1 pixel per frame, there aren't enough display frames to show each update, so then you get an irregular pattern of 1-2-1-2-1-2...

    So I don't see that either option is really any better. C2 has always done one logic step per display frame, and I think that makes most intuitive sense anyway: any less and sometimes there is nothing new to draw, any more and you burn CPU time simulating stuff you'll never see. And C2's approach has worked well for a very wide variety of games.

  • TBH the last example you posted looks fine to me. FWIW here's another version which works by having a double movement speed and disabling the behavior on alternate ticks: https://dl.dropboxusercontent.com/u/15217362/30fpsmovement.capx

    It seems to work fine even without a minimum framerate. That looks pretty much the same as the previous example to me though.

    R0J0hound - you're mainly talking about v-sync, which is a slightly different problem. It's possible to move at precise pixel offsets, but not v-sync accurately, or to v-sync accurately but not move at precise pixel offsets. Construct 2 definitely can do precise pixel offsets (either lock dt or just make your own events to move at integer amounts). All modern browsers can v-sync to within 0.1ms, at least on my system. If you see poor-quality v-sync you should file a bug report at crbug.com or at least comment on the existing v-sync bug (crbug.com/422000) with your system spec. As far as I can tell it's been a solved problem for a while now, but maybe some different system setups work differently.

  • Why do you need them listed if you either choose them from a drop-down list or have them auto-completed as you type expressions?

  • Nothing we can do without a .capx and steps to reproduce, as per the bug report guidelines. Note stable releases don't show those messages, so it could have been happening in r227 as well, just without showing the message.