113c25aac1
Closing the caveat I left last iteration -- the splash timing was +/-0.5s because I sampled at 2 fps, and at that rate I could not see ramps at all, only plateaus. Re-recorded at 10 fps: the splash FADES, both in and out, rather than cutting. And the bundles declare it. palogo_sqex.t32 carries keyframes [15 30 235 239 251 255] and palogo_gamearts.t32 [15 30 190 194 206 210], each with an _eff glow child on [15 30 45]. Under Q1's 1 unit = 1/60 s that is a 0.25 s ramp in, a 3.42 s or 2.67 s hold, and a 0.33 s fade out -- against measured holds of about 3.5 s and 2.4 s and fade-outs of about 0.3 s. The constant 0.35 s offset between declared and measured start is just that my recording's t=0 is when the WINDOW appears, not when the guest starts drawing. So the first screen's animation moves from measured to decoded: the port reads it off the disc instead of trusting my stopwatch. It also explains something the capture showed and I had no account for. The brightness overshoots on the way in -- peaks at 0.8 s, settles by 1.1 s -- which reads as a bloom. It is the _eff glow child, whose keyframes run 15 -> 30 -> 45, ramping in after the logo and back down while the logo holds. Mechanical, not a rendering artifact.