good_web_game::graphics::draw not working correctly on Windows

[MOj0]

In my game I am doing something like this in order to draw multiple rectangles using a single Mesh instance (in different destinations of course, but I deleted that code for brevity):

graphics::draw(
                ctx,
                quad_ctx,
                &self.my_mesh,
                graphics::DrawParam::default(),
            )
            .unwrap();
graphics::draw(
                ctx,
                quad_ctx,
                &self.my_mesh,
                graphics::DrawParam::default(),
            )
            .unwrap();

This works fine on Linux (Ubuntu 22.04)

However when running the same code on Windows it looks like this:

I don't know what the issue is, but it seems only one (the last) out of three rectangles got drawn.
Also there were similar issues with drawing text, where text from one draw call got mixed up with another, but I fixed that by using the queue_text function.

[PSteinhaus]

Hmm... thanks for sharing.
Does the blend modes example run properly for you? It too draws a single mesh multiple times similarly to what you're doing and last time I checked it ran fine on Windows (but I guess I'm gonna re-check just to be sure).

[MOj0]

Yes, the blend modes example is working fine - it is behaving the same way as it is on Linux.

We can take a look at another issue. I added a debug draw mode, where the grid for collisions is drawn (and some other stuff aswell eg. number of objects drawn, player's grid index, guard's rays).
This is correctly drawn on Linux:

However on Windows it looks like this:

The grid is actually flashing at a higher rate, but since I lowered the fps you can't really see that, however it gets the point across.
You can also see the text not being drawn correctly in the top-left, if you compare it to the one being drawn on Linux (I didn't use graphics::queue_text here). It says "player grid" instead of number_of_objects_drawn / total_number_of_objects. Upon further inspection I noticed the text was actually drawn correctly on the first frame of debug draw, but it gets replaced with "player grid" on all the other frames.

[PSteinhaus]

Ok, my assumption here is that these bugs are related to #59, or, more precisely, the fix I used for it.

I added this to keep bindings of dynamically allocated meshes alive for one more frame before being dropped, which solved a bug particular to Windows and Nvidia graphics as far as I know: Just dropping the bindings after they were used wasn't really workable there, as their meshes wouldn't get drawn then, probably due to the necessary resources having been released before they were no longer needed.

I realize that this is a very crude twigs-and-duct-tape fix to the problem though.

In your case it might or might not help to simply crank the number of frames (currently 1) up by one or two. If that works I would merge that change into the master branch, in order to hopefully avoid such problems for others (though I realize it's still just twigs and even more duct tape, but hey, at least somewhat of an improvement, maybe).

A more reasonable approach might be to not create, use and then drop the meshes inside of your draw or update cycle, but to instead have them created once and then stored somewhere, until you're sure that you no longer need them.

One advice that I'd definitely give you is to try out the MeshBatch struct for drawing a single mesh multiple times, as it uses instanced drawing, thereby probably improving performance and possibly even solving your problem all on its own (though this is just a wild guess).

If you could fork gwg and just change this one number and see whether this seemingly solves your problems I'd be very grateful.

[MOj0]

You were right, using the MeshBatch solved the issue.
Since this worked, I didn't fork gwg and do what you said, so I unfortunately cannot give any feedback for that.

[PSteinhaus]

Glad to hear that :)
I'll still keep this open as it's likely that someone might run into such an issue again.