A bit of a slow responce, as I only noticed this thread now.
Quote:
Originally Posted by sneaker
Spot on (I guess you tested?). Was using 3.0.0.237 from CCCP experimental. 211 does not exhibit the problem.
|
This is due to the fact that somewhere along early 2013 someone came up with a sample that would just cause xy-VSFilter to OOAS (Out Of Address Space) on 32bit systems during playback. We discussed it with cyberbeing back then, and have had two checks added to our builds since then, the latter of which (that has been in the CCCP releases for some time now) basically blocks textures that are greater than (8000 * 8) * (500 * 8) samples large (the * 8 is due to the fact that VSFilter internally renders at 8x scale).
I have also responded in more detail
on our forums for those who want a more extensive explanation.
I don't like it, I didn't or don't want to do it, but at the time it looked like the only thing to do.
Edit:
I got irritated by this enough to just go and debug the first crashing sample. After a few hours and about ten crash dumps, I seem to have been able to not have xy-VSFilter crash with the known samples.
Large things will still allocate a lot of memory, and will thus be slow, but since the sanity check was far from perfect (and because, while the Aegisub folk agreed on limiting VSFilter, they are currently shipping a VSFilter that doesn't limit, which creates a disparity), I guess there's not much else to do for now but to remove it and instead use this uncanny fix until the next crashing sample at another code path that doesn't get checked
.
Things that could not allocated of course will just not show up, but that's kind of the thing: You either get a crash or you just bail out of that part of the rendering chain.
More information
here.