Godot: Tilemap/draw_rect random flickering with Nvidia drivers

[NullNeska]

Operating system or device - Godot version:
Windows 10, godot3.0alpha1

Issue description:
I made a kinematicbody2D and a tilemap, moving the kinematic body around worked as normal however occasionally one of the tiles on the tilemap would vanish faster than any screen recording software could capture. sometimes 2 would vanish, they would get redrawn however

Steps to reproduce:
Make a tilemap, load some tiles in, make a kinematic body
move the body around the game, keep your eyes open, dont blink, watch as some tiles vanish from rendering and quickly come back

[mrcdk]

Can confirm this is still happening using Godot 3.0 custom build https://github.com/godotengine/godot/commit/29db531fc8360b1e6d5e23008b208517b6d8c627

It also happens in the editor:

It should be all grass.

EDIT: It looks like if the Quadrant Size is set to 1 the problem disappears

EDIT 2: The tiles don't disappear but get moved (a transform problem?)

EDIT 3: A low quality video. https://streamable.com/6a07b Took me a while to trigger the problem (the editor is set to update always)

[mrcdk]

This issue is still happening in latest master 1f4685375f2d2e36a2e19e67ac9f614b8c99ea28

It seems the problem isn't a tilemap only related one. I found the same issues with a big text inside a label. I have the feeling it only happens after using the percent_visible and or moving the label. This time I could only notice it while the game was running but I wouldn't discard the same happening in the editor. I've not been able to take a picture or video of it but some characters start to flicker and move to other position with a different transformation (you can see a chunk of letters from the font texture)

[mrcdk]

Update: This issue is a core issue. It's also happening to the Editor itself. I couldn't take a screenshot because by the time I notice it and want to take a screenshot the editor has probably updated and the problem goes away. I noticed the problem in two sections of the editor, it's not that it happens in these two sections but the sections I've noticed the problem: In the Output content some letters flickered and one of the tab labels at the bottom of the screen where the Output, Debugger, Audio,... labels are. The D from the Debugger label started to flicker. It's not easy to trigger but it's the same problem.

[mrcdk]

I've got the label problem on video (flickering starts about half the video) https://streamable.com/e31xp look closely towards the end of the 4th line and you will see some letters flickering

Sorry, I don't think editing will send notifications and I think this is an important issue

[Remixful]

https://i.gyazo.com/1ccc584f1746d0fc342f6de6609d33f0.mp4

I am having the same issue... (around 0:04 you see a tile flicker)
I'm just using a Sprite and my own movement script though

[jonbonazza]

After much testing, I am confident that my issue (#15113) is the same as this one. What's odd is a couple things:

1. I was originally seeing the exact same issue that @Remixful was seeing with entire squares flickering, but then that went away without changing anything, and instead, I was seeing these weird flickering lines. Then those went away out of nowhere and the original flickering squares returned... O.o
2. If I just let the scene idle, I don't see any weird artifacts or flickering, but once I start moving my character around (or maybe it's from the camera moving around?) that's when I start to see flickering in some form.
3. I am able to easily capture the full square flickering on video, but when I try to record the line flickering, despite it definitely occurring during filming, the flickering is nowhere to be found on the video.

[jonbonazza]

Also, FWIW, this did not occur at all in 2.1 with the exact same project.

[akien-mga]

Would be nice to have an example project that reproduces the issue (I know it should be easy to make based on the given steps to reproduce, but engine dev time is a scarce resource :)).

[jonbonazza]

@akien-mga
flickertest.zip

You may need to run the project a few times before seeing it, but once it's started, just let it sit and you should eventually see it.

[jonbonazza]

I tried multiple things to see if it happened in different scenarios. I could only reproduce it when a Camera2D was a child of a YSort. That might be a clue.

[reduz]

I've seen this yesterday in the kinematic_char demo :\

[mrcdk]

What I've found about this problem is that:

• It's hard to reproduce and capture in video. Sometimes you'll be seeing it all the time and when trying to record it with OBS or any screen recording software the problem won't happen. Then again, sometimes it will do happen even while recording so I don't know 😅
• It can happen at any time and anywhere (even in the editor itself, not only in the scene being edited)
• Seems to only happen with TileMaps with a cell quadrant size > 1 and, sometimes, text. I'm not saying it doesn't happen with other stuff but I've only seen it happen when using those two things.
• And I can't see anything wrong with the code. Granted I'm not an expert on it or anything. The only thing I can think of is some transform not being set correctly at random... dunno really 😓

[akien-mga]

See #16277 for another example project that should reproduce the issue.

[chadalen]

See 16280 for another issue regarding this.

[Archeia]

Hello, to add to this and just to clarify, I haven't done anything at all with Godot and I just tried out this project specifically since I was curious:

The flickering happens on a test play but not on the editor. Interestingly, the opposite happens if I try 2D Kinematic Character Demo where the editor tiles flicker but not in test play.

[jonbonazza]

At least in my experience, this seems to be resolved in the stable godot
3.0 release.

On Sun, Feb 4, 2018, 2:56 AM Archeia [e-mail] wrote:

Hello, to add to this and just to clarify, I haven't done anything at all
with Godot and I just tried out this project specifically since I was
curious:
[image: image]
https://user-images.githubusercontent.com/6222499/35776735-0b413ce2-09dd-11e8-81cc-be7a097d61cd.png

Interestingly, I don't get this problem with the 2D Kinematic Character
Demo

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913#issuecomment-362898191,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABW9yzPGCmyxZONEuNXLFKU_PtY3ADsvks5tRYzmgaJpZM4OlRVq
.

[Archeia]

@jonbonazza I used the latest stable godot3 and it still happens. My image shows it on upper right corner too T_T)

It seems this bug happens on Nvidia graphic cards that are above GTX 970M?

[Remixful]

GeForce GTX 970 here.

[MennoMax]

Here are some of my findings and a simple project to reproduce this issue. (a tilemap with 2 different sprites, the godot icon and the godot icon with inverted colors, with labels above the tilemap, scene that was converted to tileset is included)

Flicker.zip

• also happening to labels in this scene, single characters move randomly (even rotate), just like the tilemaps tiles
• if you are inside the editor and move your mouse around on the grid while having a tile selected, you can sometimes see this issue in a frozen state until moving your mouse to a different grid section
• the order of nodes in the scene tree changes the frequency of this (if the tilemap is the last node, it happens more frequently to the tilemap and if the tilemap is the first node, it happens more frequently to the labels)

Edit: Heres a screenshot of the issue. You can see 2 E's of the first line weirdly stretched across one tile section of the tilemap. (red)

The labels stop flickering once the tilemap is removed from the scene.

I hope this is going to help resolving this issue.

[ibrahn]

