Thanks! I thought I was up to date with the mega folder, but my patch.xp3 was old. The new one solved a hole bunch of issues all at once. The only thing I have found with the present version yet is this barely noticable glitch during the animation of Saegusa in Prologue Day 1:
The ks file of this part goes like:
Code:
@image4demo storage=由紀香01c(中) page=fore visible=true layer=1 left=200 top=71 opacity=0
@move spline=false layer=1 time=500 path=(270,71,150)(255,81,255) accel=-2
@wm canskip=false // Waiting for the end of automatic movement
@waitT canskip=false time=200
@move spline=false layer=1 time=300 path=(265,72,255)(275,81,255)(285,72,255)(290,81,255)(287,71,255) accel=-4
@wm canskip=false
@waitT canskip=false time=100
@ldallT c=由紀香01a(中) ic=3000 method=crossfade time=200
@texton
The screenshot is from the final position of the second move (287,71,255).
For the next screenshot I edited the foreground image 由紀香01c(中) to a black box with red single pixel demarcations to check coordinates and size. It then looks like this in game:
So the image gets placed by the game engine at a position of 444/113 with a size of 332x846 pixels.
Of course, 113+846 = 959, so one pixel too short. But why, exactly does it end up like this?
Assumption: y-Position = 71*1.6 = 113.6
It seems to floor that to 113, so that's how we and up with that value.
If it actually rounded the value, it would give 114 and not produce the glitch. (114+846=960)
But wait, there's more! It actually wouldn't need to glitch anyway: The HD WebP has a size of 334x848. So it should end up as 113+848=961. If no resampling were done to the foreground image, that is.
But it does resample. Why and how, I have no clue (the display commands don't take any size parameters), but it resamples the image to 332x846, making it too short to prevent the glitch this way.
(You can actually see the resampling artifacts if you zoom in on the black box. In the WebP, the red lines are one pixel wide 255,0,0 red. In the ingame screenshot, though, they have been smeared a little by downsampling).
Why does it resample the WebP to 332x846? Possibly it's using the size of the original PNG file (208x529) as a guide.
Floor(208*1.6) = 332
Floor(529*1.6) = 846
Would fit the hypothesis. But why does it resample at all? Just to make sure that the HD artwork is really the size it's supposed to be? In this case, it does backfire, and leaving the HD image at the original size would have prevented the glitch.
There's more! On to the third weirdness which is the x-coordinates. The ks file specified (287,71,255) as the last position of the second move command .
So converting the value from low to high res would give .
But the observed x-position in game is actually 444.
I'm pretty sure that the 444 value is a bug, though. Why, you say? Well the line
Code:
@ldallT c=由紀香01a(中) ic=3000 method=crossfade time=200
actually causes the foreground image to move to 460/114:
In the original Realta Nua and when running Ultimate in low quality mode, this jump to the right does NOT happen. Saegusa stays in place while only her expression changes. Maybe something's screwy in the position calculation during HD mode. More likely, @image4demo somehow produces a wrong starting position while the actual move commands are fine. No idea.
I find all this rather fascinating, so I spent a lot more time on what is a very minor glitch that's only visible for half a second than maybe I should have. But I guess there's a non-zero chance that bugs causing this one glith, might affect placement/sizing in other scenes as well. @image4demo, if that's the culprit, is rarely used, though. I haven't tried yet what would happen if I replaced @image4demo with @image. No clue what the difference between both commands is.
If somebody has some idea what's going on there under the hood, I'd be delighted.
Originally Posted by Tfking
