I made a simple 2D game and it works good until I build it.
In editor the game runs without any problems but when I start the .exe I've build my CPU load reaches 100% and I see a lot of lags. I've build it for Windows with x86_64 and x86 and in both builds have this issue.
Any idea why the build is extremely more laggy than in the editor and how I can fix it?
So my problem is solved.
After some testing I saw that my framerate is extremely high and fluctuating.
Trying to limit it with VSync nor with targetFramerate worked.
After updating from 2019.2.5f1 to 2019.2.6f1 the problem was solved.
Related
So I ran into the dreaded 'unfortunately....has stopped working' issue where art loads 2 classes and the debugger promptly tanks out - see this
So, in utter desperation, I switched from ART to Dalvik, half dreading a long session with ADB if the tablet got sour about the switch. Seemed to work. Tango works, albeit with a whole new set of head scratchers (flakier about getting XyzIj, flash is running, surface binding working, hell I can see the camera flashes in the surface showing the camera view - and if I try again and again, I do get tango point data :-)
Can I assume all the tango issues are of my own doing and keep using Dalvik, or must I switch back to ART and try to do all of my debugging through logcat ?
The answer to the question in title: Can we use Dalvik with Tango?
You should always use ART instead of Delvik on Tango, Delvik will work but NOT stable on Tango device, it might cause the issue you experienced like depth out-of-sync.
Same problem here,
What helps is switching to Dalvik for debugging non tango-related issues, but this really slows development process down, as all apps have to be optimized for each switch between debugging and testing session.
I used to have the ability to inspect shaders in Visual Studio 2012, but now I've lost it. The UI doesn't actually crash, but the modeless popup message saying "This may take a few minutes" never bears fruit. I found a post at another site claiming that installing VS2012 Update 3 fixed the problem, but that hasn't helped in my case.
Back when using Pix was an option, I found that rendering outside of a BeginPaint() / EndPaint() pair for speed would cause debugging issues, but again that hasn't been the issue this time.
More info: There is a warning message initially, "Debugging information for 'YourApp.exe' cannot be found or does not match. No native symbols in symbol file". This is as I'd expect, as the main app is managed, with the DirectX work being handled via an unmanaged engine DLL that loads slightly later (once I know what bit version to use).
Tombola, I'm a developer on the Graphics Debugger in Visual Studio. As you've seen 2013 preview added some big stability and scaling improvements to the Graphics Debugger. What you were probably seeing before was a playback engine crash while attempting to start shader debugging. The Graphics Debugger tool shipped with some stability issues in VS 2012, but since then Update 2 and now VS2013 (RTM should also improve quite a bit over preview) have helped this issues greatly.
Have you tried debugging the first draw call in the frame?
The further down the frame, the more DirectX calls that are made before the shader executes, the longer the debugger takes to start; it can take a really long time for a complex scene.
If even the first draw call fails to start debugging, perhaps try commenting out code to reduce the number of API calls and see if there is a particular operation which causes the problem.
It turns out that VS2013 preview can debug all the shaders in VS2012 .vsglog files without difficulty (nb. express build lacks auto and watch windows for shaders). This requires Windows 8.1 preview of course. Setting these two up inside a dedicated virtual machine for safety costs about 8 gig (32 bit, VirtualBox).
I am experiencing the exact same issue as this fellow, and cant seem to find any real solutions to the issue. The only solution I've been able to find so far that works it not maximizing VS. Keeping VS in windowed mode fixes the problem completely, but as soon as it returns to maximized state UI elements no longer redraw unless the stale area is put under new active focus. This makes it impossible to develop and I'm forced to return to windowed mode. I've tried disabling hardware acceleration with no luck. Any Ideas?
There are a handful of feedback reports at connect.microsoft.com that describe a similar problem. But none that ever evolved to a solution, most typically the programmer that filed the report stopped responding when asked to provide additional diagnostics.
Clearly this is an environmental problem, something is wrong with your machine. VS2012 uses WPF for rendering, it puts non-trivial demands on the machine. You do need a solid video driver and a functional DirectX stack to make it work without problems. This tends to be an issue in general, video drivers are by far the most problematic kind of driver. Problems are roughly correlated with the age of the machine and how old the operating system is.
So a good starting point is to look for a video driver update first, visit the web site of the company that made your adapter to look for the latest. Reinstall DirectX on the machine next. If you were considering a clean update of your machine before, like updating the Windows version, now would be a good time to start with a clean slate.
I have a game that I've made in XNA 4.0 using C# (Visual Studio 2010 express). My issue that it's running significantly faster with debugging than when I run the executable directly. I did try switching to release mode and encountered the same performance. Any ideas on what could cause this?
Thanks in advance.
Make sure the XNA game is full screen. In my experiences, I notice frame decreases in the windowed mode.
You also need to check what is happening using Debug -> Start Performance Analysis. This will allow you to see what methods are using up memory and usage.
If in the case that your game has advanced collision detection, be sure to implement multithreading in that aspect. When I make games, I use a ThreadPool to handle the collision aspect.
I hope some of this helps.
I have a WinForms application that uses XNA to animate 3D models in a control. The app have been doing just fine for months but recently I've started to experience periodic pauses in the animation. Setting out to investigate what is going on I have established these facts:
It happens on my machine only, other machines works fine
Removing everything from my render loop does not improve the problem
In 2. I didn't actually remove everything, I limited my loop to set the viewport on my GraphicsDevice and then do a GraphicsDevice.Present.
Trying to dig further I fired up PIX to capture some statistics. Screenshots of two PIX runs can be viewed here (Run6) and here (Run14). Run6 is using my original render loop and Run14 is using the bare-bones Present loop.
PIX tells me that the GPU is periodically doing something, and I assume this is causing the pauses. What could be the cause of this? Or how do I go about finding out what the GPU is actually doing?
Update: since I usually trust my code to be perfect (who's laughing?) I started a new XNA project from scratch to see if it exhibit the same behavior. So starting a new XNA 3.1 Windows Game project and running PIX I get this timeline. The same periodic pauses. So the problem must be lower in the stack, in XNA or Direct3D.
So PIX shows that the GPU is working on something, I can see the list of DX calls made within each frame and the timing calculations shows that the pause occurs during (or after) the IDirect3DDevice9::Present call.
Update 2: I had previously installed and uninstalled XNA 4.0 CTP on the problematic machine. I cannot be certain that this is related but I thought that perhaps a reinstall of the XNA Game Studio 3.1 bits could make a difference. Turns out it did.
The underlying question remains the same (and the bounty is still up): what could affect XNA 3.1 (or DirectX) to make it behave like this and is there any logging/tracing power tool for the DirectX and/or GPU level out there that could shed some light on what is going on?
Note: I'm using XNA 3.1 on a Windows 7 x64 dual-core machine with 8GB RAM.
Note2: also posted this question on the XNA Creators forums here.
You could try to see if you can find something with Xperf that is close to your periodically problem, do not run your application but keep the programs open that would normally run besides your application. You could also try to do it again with the application running but it could give a cluttered view.
Start the tracing, do this in an elevated prompt.
xperf -on BASE+LATENCY -stackWalk Profile
Wait for a fair amount of time to be sure that the problem is traced.
Stop the tracing and open it like this.
xperf -d trace.etl
xperfview trace.etl
Analyze by looking at the graphs and consulting tables of specific intervals and see if you can find something that is related to the problem, the highest chance on finding it would be in the DPC and Interrupts section. But it might as well be something odd at the CPU or I/O section. Good luck!
Also more information on Xperf and how to obtain it, hopefully this delivers results.
If not, you can alternatively try GPUView which has been used for improvements in DWM,
this is also included next to Xperf with the Windows Performance Toolkit so you can easily try both!
log v
... wait for a fair amount of time to be sure that the problem is traced ...
log
gpuview merged.etl
In the case that gpuview gets out of memory you can try to add "/limit 3" or remove the v.
Read the documentation of the tools if you are stuck somewhere.
Hmm ... this seems to be occurring on the GPU, however it sounds like a CPU garbage collection issue. Can you run the CLR profiler and see if you can see any spikes in GC activity that you can correlate to the slowdowns?
I agree that it sounds unlikely since you can clearly see it in PIX, but it might offer a clue as to the cause.
If it's only happening on your own machine, then could it be drivers? Forgive me for being skeptical, but it's a 64 bit machine after all :D
This looks like either a vsync issue or GPU in its last throes. Since going back to a different version fixed it, and the "bottleneck" is in IDirect3DDevice9::Present lets go with the former option.
I'm not familiar with XNA so I don't know how much of the workings of D3D are exposed, but do you know what your PresentationParameters are set to?
Specifically try setting the swap effect set to Discard.