View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0005445 | Valley 1 | Graphical Bug | Jan 25, 2012 2:05 am | Sep 1, 2012 1:33 pm | |
| Reporter | GrimerX | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.562 | ||||
| Summary | 0005445: Stuttering/dropped frames when entering new chunk | ||||
| Description | I have gotten this for a few builds now. It happened around the time I upgraded my video card from a GTX 460 to GTX 560 Ti (Thank you Skyrim), not sure if it is coincidence or not. Entering intro mission/surface with caves 0000003 seems to reliably reproduce it for me. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Polish Tweak | ||||
| related to | 0005197 | assigned | Chris_McElligottPark | Frameskip causing unpredictable results. |
| related to | 0009319 | confirmed | Chris_McElligottPark | Game slowdown after exiting lava flats & entering a different-type region |
|
|
I have stuttering when using a spell the first time. The graphics/sounds for all equipped spells should probably be precached. |
|
|
If you start the session with the spell it should be precaching it. If you've equipped it fresh and then are using it for the first time, it might not -- whenever anything is added to your inventory we probably need to make sure that any used images get cached right then. Similarly, when loading a new chunk it was supposed to be caching all your images right then. But apparently that might not be working at the moment for some reason. It might have to do with some of the multiplayer changes of late, I'm not sure, but it's definitely not the GPU. |
|
|
Bluddy, can you give me steps to reproduce? I'm not seeing any lag when casting spells for the first time. That may be because of my hardware in which case I can test on my laptop but I wanted to have a confirmed case to work by first. Thanks :) An inspection of the preloading code didn't show any gaps except perhaps in the just-crafted/equipped case. |
|
|
"except perhaps in the just-crafted/equipped case. " That's the case I think is the problem. I know that it's not doing it on spells you already had when you loaded into the chunk. |
|
|
Can't get it to reproduce. Maybe it's just a paging issue -- like when I load AVWW at the same time as doing something else. I'll post here if I do see it again. |
|
|
Had it happen again today -- 2 out of 4 times an ameoba did its big attack (shots fired in all directions). My system is basically idle outside of AVVW. Anything we can do to help track this down? |
|
|
More than just the first time, this happened? That's very odd. Was it right when it fired, or was it when it hit a lot of crates and popped up their health bars? It might have simply been lowered frame rate from too many draw calls. |
|
|
I get this occasionally as well when I fire a spell for the first time. I've not noticed a pattern to when it happens, but, it does happen from time to time. |
|
|
It was probably the first second of the shot. I don't remember crates being involved. Will pay more attention next time, try to pause it and look around. |
|
|
Okay -- there is definitely some stuff that is not pre-caching like it should on abilities of certain sorts, so hopefully I'll find that either way. |
|
|
I just want to add that I'm running into this problem constantly, making it almost impossible to play for long period of time. I'm on a slightly older MacBook aluminum, but it has 4GB of RAM and I haven't had the problem in previous builds. |
|
|
"I'm running into this problem constantly" What does that mean, specifically? You're getting stuttering when nothing is happening except standing there? Stuttering when enemies fire? The amount of RAM is unrelated to the general performance of this sort of thing. MacBooks in general tend to be a lot less powerful with their GPU throughput, so the dynamic skies tend to cause lag on them. Turning off the dynamic skies in settings might solve that problem if it's a constant thing, I'm not sure. |
|
|
I'm not sure on the relationship with the other ticket on this one, but, I tagged it just in case. |
|
|
Stuttering when I or enemies fire. In the case of indoor rooms with lots of espers, this means it pretty much happens constantly. The framerate actually drops into the 1-2fps range and stays there. I don't have dynamic skies turned on. |
|
|
Okay, I see. In that case, it's just a matter of your machine not being able to handle the graphics load in general -- it's definitely nothing to do with disk or RAM. I suggest turning off the parallax backgrounds as the next step in disabling stuff to keep performance up. The reason it would be happening in newer versions and not older versions is that we've added some new graphical layers, and those draw whenever windows are visible inside, as well as in general outside. Playing at a lower screen resolution (not sure what you're playing at) also can make a _dramatic_ difference if your pixel fill rate is borderline. |
|
|
I generally play it at 1280x800, which is the native resolution for the laptop. Changing that hasn't made a difference. Because the laptop uses an Nvidia 9400M, I've already disabled the parallax backgrounds and most of the other high-end graphical stuff. I've been playing off and on since the early beta and never had any stuttering or slowdown issues. It seems like everything worked fine two weeks ago (the last time I played) and now its' borked. Which is a drag, because I wanted to see all the new stuff. :) |
|
|
Hmmmm. In general, my experience of testing this has been the exact opposite lately, and most others who have commented at all have said much the same. 1280x800 shouldn't be big enough to cause problems I wouldn't think. Any chance you've got a new driver in the last two weeks? If you can hit P to pause the game during a time when it is really borking your performance, and then hit F3 to bring up the debug info, there is a line that has FPS, draw calls, and texture swaps. I'd be really interested to know what those numbers were. Hyfryl-however-you-say-it from the forums was just saying that he was seeing some of his characters being drawn "doubled" in the latest release, but we've been unable to duplicate. But if there's some sort of issue causing that sort of thing in certain old worlds, then that could definitely explain a performance drop. We'd need a copy of your world folder to duplicate if the draw count seems abnormally high, though. Usual draw call counts would be in the 100-400 range, thereabouts. |
|
|
Yeah, I thought it was weird too. Can't really remember if there were any recent graphics drivers updates. This started on an old world, so I started a new one but got the same problems. I just went in and here are the numbers: FPS: 2-6fps Draw Calls: 260-300 Texture Swaps: 60-90 The numbers were mostly on the lower end of the range in the 30 seconds or so I kept it open until the frame rate started getting better, and went back to about that range when the rate started dropping again. |
|
|
This is when there's a lot of espers attacking you at once, correct? Those number of draw calls seem in line with what I would expect, and the number of texture swaps is really really excellently low given what is going on. Those numbers don't really jive with the FPS, from what I'd expect at least. It _looks_ like possibly there's a driver issue, if this is a sudden issue. The only things that would have changed lately would be that the number of texture swaps would have gone down by about 1/3, which should mean a huge performance boost, rather than the other way around. What FPS are you getting when there's not all that going on at once? |
|
|
Yes, that's when a lot is going on onscreen. When it's more sedate, the FPS stays in the 30-40 range for the most part and rarely dips below 20. I just checked my update history and it doesn't look like there were any graphical driver updates in the last few weeks. Weird. |
|
|
That is really odd indeed. What I think I am going to need to do is to provide a few "no particle trails" options. One for no enemy particle trails, one for no ally particle trails, and one for no particle trails from yourself. Then basically that would vastly lower the draw count in these cases where it's really harming your FPS there. It's a lot of art and related to do that, but I think it will be important for maintaining wide compatibility and also for having tons of multiplayer allies in one chunk on borderline machines. The game prefers to run at 60fps, so it's already struggling a bit there in general. I may also look at putting in an option for reducing the number of texture swaps even further. That might lead to some undesirable flicker in spells and a few other cases, but overall it would also help performance on your machine and I'm not sure the flicker would actually happen. |
|
|
I'm having a similar issue with version 0.563. I was just playing version 0.561 today before updating to version 0.563 and everything ran fine. Once updated, I noticed that loading times between screens was a lot longer and once I tried to fight a boss (a blue amoeba) the game would basically freeze for a few seconds, play for a second then freeze again. I tried restarting the game to see if it would help. I could play for about 20 seconds before it started freezing again. When paused, the game seems to run smoothly and F3 was telling me I was getting 75-100 fps. This is one my old save by the way. Haven't tried any other worlds. |
|
|
c4sc4 -- can you upload your old save? It sounds like there must be some sort of issue with the game itself if multiple of you are seeing it, but I've not been able to duplicate it, and Keith and Josh have also been playing a lot lately without issue. It's actually kind of a relief if that's what the issue is, to be honest, because if it's just general specs not being good enough for laughing_man, then I'd misjudged something. |
|
|
Okay, I did find this: * Fixed several bits of wrong logic and several bits of very inefficient code from the prior version related to monster spawning. ** This was likely the cause of the lag at the start of certain areas, and the cause of the lag whenever monster spawners were present and spawning monsters in boss rooms. |
|
|
Do you still want me to upload my save? If so, I can't do it right away since I'm not at my computer right now. |
|
|
I probably don't need it, unless you still see the issue in the next version. I'll be doing a push in a few minutes, so if anyone still sees the issue after that, then let me know. I think the issue was CPU-bound, not GPU-bound, for the record. |
|
|
Okay, 0.564 is now out. Please let me know if you still see it in this version. If so, I'd definitely love it if you have a particular savegame that demonstrates it (especially if your performance is normally 60fps or more, like c4sc4, that would be the best for me to repro with). Thanks for your patience with this! |
|
|
I am still seeing it, though it's odd. Framerate drops to about 30 and stays there. Usually it is only a second or so (and not very frequent). In the intro mission where the first Ilari is, is where it happens most easily for me (about 80%). Texture loads/ draw calls are about the same when the framerate is at 60 or at 30. Happens while standing completely still. CPU is about 15%. Will attach a savegame + a screenshot with debug info. |
|
|
Should also mention -- it will probably load fine for you. Try warping to the settlement and back. That's what triggers it reliably for me. The interesting thing is it tends to hang out at 30fps for a bit then go back up. I assume you're doing some averaging -- sounds like it's latching to every other screen refresh under some conditions? |
|
|
Well, it seems to be fixed for me. |
|
|
I'm seeing this (or something similar) in 0.564. When I encounter one or more icicle leapers, CPU usage goes way up (from about 70% to 90+%), framerate drops (from about 55 to about 1.5) and my glyphbearer struggles to perform basic tasks (such as walking one step without falling into the acid halfway across the screen). (While writing this up, I did a little more experimentation and discovered that it isn't just icicle leapers. I get the same performance issues when I break a rock with fire touch or shoot a skelebot with ball lightning.) The problem seems to get worse if there are more icicle leapers visible, but it doesn't get any better when they go away (or get killed, or whatever) and the effects remain even while paused. If I switch between full-screen and windowed, the problem goes away until I encounter something that triggers it again. "Draw Calls" and "Texture Swaps" don't change, and disabling all the graphics options doesn't make any difference. This is in a fresh world that I created in 0.563, although I don't think that's relevant. Given the symptoms, I'm inclined to blame some kind of graphical effect that isn't getting garbage collected or something, but I'm not the expert here. I'm on a recent MacBook Pro with an NVIDIA GeForce GT 330M, in case that makes a difference. I haven't seen anything like this in earlier versions, but the last time I played was mid-December. (Real Life keeps getting in the way.) |
|
|
Attached Slowdown.png showing debug info while this is happening. |
|
|
A further update. I started another fresh world, and I'm seeing the slowdown much earlier in the intro mission than I remember from 0.563. Killing the red slime drops me down to an unplayable 1 FPS. |
|
|
Okay, whew. A lot of notes. First of all, a new version 0.565 is now out, and hopefully it will help: http://arcengames.com/mediawiki/index.php?title=AVWW_-_Beta_Series_2_Release_Notes#Beta_0.565_Better_Texture_Sorting_And_Other_Tricks Secondly: 1. c4sc4, it sounds like yours was always CPU-bound and was just that bug with the populations that we fixed in the prior version. So that's particularly great. 2. GrimerX, try as I might I can't remotely duplicate what you were describing on my windows machine. I didn't get a chance to test your specific save on my Mac (mid-2010 Macbook Pro), but I did test the latest versions in general on my Mac, including in the areas that people were reporting the most problems with, and I saw nothing along the lines of what was described. The new release does help with general performance on my Mac, though, so maybe that will also help with whatever it is that you guys are seeing. 3. jerith, that is really utterly bizzare. From yours, it really sounds like another CPU-bound thing, because that's not enough draw calls to warrant that sort of framerate. If you're still seeing that in the latest version, can you look at what your CPU usage is at the time it's happening? Is it literally only when the icicle leapers are on the screen, or is it also when they are in the chunk but you've not yet seen them on your screen? That may be hard to answer, if they are always right there when you first go into the chunk. Bleh, I really hate this sort of thing. Sorry about this, guys -- I did as much as I could for a weekend, but I am just not seeing any smoking gun in the code changes for the entity logic or the render pipeline in particular. It might be in some other module, and I'll look into that on Monday if this release doesn't solve the issue. I did make a ton of changes to the render pipeline with this version, so it's possible that among the other optimizations I made, I randomly also fixed this one without knowing it. That would be nice, eh? ;) |
|
|
Still seeing this in 0.565. It feels like a slight improvement, but that might just be because I'm getting better at not triggering it. There are a few different things going on, and it's not always easy to tell them apart. When the icicle leapers aren't visible, they have no effect. When they are visible, there's a small drop in framerate (50+ down to 30-40 FPS is there's no background, 20ish down to about 10-15 if there's a dynamic background visible through a window), which is kind of what I expect. Shooting at them with ball lightning causes a further (transient) dip, which I assume is due to the spell visuals or something. When an icicle leaper hits me, there's an immediate drop. After several hits (somewhere between two and five, I think, but I'm guessing) the frame rate is below 3 and the game is pretty much unplayable. If I only get hit once or twice, the framerate drops to single digits and stays there, but the game is still playable. The drop in framerate is correlated to an increase in CPU usage as well. (As I mentioned previously, the same thing happens when I break rocks with fire touch.) Switching between fullscreen and windowed makes the slowdown go away, but going to a different chunk (through a doorway, at least) does not. I got a slight improvement in framerate when I did that, but I think that's attributable to a lighter rendering load in the new chunk. This is a really nasty problem to debug, especially since so few of us seem to have it. I'm happy to help out however I can to nail this, time permitting. (I've been on the other end of similar issues, so I know your pain.) |
|
|
Aha! I have found a more reliable way to investigate than trying to dodge icicle leaper while my framerate's plummeting precipitously. If I stand in front of a red slime and take careful aim, my framerate's at 55-60FPS and CPU usage by the game is at about 75%. When I shoot the slime, the framerate immediately begins dropping and CPU usage immediately begins rising until they're at 1-2FPS an and 95-99% respectively. Being on fire drops my framerate to a fairly stable 15-20FPS with CPU usage up at 99%, which makes sense given the nature of the visual effect. However, when I *stop* being on fire the CPU usage dips briefly to about 85% before rising back to 99% as the framerate drops to 1. This seems to point to a problem with the effects going away rather than a problem with them being drawn. (Assuming it's even the rendering pipeline that's the problem here. It might be something to do with damage or spells or whatever, but that doesn't explain why hurting a red slime triggers it but not hurting an icicle leaper.) |
|
|
Another thing. Skelebot sniper fire causes the slowdown when it hits me, but not when it fades on it own. I don't know if that's relevant, but it might help narrow it down if it's something to do with effects going away. |
|
|
Most of what jerith says still applies to me. After the latest update, my framerate when nothing is going on is actually higher than it was, consistently above 60fps, only to drop to 1-3 when I have to interact with any enemies. In my case, it seems to stay there for quite a while and the low framerate "follows" me into the overland screen as well. It never seems to recover or rise much above 20fps after that. CPU usage stays at a pretty consistent 95-97% according to Activity Monitor. This is odd, because it's a dual core machine and has a maximum "usage" of 200%. I have nothing else running in the background, so I'm not sure why AVWW wouldn't try to use it. In any case, thanks for looking into this (and on a weekend, too!). |
|
|
Here's a random flail. Try disabling anti-virus (/firewalls). |
|
|
I still see it, though it is harder to trigger today. I tried using NVidias PerfHUD, but the game won't start under it (can't switch to the desired resolution) I am seeing some artifacting in this one -- flickering int he background, around where the creates are in the intro, for example, or overlapping trees. Let me know if you want me to grab some screenshots. You can also see it if you just drop platforms on top of each other -- the layering of the platforms changes. Trying Jerith's repro -- I don't have it as bad as he does, but I can double my CPU utilization from 20% to 40% of one proc if I play with the slime, icicle leapers and fire. The combo of being set on fire, having fire around, jumping through icile leapers does trigger it *sometimes* for me -- Draws/Swaps goes to 580/80 from 280/60 "standing around" and 370/70 when trying the repro and not getting the framerate hit. I can't really get it to repro without jumping. Hope that helps :-/ |
|
|
GrimerX: That sounds like normal load-based CPU/framerate impact. I'm seeing CPU going to max and framerate going to min in some circumstances and then staying there no matter what's happening on the screen. (Until I hit cmd+F to toggle fullscreen, which resets it somehow.) The only symptoms that seem to match what I'm seeing are laughing_man's. I'm pretty sure there are at least two different things in this ticket. |
|
|
Okay, a few more notes: 1. I agree with jerith, I think that what he and laughing_man are describing is something that is separate from what anyone else in this thread is seeing at this point. 2. GrimerX, it sounds like what you are describing actually is more or less how it should be working; minus the flickering objects, which is something that was just a bug in the prior version and which was reported elsewhere as well. But more or less that's what would happen on a GPU that was only sort of able to cope with it. 3. I still am not able to duplicate this issue on my windows PC, but I am about to test on my mac. This definitely sounds unrelated to graphics performance; I think it's something to do with ongoing conditions... or something like that. |
|
|
Okay, so far I'm unable to repro on my mac, either. Am going to try a few more things, though. One question: can you look and see if there are any error files being written to in RuntimeData in your game folder? Or can you look about your unity log and post that? ~/Library/Logs/Unity/Player.log |
|
|
Hooray, I duplicated it on my mac! Not sure what it is yet, but that's step 1. I got it to happen by casting fire touch on a tree. |
|
|
Nothing new in RuntimeData, but I get the following lines in the Unity log when I switch to fullscreen and back: """ Mon Jan 30 17:44:01 lantea AValleyWithoutWind[13398] <Error>: unknown error code: invalid display Switching to 1600x1000 fullscreen Mon Jan 30 17:44:02 lantea AValleyWithoutWind[13398] <Error>: kCGErrorInvalidConnection: CGSGetWindowBounds: Invalid connection Mon Jan 30 17:44:02 lantea AValleyWithoutWind[13398] <Error>: kCGErrorInvalidConnection: CGSSetSurfaceBounds: Invalid connection """ That always happens when I toggle fullscreen, but the first line (invalid display) is specific to having my second display plugged in. There's nothing logged when I hit the bug and nothing extra when toggling fullscreen clears it, though. |
|
|
Thanks, jerith -- that matches what I'm seeing also. |
|
|
Well, I can confirm conclusively that this has nothing to do with the GPU. And it's definitely only on OSX, too, and never windows (that I can tell). And never in the unity editor, even on OSX. What happens is this, apparently: after an entity is damaged, the CPU load shoots up quite a bit. This is impacting everything, but somehow is magically restored via command-F, like you said. Which makes no sense at all, and makes me really wonder if this is actually a bug in our stuff or some sort of bug in unity itself; I wouldn't think that switching fullscreen and back could possibly affect any of our stuff. The way I know that this isn't GPU-bound is that I built in a function that disables all the graphics except for the text. When I use this on my OSX machine, normally I get 330fps instead of my usual 145fps. When I trigger the bug, my normal framerate drops down to about 3-4fps, and my all-graphics-disabled fps is down to about 75-150fps. So that's definitely an enormous drop even when none of the normal game graphics are being drawn. AND it's something that survives past chunk switches, like you say, and even onto the main menu and back. That makes it really unlikely also that it's some sort of bug in our stuff directly of the in-game logic sort. Still more testing to do, but this is a real puzzler so far. |
|
|
Further update: I was starting to suspect this was some sort of FMOD bug on OSX or something, but disabling all sound effects and music still doesn't fix this. |
|
|
Still not sure what the exact problem is, but I've at least isolated the code in question that causes this. Will search now for what the problem is inside it, but disabling this code fixes the issue, so that's a great sign that a solution is being closed in upon. |
|
|
Okay, I have found the problem, though not yet the solution. The problem is with either unity having a bug, or opengl, or something of that nature. This line in our shader for making entities flash white works in the unity editor on OSX, but not in standalone builds: Combine previous + constant, previous * constant As noted in the documentation here, it should work fine: http://unity3d.com/support/documentation/Components/SL-SetTexture.html So my money is on some sort of unity bug, which is frustrating to say the least. There are a few things I'm looking into, but basically what seems to be happening is that the GPU or opengl or the unity engine itself is getting into some sort of internally inconsistent state. Switching the graphics mode (fullscreen to windowed or back) resets a lot of OS-level or openGL-level stuff, and for all I know it could be resetting some unity-level stuff as well. So that's why that fixes the issue. First thing I'm going to do is make sure I'm not sending it bad input that is causing this issue. Then it's a matter of seeing if I can find another way to recreate this effect without using the offending code -- that would probably mean a pixel shader, which I'm not thrilled about for performance reasons, but it shouldn't be too bad because very little actually uses this, and very little uses it for long (just when stuff flashes white upon being damaged). Very worst case is that the flash white effect would need to be disabled on OSX, which isn't the end of the world but is something I'd like to avoid if I can. |
|
|
Okay, finally go this one that laughing_man and jerith were reporting -- it's unrelated to the original bug report so I'm not closing it, but here's what has changed: * Improved the efficiency of the shader that is being used to make damaged entities flash white. ** As the focal point of this, also circumvented a bug that was causing GPU instability on OSX. Apparently doing two SetTexture calls inside of one pass of a shader is something that standalone builds on OSX take issue with. For whatever reason. I could duplicate the issue 100% of the time prior to these shader changes, and now 0% of the time, so fingers crossed that this fixes it for everyone else, too. :) |
|
|
Sherlock4000. |
|
|
A lot of times it comes to that! |
|
|
Spectacular work, sir. Ten out of ten for methodical tenacity in hunting your quarry and the eventual victory. Bonus points for style and keeping us up to date with the process. Extra bonus points for a solution that comes with a built-in performance improvement. |
|
|
Don't jinx it! First we have to make sure it works just as well on all other machines. ;) But thanks. :) |
|
|
Yup, works for me. Thanks again. |
|
|
Sweet! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jan 25, 2012 2:05 am | GrimerX | New Issue | |
| Jan 25, 2012 7:58 am | tigersfan | Internal Weight | => Polish Tweak |
| Jan 25, 2012 7:58 am | tigersfan | Assigned To | => Chris_McElligottPark |
| Jan 25, 2012 7:58 am | tigersfan | Status | new => assigned |
| Jan 25, 2012 8:39 am | Bluddy | Note Added: 0018069 | |
| Jan 25, 2012 9:27 am | Chris_McElligottPark | Note Added: 0018076 | |
| Jan 25, 2012 10:02 am | keith.lamothe | Note Added: 0018087 | |
| Jan 25, 2012 10:05 am | Chris_McElligottPark | Note Added: 0018088 | |
| Jan 25, 2012 10:12 am | Bluddy | Note Added: 0018089 | |
| Jan 26, 2012 7:12 am | GrimerX | Note Added: 0018139 | |
| Jan 26, 2012 8:56 am | Chris_McElligottPark | Note Added: 0018148 | |
| Jan 26, 2012 9:03 am | tigersfan | Note Added: 0018149 | |
| Jan 26, 2012 1:49 pm | GrimerX | Note Added: 0018183 | |
| Jan 26, 2012 1:53 pm | Chris_McElligottPark | Note Added: 0018185 | |
| Jan 27, 2012 3:26 pm | laughing_man | Note Added: 0018262 | |
| Jan 27, 2012 3:30 pm | Chris_McElligottPark | Note Added: 0018263 | |
| Jan 27, 2012 3:34 pm | tigersfan | Relationship added | related to 0005197 |
| Jan 27, 2012 3:34 pm | tigersfan | Note Added: 0018266 | |
| Jan 27, 2012 3:38 pm | laughing_man | Note Added: 0018268 | |
| Jan 27, 2012 3:41 pm | Chris_McElligottPark | Note Added: 0018270 | |
| Jan 27, 2012 4:01 pm | laughing_man | Note Added: 0018274 | |
| Jan 27, 2012 4:06 pm | Chris_McElligottPark | Note Added: 0018275 | |
| Jan 27, 2012 4:14 pm | laughing_man | Note Added: 0018276 | |
| Jan 27, 2012 4:19 pm | Chris_McElligottPark | Note Added: 0018277 | |
| Jan 27, 2012 4:46 pm | laughing_man | Note Added: 0018279 | |
| Jan 27, 2012 4:53 pm | Chris_McElligottPark | Note Added: 0018280 | |
| Jan 27, 2012 7:35 pm | c4sc4 | Note Added: 0018281 | |
| Jan 27, 2012 10:05 pm | Chris_McElligottPark | Note Added: 0018283 | |
| Jan 27, 2012 10:31 pm | Chris_McElligottPark | Note Added: 0018284 | |
| Jan 27, 2012 10:38 pm | c4sc4 | Note Added: 0018285 | |
| Jan 27, 2012 10:44 pm | Chris_McElligottPark | Note Added: 0018286 | |
| Jan 27, 2012 11:52 pm | Chris_McElligottPark | Note Added: 0018293 | |
| Jan 27, 2012 11:52 pm | Chris_McElligottPark | Status | assigned => feedback |
| Jan 28, 2012 2:06 am | GrimerX | Note Added: 0018299 | |
| Jan 28, 2012 2:06 am | GrimerX | Status | feedback => assigned |
| Jan 28, 2012 2:08 am | GrimerX | File Added: Environ-grimerx.zip | |
| Jan 28, 2012 2:08 am | GrimerX | File Added: grimerx-30fps.png | |
| Jan 28, 2012 2:14 am | GrimerX | Note Added: 0018300 | |
| Jan 28, 2012 2:43 am | c4sc4 | Note Added: 0018303 | |
| Jan 28, 2012 6:14 am | jerith | Note Added: 0018304 | |
| Jan 28, 2012 6:15 am | jerith | File Added: Slowdown.png | |
| Jan 28, 2012 6:17 am | jerith | Note Added: 0018305 | |
| Jan 28, 2012 6:29 am | jerith | Note Added: 0018306 | |
| Jan 28, 2012 12:35 pm | Chris_McElligottPark | Note Edited: 0018299 | |
| Jan 28, 2012 2:44 pm | Chris_McElligottPark | Note Added: 0018332 | |
| Jan 29, 2012 5:03 am | jerith | Note Added: 0018351 | |
| Jan 29, 2012 5:20 am | jerith | Note Added: 0018352 | |
| Jan 29, 2012 5:27 am | jerith | Note Added: 0018353 | |
| Jan 29, 2012 10:37 am | laughing_man | Note Added: 0018357 | |
| Jan 29, 2012 6:43 pm | TNSe | Note Added: 0018361 | |
| Jan 30, 2012 12:45 am | GrimerX | Note Added: 0018364 | |
| Jan 30, 2012 9:40 am | jerith | Note Added: 0018375 | |
| Jan 30, 2012 10:26 am | Chris_McElligottPark | Note Added: 0018379 | |
| Jan 30, 2012 10:37 am | Chris_McElligottPark | Note Added: 0018381 | |
| Jan 30, 2012 10:44 am | Chris_McElligottPark | Note Added: 0018382 | |
| Jan 30, 2012 10:46 am | Chris_McElligottPark | Note Edited: 0018382 | |
| Jan 30, 2012 10:53 am | jerith | Note Added: 0018384 | |
| Jan 30, 2012 11:06 am | Chris_McElligottPark | Note Added: 0018386 | |
| Jan 30, 2012 12:32 pm | Chris_McElligottPark | Note Added: 0018388 | |
| Jan 30, 2012 12:37 pm | Chris_McElligottPark | Note Added: 0018391 | |
| Jan 30, 2012 1:14 pm | Chris_McElligottPark | Note Added: 0018393 | |
| Jan 30, 2012 2:21 pm | Chris_McElligottPark | Note Added: 0018394 | |
| Jan 30, 2012 2:39 pm | Chris_McElligottPark | Note Added: 0018397 | |
| Jan 30, 2012 2:39 pm | Chris_McElligottPark | Status | assigned => feedback |
| Jan 30, 2012 2:51 pm | TNSe | Note Added: 0018399 | |
| Jan 30, 2012 2:54 pm | Chris_McElligottPark | Note Added: 0018400 | |
| Jan 30, 2012 4:08 pm | jerith | Note Added: 0018404 | |
| Jan 30, 2012 4:18 pm | Chris_McElligottPark | Note Added: 0018405 | |
| Jan 30, 2012 5:56 pm | jerith | Note Added: 0018422 | |
| Jan 30, 2012 6:16 pm | Chris_McElligottPark | Note Added: 0018425 | |
| Mar 30, 2012 1:03 pm | Chris_McElligottPark | Status | feedback => resolved |
| Mar 30, 2012 1:03 pm | Chris_McElligottPark | Resolution | open => fixed |
| Sep 1, 2012 1:33 pm | Pyrrhic | Relationship added | related to 0009319 |
| Apr 14, 2014 9:29 am | Chris_McElligottPark | Category | Bug - Graphical Issue => Graphical Bug |
