Debugging the Ancient "Adventure Select Screen" MAV ***WE FIXED IT!!!***

The Wonderland Open Source Project

Moderators: ILoveWonderland, Sammy_P, Lazy Loof

Post Reply
User avatar
MyNameIsKooky
Rainbow Spirit Master
Posts: 9711
Joined: Mon Dec 01, 2008 10:18 pm

Debugging the Ancient "Adventure Select Screen" MAV ***WE FIXED IT!!!***

Post by MyNameIsKooky » Fri May 24, 2019 11:26 pm

EDIT: We managed to fix the Adventure Select Screen MAV! Download the fixed executable here (also contains the modified player.bb source file): https://www.dropbox.com/s/4zhh3rr8ssp9x ... x.zip?dl=0

This fix will be included by default in v10.05.


For historical purposes, I am keeping the original post below.

* * *

In this topic, I am going to talk about a bug that has been present ever since the WA1 editor came out. This bug is the fabled MAV error that sometimes appears on the adventure select screen, seemingly at random. Because it has been such a prevalent (and annoying) issue over the years, I am giving this issue its own topic. I seem to have found the ostensible source of the MAV, but more research is required, and having help from the other modders in this community would be good.

Here's what we already knew prior to the open source release: when a player has a large number of custom adventures installed, the adventure select screen lags much more. This high lag appears to have a correlation with how frequently the adventure select screen crashes. Less lag means the screen seems to crash less often, and more lag means the screen seems to crash more often. Also worth noting is that a higher amount of lag appears to correlate with the text "smearing" across the screen.

The first thing I did, of course, was launch Blitz3D's debugger. I was able to discover the line on which the MAV occurred (note the text smear on the adventure select screen):

Image

In the log, the error line is highlighted. Here's the full function where the error occurred:

Image

The function is called RenderGame. It is located in player.bb.

I ran the debugger several more times. Every single time, the MAV occurred on one of the two RenderWorld calls.