45ab9cdfb55eed4eef59feee225248ccc20a6235
exported (release) on Linux to windows (32 and 64 bit)
Flickers on Win 10 with Nvidia GTX 750 Ti (don't have access to this machine to debug)

Could not reproduce on Nvidia GTX 760 with Debian or Win7.

[vinterskog]

Flickering is present with a GTX 1060 on Win7 for me. I really hope this gets fixed very soon because as it is now, TileMap is simply not usable for production. :(

[podmentor]

same issue with flickering lines between tiles here. check this out
platformer tut.zip
Very annoying and unpleasant glitch =(((

[mrcdk]

@podmentor lines between tiles is normal and it's not related to this issue. There are multiple ways to solve your issue here: http://docs.godotengine.org/en/latest/tutorials/2d/using_tilemaps.html?highlight=tilemap#offset-and-scaling-artifacts

[Algorithmus]

I have this issue with my game as well. But only when I switch on the dGPU (Nvidia). I haven't noticed it with the integrated Intel GPU yet.

[securas]

A note that may help. I have this issue with win10 and nvidia gtx 1070. But turning on ysort on the tilemap seemed to stop the glitch.

[bojidar-bg]

Note that Ysort forces ~~(Cell)~ Quadrant Size = 1.

[vinterskog]

@securas Wow, that actually worked! Thanks for that. :)
@bojidar-bg Maybe I misunderstand what you mean, but I have a tile map with a cell size of (16, 16) and enabling Ysort didn't change anything about that...

[Archeia]

@securas sorry for asking this newbish question but where can I find ysort?

[MennoMax]

@Archeia You can find it under "Cell" when inspecting the tilemap.

Edit: In my example from above, the labels still flicker even with Y-Sort on, but I didn't see the tilemap flicker yet.

Edit2: Just saw a tile flicker with Y-Sort on. That doesn't seem to fix this issue. It does seem to happen much less frequently however.

[Archeia]

Thanks! That did fix it for me.

[securas]

Thanks @bojidar-bg . I was under the impression that cell size was something else like the size of the cells... What did you mean by cell size?

[bojidar-bg]

@securas oh, my bad, I meant Quadrant Size. Not sure why I mistook that....

[ASxa86]

Apologies if this doesn't add much to the conversation but I am noticing this flickering with the Kinematic Collision demo in both the editor and as an exported executable. Windows 10 64 bit. GTX 1080 Ti. 2 monitors @ 1440p. I'm running a self compiled version of godot 3.0.2 stable. I've tried this in debug, release, and release_debug and the flickering is present in all instances.

Edit: At first glance, it does appear that enabling ysort for the tilemap makes the flickering go away.

[jonbonazza]

Im starting to wonder if this isn't a driver issue. Seems that everyone that is experiencing the problrm is using an nvidia card, and sounds like most people are on windows 10.

[jedStevens]

Gettnig this too and I'm on Manjaro, GTX970 here

[ecdavis]

I can repro this and can also confirm that enabling Y Sort fixes it. I'm running Windows 8.1 with a GeForce GTX 1060.

EDIT: Actually I think the flickering may be related to quadrant size, as @bojidar-bg suggests. With Y Sort disabled I see varying levels of flickering as I vary the quadrant size. I have yet to observe flickering at quadrant sizes 1, 2, 64, or 128. I see plenty in the 16-32 range.

[MennoMax]

@ecdavis Are you sure it stops flickering completely? I'm using a GTX 1060 too and I did still notice the flickering with Y Sort on, just much less frequently.

I'm really curious what might cause the labels letters being placed inside tilemap tiles sometimes.

Many things seem to have an impact on the frequency of the flickering, like the node order, I don't think it's very closely related to the quadrant size.

[nyenye]

Archlinux - Nvidia GTX 970 - Godot v3.0.2.stable.custom_build

With Quadrant Size set to anything !1, the tile displacement issue happens constantly.

With Quadrant Size set to 1, didn't get any displaced tile, yet got a tearing glitch for a few frames, just once. Probably unrelated.

[rosshadden]

The flickering for me was fixed by enabling Pixel Snap in the project settings (Rendering -> Quality -> 2d). And I had a tearing issue that was fixed for me by messing with settings on the tilesheet images and tilemaps I was importing. Namely "filter" and "mipmaps". I just told it to use the 2d Pixel preset, and set that as the default for textures.

[nyenye]

@rosshadden Will try when home and update on results. Thanks for sharing!

[irresistiblejelly]

Pixel snap was on when i did this and it did not solve the issue.
I have actually hit on what might be a solution.
If you turn on Y-sort on the cell size AND turn up the quadrant size to match the cell size (In my case 128) it seems to completly eliminate the issue at least for me

[nyenye]

@irresistiblejelly As @bojidar-bg pointed out, turning on y-sort sets quadrant to 1 internally, ignoring the value set on the editor. Then again is not solely a problem of tilesets, because dynamic fonts with mipmaping and filter activated have the same issue (displacement of letter in this case).

Need to make exhaustive testing to pinpoint the exact issue.

[Metalraptor]

I just tried @rosshadden's suggestion of turning on Pixel Snap, that seems to have fixed it for me.

[jahd2602]

It's still happening in iOS and in macOS, not happening on Android.
I activated Rendering -> Quality -> 2d -> Pixel Snap which helped reduce the frequency, but it is still happening.

[jonbonazza]

@ByTheQuietLake did you see these issue previously, I believe that you are the first person to chime in with a non-NVIDIA card.

[jonbonazza]

This very well may be an nvidia driver issue then.

[mrcdk]

Tested it on Windows 10 using Godot 3.0.2:

• Nvidia 1070 GTX (driver 397.64): Issue is happening.
• Intel HD 4600 : Issue is NOT happening.

[jamesaddy789]

This is a definite problem that is occurring at least with users with Nvidia gpus. I notice that the tiles are drawing randomly around the scene in edit mode as the mouse cursor moves along the scene and side tabs. It also occurs when running the game. The intensity does seem decreased when setting the quadrant size to 1 (Y Sort sets it to 1) but it still occurs and this takes away the optimization on large maps causing heavy frame rate sinks.

I've also experienced crashes when attempting to set the quadrant size back to 1 (or trying to check Y Sort) after changing the setting on a large map ( I opened the issue with #19617). This seems to show overly heavy processing is involved ( or memory leak maybe?) and may be related to the overall problem with the way TileMaps are coded to be rendered that is causing the tiles to be drawn irregularly. I suspect the issue is in tile_map.cpp and possibly in VS or whatever code is handling the rendering of tiles.

I haven't experienced the issue with fonts being drawn incorrectly mentioned above yet but I also may have not messed with fonts enough to experience the issue. Unless things are looked into and fixed, I fear I may see that as well.

This really needs to be looked into and sorted out as many users have Nvidia cards and publishing to desktop means many people with Nvidia cards will be playing the game and noticing these issues.

[guilhermefelipecgs]

It seems that the problem maybe is related with the "PowerMizer", when the preferred mode is set to "Adaptative" the performance levels decreases to zero (after 35 ~ 40 seconds) and then the flicker starts, but if I set to "Prefer Maximum Performance", the flicker disappears.

I tested with Linux (driver 390.59 and 396.24) and Windows (driver 388.71 and 398.11).
~On Windows, after upgrade my driver to 398.11, it seems that the problem has stopped~

Video that I recorded showing the bug: https://youtu.be/R6TLpDX71RQ?t=32s
If someone wants to test, here is the project used: Flicker.zip

Update:
In my example, I'm not using TileMap, it's just simple draw functions (draw_line and draw_rect) to create that grid.

[jamesaddy789]

@guilhermefelipecgs I really don't think that is a true solution. I am assuming Nvidia X Server is a linux OS program similar to Nvidia Control Panel with windows 10. I set the power management setting to "prefer maximum performance" within and it seems to reduce the relocating tiles, but I still have seen it occur after changing the setting. This bug is weird in that it doesn't always show when using the program, but it does occur. Maybe you should try this with an actual TileMap.

Even if that setting worked. WHY would it work? Wouldn't setting the power manager to maximum performance mean the code is hard on the processor? It did seem to make a difference for me but did not completely resolve the problem. I still can catch tiles drawing out of place.

[guilhermefelipecgs]

@jamesaddy789 I'm not saying that is a solution, just trying to have some clue about what could cause that. I was intrigued because when I use my intel gpu, works fine, only happens with nvidia and I noticed that when the gpu clock drops the flicker appears, but this could be just a coincedence, I dunno. I also tried with TileMap and for me at least, it's the same think.

It's strange that you didn't have the same experience as me. Just for curiosity, what's your nvidia driver version?

[jamesaddy789]

@guilhermefelipecgs It is Version 398.11. It seems PowerMizer is a laptop app whereas I'm using a desktop pc so I don't have that program. I just changed the setting power management to "prefer maximum performance" in Nvidia Control Panel. It did seem to reduce the amount of dislocated tiles but when running the game I noticed it still. Similarly to setting quadrant size to 1, it reduced the frequency but did not completely resolve the issue. I also still have the issue that if I change the quadrant size to 1 on a large map, the editor crashes. This is also less frequent after changing the setting to max performance but I tested it just now and it crashed.

Note My gpu is Nvidia Gtx 1060 6gb with the aforementioned driver. My OS is Windows 10 Professional.

[guilhermefelipecgs]

I'm also using a PC here. On WIndows, the control panel it's a little different indeed, the option you changed it's the same option I tested here. Dunno what to do. This bug is very boring. :(

[jamesaddy789]

It's a problem that has to be in the rendering code. I don't have experience enough with the engine code to test it out and work it out myself. It is interesting that you (@guilhermefelipecgs) noticed the problem when drawing the grid manually. I thought the problem resided solely in the TileMap source code.

If the rectangles are drawn all over the place even when not using the TileMap node, I have to assume the bug is also active in the draw_rect() function (in the source code at https://github.com/godotengine/godot/blob/master/scene/resources/texture.cpp at line 47).

Drawing TileMaps uses VS in most of its functions (in https://github.com/godotengine/godot/blob/master/scene/2d/tile_map.cpp) and the function draw_rect() uses VisualServer (I'm guessing these are the same thing).

Why would this affect Nvidia gpus? I don't see this type of problem in other programs (other game engines) so I can only aim toward it being a problem in the source code that for some reason impacts (at least more noticeably impacts) Nvidia graphics processors.

[jamesaddy789]

@guilhermefelipecgs The problem is ALOT less frequent after changing the power management setting and this may be why you are not noticing it. It actually took a bit of time running the game and walking around before I saw the glitch again. I walked around the game with a KinematicBody2D for some minutes before I caught the tiles being misplaced. I saw enough to know the problem still exists.

[mrcdk]

I'm 98% sure this is a driver issue. Setting the nvidia driver Power management mode to Prefer maximum performance seems to solve the issue.

The following tests use @guilhermefelipecgs flicker project and stripping it down to the basics that still trigger the issue.

I've been trying to get a GPU trace with RenderDoc for about 4 hours enabling low process mode in the game (so 1 frame per second basically) but, while I think I was able to capture some problematic frames, I couldn't see any error in the opengl commands or the reconstructed frame from RenderDoc. Again, I THINK I got some problematic frames... it's kinda hard to get them when they are random.

I've also logged the rects that are sent to the shader to draw each rect into a file and searched for any rect outside x < 60 or x >420 or y < 60 or y > 420 or with width or height different to 20 and I've found nothing and I'm 100% sure there should be bad rects because I've seen them while running the project and logging it. Here are the logs godot_tilemap_issue_logs.zip if you guys feel like going through them (145 is the item rid then a bunch of rects then 145 again then rects then...) What's logged is dst_rect from here https://github.com/godotengine/godot/blob/master/drivers/gles3/rasterizer_canvas_gles3.cpp#L687-L701

Here's the windows build plus modified flicker that I used to log the rects. If you want to log it use something like godot.windows.opt.tools.64.exe > log.txt in a cmd (not a powershell because it uses another encoding and it's a pain)

[akien-mga]

For the reference, I've tried both @guilhermefelipecgs's Flicker test (Linux x86_64) and @mrcdk's modified version (Wine) and couldn't reproduce any flickering on the following system:

• Mageia 6 x86_64
• X11 1.19.5, Plasma/KWin 5.12.2 (tested with compositing ON and OFF)
• Optimus laptop, using Nvidia GTX 670MX via Nvidia PRIME (drivers 390.59)
• Tested with Godot vsync ON and OFF, as well as drivers vsync ON and OFF

It could be that the drivers bug affects only desktop or recent GPUs.

[irresistiblejelly]

This is my assumption too as 7 days is having issues with series 10 cards
on a much larger scale. I get random fps drops from 160 to 10 for no reason
on minimum settings with a Nvidia GeForce 6Gb gtx 1060. Desktop pc

On Tue, 19 Jun 2018, 09:04 Rémi Verschelde, [e-mail]
wrote:

For the reference, I've tried both @guilhermefelipecgs
https://github.com/guilhermefelipecgs's Flicker test (Linux x86_64) and
@mrcdk https://github.com/mrcdk's modified version (Wine) and couldn't
reproduce any flickering on the following system:

• Mageia 6 x86_64
• X11 1.19.5, Plasma/KWin 5.12.2 (tested with compositing ON and OFF)
• Optimus laptop, using Nvidia GTX 670MX via Nvidia PRIME (drivers
  390.59)
• Tested with Godot vsync ON and OFF, as well as drivers vsync ON and
  OFF

It could be that the drivers bug affects only desktop or recent GPUs.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913#issuecomment-398311432,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS-y9jLkTsEpQyBdu204PCK63wHgD1dxks5t-LCXgaJpZM4OlRVq
.

[mrcdk]

@akien-mga does the graphics clock change while running the test as @guilhermefelipecgs shows in their video?

[akien-mga]

does the graphics clock change while running the test as @guilhermefelipecgs shows in their video?

It doesn't change, when I start Godot it moves to the highest clock value and stays there. So that explains why I wouldn't see flickering, as per @guilhermefelipecgs's video it happens only when downclocking (I guess my card is not powerful enough to want to downclock when running a simple Godot project).

[guilhermefelipecgs]

When you think this can't get more weirder...

I made a new project and notice 2 strange behaviours.

1) I know "exactly" where the flicker will be.
2) Control 3 never get "flickering".

I'll try to explain what is happening:
1) I added 4 controls on the scene like this:

All controls use the same base code. Control 1 will be the only node with flicker.

2) After some time (20~50 seconds), Node.gd will reparent the nodes, like this:

And then, flicker will jump from Control1 to Control 2, that is, only the first child have flicker.
Note1: I think this probably happens because the draw functions will be queued in the order of the nodes.
Note2: Control 2 is using draw_texture, this method also have flicker.

3) When Control 3 become the first child, the flicker magically disappear, and the reason is this flag:

