C3 Local Preview (Remote Preview Alternative)

From the Asset Store
Template for an alternative to falling shapes, fully documented in comments and video
  • Hi,

    Mikal and me we have been working on a "C3 Local Preview" like we use to have on C2 >>>Preview over wifi.

    This is especially for users that have a problem with the "C3 Remote Preview" loading super slow when you preview on Mobiles or Testing Multiplayer etc........

    Will be nice to have something native integrated on C3 but 3 years passed already and there is no sign that will be implemented any time soon, so here is an alternative, works pretty good and it's easy to install.

    Download Zip:

    https://www.dropbox.com/s/u1cg22njohi7e7g/local_preview.zip?dl=0

    ==========================================================================

    Here are some BenchMarks:

    same Capx tested on all of the BenchMarks: 32MB capx size tested on iPhone6

    C3 Remote Preview = 9 Minutes https://www.dropbox.com/s/3gec9ullndon4ot/C3%20Test3%20%28iPhone6%20iOS%2012.3.1%29.mp4?dl=0

    ======================

    C2 Preview over wifi = 37 secs

    dropbox.com/s/ca9c0dkeqn7aguj/C2%20Test%20Preview.mp4

    ==========================

    C3 Local Preview = 9 Secs

    https://www.dropbox.com/s/a257mmkf7dh7shh/c3%20local%20preview%2032mb%20test%20.avi?dl=0

    9 secs for this C3 local Preview it's Awesome after tree years I never loaded less than 7 min in my iPhone 6 using C3 remote preview not even once.

    If you have any problems please let us know

    ===========================

    Instructions are inside

    If The C3 Local Preview works better for you consider to vote to have it Native here

    https://construct3.ideas.aha.io/ideas/C3-I-618

    Enjoy having fun

  • As I've said before, remote preview should be very fast so long as it can establish a LAN connection. I just tried Space Blaster over remote preview and it loaded in 3 seconds for me.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • As I've said before, remote preview should be very fast so long as it can establish a LAN connection. I just tried Space Blaster over remote preview and it loaded in 3 seconds for me.

    It looks like it doesn't work the same for everyone, I and some other users reported that we have this problem for a long time, I don't know what could be the problem but I been tree years+ trying to resolve it but I couldn't.

    One thing I know for sure its that the Local Preview it never fails, for example, you mention "Space Blaster" that it takes you 3 seconds but here is my test on an iPhone6

    "Space Blaster" is 5mb only after exported to HTML

    C3 Remote Preview: 1.20 minutes https://www.dropbox.com/s/q7p0ruqom4dirjr/space%20blaster%20remote%20preview.mp4?dl=0

    C3 Local Preview: 4 seconds

    https://www.dropbox.com/s/91ahnvo5hhsunqi/space%20blaster%20local%20preview.mkv?dl=0

    ==========================

    "Demonoire" is 7mb only after exported to HTML

    C3 Remote Preview: 2 minutes

    https://www.dropbox.com/s/elyfd8ft4vzsucd/demonoire%20remote%20preview.mp4?dl=0

    C3 Local Preview: 6 seconds

    https://www.dropbox.com/s/9uaa7dfbpkgyg6u/demonoire%20local%20preview.mkv?dl=0

    =================================

    There is a big difference between (Remote Preview & Local Preview) not sure why it will work for some fast and some not

  • Ashley

    As I've said before, remote preview should be very fast so long as it can establish a LAN connection. I just tried Space Blaster over remote preview and it loaded in 3 seconds for me.

    tarek2 and Mikal are right, we do encounter the slow loading, even on stable LAN connections. We have discussed this in Discord for quite a few times now. It seems that a project that is not light, something that is not as simple as Space Blaster will not load fast enough.

    Trying for multiplayer games are even worse, Remote Preview takes so long to load that if you open 10 windows at the same time, a project of 50mb for example. 7 to 8 instance windows will disconnect.

    Their solution works great, and we are just thankful they have a workaround, until this is solved.

  • I love C3’s remote preview, especially the video feature. It’s really well thought out. But yesterday, it took my large scale project around 20 minutes for someone to load it, getting especially sluggish at “loading textures”. This isn’t going to replace it for that use case, but good initiative!

  • There's a big difference between Remote Preview to someone else over the Internet, and remote preview over your local area network (LAN). Over the Internet may well be slow, since it will be limited by your upload speed. Over a LAN, it should be super fast, since the devices can communicate locally at a very high bandwidth.

    I have no idea why a LAN would be slow as some people describe though. As I said I have what is probably a typical home wifi setup and it's really fast. Maybe it's routing everything over the Internet for some reason, even though the devices are local. I don't know why that would happen though.

    Time is by far our most limited resource and these features are difficult to implement and hard work to maintain. I really don't want to have to do loads of work to implement a sort of "Remote Preview 2" feature just because we don't understand why some LANs seem to be slow. I would much rather figure out precisely what the problem is, and what else can be done about it. For example perhaps there is some network setting that can be changed and makes everything super fast again. If that's the case it provides a workaround in case Remote Preview is slow, and we can document that and point anyone having trouble to a guide. Also the results people state with C2's preview-over-wifi suggests that fast speeds over LAN is possible, so there may be something that can be done to reach that speed in C3 too.

    Another risk of not understanding the problem is we could end up doing loads of work for "Remote Preview 2", and then it's still slow! How do we know that won't happen if we don't know what the problem is in the first place? That's why it's essential to start by working out what the actual problem is for some people.

  • Ashley Agree with your point of view. Along the lines of debugging the issue for some folks (and for me intermittently), can you please help us with hints for debugging on our systems (since you do not see it on your side.)

    Can you give us a _brief_ description about how C3 Remote preview determines whether it can serve over LAN or if it requires another method? What does it check for? Is there something we can look for in Chrome network traffic on client or editor to check for what could be causing LAN not to be used?

    Can you describe the initial process a little so we can get some ideas about where to look (Chrome settings, wifi setting, local dev PC firewall, etc.)

    Looking at some of the code, it looks like the client starts with loadings some initial pages from a C3 server (preview.construct.net), I also see connections to a C3 signaling server and setting up a websocket to editor from client (for messages like reload, etc.) I am sure this is all jumbled, since I am just scanning code and it could happen after the path has already been determined.

  • It's a peer-to-peer connection done with WebRTC DataChannels, much like the multiplayer feature. However all the connection details are handled by the browser and it's not an area I know a huge amount about the internals of, so it's difficult to comment further. Our role is largely just the signalling server. Both sides generate some connection info about how they can be reached, our signalling server merely swaps those so each side gets the other's connection info, and then it tries to establish a connection.

    This is different to the HTTP server model used by Construct 2, which is more of a client-server model so in that sense is probably simpler. But you can't run a HTTP server in the browser - which is why Construct 3 does it differently. Also the HTTP server model had its own issues - sometimes you had to configure the firewall; sometimes you had to try a different port; sometimes you needed admin permission (which in some cases you can't get); some people had an altered system "hosts" file which broke it; sometimes Windows would just return a mysterious error code and refuse to work, for reasons we never figured out. So that was never a perfect option either. As with most things in technology, any particular solution has a series of tradeoffs, and other solutions have different tradeoffs and aren't always clearly all better or all worse. I like Remote Preview because it's convenient with the QR code, doesn't need any specific configuration, and works over both local networks and the open Internet. But I guess the connection speed is not always perfect.

    One potential workaround is if a HTTP server really is much faster, you can host your own local HTTP server using tools like nginx, caddy, python or node. It requires a bit of technical set up, but then you have a folder you can do a HTML5 export to which you can load on your phone from your PC's local HTTP server. (Edit: I realise that the original post pretty much does exactly this! So you're ahead of me on that one.) Then to make that work more smoothly we could explore a feature like "quick export" which just does a default settings HTML5 export to a local folder (which we can directly write to with the new native file system API in Chrome). This is the kind of thing which despite not being ideal and still taking some work to put together, is still far less work than coming up with an entire "Remote Preview 2" type feature.

  • Thank you Rory for your feedback I appreciate it )))

    Ashley

    That sounds good to me as long the solution it can be found I don't mind either to fix the existing Remote Preview or to add a second alternative, I normally been requesting the Local preview like the Mikal and I did because that is the most secure as it guarantees that the connections are stabilised and Fast always, but I wouldn't mind either if the current Remote Preview gets fixed. I can offer myself for helping on to diagnostic whats is the problem with the current Remote preview if you need help.

  • One potential workaround is if a HTTP server really is much faster, you can host your own local HTTP server using tools like nginx, caddy, python or node. It requires a bit of technical set up, but then you have a folder you can do a HTML5 export to which you can load on your phone from your PC's local HTTP server. (Edit: I realise that the original post pretty much does exactly this! So you're ahead of me on that one.) Then to make that work more smoothly we could explore a feature like "quick export" which just does a default settings HTML5 export to a local folder (which we can directly write to with the new native file system API in Chrome). This is the kind of thing which despite not being ideal and still taking some work to put together, is still far less work than coming up with an entire "Remote Preview 2" type feature.

    That sounds like a really good idea, it's exactly what we did but using browsersync.io to create the Server but it will be nice if a similar thing can be integrated native from c3 as you say, plus adding the quick export HTML that will be Awesome!

    Thanks very much for looking into this issue

  • Thanks Ashley! I will also keep looking to see if I can see errors or configuration changes on my dev environment when the non LAN C3 Remote connection appears again for me (I know for others it happens all the time.) Looking at the details of the C3 remote scheme, it's very clever and definitely has good value when it's working (e.g. video preview, stats, host update status, etc.)

    In the meantime, the native quick export of html to a local folder would be very helpful. The one request there is to have the UI save the folder used, so that it will be quick to export another version once the correct folder is targeted. Also whatever behavior you think is best in terms of removing the original files or overwriting the existing files.

  • Thanks Ashley! I will also keep looking to see if I can see errors or configuration changes on my dev environment when the non LAN C3 Remote connection appears again for me (I know for others it happens all the time.) Looking at the details of the C3 remote scheme, it's very clever and definitely has good value when it's working (e.g. video preview, stats, host update status, etc.)

    In the meantime, the native quick export of html to a local folder would be very helpful. The one request there is to have the UI save the folder used, so that it will be quick to export another version once the correct folder is targeted. Also whatever behavior you think is best in terms of removing the original files or overwriting the existing files.

    +1

    Also for the best results if it can export the HTML Unzipped that will lessen the job we have to do after the export

    Not sure if it was already gonna do that but I will mention it just in case

    Thanks

  • Did a little debug.

    A wild guess is that the icecandidates being exchanged through the signalling server are not properly presenting or choosing the right candidates, instead of choosing a local server on the internal network, the 'external' network connection is being used.

    Currently mine is working now directly from LAN, again wild guess, the network costs are all the same, I wonder if the 'external' candidate interfaces should be lower than the internal LAN, so it's chosen if available (but I'm not sure how the client knows that one should be chosen.)

    This is messages from the C3 editor side connecting with the signal server then exchanging candidates with the client (another PC running the preview client.)

  • What Mikal says it's my number one suspicion also,

    I have the feeling that maybe C3 Picks the wrong IP to use when it detects more than one IP.

    I have this issue also with the "Browsersync" that we use when I start the server it detects two IP addresses, one is the good one and the other one is the one that is reserved for the VM when it's in use but for me is not a problem because I open the URL with the correct one using the right IP manually I don't use the one that "Browsersync" gives me.

    Example:

    Browsersync shows me on the Command Prompt that my external IP is

    187.134.1.4 so the URL is like this 187.134.1.4

    But that is the wrong IP because it's for the VM, so I have to adjust it manually with my right IP like this 196.467.1.2

    If c3 Remote Preview chooses automatically our IP that could be one of the problems.

    It could be easily checked if this is the case if we had on C3 Settings the option to add our IP manually to be used for C3 Remote Preview as we do on C2.

  • One idea in the near term is to add some debug console logging to one of the C3 beta releases, so different users with different setups can report the IP addresses that being suggested or used, so we can see if the correct local addresses are available and why not (e.g. tarek2's VM scenario with multiple network adapters, virtual and physical.)

    So, for example the candidates ip / addresses (I know some are also obfuscated, but can unobfuscate with a chrome setting on PCs at least.)

    I also run a VM (Parallels on Mac), but only have intermittent problems, but that's a commonality with tarek2.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)