Ashley's Forum Posts

  • C2 knows not to run any timer for sprites with only one frame. The animation speed does not affect this at all.

    Closing as this is in the Bugs forum and it's not a bug report.

  • fisholith - the system 'fps' expression is based on the number of frames over 1 second, and is probably a much less noisy measurement.

  • That's a good point, things have been evolving lately and it would be good to cover it in a blog post. After the next stable release I'll write up all the changes and our new advice on the blog.

  • I don't know what we can do about this - as far as I can tell we use the standard math for HSL adjustments, and this looks like some kind of floating point rounding errors are happening on the GPU. I tried improving the float precision but it didn't have any effect. So I'm afraid this is has to be closed as it's just an artefact of the GPU processing.

  • Closing as this report does not follow the guidelines so it is not actionable.

    Note that the multiplayer engine by design does not send information about which layers objects are on. You must send this information yourself if it is important.

  • If there are a different number of layers on each layout, then it's not possible to preserve the Z order and some objects will be bundled up together on to the same layer. This is by design. You should provide a .capx if you want further input.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct 3 will *not* be coming out soon. It's in our multi-year plan. It's not going to come out tomorrow

    People often ask about sales, but we can't say in advance when we run them. Sometimes people get upset if they buy just before a sale, but then if we announce sales in advance, people will just be upset that they bought just before the sale announcement instead. I don't think there's anything we can do about that.

  • You can display fullscreen in the browser too, which works in Chrome for Android.

  • Actually, C2 is capped at 60 FPS rendered

    That's not true actually - C2 games run at the refresh rate of the display, at least in modern browsers. Also even if on some platform the game is being capped at 60 FPS, it's not C2 doing it, it's the browser engine - we've coded our engine to run at any refresh rate.

    You generally can't get hardware information in a browser. Browser developers are very cagey about giving out hardware details since it improves fingerprinting on the web which has privacy implications. I don't think you actually need to get the refresh rate for what you described though - if you measure the FPS and the system is fast enough, then the FPS will report the refresh rate. You can default your graph to 60, but if the FPS goes over then set a new maximum for the graph. You could even round it up to known common refresh rates like 75, 120 etc.

  • I could create an action queue to handle this so that when the player resumed, all the actions updated one after the other (and it would work) but it would end up slowing the game down as the resumed player waits for all the animations to run through (the player only needs to analyse what is currently on the board in order to make a move).

    I don't see any fundamental reason you have to make the player wait for all the animations. Surely you'd make a catch-up mode which works instantly instead of making them sit and wait?

    IIRC triggers still fire when suspended, so 'On received' etc. should still fire as messages come in. Also you could send messages in 'On suspended' and 'On resumed' to notify players you've gone AFK, so they know they won't be responding.

  • No, as per the guidelines we cannot normally accept bug reports for complete projects anyway, since they are nearly impossible to debug. Try to reproduce the problem in a new project, then you can share it and we actually have a chance of being able to fix it.

  • C2 compiles all shaders the project uses on startup, so I'm afraid it will crash on WP8.1 if the shader is used anywhere in the project.

    I'm not sure there's much point filing a bug report since as far as I can tell it's already fixed (since the latest IE is not affected) - the only problem is the fix hasn't reached WP8.1 since it's on a much slower cycle. So it's just a matter of waiting for the already-fixed code to reach devices.

  • You can give the progress bar an ID (in its properties), so then you could do more advanced styles by using rules like #myprogressbarid::-webkit-progress-value { ... } - but to get that CSS in to the page I think right now you'd need to modify the exported HTML, or use a third party plugin which can write more advanced CSS rules...

  • Please file a bug report following all the guidelines if you want me to investigate.

  • It's really very simple: Construct 2 creates a <progress> element, and 'set css style' sets CSS on that element (as in, it goes on the style attribute of the progress element). That is all!

    I had a quick look and there doesn't appear to be any standardised way to modify some parts of the progress bar, since some browsers implement it via shadow DOM with different internal elements, but I don't think the standard requires that. It's another reason to go with your own composed of objects so you have 100% control over the appearance. The progress bar plugin is intended for apps which want a system or platform styled progress bar which fits with the rest of the apps on the system - so you'd want to keep it the same.