The Invert flag tells the code to invert the drawing functions, so my code will call first draw_line and thereafter draw_rect, so the red rectangles will be in front of the grid.

4) And finally, the flicker come back in Control 4, here I only call draw_rect.

I forgot to say before that I've a GTX970.

On Windows, I used a program to see my gpu clock changing:

*The problem also affect Windows with latest driver (398.11), but less often and I need to wait a little more time. Ignore the drive version on this screenshot, I just downgrade my drive to see if it has any difference.

New project: Flicker_2.zip
Video 1: https://youtu.be/01LWVQqp5yg
Video 2: https://youtu.be/XTKTe9aZAuU?t=50s

I must tried 5~8 times until I get a more intense flicker. It seems that the more I play, the more intense the effect.

Video 2 is the same thing as video 1 but the performance level increases in the final part of the video for some reason and when this happens you can notice the flicker disappear. And also I let the "Remote" tab opened, so you can see the reparent happening.

The videos are recorded on Linux (because the bug is more intense on Linux) with 60 fps.

[guilhermefelipecgs]

I'm 98% sure this is a driver issue.

I agree, I looked in the code (godot) and I can't find anything strange.

[mrcdk]

Okay, I was able to launch the project with apitrace and I'm now 99.9998% sure that this is a driver issue related to the Power management mode Here's the flicker_trace.zip file so you guys can run it on your end too.

