It should run perfectly, has in the past, and is a simple 2d layered tilemapped metroidvania.
Now with a new computer, and new windows, I get these occasional hiccups few times per minute, or stutters, during gameplay… All I’m doing is drawing sprites on render targets, that sort of thing… I don’t even have gameplay logic. So there is NO action, other than character movement.
I am only using like 5-10% cpu whether the game runs or not. It’s THAT little…
Tried disabling lights, shaders, animations, fancy architecture, etc… Tried disabling g-force software, running as admin, running release mode, with v-sync, windowed, full screen…
Out of curiosity, how are you drawing? Are you sending your Vector2 positions to the SpriteBatch.Draw call, or are you resolving them to integer first?
How are you utilizing your render targets? Do you draw your entire scene to an unscaled, low-rez target first and then scale up, or are you drawing to many different render targets at screen resolution to build up your scene?
I don’t know your code and this is hard to visualize without a video, but I’m wondering if stuff just isn’t drawing in the right place? With a 2D pixel game these are things I usually check.
How old was your older computer by the way? Was it running MonoGame or XNA? What version of MonoGame?
I’m just spitballing things to check here. I agree with @EnthusiastGuy, try to distill this down to as simple a problem as possible, preferrably in a stand alone program. That helps debug, and it’s also something small you can post here that other people can try.
it was pixel perfect for years, except for the new random occasional stutter. The visual artifacts are new as well, but seem to appear ONLY when running in WINDOWED mode… hmmm.
So yeah, I mean, everything draws using vector2 on some render target which is also drawn using vector 2s… I cant round things off, because I rely on the precesion for drawing things that move on things that move… For shaders and shadows in moving lights etc…
But yea, the STUTTERING happens even with just my keys moving an icon around a tiny room.
Like its INDEPENDANT of my game, unpredictable, and under all circumstances…
I’ve commented out lights, shaders, you name it… And my cpu load is at like 10 with a browser and windows going…
Although the picture doesn’t update, and sfx are not triggered, it’s like input is still registered.
so if I start a jump mid stutter, i’ll be in the air when time resumes… Also fading lights will have faded and such…
Almost like its related to my graphics card… its an 1400 dollar consumer grade pc, runs games just fine. Something has changed in the environment to make my old game slow…
What I mean here is that you round at the very last minute, as you make your draw call and only for that submission. The screen is in integer pixels anyway, so that rounding is happening whether you like it or not, but the rasterizer can do weird things so sometimes it’s good to just handle it yourself.
Try just a stand alone project rendering a tilemap that you scroll with some keys and see if you can reproduce the issue. If you can, post the code and I’ll try it on my end.
It could be your graphics card, or some other reason isolated to your machine, but we could probably do a few experiments to try to narrow it down.
No. It’s not your graphics card. It’s your code, and I would vouch my arm on it. I have been on your side of the problem far too often, thinking the same as you did, until I debugged it thoroughly and found the problem always in my code.
The fact that you have not seen this problem before is not a guarantee of it not existing.
Create a new project bring the code from your other project here and draw a scene with it. I would be curious in “how” you draw and when. A minimal code on that would help us.
I ran another project for comparison, and it works fine as expected. Colorful dynamic objects all over the place.
The graphic glitches / artifacts occur only in windowed mode, even though the window is 1920*1080 like my full screen, and ALSO only effect THIS project… So that is a mystery.
But the random halting, or stuttering, I have indeed reduced by commenting out systems that tax the graphics card… Switching render targets to do lighting and shadows etc…
It’s ALMOST gone now, but I am down to a mere 2d tile editor, with a moving sprite sheet character.
Since my SUPER old pc could run it fine, I think it must be down to the declaration and use of rendertargets, blendstates or something like that…
Also, maybe you said it before somewhere, but I didn’t pick that up. Do you update the graphic logic exclusively in the Update loop? Ideally you should NOT have expensive logic anywhere in your Draw loop. It should just draw something already pre-computed.
yea yea I use update, and it HAS literally run pixel-perfect for like a year or more on my old pc.
But I do have stuff going on within draw, like switching blendstates, and rendertargets…
Maybe something has changed in the way something is declared, I remember chat GPT pointed out that some of my 3d code was outdated on a different project. Something about how the vertex or index buffer is declared or used, or in what form the geometry is stored…
A definite change I have seen, is how windowed mode in 1920*1080, it places the title-bar outside of the screen area… Making it impossible to drag the window.
In the old monogame or windows or whatever it was, I got the window bar at the top of my screen, and some of the game was lost to the bottom…
I was USING this as a feature, and now that feature is gone, but of coarse, there is no logic problem or error warning… Just UNINTENDED consequence of environment change.
I had to go so far as to save screen-shots of hidden render-targets during various processes to eventually correct the bugs…
I had some blend-states being constructed inside of draw, which I moved to constructor instead,
but ALSO some things had to be changed with how render-targets are declared.
In order to preserve contents of a rendertarget correctly, I had to add code to clear it transperant inside the constructor…
Changes I had to make were minute, and hard to detect, in that the “logic” seemed perfectly good, and produced no errors.
EITHER I broke the code myself, at the END of my last dev cycle, and forgot, OR something has been changed in the manner of which graphics cards are served tasks. IDK…
There are OTHER little examples of old code not working with my NEW computer.
Like keyboard input is partially unmapped, like MOST keys work, but I can’t use the plus sign. Minus works… So I had to remap to letter M and P… (for minus and plus)…
Granted, I have a new keyboard with a few scandinavian characters on there, but this has ALWAYS been the case, and users can have ANY kind of keyboard…
ALSO, there is still artifacting / flickering in windowed mode, which is not present in full screen mode.
using the same resolution, and everything… YEEEEESH.
You may also try to tinker a bit with the fullscreen mode if you haven’t done that already. There are two modes, the soft and hardware fullscreen. You can toggle them by setting the HardwareModeSwitch accordingly:
protected override void Initialize()
// Set the hardware fullscreen mode
graphics.IsFullScreen = true;
graphics.HardwareModeSwitch = false; // true - hardware, false - soft
// Set the desired resolution
graphics.PreferredBackBufferWidth = 1920;
graphics.PreferredBackBufferHeight = 1080;
Since you’re saying that the window mode is working fine, maybe you are now using the hardware fullscreen and that might create issues, but try the opposite of what you are using now and see if it changes anything.
Note that with the “soft” fullscreen, the input lag might be slightly higher.