I am having a problem with my unity build when targeting the Universal Windows Platform. The game runs perfectly (200+ FPS) on the regular x64 Windows build, but as soon as I run the build through the App packages or Visual Studio for UWP, I get only around 30 FPS with studders as well.
At first I thought it was a VSYNC issues, but the studdering makes me think otherwise, as well as the setting not being set in the graphics settings.
When I run the build on Xbox One with the app package, the system performance is the same as on PC, 30 FPS and some studdering. The system profiler on the Xbox One is saying that File I/O is causing some problems, so possiblly garbage collection?
As far as garbage collection goes, the worst thing that I would be doing is setting game objects as inactive/active through an object pool.
Any clues as to why the performance is so bad only on one platform? Or optimization tips for UWP specific?
Related
I am trying to make an Android app in Unity that uses some heavy computation, when I tried to publish it to the google developer console I got an error "This release is not compliant with the Google Play 64-bit requirement"
After some digging around I found that I need to change the Scripting Backend to IL2CPP Instead of Mono and un-select x86
Now Google lets me publish the app, but when I build and run it on my phone it is significantly slower, should I be worried about this? If so is there any way to fix this? (when I change Scripting Backend back to Mono and build and run the app doesn't lag any more when it's running, perhaps there are some different settings that I need to use?)
What I read so far was that the Scripting Backend IL2CPP is supposed to be faster as far as when the app is run, but at least on my phone this doesn't seem to be the case
The phone I'm using to test this is a ZTE Blade, Model number Z965 (I think it's called ZTE Blade X but I'm not sure)in case that's useful
I (might have) found the reason for the lag from this post:
https://forum.unity.com/threads/huge-fps-drops-from-60fps-armv7-to-25-30-fps-arm64-unity-2017-4-20.682018/
It seems that any logging operations take a long time using the ARM64 architecture(I ran the app using the ARMv7 and ARM64 architecture and the ARMv7 didn't lag that much) now that I changed every logging setting to "none" the app seems to run more smoothly(anyway at least I hope that was the only problem)
I am using a remote desktop having configured Win 8.1, 3gb ram DDR2, 15gb HDD free space, latest Xamarin Studio Starter version with api 21 packages. When I try to debug a simple "Hello World" solution on studio, the manually created AVD loads too slow, even android home screen does not appear after 1 hour. What should I do to speed up the process ?
I don't know if your IDE supports it but you should really try out Genymotion, it changed my development time and testing significantly.
https://www.genymotion.com/
Considering your configuration, 1 hour is too much, try restarting first.
If not go for your Android device(physical), I debug on my mobile(you don't have to wait for your mobile to start).
You Can also go for Genymotion . Many find difficulty in genymotion setup. it is pretty simple though, follow this video If you'll understand once about VirtualBox and IP, it'll be easy for next time
I would recommend 6GB Ram and i5 processor for performance lag problem. So if it is possible, you should upgrade your machine.
Thanks for your responses. Finally I have resolved the issue by creating a low resolution Android Virtual Device (Nexus One) by Xamarin Studio.
But another problem arises, the published apk file is too large.Which steps need to be done to make it perfect ?
You should try the Xamarin Android Player. In my experience it's the fastest option over Genymotion and Android's AVD images even with Intel's HAXM installed.
https://www.xamarin.com/android-player
This issue is getting real tiresome and I've been spending atleast 2 days looking around for an answer. Basically, I want to publish a game, and I've hired a friend of mine to test it out before I officially release it. Whenever he runs it, reports as "nothing happends".
These conditions are met:
He has installed the .NET Framework 4.0 and the XNA Redistributable 4.0 (he most likely also has installed other .NET Frameworks and XNA Frameworks as well, because nothing worked).
The game is compiled onto a Release build.
GamerService referenced is removed.
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
So, what's going on? I'm clueless.. I even put a MessageBox.Show(); after the execution of my game in my Program.cs file via try/catch, and no results.
Are there any extreme conditions in my code that I need to meet?
Any site describing 100% of all requirements to run an XNA game and the most proper way to build it?
Any issues when using non-distributable "developer tools" in XNA coding? If so, what includes in these "developer tools", and what do I need to modify? (I noticed that on another thread).
An answer to this issue would more than make my day...
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution, and various other random errors such as missing files when they clearly are there.
Thank you greatly!
In summary I think your app wont run on Windows 8, let me explain:
Windows 8
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
Officially, desktop games using unmodified Microsoft XNA 4/is not supported on Windows 8 in any form:
Microsoft officials have said the XNA tools/runtime environment used primarily by game developers isn't supported on Windows 8. - Read more...
Redistributables
Any issues when using non-distributable "developer tools" in XNA coding?
That depends on whether they are required at runtime on the target machine. That might sound like an oxymoron but in Windows c/c++, I can have an app that depends on Microsoft DLLs but we are not allowed to deploy the DLLs, one must depend on it being present in the OS; service pack or some other form. Is there something you are missing?
Windows 7
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution
This is more interesting and I suspect is one of the more testable aspects of your application (also that it is not Windows 8). I suggest you setup a remote-debug session to your Win7 VM or if that is not possible, use Debug.WriteLine() or equivalent displaying critical state contents.
I'm planning to benchmark the graphical performance of the Unity engine on Android.
To do that I want my application to run without any fps-limits. The problem is that I have possible encountered such a limit when using the Unity engine.
I think that Unity is somehow limiting the framerate because I've been able to run native benchmarks on my device with well above 100fps whereas an empty Unity app can't get beyond 60fps.
I have already tried setting Application.targetFrameRate to -1 and setting the project-quality settings to "Fastest". Setting the quality settings to the fastest settings should have disabled VSync which in my experience often caused a 60fps limit.
Thanks in advance
We have a near complete application, and are trying to squeeze under the 50MB download limit for Google Play.
When inspecting our APK to try to find ways to drop our file size, I noticed the lib\x86, lib\armeabi, and lib\armeabi-v7a directories that are described here. They correspond to the 'Supported architecture' option in project options of a Mono for Android project.
If I remove x86, I save around 1.1 MB on our APK size. (This is almost enough to get us under 50MB)
What are the drawbacks for removing x86?
Will my APK still run on x86 devices?
Is there any substantial market share on Google Play for x86 devices?
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
Note that the following answers are for general Android development and do not reflect anything specific to Mono:
What are the drawbacks for removing x86?
Your app will not run on x86 devices. Intel may cry.
Will my APK still run on x86 devices?
No.
Is there any substantial market share on Google Play for x86 devices?
IMHO, not presently. A few handsets were released in 2012 that are Intel-powered (e.g., Motorola RAZR i), and the first generation of Google TV devices were powered by Intel CPUs. But Google TV has switched to ARM, and it will be some time before Intel CPUs make up a substantial portion of the Android device ecosystem (again IMHO).
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
It should. If not, the Play Store has serious issues. While I have a RAZR i sitting here, I don't off the top of my head know an app that uses native code that does not ship with x86, to see if the app in question is indeed filtered out of the Play Store.
are trying to squeeze under the 50MB download limit for Google Play
If a 1.1MB savings "is almost enough to get [you] under 50MB", you are already in trouble. Apps tend to grow, not shrink, over time. If you expect that you will be able to switch to some other distribution architecture (e.g., use APK expansion files) eventually and just need a short-term stop-gap solution, cutting x86 may be OK. But you really need to have a plan for dealing with app size growth that takes you back over the 50MB barrier, and you may be better served addressing that now rather than shipping something and finding yourself painted into a corner as a result.