And here's a video I recorded: https://streamable.com/yk1qq Quality is kinda bad so here's the original (which isn't much better 😅 )

The first 20 seconds is the project running and logging. I forgot to minimize OBS the first time I used apitrace and my gpu clock was locked to the maximum (it's the graph on the top-right corner) and the flickering wasn't there. Skip to aprox. 3:15 where I minimized OBS and got the bug to appear when replaying the trace. I then used the Show thumbnails option to create a thumbnail for each frame. I then searched through the thumbnails until I found a frame that had the bug. I ran the lookup state to get the opengl state of that concrete frame and, after it finished, I showed the framebuffer without the bug.

So, if this issue was caused by godot, not only the trace should show it everytime (it doesn't the first time I run it while I left OBS opened) and the thumbnail and the lookup state framebuffer should have looked the same (which they clearly didn't).

[jonbonazza]

So what can we do here? I don't think we (as a community) necessarily have the clout to initiate change from NVIDIA themselves. Or do we?

[akien-mga]

So what can we do here? I don't think we (as a community) necessarily have the clout to initiate change from NVIDIA themselves. Or do we?

IMO it's worth a shot :) Worst case we don't get an answer, but opening a thread about this in the Nvidia dev forum would be good.

[nobuyukinyuu]

Hi guys,

I am wondering, does the problem still occur when you use Nvidia Inspector and disable CUDA - Force P2 State? This was a problem which caused flickering in some other projects (like OBS). I'd like to know if it is a power issue, too, since I'm seeing a similar problem in another (non-godot) game and am starting to suspect a driver issue as well. GTX750 here.

[Flairieve]

I'm still getting the same issue as well on Godot v3.0.6 and downloading the latest Nvidia drivers doesn't help with this issue at all. I'm using a Nvidia GTX 750 TI graphics card. Is there anyway to fix this issue? Also when I run my game on a web browser, the flashing issue doesn't appear at all?

[chadalen]

Has anyone reached out to nvidia about this issue yet?

[ghost]

have this issue ty @guilhermefelipecgs for that video, exactly what is happening to me.
i'm on gtx 950. i tried the quadrant size thing && ysort, but no luck.

i am not sure what to do. was going to make a new issue but figured i'd post in this instead. i'm on Godot v3.0.6 as well

[nyenye]

Has anyone tried it with version 3.1 alpha with GLES2.0 activated? Maybe it's a OpenGL3 x nvidia driver issue?

[reduz]

I guess I will have to change how rects are drawn, this shows how bad the situation is with OpenGL driver support and why moving to Vulkan is needed soon.

[reduz]

also, did anyone test it with the GLES2 renderre?

[ghost]

@reduz am sorry it took so long. finally got 3.1 to compile
yes, i cna confirm the flickering is still happening on GLES2 renderer

[ghost]

i've been doing some testing with this, and i can't trigger any black tile flickering on a 128x128 cell sized tileset (quadrant 16). but on my 32x32 and 48x48, it's still there.
i'm not sure if that helps but i think it's something
e: btw if anyone wants me to edit some c++ code and re-compile to test stuff, just lmk
e2: nvm it just came back. yeah, it's much less frequent though

[ghost]

i found a temporary solution that works quite well actually. (if anyone is releasing their game soon)

-- in tiled:

• create a new tiled map and set the amount of tiles to be 40x40
• select your ground tileset
• then click on the bucket fill tool on the top header bar (key f), click anywhere on the tile'd grid
• now go to file -> export as image, uncheck _draw tile and include background color_, click export.
• go to tinypng.org, compress it (i saved 71% of the filesize).

-- in godot:

• add a sprite node to your tilemap layer.
• set the sprite's texture to the exported image from tiled.
• set the grid step options to fit the same as your cell size (in my case, it was 48x48)

now, you can just do ctrl+d on the sprite and snap it around. no flickering and performance is great (godot internally only renders whats on canvas)

e: hope this helps. it's a bit weird, but it's a solution (not the best, but its something)
e: you can still use the other tilemap layers for objects and whatnot. this is just for the ground to stop the flickering while maintaining good performance (enabling ysort on a ground tilemap layer drops fps bad)

[ghost]

@ByTheQuietLake np, my pleasure! i have nvidia gtx 950 and i can confirm its working. have not seen any black tile flickering for over 20+hours. in editor, or in-game. the only thing i've noticed is load time is increased by like 20ms (which is barely nothing really), but that's just because the image is huge. however, when moving across the map with your character, it feels just as smooth as if it were a tilemap.

not sure about flexibility. long story short, just create your ground tiles in tiled, export as image, and use them as a sprite as a child in your tilemap. then, once reduz / nvidia devs / etc find a fix, just delete your old sprites and use the tilemap as you would normally. it should be an easy transition.

solution worked or not if you don't have a nvidia gpu :(

e: this bug only happens with nvidia gpus bythequietlake

[Aaron-Fleisher]

This is my first post on github, and I apologize if this is in the wrong place (found this thread from google).

I recently experienced this same issue after converting a game from 2.1. Girng's solution does work for me, but it seems a bit hacky. I also noticed there is a slight offset between a Sprite node texture, and the tilemap cell textures when moving (using his solution). This was not apparent using a floor tilemap.

I am on a GTX 960. I can't find any PowerMizer settings on Windows 10 (from guilhermefelipecg's above post). That might be because I'm on Windows, and it might a linux thing. I also read above, that even that didn't fix it.

This might be slightly off-topic, but should I stay on 2.1 until this gets fixed, or would I need to compile a "custom version" of Godot?

Kind Regards,

--Aaron

[gavriil07]

Same question here as Aaron, do we have other options? This is a very nasty issue and makes Godot not suitable for production, please give it a higher priority.

[jastadj]

One thing I found that worked for me was disabling HDR in the project settings.

[gavriil07]

One thing I found that worked for me was disabling HDR in the project settings.

Not for me, the only one that worked was setting Ysort on, but it's not quite a viable option(sets quadrant size to 1)

[XNargaHuntress]

I was running into this as well..and was able to consistently reproduce every time I ran the scene.
Has anyone tried messing with the render quality settings? Specifically setting the Framebuffer Allocation to 2D?

So far it _looks_ like that may be working...or at least making it happen far less often (I haven't seen the flickering occur again..._yet_)

[XNargaHuntress]

@ByTheQuietLake so far it looks like no instances of flicker at all.

[ghost]

@XNargaHuntress really? What did you set for the framebuffer allocation? that could be a good temp fix
edit: nvm read that wrong, gonna test this for 2d framebuffer

[atomius0]

@XNargaHuntress The flickering is still happening for me with Framebuffer Allocation set to 2D. I feel like it's happening even more often now, but that could be a coincidence.
I'm using a Nvidia GTX 750 Ti on Windows 7 x64, Godot 3.0.6 stable.

Edit: I just tried setting Framebuffer Allocation to "2D Without Sampling". Still flickers.

Edit 2: Flickering also happens with Godot 3.1 alpha using the GLES3 renderer. But when using the GLES2 renderer I haven't noticed any flickering at all.

[gtkampos]

Maybe I can be wrong, but after the last nvidia driver update, I could not see any flickering until now. Will fully test when in home today.

GTX 1050TI, Windows 10, Godot 3.1 alpha

EDIT: After lot of test, it showed again...but very few.....but still there

[jonbonazza]

After a former driver update I haven';t seen the issue at all for a while now. Not sure exactly which update fixed it, and probably going to depend on the specific GPU, but yea...

[reduz]

Remember guys that GLES2 driver does not exhibit this problem on Master.

[mikeleeman]

Setting camera zoom back to (1,1) might have fixed the problem for me, previously I set it to (0.5, 0.5) and I was seeing flickers. So far I'm not seeing any flickering. Can anyone else confirm?

[securas]

As long as the ysort option is OFF, I always get flickering.

On Mon, Nov 19, 2018 at 2:10 PM mikeleeman [e-mail] wrote:

Setting camera zoom back to (1,1) might have fixed the problem for me,
previously I set it to (0.5, 0.5) and I was seeing flickers. So far I'm not
seeing any flickering. Can anyone else confirm?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913#issuecomment-439773424,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACv4240No-elY7BK16HKAmxhHrFRaOj4ks5uwj1UgaJpZM4OlRVq
.

[Aaron-Fleisher]

@mikeleeman Still happening on GLES3 with a GTX 960. Tried 2D framebuffer mode, camera shenanigans, etc. At this point I think Vulkan is our only hope.

NVIDIA has still not fixed their shader disk cache lock issue. Which makes Godot run 200-300ms (sometimes even more) slower on scene previewing. It's sad because people who are on Windows w/ NVIDIA cards are not experiencing Godot's full potential. Or, worse yet, they became accustomed to the delay while scene previewing.. thinking that it's normal when it's not! Is a rant, please don't read

[reduz]

Most vendors are not giving fluff about OpenGL recently, and working around this is quite complicated..
For now the best workaround in Godot 3.1 is switching to OpenGL2, where it works fine.
Eventually GLES3 will afterwards be deprecated for Vulkan, where this should hopefully no longer happen.

[gcardozo123]

Still happens in 3.1alpha with GLES2 (as shown in the top right corner of this gif):

[Aaron-Fleisher]

A temporary solution that I found to work, which should hold us over until Vulkan:

• Use Sprite nodes for each separate ground tile. Enable snapping when editing so it makes it easier to mimic the same ground layout. This way is actually not an issue performance wise I found. It's just time consuming and a bit weird to do. It's obviously not ideal, but it does do the trick for now.

I can also confirm this happens on GLES2 as well :/ (last build b47d4e1ba5d72bac5c2e671d9e4c0ae037a248c0)

[jonbonazza]

That isnt even close to a valid work around. You lose out on literally every reason to use tile maps in the first place.

[Aaron-Fleisher]

That isnt even close to a valid work around. You lose out on literally every reason to use tile maps in the first place.

Yeah, but I mean it stops the flickering and it's only for the ground layer.. And your game looks exactly the same. But I agree with you, it doesn't take advantage of the tilemap features, but I feel it's a fair trade off until a fix gets in

[mikeleeman]

I'm not seeing flickers anymore which is weird because I was definitely seeing random flickers before for a long time.

Last time I also tried drawing tiles on a canvasItem with draw_rect functions, emulating a tilemap, and calling update() on the canvasItem only once, so it only draws once at the start of the program. Surprisingly the canvasItem has similar random flickers too (maybe less frequent?), but only when camera is zoomed in (0.5,0.5), but not when camera is at (1,1). I know it sounds weird, maybe I misunderstood something.

Now the flickers are not happening anymore, for both the one using custom canvasItem draw and ones using Godot's default TileMap. I suspect a driver update? My card is Nvdia GeForce GTX 970, on windows. Side note can anyone check their currently installed openGl version? I heard it's easier to do on linux.

edit: The uncertainty is not good I think, need Vulkan to make sure there'r no problems.

[reduz]

I changed how these are drawn in OpenGL ES 2.0 renderer, so it definitely should work fine there. On OpenGL ES 3.0 any workaround I can think of will most likely hurt performance, so priority will be push full on getting Vulkan to work as soon as possible after 3.1 is out.

[reduz]

Please confirm if you can that this no longer fails in OpenGL ES 2.0 renderer.

[gcardozo123]

@reduz I've tested for a few minutes here and it didn't happen. Thanks for fixing this! :)
Note:
I don't know if it's related, but I can still see some horizontal white lines between tiles when the camera shakes.

[girng]

thanks reduz for the OpenGL ES 2.0 fix!

to @mikeleeman and others:
here are the last 3 patch notes since November 20th for NVIDIA GeForce cards:
Nov 20th, Dec 3rd, and Dec 12th. the fixed issues list is on page 15.

the only issue i found that might be relevant (not sure) is on Dec 12th:

• [Hitman 2 Silent assassin]: There is flickering texture corruption in the game.
  [200472315]

[gcardozo123]

I also noticed that some went wrong with my tilemap:

[reduz]

I am not sure I can do more for this than the current fix. After 3.1 is out, this bug will most likely not be present on Vulkan, and it should be gone from ES2 renderer now.

[securas]

Testing alpha 4, I saw this using GLES2 and GLES3. No shaders, nothing special in particular. Just tilemaps.

[guilhermefelipecgs]

@securas Are you using camera with zoom?

[securas]

no

On Sat, Dec 29, 2018 at 12:35 AM Guilherme Felipe de C. G. da Silva <
[email protected]> wrote:

@securas https://github.com/securas Are you using camera with zoom?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913#issuecomment-450378016,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACv425NmiZKRUJHDzxg0NPB-PszWJaa2ks5u9jpGgaJpZM4OlRVq
.

[akien-mga]

@securas That looks like a different issue, it's more an issue with pixel correctness than tile flickering.

[securas]

@akien-mga Fair enough... It only seems to happen to the tilemaps so I figured it belonged here.

[DavidSichma]

@gcardozo123 looks like #24642 to me, PR coming soon

[reduz]

Will move this to 3.2 as nothing else can be done for now. Also hope nvidia fixes this for good, I contacted them directly to ensure this is fixed from their side too. With the Vulkan rewrite, this will hopefully no longer happen but in the meantime please use GLES2.

[reduz]

sorry did not mean to close

[girng]

are there other open source game engines that use GLES3 that have a tilemap class or some rendering that could be looked at? i was just looking at the dates, and it's been over 530 days, and it's going to be set back even longer :/

[girng]

i reached out to a godot dev on discord (@bojidar-bg), and received ample help. i was trying to show the issue but couldn't get the black tiles to appear while recording in OBS. he then recommend me to change some settings in the NVIDIA control panel.

info: fa7329f6485058fde30b8e2bfe26291dfbfc4434, GLES3, W10-64bit, GTX950

• Go to the NVIDIA Control Panel
• Click on Manage 3D settings
• Scroll down to Power management mode, change it from optimal power to prefer maximum performance
  
• Click Apply

i have not seen one black title yet (reloaded game about 20+ times, and will continue to test until the cows come home). so far so good! hope this helps, and a great thank you to Bojidar!

[agameraaron]

girng: I saw this same phenomenon in exports. That is where my concern lies most. We shouldn't need to ask our end-users to do change their GPU settings to not have intermittently disappearing tiles. Did you not try the latest 3.1 beta with the nvidia tile hack?

[OvermindDL1]

• Scroll down to Power management mode, change it from _optimal power_ to prefer maximum performance

Doesn't this imply a driver fault, I'm unsure how an engine could work around every potential driver bug.

[girng]

@OvermindDL1 yeah, reduz stated he contacted the nvidia devs directly, which is greatly appreciated! i'm happy with the power management mode solution for development. i think it should hold us over until nvidia themselves fix it.

@agameraaron i only use gles3 (game is gpu particle bound). sorry, can't comment on the tile hack. but i've heard it works

[reduz]

From what I just discussed with nv representatives, they say they can't observe this issue anymore. Can you guys try with latest driver versions and, if it fails, report a bit more information about your hardware? (GPU Model, driver installed, power management settings) ?

[girng]

@reduz tested on the latest driver (419.17). tile flickering now happens with the following power modes: prefer maximum performance, optimal, and adaptive.

GTX 950, W10, GLES3

• when OBS studio is opened, the flickering disappears

[gavriil07]

@reduz @girng @xsellier
GTX 1070, GLES2, W10
Latest driver 419.35
No flickering regardless of power mode used 👍

GLES3 also seems to work..also found this issue on stack overflow:
gles2 screen flickering

[MennoMax]

GTX 1060, W10
With the same driver as above (419.35), the flickering is still happening in both GLES2 and 3.
You just have to click around in the UI and hover over Controls, as the default redraw setting now is "on changes", which can be changed by clicking on the circle in the top right corner.

Used the old project I posted in https://github.com/godotengine/godot/issues/9913#issuecomment-364707061, everything is still happening - label and tilemap flickering and the letters being stretched across some tiles in a weird way.

[volzhs]

try this option.

[MennoMax]

I'm aware of this option, which only works in GLES2

@reduz @girng @xsellier
GTX 1070, GLES2, W10
Latest driver 419.35
No flickering regardless of power mode used 👍

GLES3 also seems to work..also found this issue on stack overflow:
gles2 screen flickering

The comment above just suggested the issue was no longer present.

[gavriil07]

@MennoMax you're right the flickering still happens..but the workaround for GLES2 works, hope Vulkan support will come soonish 🙏

[girng]

@gavriil07 problem is, gles2 workaround means you can't use gpu particles :/
also, the flickering was fixed on gles3 when i posted on feb 11 (with power mode set to prefer max performance). now, the flickering has returned, and happens on all 3 power mode options with the new updated drivers. doesn't make sense, one of their driver versions has the flickering fixed on prefer max performance, now the new drivers don't have it fixed.

[gavriil07]

@girng what this has to do with gpu particles?
@reduz do you have an ETA for a preliminary Vulkan renderer?

[girng]

@gavriil07 if a game uses GLES3 (with gpu particles), it's not really a workaround for them to use gles2. cause then, gpu particles are not supported

[Calinou]

@girng CPUParticles can still be used in GLES2 though; they're sufficient for many use cases (which is especially true in simpler 2D games). Please keep the discussion on-topic :slightly_smiling_face:

[girng]

CPUParticles can still be used in GLES2 though; they're sufficient for many use cases (which is especially true in simpler 2D games). Please keep the discussion on-topic

i'm talking about gpu particles, not CPU

[gitajerb]

Saw a post at https://www.reddit.com/r/godot/comments/9ljor3/psa_tilemap_flickering_possible_fix/ written months ago that says "try disabling HDR in the project settings". (Rendering -> Quality -> Depth -> Hdr)

I tried that on a GLES3 project and it seems to work so far for me (Nvidia 970 version 415.27, Linux Mint). Sorry if this is a repeat message.

[nobuyukinyuu]

I can say that this bug exists for the GLES2 driver on my Nvidia gtx760 (Windows 10 x64). The problem was exacerbated by running a game capture on it through OBS. Video below:

https://www.youtube.com/watch?v=TM1BN4uwMfA
First instance of it happening in the video is at 0:36, and happens again within about 5 seconds. Occurs randomly with intervals as short as less than a second but usually longer up to 30 seconds with small clusters of pop-outs happening at once.

The GLES2 fix seemed to alleviate the issue for me.

[Caenhorn]

Disabling HDR in project setting worked for me. Thanks!

[viktor-ferenczi]

Windows 10 Pro 64bit
nVidia driver 430.39

Godot 3.1.1 stable
OpenGL ES 2.0 Renderer: GeForce GTX 1080/PCIe/SSE2

Flickering happens.

Turning off HDR mostly removes the flickering, but it comes back in some situations I could not narrow down further.

[navaronbracke]

Windows 10 Home
Godot 3.1 stable
GTX 1070, driver 430.86
GLES 3.0 with HDR on, flickering, turning it off fixes it.

Have tested this with a custom grid(Node2D with sprites as children)

[janesteban]

Godot 3.1.1 stable
Windows 10
GTX1080 driver 430.86
GLES 3.0 with HDR off, the flicker continues, when turning on "prefer maximum performance" it looks like it disappears (thanks dev for the partial solution). Glad to see devs are aware of this, looks like is more of a nvidia problem than Godot. Any 1 with amd cards having this issue?

[girng]

GLES 3.0 with HDR off, the flicker continues, when turning on "prefer maximum performance" it looks like it disappears (thanks dev for the partial solution). Glad to see devs are aware of this, looks like is more of a nvidia problem than Godot. Any 1 with amd cards having this issue?

Issue doesn't happen with AMD cards (title says with nvidia drivers btw)

[Zylann]

Having this issue in Godot 3.1.1 on OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2.
I don't have a tilemap, only a bunch of custom draw_texture(). I get random flickering points, but sometimes it's an almost-fullscreen glitch.

[girng]

At this point, I think Vulkan will be the solution to this issue once and for all.

[GammaGames]

I was getting weird flickering in my project too, the Gles 2 Use Nvidia Rect Flicker Workaround setting fixed it though.

[girng]

https://twitter.com/reduzio/status/1155953280368775171 🤤

[Toemsel]

Can reproduce on build 3.1.1 stable with a GTX 980.
Disabling HDR fixes the issue for me.

[agameraaron]

Just an update that I am still seeing tiles pop out & I've tried everything mentioned here so far. I can only hope Vulkan can fix it, but would be nice if they could figure it out for 3.2 as well.

[girng]

I've been really positive lately, but this bug is really wearing me down and becoming very detrimental to my workflow (I've tried everything). To the point where I am dreading to press F5 because of the inevitable black tile flickering. I can tolerate flickering once in a blue moon or something, but the flickering is a constant thing now. I love Godot, there is no turning back now, but it's becoming extremely frustrating.

