Ashley's Forum Posts

  • I don't understand why you can't have separate objects. Of course it's a lot of text, you just need to break it up in to separate objects, so instead of one object with 100 paragraphs, you have 100 objects with one paragraph, positioned in the right places for appropriate text layout. That will probably be far more performant no matter which object you use, since word and glyph layout and rendering only happens on a paragraph level, not on a novel-length level.

    One other thing to try if you really must have extreme-sized text objects is to disable WebGL mode. Rendering text in WebGL mode requires an intermediate texture which caps you at the device maximum texture size, which is sometimes as low as 2048x2048 and commonly 4096x4096. Rendering text in canvas2d mode can be done directly and the maximum texture size (probably, depending on browser implementation) does not apply. Even so each time you draw text the browser may need to do a full text reflow to calculate word wrapping, kerning etc., so it will still be a significant benefit to break it up in to separate objects.

  • I'm not really prepared to integrate a fairly complex third party javascript library to address a relatively minor use case. I will leave this to third party developers to resolve.

  • Closing as not a bug. Your updated example appears to work correctly. Given the absolutely extraordinary size of the layout, it takes 10-15 seconds for my high-end desktop machine to trace a path. Once it's found the path though, it is calculated correctly and goes to the right place. I'm afraid your gif images of a project I am not familiar with are not much help; from the evidence I see here it is working correctly, just very slowly, due to the extreme scale of the layout.

  • This is very confusing: when I run it in Chrome in r175, I don't see what you've posted screenshots of. I see this:

    Since this does not appear to match any of your images/descriptions, I don't know what to make of it. Also since we did not change any collision/event related code in r174 as far as I can remember or tell from the changelog I am at a loss as to what we could have modified that would have caused any change in behavior here. On top of that the events implement a relatively complex algorithm with function calls, arrays and loops, so it is very difficult to debug.

    To help me have a chance at figuring out what is going on here it would be invaluable if you can:

    1) reproduce the problem without requiring any user input at all, so I can see exactly the setup you have

    2) simplify the events as far as humanly possible while still demonstrating a change in behavior - ideally <5 events

    3) identify the specific event or feature that is now working differently, and explain precisely what the difference between the versions is

  • r174-5 ship node-webkit 0.10.0-rc1, and the next build will ship node-webkit 0.10.1. Hopefully that fixes it. If not contact the node-webkit developers - going back versions is not a long term practical solution since Chrome is always updating and node-webkit is moving forwards with it.

  • Thanks, should be fixed in next build.

  • Can't reproduce, Firefox renders identically to Chrome here. Probably specific to your system or a graphics driver issue, so closing.

  • Closing, project uses third party plugin and it sounds like the report relates to that plugin too.

  • Closing as won't fix, this is just how these browsers render the controls, there's nothing we can do about that.

  • There is not much we can do about this, nothing in C2's engine has anything to do with input delays - it would happen at the browser or OS level. The next build updates to node-webkit 0.10.1 so hopefully that fixes it, but if not, please report the issue to the node-webkit developers.

  • Closing as won't fix. Modifying the size every tick causes the engine to have to destroy and re-create the physics body every frame, which probably is what prevents forces acting on it properly. I'm afraid this is just the kind of thing you can't do with a physics engine.

  • I think this is a known issue with Chrome breaking connections with the preview server. I'm not sure there's much we can do about it. Have you tested r175?

  • Could you post this to the Ejecta developers? I think the first warning is ignorable and the second issue with recognising fonts is solved if Ejecta is more tolerant of the font names it accepts. This is the same code we export to all platforms after all.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If there is no freeze in r175, then closing as fixed. If the framerate is lower then please check blacklisting (in chrome://gpu) to verify that is not the cause, and post a new issue to the node-webkit developers if you still think there is a problem.