510.1345 causes Frame Stuttering and Freezes

ID:2095793
 
Jun 6 2016, 6:21 pm (Edited on Jun 6 2016, 7:15 pm)
BYOND Version:510
Operating System:Windows 7 Home Basic 64-bit
Web Browser:Chrome 49.0.2623.112
Applies to:Dream Seeker
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Updated to 510.1345 from 510.1309. Tested several games, in both notable visual slow down occurred, and in one instance one game froze completely 3 separate times. Reverted to 510.1322 > problem was gone.

Numbered Steps to Reproduce Problem:
Explained above.
Code Snippet (if applicable) to Reproduce Problem:
N/A


Expected Results:
^
Actual Results:
^
Does the problem occur:
Every time? Or how often? yep
In other games? texted 2 different projects.
In other user accounts? idk
On other computers? idk

When does the problem NOT occur?
when i revert to lower builds.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
510.1309-510.22 at the least.

Workarounds:
Jun 6 2016, 7:12 pm
I need a test case for this. I can't investigate this issue without information.
Jun 6 2016, 7:15 pm
What is sufficient for a test case
Jun 6 2016, 8:43 pm
If you have source that shows the problem, that would be something.
Jun 6 2016, 8:44 pm (Edited on Jun 6 2016, 8:59 pm)
Not sure the source is the problem.
*Editted Elaboration*
I've been working from Ki Warriors for months. It's never shown this type of slow down until today when I updated to the latest version.

Upon seeing the frame rate issue, I waited for a few mins to see if it was my PC - then opened up a second source I've been working on for SS:O .

That one completely stalled out.


Considering that SS:O is relatively new and being worked on all the time, its perfectly possible that its an error on my part.

On the other hand considering Ki Warriors has been refined for a few months, and has been hosted for weeks at a time with 0 down time that is much less likely of an issue with source code.

In both instances, both projects showed sighs of slow down, and in one case flat out stalled the game (dream seeker.exe) entirely.

Jun 6 2016, 8:45 pm
I should note it would also be extremely helpful to narrow down the version where this occurred. There was no change in 510.1323 that would account for this, so it obviously would have been a later development.
Jun 6 2016, 8:45 pm
In response to Avidanimefan
Avidanimefan wrote:
Not sure the source is the problem.

I'm not sure it is either, but it would be something I could run and test myself.
Jun 6 2016, 9:17 pm
That being said, I really don't feel inclined to share any of my code with you(based entirely on past experiences - you see reputations go *both* ways).

There was a time (1-2 years to be exact) where if someone (anyone) from this community would have stopped trying to ostracize me and tell me what I am instead of finding out what I am-- I'd have gladly worked with them. The problem is that never happened, instead, what occurred was a persistence and perpetuation of rumors, and most of the time flat out lies.

Past experiences dictate that what I do or say won't matter because the situation is going to be warped in a way that is fitting to the narrative of "BYOND community" regardless of what I say or do.

I'm no longer taking steps to clear up misconceptions. I'm not longer open to possibilities or networking. That's not my doing. I've done all the trying I'm going to do.

I just bought a problem to your attention, if there's anything else I can do to help you locate it -aside from sending you entire source codes) by all means let me know.

Likewise if you just want to dismiss it and don't care- that's also fine.

I already reverted to lesser versions and my work goes on.
Jun 6 2016, 9:58 pm
Unless you're referring to some kind of reputation for sharing people's code without permission, which would be news to me since I don't do that, I don't see how it follows that I can't be trusted to look at it.

The reason I asked for source is twofold: First, I insist on compiling any test cases myself. Second, it's extremely important to know exactly what's going on with a particular object. If I see something in the debugger that stands out, I need to know what sorts of vars and flags are involved that might explain it.

This report is too vague to act on without more info. I can't reproduce the problem without a test case, and without reproducing it I can't fix it. This doesn't happen to all games, so there's likely something particular about your game--by which I do not mean anything wrong or badly programmed or anything of the sort, but just something different from all the other cases I've tested--that makes this issue stand out. Being able to investigate that difference directly is the only way to clarify where the problem is.

It doesn't have to be a whole game, just something that demonstrates the problem. If you can't collapse it to a simple test case, the whole game will do, but I need something to look at.

510 is still undergoing maintenance releases and if there's a performance issue I can fix without needing to bump the major version, I'll gladly do so. (And if there's one I can fix with 511, I'll gladly do that too.) What I can't do is fix a performance issue I can't even evaluate.
Jun 6 2016, 10:01 pm
if there's anything else I can do to help you locate it -aside from sending you entire source codes

Best course of action would be to find the exact version where the slowdown starts. 509.1309 is a pretty big jump to 510.1345.

If you can narrow down the exact build where rendering took a major performance hit, there's a strong possibility that Lummox can narrow it down to a specific feature or change based on the version number alone.
Jun 6 2016, 10:04 pm
That's often the case, but because 510 went through the whole thing with the big-icon reorg, I have serious doubts I'll be able to find the exact cause without debugging. Still, the effort to narrow things down couldn't hurt.
Jun 6 2016, 10:09 pm
Oh, also: Since you mentioned 510.1345 caused freezing, it would be very helpful to try catching that in WinDbg. If the game is completely hung up, then WinDbg should be able to break in and get a stack trace of the spot where that happened. That stack trace would be an enormous clue.
Jun 6 2016, 10:10 pm
but because 510 went through the whole thing with the big-icon reorg, I have serious doubts I'll be able to find the exact cause without debugging.

Having a client-side profiler that told us which specific processes were taking up how many milliseconds of rendering time and overall frame deltas would really be a godsend for identifying performance from an objective standpoint as well as cluing curious developers into what methods of achieving visual effects are the most performant. As it stands, "stutter" threads are a damn nightmare for everyone involved because we don't have the tools to look at the "stutter" people report objectively.
Jun 6 2016, 10:12 pm
In response to Ter13
Ter13 wrote:
Having a client-side profiler that told us which specific processes were taking up how many milliseconds of rendering time and overall frame deltas would really be a godsend for identifying performance from an objective standpoint as well as cluing curious developers into what methods of achieving visual effects are the most performant. As it stands, "stutter" threads are a damn nightmare for everyone involved because we don't have the tools to look at the "stutter" people report objectively.

You speak the truth. I'll have to add this to my feature list and mull it over, because I think having a way to turn on client-side profiling (even just for hard-coded stuff like the map) would be huge.