I’m not sure what the first step would be.
I’m wondering if it’s either a state issue, or a shader issue.
One way would perhaps be to debug it using RenderDoc on windows
I’m not sure what the first step would be.
I’m wondering if it’s either a state issue, or a shader issue.
One way would perhaps be to debug it using RenderDoc on windows
Yes, for me it is the same issue, workaround is to reduce atlases amount - it is always happening for one atlas (e.g player’s atlas like here), and when you move player’s sprite to the background’s atlas everything is OK.
Also I am confirming that HTML5 and Windows builds are working without such issue, and in Editor view everything is OK, yet it occurs only when running from Project->Run.
Also Windows (64bit), laptop with integrated graphics
Thanks to all of you for helping me figure this out.
How would I do this?
Edit: I am wondering if there is such documentation or any other information regarding this issue with the gpu.
I had run it already and it was attached to the regarding topic, I will try to find it
EDIT:
This is the thread, some more findings are there and there is a Github issue reported for this. Regards atlases used for both GUI and GO.
When you say “Window build”, you mean you’ve bundled for Windows?
I mean, “Build and run” from the editor, is a Windows build too (if your’re using windows)
If that’s the case, there seems to be a difference in how the content is created between the editor build pipeline and bob (bob is used for HTML5 and bundling).
Yes, yes
Oh! I missed this bit of information. So it’s only when you do Project->Build that the problem happens?
I can confirm yes for myself. This only happens when doing project > build.
Yes. Bundles are OK and on Windows bundle in Renderdoc everything is rendered, it’s just not visible in the build from Editor.
Also, it is not a matter of wrong z-ordering as I checked this and the sprite was not visible (in Project->Build ofc) even if there was only this particular one in the scene.
Seems like the issue is with handling more than one atlas (or few - there is no number of atlases I could say is always the same) or some atlases being “broken” for some reason. In particular projects, when this happens it regards always one particular atlas. When you move the images from that atlas to other one - everything works. I don’t know why in different projects this happens or not, depending on amount of atlases used in the game.
Notice also that one strange behavior, that was described in the linked thread - when you switch screen (with Monarch) and some other textures/atlases are loaded for this scene, the sprite in the screen below is instantly becoming visible (example of this is described thoroughly in that thread and there are gifs showing it).
Like adding more textures on the screen is magically helping solve this issue.
So you are able to cause the atlases to display on build by changing them or replacing them and/or adding more? This is a bit confusing for me, as you might understand. Not knowing exactly how to make this work is really making me feel skeptical to continue using this game engine. I have learned Lua as my main programming language and finding Defold got me super excited to get working on some games. But if there’s something I can’t control, like the sprites disappearing (which seems like it’s something that shouldn’t be a problem) for no clear reason, I am worried that my efforts will be wasted.
It is a bug and we will look into this issue during the week and hopefully provide a fix in the next release.
Recently I sold my dedicated GPU, so I temporarily have to use iGPU (Intel UHD Graphics 630). The result is that I got the same bug
I confirm that it happens only if you do Project/Build. I want to help fixing the issue, but the bug doesn’t appear when you launch the Defold game through RenderDoc. Hm.
Yep, exactly, that’s why when I reported it the first time it got stuck
Yes - for example:
When it happens that for hero.atlas the bug occurs - I move sprites from hero.atlas to background.atlas and it is working.
Simply, if I move images from “broken” atlas to another, sprites are visible correctly.
This is not a satysfying workaround of course, I do have a proper system for packing sprites in atlases and when such bug occurs for some atlas, it is not cool
Thanks! I can try to use this as a temporary workaround. I see that this wouldn’t be such a great way to make it work, since it doesn’t explain what the issue is. But much appreciated!
I’ve been going through the default render script and just fiddling around with the materials and such, trying to see if I can at all recreate a scenario that would cause all sprites to appear. I haven’t made any sure findings yet, but it seems that every once in a while, all of the sprites will in fact render properly. When that happens, I close the build, and try to build again without changing anything, but then only a few sprites show up again.
First I noticed that the tags in the “tile” material and “sprite” material both have the same tag, “tile”. I tried changing the tags and separating the sprite material with its own tag, “sprite”. Then I just changed accordingly in the default render script by adding a separate predicate named “sprite” also. Then inside update() I put in render.draw(self.sprite_pred)
. It fooled me! I got the build running and voila! All of the sprites were showing. I was so excited but then I tested it again… The sprites were gone again .
I just made a little discovery.
This. I think it’s the sprite vector position? Maybe something completely different, I’m not sure. But what I do know is that if I go into the script and change this line:
and change the 1.0 to something higher, (Which seems to shrink everything) I am able to see the other sprites every time. Here are some screenshots to demonstrate:
This was at 1.0
:
and this was at 2.0
:
I recall when I just started (which was like 4-5 days ago) I realized there was something covering the tilemap I was working on. I’m sorry, I can’t remember how to replicate this. But I will keep trying to so I can show you all that there is possibly some kind of “cover” that’s covering the sprites. Maybe it’s a clipping area?
Do you guys have any other ideas based on this discovery?
Edit: I think it’s actually the view projection, not vector position.
The .vp file is the vertex program and it is part of the material and shader of a visual component in Defold:
This new info reaffirms my belief that it’s a shader issue.
My guess is that the shader generated by the editor is slightly different from the one produced by bob.jar. Not the code you see, but the preamble that we put at the top of the shader.
So we should be able to compare the quite easily right?