I am working on a multiplayer game for WebGL platform and i am using (http://lockstep.io/ - SocketIo & node.js server ) for handling the game.
I am facing these issues as shown in the attached image.
I have no idea about what these errors state?
I don't think that the issue is from my coding side as my multiplayer game runs perfectly in standalone builds with more than 4 instances of the standalone build.
But it does not even open in my WebGL build.
Does WebGL does not support threading??
Please guide. What are these errors all about? Can these issues be solved?? or Do i have to change my whole project implementation?
Unity WebGl does not support Multithreading. Although Unity is working hard to bring Thread support in WebGL.
Do not compare standalone with WebGL because many features are not supported in WebGL. Looking at the error, it says something about Thread and that could definitely be the problem. About 90% chances it is the problem.
You cannot solve this problem right now unless you remove the use of SocketIo.
I don't know how SocketIo is implemented so I can't tell you if Thread is the only problem it has but if it uses other API's not supported in WebGL, then you will still have problems.
The only known network API that is made and optimized to work with WebGL is the new Unity web API called UnityWebRequest. You have to modify your code to use that. The link I provided provides many examples needed to get started with it.
if you use anything like webrequestm System.web or socket, WebGL will crash. UnityWebRequest is the only solution. It is faster than WWW and you need Unity 5.2 and above to use it.
Related
I'm currently trying to get an Angular-Nativescript-OpenGl-App runnning. See: https://github.com/Franziskus1988/nativescript-opengl.
Unfortunately it only works when I use native Java for the OpenGL rendering part (GLSurfaceView.Renderer).
Can somebody help me to get this running in "plain" NativeScript.
As you might already know there is a open feature request, register your vote on the issue and hopefully they will pick it up soon when more people show interest towards the feature.
The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3
I understand that any components library that depends on window or document cannot be used while we pre-render an angular app.
Does this mean it is practically not possible to pre-render an app without writing our own components library and making it somehow not dependent on window? if there was an amicable way of doing it, people would have already done it, right ?
this begs the question what strategies people have followed while successfully pre-rendering an angular app and also using an external components library ? if there is no way of doing that, are people using pre-rendering without any such library in prod ?
I have gone through all the possible solutions to make angular material work with aspnetcore 2.0 pre-rendering and none of them has worked, eg: angular-ssr
Any kind of strategy advice is hugely appreciated, this makes me also wonder if pre-rendering is such a pain in angular and very important for the business side of an app, using react is a better strategy ?
I've been working on a React Native app on an Android tablet for my current contract and it's now going through its Alpha phase. For the most part it's working very well, it's responsive, performant, and mostly stable.
There's one issue that keeps occurring though which I'm having trouble tracking down. It seems very random since I've seen it happen on nearly every screen in the app all at times.
When transitioning to a new screen, I just get a blank white screen. Seems like the javascript just doesn't get loaded and the UI never loads. This happens in both our debug dev versions, and our bundled release versions.
Some things to note about the architecture
Android 6.0
React 15.4.1
React Native 0.39
Flux 3.1.0
I know this isn't a lot to go on so I'm mostly looking for people that may have experienced this problem (that wasn't related to the development server issues) and what they had found as a cause in their app. Hoping to get some suggestions of what to look at or possibly how to even troubleshoot what's causing this.
Oh one other thing, If I background the app when a white screen happens, then select the app from my running apps list, the screen loads just fine and I'm able to continue using the app as if nothing happened.
Sorry for the vagueness here but I'm really at a loss and looking for any kind of suggestions.
Thanks!
Regarding to the immature situation and the somewhat bright feature of WebGL, I decide to use it to build an online application. For those users who have Firefox 4 or Chrome, there is no problem. But what should I do for the users of Firefox 3.* or even IE 6, 7, etc.?
So I'd like to ask that if there is any possible to write a plugin/addon. And when my codes detect the incompatibility, it can alert the user to download/install this extra component to enable them using the WebGL contents.
I noticed that nearly all instructions of WebGL only ask you to install the new, modern browsers to access WebGL contents, but none of them tell you how to handle the old browsers. Will there be a way for the survival of old school browsers?
Thanks very much.
As far as IE goes you should be able to use google chrome frame when webgl hits chrome(you can already hack it to get it working). And since you don't need admin rights to install it anymore it shouldn't be that much of a hurdle. As far as FF3 goes, I don't think that's much
of a long term issue, FF users are sensible and upgrade ;-)
To the best of my knowledge there is no easy answer to this.
If you want to write WebGL code that - without change - will also run on old browsers, then I can only think of Google's O3D project. Here you won't be directly writing WebGL code though. O3D is being implemented on top of WebGL, but its previous implementation was plugin based. So you can write your game or 3D app in O3D and prompt your users with old browser to install the plugin.
A much harder solution that I implement in my project 3DTin, is when WebGL is not available I do some 3D math in software and render it on Canvas 2D. It works if your 3D app is not very complicated. My app runs on all major browsers, including IE 7,8 with the help of excanvas. However this approach is not an option if your 3D scenes are complicated. You may want to look at following 3D javascript libraries that render on top of Canvas 2D:
pre3d
three.js