Closed tchebb closed 3 months ago
cc @AllyTally, who wrote #1140
Out of curiosity, do you know how you might have gotten your save file into that state? You have a couple more interesting values in there:
<stretch>37</stretch>
<useLinearFilter>160</useLinearFilter>
<usingmmmmmm>32767</usingmmmmmm>
To me it seems like either this was some kind of bug with uninitialized data being saved in certain conditions, or you were fuzzing the game (and were unexpectedly successful, 10 years later!)
I don't believe I ever edited that file manually, and I certainly never tried to fuzz the game. I played it briefly back then, and this file was the result. I don't know exactly what version produced it, but it'd have either been a Steam or the Humble Bundle distribution from that time.
The values aren't totally bogus, since the width and height (1440x900) match the monitor I had at the time.
VVVVVV 2.2 was originally released precisely the day before your save file (11 June 2014).
Reading back threads from back then, there were definitely some teething issues in the first few days; including random crashes while playing and unrelated problems with save folders, that got patched out within days after release. I don't think 2.2's version history was ever properly tracked, but there were definitely several updates made in the first week. It seems very possible the original 2.2 just had a bug where it could save uninitialized data like that, and that was one of the fixes that was made.
I haven't played VVVVVV in years, but I figured I'd start it up again with the new update. Unfortunately, when I did so, I was met with
A bit of (easy, thanks to the unstripped binary!) digging revealed that these lines were dividing by zero:
https://github.com/TerryCavanagh/VVVVVV/blob/91e144736b875844ec72ab2499d5d0af4c00f7c4/desktop_version/src/KeyPoll.cpp#L554-L555
The divisions were added in commit 77a571017d9c (from #1140), and indeed a bisect showed that the game started up fine prior to that commit. However, the root cause turned out not to be those lines, but rather the new
switch
statement used to set scaling parameters. It expectsgameScreen.scalingMode
, which is read from<stretch>
inunlock.vvv
/settings.vvv
, to be either 0, 1, or 2.But in my
unlock.vvv
, which is dated June 12th, 2014,<stretch>
is 37! As a result,get_stretch_info()
never populates any values of the passed SDL_Rect, which breaks both the division above and rendering in general. Here's the exact settings file that I had:unlock_vvv.txt
I tested on Arch Linux, SDL 2.30.0, Sway Git, with both the Wayland and X11 SDL drivers.