I have sucessfully used Farseer to develop one of my game using XNA. The game runs like a charm in Windows and WP7. I'm currently working on porting my game in IOS using Monotouch and Monogame. I've sucessfully compiled and used Farseer also over the first version of my game ported over Monotouch and Monogame. All works fine except for performances. The game runs much more slower on the iPhone device. I did some code investigations and it seems that the major bottleneck is Farseer. It become really slow when it has to manage more then 5-6 bodies with a single fixture attached (circle).
Reading the documentation I noticed that to tune Farseer I could change values from the Setting static class:
Performance
In order to get the most out of the engine, you should try and follow the guidelines below:
Enable sleeping
Sleeping enables you to have large number of bodies in the world. It can also increase the stability of the engine since small movements in a stack of bodies don’t spread in the stack. A sleeping body has little overhead, so enabling it is recommended.
Disable CCD
Continuous Collision Detection prevents tunneling but at the cost of performance. If you don’t have problems with tunneling, you should disable CCD all together.
Minimize the number of position and velocity iterations
A high number of iterations makes the engine more stable at the cost of performance. You should tweak the values to fit your game.
The bad news is that if I change any value of that class, nothing seems to happen. I tried to change values as follow:
EnableDiagnostics = false
VelocityIterations = 6
PositionIterations = 2
ContinuousPhysics = false
I tried also with lower values like VelocityIterations = 1 but nothing seems to change....
Anyone have already changed Settings class values to improve performances?
Ok,
I have managed this. The major bottlenek was not related to Farseer. Once I solved all performance issues related to my "bad code", tuning Farseer like described above works very well to gain 5-10% of performances.
My game is written in XNA, ported to iOS an Android with monotouch and mono4android sucessfully.
Related
we're using the HoloLens 2 and Azure world anchors to place the content within a room but when viewing the app content the anchors/room are spun 90% or 180% from where they should be. They are always square on and never diagonal, so it's like the room is being flipped.
We’re confident it's not the code, as we've successfully used it in multiple other locations, it just this one room we can't get it to work in.
To ensure it’s not our code we’ve tried rebuilding the app, as well as ensuring we’re on the latest versions of Unity and MRTK. The HoloLens 2 firmware are also up-to-date and we’ve also tried adding a delay to the code, just in case the network's too fast and it needs some latency to do it’s thing but none of this has helped.
Additionally, the anchors stick in a position for 5-20mins, then will move to a new position - so occasionally they seem to be working but even a broken clock is right twice a day!
There’s no consistency across headsets either and the anchors will be a different position for each one. The app and code is rock solid in all other locations and we've tested placing the content on another wifi network and the same wifi network but another location and all works as it should. We've tried removing all and nearby holograms to refresh the spatial map but this doesn't cure the issue. We've also tried making the room less complex as well as more complex but again this doesn't fix things and if it does it's only temporary.
Our gut feeling is it’s something out of our control, such as wifi points throwing it out of whack, or interference of some kind such as magnetic or radio etc. If it's useful or relevant we also use Photon to facilitate a shared experience across devices.
Any suggestions much appreciated!
I want to debug which part that consume most of mono memory in Unity because what I saw from profiler is only a chunk said "Mono" something like that and do not know what it is.
I have already done the texture observe in Unity profiler and I do not have a problem with it. (I stated that I used it and saw only mono chunk with high memory) The problem is there must be some kind of memory leak not memory spike because if I play the game long enough, my Galaxy Grand Duo will crash with black texture which is memory used too much. If I saw it in the profiler, it said ManagedHeap and Mono Domain only with large chunk of memory after play the game multiple times.
More information about which platform you are developing for, which tools you are already using, and the reason you are profiling your memory to begin with would be helpful. Without that information I can only suggest the following ...
1) Unity Memory Profiler
I would recommend starting with the memory profiling tools included with the Unity3D editor. You can find out more about these tools here: http://docs.unity3d.com/Manual/ProfilerMemory.html
It sounds like you are already doing this since you have narrowed it down the the "Mono" item from the profiler. This is good, you now know that it is one of your scripts that is consuming the memory.
Make sure you are using the Advanced View. The advanced view of the Unity Profiler will give you more information about which scripts are utilizing your memory.
2) Textures
When it comes to Unity and memory I always start with the textures. It seems like every time I do something with dynamic loading or modifying of textures I end up creating a memory leak. Take a look at your scripts, particularly any that load textures, and try temporarily disabling this logic. Does it help your memory issue?
3) Observe and Optimize
If you aren't able to locate any scripts that seem like they could be causing an issue, I would try observing your game and locating the point where you see your memory spike. Try to identify what logic is running at this point in time. Disable individual scripts and run your scene again. Did this reduce the memory usage? Repeat this process until you locate the script or scripts responsible for your spike. Once you find these scripts you can try re-factoring them until you get the results you are looking for.
I am having issues with the Depth callbacks (in Unity) consistently populating with data. It seems somewhat random as I start and stop and restart my application. I'm utilizing the Pose (position) updates as well as the Depth updates. (For the "RoomScanner for Project Tango" app on the play store)
Is there a recommended way to be "closing" or "killing" the apps within the Unity C# code that will produce better/more consistent behaviour with the Depth stack?
I'm getting "bad" returns approximately 60% of the time I run/launch my app for the Depth data, though the Pose data is happy. I've made great progress with my code, but am very hesitant to publish this version to the play store with it being so unstable.
Suggestions? Did I miss something in the Unity/Tango Walkthroughs?
There was actually a regression in the unitypackage, it has been fixed. Try download and re-import the package again.
are you using an area definition file ? If so, if the environment doesn't match, pose stops returning results - the callback is fine, you just aren't getting any - see this question Tango Pose Pair Base
A game I"m working on has several XML files it uses to manage sprite animations. Currently when I create an instance of a sprite I load it up into an XDocument once and keep it in a cache so that if I need to load it again I can just grab what is arlready in memory.
I do this very often in-game as I create animated sprites and such, going through its definitions like so:
var definitions = doc.Document.Descendants(name);
foreach (var animationDefinition in definitions)
So my question is, is this acceptable on a mobile phone? Say iPhone 3GS/iPhone 4/Windows Phone 7/Android? I use MonoTouch in ANdroid and iPhone while WP7 has its own .Net running.
The reason I ask is currently I don't load that many animated sprites up but as I do more and more I'm worried it will start hurting performance. I figure it might be best to change my design ideas now than wait to suffer at a later date.
Thanks for any help!
I would simply test what's faster (reading it again an again using a SAXParser or storing it in Memory using DOM).
Maybe it also makes sense to save the read data from your XML-File in something like an Array/Vector/Class so you don't need to parse the XML File over and over again.
Well in essentially what you are trying to ask is how many is "too many". I would suggest to find a "practical" limit considering performance, you just need to recursively increase the number of sprites and notice when the application slows down. Keep a safety factor of say 1.5 to 3. And there you know. Again you need to consider how many sprites do you have in all to begin with. If all can possibly be kept in memory respect all other specifications, then go for it. Customer's won't mind a slightly longer loading time for games, as long as it is smooth inside. Else just test stuff out.
I've just started playing around with opengl es on the iphone the past couple of weeks and i'm looking at refactoring some of my code to use Vertex Buffer Objects(VBO). Before I do though I would like to make sure it'll be worth it. The problem is that afaik the only reason you create VBO's is to shift a chunk of data onto the graphics card so that it doesn't need to be retrieved from system ram when it's used. The iPhone however does not have any dedicated ram that I'm aware of so i'm struggling to see why I would benefit at all from using VBO's. I have seen talk around the internet with conflicting opinions and apple certainly want dev's to use it so there's probably still a reason to use them but just wanted to see if anyone on SO had an opinion to add.
I saw no performance improvement on an iPhone 3G. I moved a bunch of stuff to VBOs, but eventually backed it out as it made it more difficult for me to pursue other performance gains. It's not the quick 25% performance increase that I was hoping for.
I've read somewhere that it can make a difference on the newer hardware (3GS), but I don't have references to back that up.
It depends. (sorry).
Rob didn't see an improvement for his setup, but here is an interesting post that did see a large improvement.
The main reason to existence of VBO's is the presence of static data on 3D models. The first bottleneck you encounter is the slowness of copying data to video memory (by using the unavailable glBegin/glEnd block or glVertexPointer, glBufferData and friends).
Let's imagine the old "flying toaster" screensaver. All toasts are static (changing only the position) - why waste resources copying them every frame from CPU's memory to GPU's? Copy it once with buffers and draw it with a single command. And, depending on how you do animations, even the animated toasters can be described in a static fashion.
My first 2D game I started without VBOs. When I changed to VBOs, no difference (like Rob). But, when I refactored to use more static buffers, FPS gone from 20 to 40. Since my goal was to reach 30, I was satisfied. I had some ideas to refactor even more, leaving everything static, but I don't have time now (game is on review, next one to come).