RenderWorld is a built-in Blitz3D function created to render everything onto the screen. Hence, we can conclude that our MAV has something to do with rendering. I did a bit of research, and I found out the RenderWorld function only throws MAVs under some rather extreme circumstances (http://mojolabs.nz/posts.php?topic=22541):

1. Manually manipulating the vertices, triangles, and/or surfaces of entities in improper ways during runtime.
2. Rendering a surface with more than the maximum number of triangles. This number is somewhere in the realm of 40,000 triangles.
3. Playing a frame of an animation which does not exist.

This means the true source of the problem isn't either of the RenderWorld calls themselves. Instead, it must be some other rendering routine elsewhere that creates and/or manipulates vertices for RenderWorld to use.

As for what rendering routine that would be... let's recall the text smear that is frequently present around the time the MAV occurs. I figured that examining the text rendering would be a good place to start.

Near the start of the RenderGame function, prior to calling RenderWorld, there is a call to a function called RenderText. As the name suggests, this is WA's function for rendering text, and its implementation lives in particles.bb.

Image

Note the region that I have circled in red (OK, it's a square, not a circle, but I have no time for your pedantry). This for loop appears to render text glyphs on a texture surface. To do so, it constructs quads out of triangles by building the vertices manually. Recall the list I posted above about RenderWorld's conditions for throwing a MAV. This code could be a prime candidate for causing a RenderWorld-related error.

What I did was comment this entire code block out and see if that changed the outcome at all.

As a result of this change, all of the game's text was, of course, invisible. However, no matter how hard I tried, I could not get the game to MAV on the adventure select screen.

What's interesting to note is that even though the text was gone, the game still lagged on the adventure select screen. However, even though the game started to lag intensely, there was still no MAV. Hence, we can conclude that the adventure select screen lag and the MAV most likely have unrelated sources. However, we can assume from past experience that higher quantities of lag increases the probability of a text rendering error occurring, so the issue of the lag influences the issue of the MAV.

The conclusion I have drawn from this is that the infamous adventure select screen MAV is caused by some sort of fault in the text rendering routine. The text smear that occurs may very well be related to this issue.

With this conclusion in mind, I ran one more experiment.

Image

I decided to comment out the ClearSurface line (marked here in red) that appears right before the glyph-rendering loop. As a result, the main menu's text stopped animating, but it still ran fine... for a brief moment. However, after a few seconds, even the main menu screen throws a RenderWorld MAV. In other words, with the ClearSurface line commented out, a RenderWorld MAV occurs much quicker than usual. Perhaps this is a MAV related to a rapidly-accumulating number of triangles approaching that deadly 40,000 mark without being deleted? Think of the adventure select screen's text smear. Could that smear be the result of undeleted triangles still being present from previous frames, thus drawing extra copies of each text glyph? With more adventures being present in your adventure select screen, the game would have more text glyphs to render, and hence have to create more triangles. Do we have a memory leak on our hands? Are we leaking triangles? Food for thought.

Writing the above paragraph gave me one more idea. I decided to run the game in its unmodified state one more time.

Here is what the text looks like with no MAV:

Image

And here is what the text looks like with a MAV:

Image

There is a subtle difference between the text in both cases.

Image

In the MAV case, the anti-aliasing appears to be much darker and much thicker. This is symptomatic of multiple copies of the same text being drawn on top of each other, which would also explain the smearing case.

It's worth noting that smearing and faulty anti-aliasing can also be the result of not properly clearing buffers and/or textures. As I experimented with above, the undeleted triangles may be present due to not properly clearing the text surface.

Extra triangles... 40,000... the cursed number...

More research is required to create a solution for this problem.

tl;dr The adventure select screen MAV appears to be related to the text rendering routine. There is evidence that a memory leak may exist in the form of undeleted text triangles; the text surface might not be getting cleared properly.
Last edited by MyNameIsKooky on Sat May 25, 2019 3:49 am, edited 2 times in total.
User avatar
Sammy_Bro
Rainbow Star
Posts: 1738
Joined: Thu May 07, 2009 8:58 pm

Re: Debugging the Ancient "Adventure Select Screen" MAV

Post by Sammy_Bro » Fri May 24, 2019 11:35 pm

good write-up. do we know if there's a routine to view the number of visible triangles?

additionally, i bet a bug like this could also be cured with a solid overhaul of the adventure select screen (maybe by being able to see only the folder of a user or other various search options?) to help supplement being able to show less adventures on a screen at a time, to hopefully lessen the total triangles?
:D
User avatar
MyNameIsKooky
Rainbow Spirit Master
Posts: 9711
Joined: Mon Dec 01, 2008 10:18 pm

Re: Debugging the Ancient "Adventure Select Screen" MAV

Post by MyNameIsKooky » Sat May 25, 2019 1:59 am

Yeah, there's a triangle counting function. Kyuu helped me out by providing this debug line:
DebugLog "Number of Triangles in Surface: "+CountTriangles(mySurface)
It turns out my hypothesis was correct - the problem is indeed related to triangle counts. When the triangle counts on the text surface reach around 30,000, the MAV occurs.

Incidentally, the more triangles there are, the more the game lags. The lag and the MAV are more closely related than I originally thought.
User avatar
MyNameIsKooky
Rainbow Spirit Master
Posts: 9711
Joined: Mon Dec 01, 2008 10:18 pm

Re: Debugging the Ancient "Adventure Select Screen" MAV

Post by MyNameIsKooky » Sat May 25, 2019 3:04 am

The MAV has been fixed! It turns out the same DisplayText routines were being called multiple times per frame. It wasn't just affecting the custom adventures menu - it was affecting other parts of the game UI as well, such as the adventure title screen and the pause menu! DisplayText also calls the AddLetter function, and AddLetter being called so much is what caused the lag in the first place. It turns out both issues had the same source after all!

The menu rendering code was located inside of the render tweening loop, which in turn is inside of the game's main loop. The UI code being placed in that extra loop seems to be a mistake. By simply moving that menu-rendering code out of the tweening loop, everything works properly! That means we aren't getting drowned in tons of text glyph triangles that we don't need!

I've attached a fixed wg.exe. The adventure select screen MAV and lag seem to be gone!

Download the fixed executable here (also contains the modified player.bb source file): https://www.dropbox.com/s/4zhh3rr8ssp9x ... x.zip?dl=0
Post Reply