C3 Local Preview (Remote Preview Alternative)

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

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.

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.

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.

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

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.