I don't like writing posts like this because it's not helpful and it comes off as whiny, but I don't know what else to say/do. At the same time, I want core developers to know how this bug is affecting the Godot experience. 😭 Please @reduz / core developers if you can shed light on the status of this bug and what might be the possible solution (Vulkan?), it would be great!

[lamsorsen]

Windows 10 Home
Geforce GTX 1060 driver version 440.97
Godot 3.1.1 stable using GLES3
I've tried a few of the suggestions listed here (disabling HDR, clicking the "Gles2 use nvidia rect flicker workaround" option, and messing with my performance settings) and none appeared to resolve the issue

[drarem]

Same here, getting flickering. Have 3 tilemaps, 1 for water level and 1 for ground level, 1 for clouds with Y-Sorting turned on.

Windows 10 Home
Geforce GTX 1060 latest driver
Godot 3.2 beta compiled from last week, using GLES3
gdscript, have HDR off

See the water tiles popping up intermittently, or flickering.

[drarem]

Updated:

Looks like I have to use GLES2 and click the 'NVIDIA flicker fix' thingy, to get the flicker to go away. Could this fix be adapted to GLES3 by any chance?

[paulhocker]

I just purchased a new ASUS RTX2060 hjoping it would correct the problem, but alas, it was not to be. The flashing continues. Going to try a build with the 3.2 and VULKAN branches.

