View Issue Details

IDProjectCategoryLast Update
0018779Starward RogueGraphical BugMar 19, 2016 6:55 pm
ReporterPepisolo Assigned Tokeith.lamothe  
Status resolvedResolutionno change required 
Product Version1.016-1.017 
Summary0018779: Timing Issues
DescriptionMisery:

"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? "
TagsNo tags attached.

Activities

Pepisolo

Mar 15, 2016 3:08 pm

developer   ~0045431

Just a note on this. Misery should be updating this with a repro for the issue some time.

keith.lamothe

Mar 15, 2016 3:34 pm

administrator   ~0045432

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.

Misery

Mar 15, 2016 7:36 pm

reporter   ~0045434

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.

keith.lamothe

Mar 19, 2016 6:55 pm

administrator   ~0045443

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.

Issue History

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