Ashley's Forum Posts

  • Please see the bug report requirements, we don't want your full project.

    r211 just came out anyway, does it fix the problem?

  • Commercial multiplayer games deploy servers around the world so players are never too far away from a server, which improves the reliability of connections. You can do the same by running your own signalling server in the same country/region as your players.

    Also I can tell you I've played some major commercial titles that had horrible connectivity over the Internet and would regularly kick me off

  • Prominent - it's an option, but it could actually work out slower in some cases. Right now if you zoom in a long way then scroll around, it's just moving around a large texture as if it were a sprite, which is fast. If it cropped the texture area to the size of the screen, then scrolling around will need to keep updating the texture, and texture updates are slow (especially every frame, hence the poor performance when zoomed in a long way in the example in this thread). So really it's just another tradeoff between memory use and performance, and isn't necessarily always better. Also given that it would probably be very tricky to implement that correctly (especially when layer scaling and rotation gets involved!) I'm not sure it's worth the trouble.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The final Visual Studio 2015 RTM version made a few changes to the Windows 10 project format. I've updated the next build to use the latest format, so that should fix it.

  • Huh, interesting - C2 tries to avoid redundantly updating the video image based on the browser's reported decoded frame count, but it seems Chrome now updates the decoded frame count in chunks instead of in real-time, making the video update very choppily. I've removed the usage of the decoded frame count and it fixes it, so should be working in the next build.

  • If the game is in an iframe, I think this bug is already fixed for the next build. Also please ensure all your reports meet the bug report requirements: since you did not provide a .capx, our standard procedure is to close without investigation.

  • Just hold shift to keep the aspect ratio when resizing.

  • It might just be a bug, since the shared runtime is a relatively new feature. As far as I'm aware Intel fully intend to support both options, not force everyone to change. Either way it would be better to get in touch with Intel directly about this.

  • I'd contact Ludei for help - unless you're using a real browser engine, most CocoonJS problems derive from the fact it is not a real browser engine, which is why we don't recommend you use it. (The WebView-based platforms are based on real browsers, though.)

  • No, WebRTC is not extremely buggy, nor is our signalling server unreliable. multiplayer.scirra.com runs on a dedicated server with a 1 gigabit direct connection to the Internet (there is no NAT).

    The problem is the Internet itself is sometimes unreliable. The quality of a connection between two random devices on the Internet is highly variable. If you cannot get a reliable connection to the US-based signalling server, running your own server closer to you is one possible solution, but that's not because WebRTC or our server sucks, it's because sending data over thousands and thousands of miles across the planet's surface is not a perfectly reliable process.

  • A 40x40 image is still tiny. Reducing a 2048x2048 image to 512x512 might bring some benefit (that's 16mb vs. 1mb respectively), but 40x40 is something like 6kb, so probably not something the GPU is going to struggle with!

  • Events are completely suspended when the game is in the background. You probably want to use the Browser object's 'On suspended' and 'On resumed' triggers. If you save the wallclocktime in both, you can figure out how long the game was in the background for, and compensate accordingly.

  • > The problem is when you zoom in it increases the detail of the text by creating a larger texture - the size of the object in screen space...

    >

    Wouldn't make more sense if the texture size was based on the object size in layout coordinates? This would avoid things blowing up.

    Layout co-ordinates don't change as you zoom in. So this would mean as you zoom in to text it becomes blurry or pixellated, instead of increasing detail. It would look the same as putting some text in a Sprite object and zooming in very far.

    I could perhaps add that as an optional mode for the Text object? Something like a 'Upscaling quality' property which can be 'Low' (no detail increase, goes blurry as you zoom in, but uses less memory) or 'High' (as it works now, increases detail but can use lots of memory).

  • You do not have permission to view this post

  • This is to do with the way text is rendered in WebGL mode. Since WebGL provides no features to render text, a text object does the following:

    1. Create a normal 2d canvas.

    2. Render text with the 2d canvas (since that is a capability canvas2d has, but not webgl).

    3. Create a WebGL texture the size of the object.

    4. Paste the 2d canvas in to the texture.

    5. Render the texture like a sprite.

    This is a pretty well optimised process - it only does that when the text changes or its size changes, and the rest of the time it's basically a Sprite. Normally it's also only operating on small rectangles.

    The problem is when you zoom in it increases the detail of the text by creating a larger texture - the size of the object in screen space and rendering larger text (so as large as the object would appear if your monitor were large enough to display it all). If you keep zooming in, you end up creating huge textures. Worse if you are zooming in a bit further every tick, every frame it will run the whole process again, including creating a new texture.

    So this is by-design for high-detail text. The best thing to do would be to use SpriteFonts, or, er, not zoom in on text that far. I guess I could put in a max detail level clamp though so it doesn't explode. I'll leave this bug open for that.