afaik you can just download Win 10 Installation Media and provide a Win7/8/8.1 key after installation, chances are this is still working and will upgrade your key to Win10. Highly recommended for everyone using Win8 (because that was crap)
anyway, I doubt this will solve your issue, and it may make your laptop significantly slower than you are used to (depending on specs)
There is another thing I’ve found in the MonoGame/Game.cs when using FixedTimeStep, there is a sleep, when the TargetElapsedTime is bigger the elapsedtime. Maybe that causes issues, when the difference is just fractional and the sleep call itself takes longer than it should actually sleep (it’s also requerying NTTimeResolution everytime, I don’t think this is changing during a session).
That sleep is ommited with DESKTOPGL - so maybe this is an easy way of trying it by making a DESKTOPGL project and see if the stutter is there
That sleep is ommited with DESKTOPGL - so maybe this is an easy way of
trying it by making a DESKTOPGL project and see if the stutter is there
Sorry; my game was always a Windows OpenGL project. Also, even when FixedTimeStep is false, the stutter occurs at the same time (regardless of the fact that several thousand more frames have elapsed before that time is reached).
As for Windows 10… I’m afraid the choice to not upgrade to it was a deliberate one by me (I’m not a fan of the changes they introduce). I know many others who also choose to deliberately keep 7. However, though it may take me a long time I’ll look into getting a separate installation of 10 on this machine just to be sure. I suppose I’ll just live with the stutter while testing until that time. For all I know, by the time I actually finish my game we’ll be up to Windows 12 and this won’t be a problem anyway : P. I’m just relieved it wasn’t my programming that was causing the issue to begin with.
Another thing I just stumbled upon - worth a check:
sometimes, the screen Refresh Rate in windows settings is set to 59 Hz instead of 60Hz … if MG tries to run at 60 Hz this could maybe induce a famedrop here and then
That would explain why i see 58.86 or 59 instead of 60 when i time the monogame timer and i end up short always with fixed on and 60 fps.
However if i run at 120 more often then not i end up at like 125 fps or so which is just another indication that the timing that was patched into monogame last was not tested properly or something is buged,
Also if i remember right win 7 uses a different underlying call to query the time deep down the rtc is not always used if a certain bit flag is set windows will switch and some of the resolutions are 16 ms.
It is in that ms page i linked.
Timing is absolutely critical to a smooth running game so this is where i tend to think the problem stems from.
This could be hardware interupts as well like the mouse interupts interfering with the timing interupts or something thread wise but the more likely suspect is the timer.
I can manually time things better myself with fixed off then on to be honest even with gameTime which does have a very small error interval so its fairly accurate.
Ok so i was just thinking about this and i had a idea if its really hard to know were the problem is maybe it is possible to know when the problem is.
If it is stemming from a interrupt or some gc or even a big hiccup in the timer.
Then the interval error on a single frame should show a spike in proportion to the average interval error.
I suppose if you were recording everything that was going on in the last frame then you could see likely culprits for the reason that spike occurred and start to narrow down the source that way.
I had a laptop that used a similar layout and had problems. When I dug into it I found that ONLY the Intel card is connected to the display.
The GTX card renders to a memory buffer which is then fed to the Intel card for display.
So you get a nasty, unexpected, DMA access at the end of every rendered frame. This is run at very high priority, it is effectively a blocking operation.
Maybe Windows 7 does not handle the timing of this well, though you said a friends machine had the same issue with windows 7. Did his machine have the same configuration?
@reiti.net Good idea, I’ll check… nope. I only have 60Hz as an option on this machine.
@willmotil I have that exact same framerate (59 and 125, depending on the settings). Also, I’ve tried to “narrow down” the culprits for “when”, but even if I don’t even start my MainGame object (essentially loading nothing), the issue still happens. Unless…
This is my FPS tracking code. To prevent issues with my physics engine, I’ve made my game slow down if the FPS is ever below 30FPS (and post a message to a debug window if that happens). As far as I can tell, the deliberate “wait” is not the cause of the stutter (it only activates if the game naturally drops below 30; and I’ve tried running my game with the “wait” code disabled and the stutter still occured regardless).
Is there anything glaringly off about this to you?
long elapsedGameTimeTicks = gameTime.ElapsedGameTime.Ticks;
// If the FPS drops below 30 FPS, post a message to the debug window and make the game wait.
if (elapsedGameTimeTicks > MAX_DELTA_TIME.Ticks)
{
// Post a message to the debug window detailing when the stutter occured.
string fps = (TimeSpan.TicksPerSecond / elapsedGameTimeTicks).ToString();
string space = "";
for (int i = 0; i < 4 - fps.Length; i++)
space += " ";
debugFPSWindow.AddDebugElementString(Global.totalFrames + space + (TimeSpan.TicksPerSecond / elapsedGameTimeTicks) + "FPS");
elapsedGameTimeTicks = MAX_DELTA_TIME.Ticks;
//gameTime.ElapsedGameTime = MAX_DELTA_TIME;
}
// Store the time values in a Global class for convenience.
Global.deltaTimeSpan = TimeSpan.FromTicks((long)((double)elapsedGameTimeTicks * (slowMoEnabled ? 0.2 : 1)));
Global.totalTimeSpan += Global.deltaTimeSpan;
// Float versions of the Timespans (save on converting).
Global.deltaTime = ((float)Global.deltaTimeSpan.Ticks / TimeSpan.TicksPerSecond);
Global.totalTime = ((float)Global.totalTimeSpan.Ticks / TimeSpan.TicksPerSecond);
I had a laptop that used a similar layout and had problems. When I
dug into it I found that ONLY the Intel card is connected to the
display.
The GTX card renders to a memory buffer which is then fed to the Intel card for display.
That… sounds like my situation. Did you end up fixing it?
you said a friends machine had the same issue with windows 7. Did his machine have the same configuration?
I don’t think so. I don’t really have the same level of access, so I can’t say for sure off the top of my head. However, his machine is a more powerful desktop, and I think lacks the Intel part.
@Paolo_Ferri What’s your machine’s specs? I’m seeing a pattern.
I fixed it by going down to Maplins and buying a back of parts, then building my own PC.
There is no way to fix this awful hardware setup. It’s a terrible design, but cheap to manufacture. They don’t have to have two motherboard layouts, two tool chains, two manufacturing lines. Just bolt in the extra card when needed.
Hmm I still have that laptop, I will see if I can run a test for you.
Interesting update: i may be tempted to assume that this (in)famous fps problem migth come from my laptop.
Something that started recently, I noticed that I encountered a very similar problem while using different technology (C++ and OpenGL). This is something I never experienced before.
Additionally, I run the Monogame app I’m building on a friend’s PC and to my surprise, no stuttering at all there!
I know Maplins has closed down now, I did buy some bits and pieces in the closing down sale.
I have a couple of USB boards that I have ear marked for aircraft cockpit instrument panels and a Raspberry PI with a 5" touch screen I am using as a radar warning receiver.
I miss Maplins
I ran my multi-threaded renderer on the laptop I was talking about, and I got a stutter as well.
Hey all. Sorry to resurrect an old thread, but I was tinkering around with a side project of mine and I think I found what was causing the issue for us! It was… a misunderstanding of how the Game1.Update() call worked. Allow me to explain.
I was working on a game that has the following game loop:
During Update(), fill a List<> with objects.
During Draw(), draw those objects.
At the end of the Draw() call, clear the List<>.
My assumption was that MonoGame would run Update() once, and then Draw() once, and then repeat.
What I noticed however, is that my List<> would get overfilled (which resulted in large quantities of lag). I did a check, and now I know that Update() may be executed multiple times between each Draw() call. That right there, was most likely what was causing my lag (I’d test it on my game, but unfortunately it’s a bit broken at the moment. Knowing this however, I did fix my side project).
What do you think? (If I’m wrong about Update(), by all means please correct me).
EDIT: Nevermind… Stutter happened in my side project. Still, I’ll leave this information about Update() up since it’s good to know.
Dunno if it will be of any help but you can use my framerate class if you like it watches for garbage collections as well. Basically it gives all the info shown above. All of which is relevant.
Declare it set it up in load with LoadSetUp
call it’s update in update and call draw in draw.
But second off, I found out what was causing it for my specific instance.
I had made a static DebugDraw class, and the way I had set it up was that basic 3D and 2D shapes and text could be drawn from anywhere. What I mean by that is, it didn’t matter if I called DebugDraw.DrawText(); in an Update(), a Draw(), or wherever, it would still be drawn (it’s not the most efficient way of doing things, I know, but it’s for debug use only).
Here’s the stutter causing part: the way I accomplished it was by having the DebugDraw.DrawX() calls fill up a List with the debug shapes, which were then iterated through and drawn DebugDraw.Draw(). After they had been drawn, I cleared the shape list in preparation for the next frame, but I cleared it in the Draw() step.
This was what was causing the issue. It finally hit me when I needed to draw 200+ debug shapes each frame, and my game just locked up. What was happening was, multiple Update() calls were happening before the Draw() was being reached, and my debug shape list wasn’t being cleared between them. Once I put the debug shape list clear() call inside of PreUpdate(), the stutter bug was finally fixed!
