View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0018779 | Starward Rogue | Graphical Bug | Mar 14, 2016 3:20 pm | Mar 19, 2016 6:55 pm | |
| Reporter | Pepisolo | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | no change required | ||
| Product Version | 1.016-1.017 | ||||
| Summary | 0018779: Timing Issues | ||||
| Description | Misery: "Okay, so, I've found something odd about the way the game is handling timing here, for things like angle changes and whatnot. I've got a boss using a spinning shot similar to the ones used by Crystal Mother's misery patterns; the shots that just sit on top of the boss and spin and constantly fire. The angle change is about 15 with .03 seconds for how long it takes. The boss I'm working on is Aggressor, which is a "high-density" boss overall, so there's a ton of shots on the screen. But it doesnt seem to be more than some other bosses use on that difficulty level (I think Crystal Mother might actually be firing more, on the third pattern, but that pattern doesnt have this issue). However, the actual in-game timing of the shots seems to actually change depending on things that Windows is doing outside, slowing down the game. Theoretically the game should JUST slow down a bit, but all timing remains the same, relatively speaking, but that doesnt happen. The pattern actually distorts. I noticed this when trying to get a recording of the thing; when playing it normally, there would be no issue, though it does get slightly odd at times. But when I had the recording software running (which sometimes causes slowdown, sometimes not; the slowdown is typically light enough that it's very hard to spot), the whole thing would become a distorted mess, creating solid walls at times or things like that. Shut that software off or just stop recording, and it goes back to normal. Unless, of course, Windows itself does something dumb outside of the game, causing a system cough, which will cause a momentary distortion. I have all of the boss systems using the shot sensitive logic and "do not collide" tags. Any thoughts on this one? " | ||||
| Tags | No tags attached. | ||||
|
|
Just a note on this. Misery should be updating this with a repro for the issue some time. |
|
|
Which version of the Aggressor are we talking about? I just tested it on both Normal and Misery and I only see one stage and it doesn't seem to be especially high density (actually on Misery I can stand right in front of the thing and the patterns always miss me). Anyway, the problem's not specific to that, but a solid test case would be very helpful to me in diagnosing what's actually going on and seeing if any changes I try actually help. The main problem, I'm guessing, is shown by this example: There's a bullet that's supposed to emit another bullet 1.0 seconds after it's spawned. Case A) Frames are exactly 0.01667 seconds long (0000136:0000060 FPS) for 60 consecutive frames. So on the 60th frame, at 1.0002 seconds after the first spawn, the second bullet is created. Case B) Frames are exactly 0.01667 seconds long for 59 consecutive frames, but for some reason (too many shots, OS is being dumb, or computer is still recovering from the shoe Misery just threw at it) the 60th frame is 0.033 seconds long (i.e. framerate drops to 30 FPS). So on the 60th frame, at 1.01653 seconds after the first spawn, the second bullet is created. The difference is only about a sixtieth of a second (i.e. about a normal 60 FPS frame), but if the bullet is travelling at 300 pixels per second (relatively slow) that's still a potential difference of about 5 pixels in the bullet's position. So in case B the second bullet could be 5 pixels "behind" where it should be. That said, there is a limiter that keeps individaul frames from being longer than 0.033 seconds, so it can't get truly ridiculous for any one bullet. If the patterns are so tight that a 5px contraction makes it undodgeable then we're probably already in unreasonable territory. But if you have many stages of bullet emission, and many emitters, and so on, those "later generation" bullets could be way further "off". The first one is off by 5px, then the first emits a second which is now 10px off, the second emits a third which is now 15px off, etc. Solutions? 1) I can try to have bullets created on "long" frames (ones that were delayed for some reason) "catch up" by immediately moving however far they would have during the time they theoretically "should" have been created (1.0 seconds) and the time they actually were created (1.016 seconds, or whatever). or 2) I can lower that limiter from 0.033 seconds to 0.017 seconds. The disadvantage is that if you're only getting 30 FPS for some reason your mech and shots and whatnot will only move 1/2 as fast. The advantage is that (probably) there will be far less of these weird timing shenanigans where a butterfly flaps its wings in your recording software and this leads to a hurricane in your boss fight. I'll probably try the second one first, since it's much less complex and less likely to cause weird interactions. But I'll need a case known to have this problem, so I can see if this change actually helps. |
|
|
The reason why you're not seeing different patterns is that I'd not sent the boss yet, hah. Since it hadnt been functioning right and at that point I'd already stopped for the night. And then forgot after. But I've sent the whole thing just now, so the misery pattern should be working now. There's some alterations to the already-existing pattern but for the most part all this one does is add 2 spinning firing points. They should be firing their shots very evenly, but they never do, and they have that distortion problem beyond that. The spinning points are just bullets that spawn once and never vanish, they simply keep spinning and firing. The alterations to the already-existing stuff just involved some changes to angles. Anyway, hope that helps. |
|
|
Ok, looking into the actual case I don't think we need to mess with the core timing mechanisms. I was able to get reasonable (to me) behavior from the blue spinner by two changes: <loop iterations="-1"> to: <loop iterations="-1" take_pants_off_head="true"> (this suppresses the "sometimes skips the first action inside a loop body" bug; yea, I know, I'm sorry, but if this defaults to true then who knows what else will break) and <change angle="-13" relative="true" time=".03" /> to: <change angle="-26" relative="true" time=".06" /> This also cuts the thing's rate of fire in half, of course, but ultimately the game just can't guarantee that it's checking often enough for something that happens in three hundredths of a second to be done exactly the same way every time. If you need this degree of precision, then I suggest a couple alternate approaches: a) keep the less-frequent firing, but have it fire larger bullets or a spread (either with the individual shots fanning out like usual or starting slightly offset and travelling on exactly the same angle) b) just put in those spinning turrets that fire spirals of bullets, or perhaps copies of them tuned to be as desired; actually having it be a system that emits these things works more precisely (or, at least, I don't recall hearing that the spiral turrets weren't working right) Anyway, if this doesn't resolve things please let me know. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 14, 2016 3:20 pm | Pepisolo | New Issue | |
| Mar 14, 2016 3:20 pm | Pepisolo | Status | new => assigned |
| Mar 14, 2016 3:20 pm | Pepisolo | Assigned To | => keith.lamothe |
| Mar 15, 2016 3:08 pm | Pepisolo | Note Added: 0045431 | |
| Mar 15, 2016 3:34 pm | keith.lamothe | Note Added: 0045432 | |
| Mar 15, 2016 3:34 pm | keith.lamothe | Status | assigned => feedback |
| Mar 15, 2016 7:36 pm | Misery | Note Added: 0045434 | |
| Mar 19, 2016 6:55 pm | keith.lamothe | Note Added: 0045443 | |
| Mar 19, 2016 6:55 pm | keith.lamothe | Status | feedback => resolved |
| Mar 19, 2016 6:55 pm | keith.lamothe | Resolution | open => no change required |
