I've found a strange bug. It caused me lots of headaches this week until I isolated it. Or at least kind of isolated. I managed to make an MFA that reproduces it, but how/why/when exactly the bug happens still makes little sense to me. It started when I noticed a very disconcerting bug in my game where certain enemies would behave differently on 2 different computers, despite using the exact same MFA. I even found situations where the problem would reproduce on the same computer, under specific circumstances - for example when running edrtex.exe vs 'Build & Run'. You can see the problem in the GIF below - the blue object is supposed to move identically in both cases, but in the bottom example it starts climbing the wall about 50 pixels too early.
Over the course of various tests and experiments, I found a whole bunch of factors that seemed to affect this bug. For example, turning machine independent speed off, doing 'build & run', or just running the MFA on my laptop, all increased the chance of the bug occurring. On the other hand, turning machine independent speed on, increasing vsync back buffers to 3, or even just making small unrelated changes to the MFA (thereby perhaps forcing some refresh of a cache?) all seemed to help prevent it.
I finally identified the culprit of the problem, though not necessarily the cause (that is, I know what goes wrong, but not why). Please patiently bare with me as I try to explain the issue, as this seems to be a very elusive and inexplicable bug, and the steps required to reproduce it seem almost nonsensical.
The problem is related to a particular detector object that I use to help the blue object (seen in the GIF) navigate the environment. This detector object has 2 frames. The first is a 50x50px square (which serves as an icon that is easy to see in the Frame and Event List editors), while the second is the actual detector that gets used at runtime - a flat rectangle shape:
Now, the first frame has its hotspot in the top-left:
...while the second frame has its hotspot in the centre (at x=31):
Now, here's the line of code that is causing the bug. When the detector hits a wall, I record the X position of the detector's left edge, and I store this as the altVal turnCornerPoint. The enemy will then start climbing when its X position reaches the value of turnCornerPoint:
It's the left edge part that goes wrong. Sometimes, in certain circumstances, for some weird reason, Fusion reads the X Left information from the first frame of the active, not from its current frame.
I stripped down my MFA until I could isolate the problem in a 100% reproducible way (at least for me, tested on both desktop and laptop). The resulting MFA shows the problem clearly, but also reveals the enigmatic and seemingly nonsensical nature of the bug. Let me explain:
In the test MFA (attached: Attachment 29306 -required), there are 3 near-identical rectangles:
Two are just like my detector, and contain two frames, like this:
While one just contains a single frame:
All three rectangles have their hotspot at X=31. When you run the MFA and open the debugger, the output window displays the same equation for each rectangle: X left - X (in other words, the X difference between the left edge and the hotspot). In each case, the true answer is -31.
As you can see, the answer for the white object (the one with only one frame) is given correctly, while the answers for the others are wrong. They are evidently based on the information of the rectangles' first frames (the hotspot in the first frame of the black rectangle is at X = -99):
Now, here's where it gets weird. There's a Time X object sitting in the frame doing nothing. It has no referenced events, it's just sitting in the Frame Editor:
Now, if we delete this Time X object and run the frame again, suddenly the problem vanishes!:
This is what I discovered when I stripped and stripped my MFA until the bug went away. Eventually I had deleted everything until I had just one single event left, which happened to reference the Time X object. Once I deleted that event (and the object), the problem was gone.
Well, that's problem solved, right? The Time X object is causing some sort of conflict - end of story? Well, not quite. I went back to my main game MFA and deleted every Time X object and every event that references it. Then I quit Fusion and reloaded it....and the X Left bug is still there! So while removing Time X very clearly resolves the problem in my example MFA, it actually doesn't do anything in my main game, which is where I found the bug in the first place.
In fact, let's return to the demo MFA. We'll reinstate the Time X object, which again produces the bug (as we can see by the debugger not showing -31 for all objects):
And now, let's add in a simple, empty Static Text object. Now, the problem magically goes away, even though the Time X object is still present:
Hopefully the MFA I attached above can help Clickteam fix it. But keep in mind that the bug seems more elusive than that MFA alone suggests. As mentioned, it seems to interact (either positively or negatively) with machine independent speed, vsync, triple buffering, building the EXE (vs running edrtex.exe), and even just making unrelated changes in the MFA (eg. adding a line of code or changing some pixels in a graphic). There's a clear interaction with the Time X object at some times, but an ambiguous and/or non-existent one at other times. It's even affected by a Static Text object, so who knows how many other objects/factors might come into play. Oh, and I haven't tested X Right, Y Top etc. but I assume they have similar problems. Thankfully, XActionPoint seems to be ok, though I only tested it briefly.
For now, I guess I'll just avoid using X Left (and X Right, Y Top, etc.). Though a fix for (or at least some insight into) this bug would be greatly appreciated. Thanks.
Reply With Quote
Originally Posted by Volnaiskra