Windows 10
RTX 2060 Latest Driver
Godot 3.1.1

[mohsenph69]

OH GOD
I try everything, But it is still there, my game work with GLES2 even I activate "2d/gles2_use_nvidia_rect_flicker_workaround", But still flickering.
I love Godot even I love Godot new version 3.1 more, but please solve this problem.

[paulhocker]

Good news is that VULKAN build corrects this problem. So I dont know if this will ever be corrected in the 3.X branch.

[mohsenph69]

So when the Godot with VULKAN built arrive?

[securas]

As far as I know from the comments above, this will not be fixed in Godot 3.x, which prevents any tilemap-based project with GLES 3. The devs state that this is an NVIDIA issue so there's not much they can do about it. You can either wait for 4.0 with Vulkan (no less than 6~8 months), which will take a while, or start with 3.x and hope for an easy upgrade to 4.0. I doubt that the upgrade will be easy though, especially if you're using GLES 3 features like fancy shaders and GPU particles.
My workaround has been to use y-sorting on the tilemap options. This seemed to have reduced the frequency of the problem. Nevertheless, I still had players complaining that occasionally, parts of the game world would vanish.

[CrowbarKZ]

If it's NVIDIA issue, why doesn't it happen on, say, Unity? (Just wondering)

[securas]

Commercial libraries vs open source libraries, I think. Check previous
posts by devs.

