random checkered pattern flickering on screen..?

1

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…

Am using vis stu 2022.

Any ideas would be great.

2

That’s a bit weird.

I’d recommend to start commenting out code until what is drawn on screen is stable, even if it’s just a background. Then, work your way from there, re-enabling things to see what breaks it.

Also, exagerate draws, put a loop to draw 100 times more than what you’re drawing, to exacerbate eventual errors.

At this point, it’s really about debugging this. I’d guess there’s a memory leak or some other rendering issue in your code that for some reason did not got apparent until now.

3

I have been doing that… I noticed something. I was drawing water using some primitives, but these primitives are now off position… scaling linear with cam distance from 0…

It’s like something has changed under the hood with modern graphics cards, or new .net or something beyond my control…

This game was running perfectly on my last and much older comp.

4

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.

1 Like
5

Agreed, maybe pull your draw engine in a very small standalone minimal example. Probably there’s a bug somewhere and you’d also benefit of refactoring it a bit.

6

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… :frowning:

7

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.

8

The glitch happens sometimes even standing still, with no actors on screen, and no movement.

I can think of no values changin in my game, and boom there it is, little black squares popping in for a split second… They seem to be in formation, like a formation or array of artifacts.

If I add some object like a ball to move around, even with no input, it will stutter…

9

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. :slight_smile:

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.

10

I have been thinking of starting a new project, and just see what happens. But I need a long break first. Its been a hard frustrating day of restoring old code…

Could it have something to do with the project type being the open cross platform, and not the windows one?

1 Like
11

I would highly doubt that. But I agree with you, take a break from this. Just know it’s maybe a simple thing you’ll figure out and maybe we can help. We’re around when you need us. :wink:

12

A few days ago I would have said the same thing, but then this thread happened…

Sometimes it’s actually not your code! :stuck_out_tongue:

I’m not saying that’s the case here though, there’s a lot we should look at before making that determination.

13

Ok, so I’m rested, and have made some progress.

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…

Feels like a little progress at least.

1 Like
14

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.

15

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.

16

Ok, so an update for you guys to close this off…!

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.

17

Alright, that sounds like progress. :slight_smile:

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;
     graphics.ApplyChanges();
 
     base.Initialize();
 }

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.

19

Thanks, I will mark this as the solution.