On Sun, Jan 12, 2020, 21:33 Sergey Kospanov [e-mail]
wrote:

If it's NVIDIA issue, why doesn't it happen on, say, Unity? (Just
wondering)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913?email_source=notifications&email_token=AAV7RW2ZZLY7ZYQ46RUK7KDQ5ME3HA5CNFSM4DUVCVVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWY4MQ#issuecomment-573410866,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV7RWYIXVBYAYGZ3VLSPF3Q5ME3HANCNFSM4DUVCVVA
.

[Calinou]

@securas That's not true, as many other open source frameworks don't suffer from this issue (even if they use OpenGL for rendering).

This is just a bug that happens to be very difficult to diagnose, and no one is currently willing to put the time in it.

[akien-mga]

This is just a bug that happens to be very difficult to diagnose, and no one is currently willing to put the time in it.

To clarify, current understanding is that we're hitting a Nvidia drivers bug. It's triggered by the way we use the OpenGL API, and if other projects don't run into the same issue, it's because they likely use OpenGL different, or understood what triggers the bug and wrote workarounds to prevent it (like we did with an option for GLES2, at the cost of performance).

The way we use the API is, to our understanding, completely appropriate as per the OpenGL specificaiton. But driver bugs mean that even a legal usage of the API can produce problematic results.

[securas]

My bad. Sorry about that. I have very little understanding of the
implementation details.

On Sun, Jan 12, 2020, 22:46 Rémi Verschelde [e-mail]
wrote:

This is just a bug that happens to be very difficult to diagnose, and no
one is currently willing to put the time in it.

To clarify, current understanding is that we're hitting a Nvidia drivers
bug. It's triggered by the way we use the OpenGL API, and if other projects
don't run into the same issue, it's because they likely use OpenGL
different, or understood what triggers the bug and wrote workarounds to
prevent it (like we did with an option for GLES2, at the cost of
performance).

The way we use the API is, to our understanding, completely appropriate as
per the OpenGL specificaiton. But driver bugs mean that even a legal usage
of the API can produce problematic results.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9913?email_source=notifications&email_token=AAV7RW2U4Q6NE3R62ME75GDQ5MNJVA5CNFSM4DUVCVVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIW2LOI#issuecomment-573416889,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV7RW4WGXFM7MQZKAQJ4X3Q5MNJVANCNFSM4DUVCVVA
.

[lawnjelly]

This may well be due to vertex buffers currently being reused multiple times per frame (which is also probably causing the performance issues). I.e. the vertex buffer is being used to draw one object, changed mid way to start drawing the next. Am investigating.

I suspect that proper 2d batching will solve this and 2d performance issues.

[Lilith-In-Starlight]

It doesn't seem like an Nvidia issue. It also happens to me and a friend (AMD and Intel, respectively), and, ironically, it doesn't happen to my other friend, who uses Nvidia. Everything that's specified in this thread happens to me and my Intel friend.

[bionick7]

I have this issue to on an integrated Intel HD Graphics 620 on my laptop. Switching to GLES2 fixes it for me. Another thing for me is that it seemed to only occur with 2D Lights on

[paulhocker]

interesting -- i will need to check if i have lighting on as well

[paulhocker]

sorry to report that I did have this in my scene, but removing it had no effect. to me it seems more because of the amount of tiles on the tilemap -- who knows

[paulhocker]

i did an interesting experiment yesterday -- i created the same map using TILED and imported it with VNEN's TILED importer and there is NO FLICKERING -- so this is leading me to think that it is something else in the scene, or the way i setup the tilemap -- so i am doing some more research and will report back

[jonbonazza]

FWIW, ive always only used Tiled and I still got the issue.

[paulhocker]

@jonbonazza i am sorry to hear that -- makes me feel like there is no hope on this one until 4.0 arrives -- or I use GLES2 which I would prefer not to use

[JakeBaumbaugh]

Also found myself running into this issue. Does it still persist when program is compiled and run as an executable, rather than in the Editor?

[Calinou]

Does it still persist when program is compiled and run as an executable, rather than in the Editor?

Yes, as rendering code between the editor and a release export template is identical.

[Firty]

I have a computer: i3 2120, gt630.
On this computer everything works perfectly. On my other computer: ryzen 1600, gtx1060. The tiles flash like crazy ... Both with windows 10 pro x64.

[Firty]

Driver name: GLES2
Gles 2 Use Nvidia Rect Flicker Workaround: On
My 1060 runs on average 30~50 Fps
Waiting the Vulkan...

[lawnjelly]

Anyone having this in GLES2 might want to try the test builds we are making on #37349. It is possible it may help as it uses a different method for drawing rects.

[Shawak]

Having the same issue. GTX 1060 6GB and Ryzen 7 1700X. Enabling cell_y_sort fixes it for me, but causes huge performance issues (fps drops). Same for setting cell_quadrant_size to 1.

[lawnjelly]

Just to ask again, can anyone try the 3.2.2 beta with use_batching set to on? Also this time, set use_nvidia_workaround to on as well.

Unfortunately no one with the flicker problem tested it since my earlier comment :disappointed: (naughty testers), and since that time there is now a backup path for single rects, using the old method which may reintroduce the problem

However, if it is cured with batching AND the nvidia workaround, it will confirm that the uniform drawing method is the cause of the flicker problems, and it can be removed, thus curing the problem for good.

[Shawak]

So I just downloaded the 3.2.2. beta 1 and using Driver Name: GLES2 with Use Batching and Gles 2 use Nvidia Rect Filcker Workaround seems to fix the problem. Although I didn't test it for a very long time yet (since the flickering on 3.2.1 only accours after a couple of minutes, atleast for me).

[lawnjelly]

So I just downloaded the 3.2.2. beta 1 and using Driver Name: GLES2 with Use Batching and Gles 2 use Nvidia Rect Filcker Workaround seems to fix the problem. Although I didn't test it for a very long time yet (since the flickering on 3.2.1 only accours after a couple of minutes, atleast for me).

Ah that is great. I suspected it would. By using the workaround for single rects, we know that works and doesn't cause flicker. But the rest of the sprites will be drawn using the batching code which draws using indexed primitives, and I suspected that might solve the problem and this does seem to. :+1:

I'll have a look and see whether we can remove the old uniform method entirely from the batched renderer, that should solve the problem for good. In the mean time, the batched + nvidia workaround combination you will probably find is faster anyway than the old renderer, and doesn't flicker.

[Shawak]

Yeah it's definitly faster. Using godot 3.2.1 stable with the GLES2 driver I hit only 20 fps, while using godot 3.2.2 beta 1 I hit 60 fps easily. But I am curious:

I'll have a look and see whether we can remove the old uniform method entirely from the batched renderer, that should solve the problem for good

Does that mean there will there be a fix for GLES3?

[lawnjelly]

Yeah it's definitly faster. Using godot 3.2.1 stable with the GLES2 driver I hit only 20 fps, while using godot 3.2.2 beta 1 I hit 60 fps easily. But I am curious:

Ah that's good! :grinning:

Does that mean there will there be a fix for GLES3?

GLES3 I haven't done anything on so far. We could possibly end up doing a vastly simplified and cut down version of batching just to tide GLES3 guys over until 4.x is released (but I can't make promises at this stage, there's a lot on the roadmap). That should solve the problem on GLES3 too if it occurs there.

[Zireael07]

We could possibly end up doing a vastly simplified and cut down version of batching just to tide GLES3 guys over until 4.x is released

Pleeease (what is the timescale until 4.x, to put it in perspective? I suspect several months, if not half a year)

[paulhocker]

I think a fix would be needed if there were hundreds of people reporting this problem. I don't think we have that. At least this thread is not suggesting it.

That said, if there are some commercial releases that are suffering from this it might be good to help them out. If I had more experience I would dive in myself, but I would not know where to begin. I have just started exploring the Godot code, which is very well written by the way.

This is where it would be nice to have a voting system for crucial bugs that need to be fixed.

My vote is to wait for 4.x, and have resources focused on that. We know Vulkan already solves this problem.

[Calinou]

This is where it would be nice to have a voting system for crucial bugs that need to be fixed.

In my experience, voting is generally not conductive to getting bugs fixed faster. This is true in community-developed projects, but even commercial proprietary software faces the same issue (look at Discord's feature tracker).

[paulhocker]

True. I am not suggesting it would help get it fixed. It would be more of a gauge on how wide spread the problem is. I suppose the number of people involved in this discussion could be a gauge. At any rate, I am pretty much done with this thread, and will patiently wait for 4.x

[RamiAwar]

I'm also facing the issue. I never faced it when autotiling normally. If I drew the map by hand ( which I did in another project, using the same tilemaps ) I never came across this issue. But when I came to render a procedurally generated dungeon using tilemap.set_cellv( ... ) I encountered the issue consistently. I all suggestions, and the only one that worked was using GLES2 with the workaround. This is a pretty serious issue though! Most basic tilemap rendering is failing. Why isn't there a workaround for GLES3 btw? I know some OpenGL, I've written a basic game engine that renders textures with shaders but nothing more. Can someone explain what's causing this exactly? Hopefully I can understand. <3

[gcardozo123]

I'm also facing the issue. I never faced it when autotiling normally. If I drew the map by hand ( which I did in another project, using the same tilemaps ) I never came across this issue. But when I came to render a procedurally generated dungeon using tilemap.set_cellv( ... ) I encountered the issue consistently. I all suggestions, and the only one that worked was using GLES2 with the workaround. This is a pretty serious issue though! Most basic tilemap rendering is failing. Why isn't there a workaround for GLES3 btw? I know some OpenGL, I've written a basic game engine that renders textures with shaders but nothing more. Can someone explain what's causing this exactly? Hopefully I can understand. <3

There are already some explanations on this thread. I suppose that at this point there won't be new workarounds or fixes for this issue until the 4.0 (vulkan) release, unless the community comes up with something. IMHO the maintainers are correct in not worrying with a potentially complex fix now that 4.0 is on the horizon.

[lawnjelly]

Why isn't there a workaround for GLES3 btw?

I hadn't actually noticed that, I might have a go at porting the workaround code to GLES3 tomorrow. It will be slow though if we can get it working.

[lawnjelly]

I've now got a WIP PR (see above) for the workaround for GLES3. I've also got some ideas for fixing the uniform drawing method, as the shader seems overcomplicated for what is needed. I might need some help testing that if I do a fix, as I can't repeat the flickering on my machine.

[paulhocker]

I think I can help with that. I should be able to do a custom Windows build on your PR.

[lawnjelly]

I'm now working on rewriting the fast path shader to prevent flicker. I now have a prototype available for trying in #38628. I would greatly appreciate if someone could try it out who has hardware that exhibits flicker, instructions are in the PR.

[lawnjelly]

Well update:

• it seems the GLES3 workaround works fine :partying_face: (_it should be in the next beta_),
• however the experiments with the fast path shader didn't help :disappointed: , and after that testing it seems the shader can probably be ruled out as the cause.

So currently I'm thinking in terms of it being some weird situation in terms of binding failing on our side only on nvidia, or a driver bug (maybe not envisaging this method of drawing perhaps, or not testing it?).

Anyway the good news is that

• with GLES2 with batching, you shouldn't even feel the need to use the fallback method in 99% of games, thus you won't get flicker
• And with GLES3, the nvidia fallback is confirmed to work to prevent flicker, albeit at a performance cost.

At this stage, I think my time would be more productively spent getting some batching working in GLES3, which would make the performance difference moot. :+1:

[mrcdk]

@lawnjelly It's is a driver bug and how it deals with power managment. In this comment you can find my findings.

[lawnjelly]

@lawnjelly It's is a driver bug and how it deals with power managment. In this comment you can find my findings.

Ahha! :grin:

One of the problems is this thread has become so long now! Actually API trace is a very good way of determining this if you get the flicker on your hardware, and I'm in agreement if you get different results each time you replay the trace that does point to a driver bug. :+1:

[Shfty]

@securas Did you ever confirm that the issue in the video you posted was being caused by this flicker bug?

I'm seeing similar single frames of black background + horizontal white lines in my own project with both the built-in camera drag feature and a custom camera script, and none of the mentioned workarounds (GLES2, NVIDIA flicker fix, disable HDR, various different kinds of viewport allocation) prevent it from happening:

This is on 3.2.1 stable, Windows 10, GTX 1080.

The scene has four 1400x800 tilemaps stacked on top of eachother for the black far background, zigzag near background, foreground and camera collision.

I'd be much obliged if anyone can offer some insight - writing a robust workaround is going to be a considerable chunk of project time that I'd rather not commit to if it can be avoided.

[securas]

If I remember correctly, it was due to 2d pixel snapping set to off.

[lawnjelly]

@Shfty That actually looks like it may be a different issue. That would seem to be confirmed if the nvidia workarounds don't fix it. Would you be able to open a new issue, with hardware details and a min reproduction project?

[Shfty]

@lawnjelly That sounds about right. I've opened #39720 with a minimal reproduction project based on the scene in the above gif.

I managed to fix the issue by nesting the affected scene inside its own Viewport node, so have included an example setup for that inside the project as well.

[RobertBColton]

That gif looks to me like vertical synchronization/screen tearing in a way.