I think we will potentially see the new collision code element in a few tables / scenarios but looks like in a minor or easy to fix way as it seems pretty good right now considering how little has been reported / noticed. I have had an event that now occurs on a personal LW3 mod I made where I enlarged the ball using the more recent code to better fit the table dimensions. That enlarged ball never got stuck on the ramp previously but now does occasionally since the latest build. However, it was already a very tight intersection (knew that when I modified it originally) and even when it does get stuck now (only 3 times in about 50 runs / play tests), it's still small enough of a catch to be freed generally with a nudge.
Something though to keep in mind as all of us play test. After reading the recent posts it dawned on me what was likely happening and the timing was perfectly coincided.
The changes to the collision structures should have caused no changes in behavior at all, only different performance implications. This is why I'm still kind of puzzled what's actually going on.
Is it easy for you to compute whether the ball should mathematically fit through the ramp that it now gets stuck on, or is that difficult? The reason I ask is that I have the suspicion that the old engine may not have processed all collisions, and by changing the collision structures we have just exposed that old bug.
If the piece of geometry you're talking about is something you could easily extract into a minimal test table to play around with, that would be even more valuable.
I think it's a bit difficult to compute as it's on a spiral portion of a ramp and will not be completely known at what height between the top and bottom values is the actual intersection with the lower part. However, I should be able to copy that object to a test table but it will take some time as I would want to model the rest of the table to be identical physics / settings wise and that would even include adding BMPR, which is on this personal mod where the problem was observed, as I would want everything affecting the ball motion to be constant in the test table from the main table. It may take me a couple hours but I'll try to work on it this weekend and post here when done.
It may still be tough to reproduce and I can't be 100% sure it's just the latest revision, but I play test with this one table extensively and I had not had that happen at all or at least in such a long time I'd completely forgot about it, so it does seem quite relevant that the two times it happened were since this latest test10 build and the stuttertest versions you had me test out just before it's release. I'm fairly certain the first time it happened was on that special stuttertest build so if that didn't have the collision changes that would say something about this whole assumption / theory. Did you have the collision changes in that build? I'm assuming so for now that's the case but let me know as if you didn't, it may not be fruitful for me to try and model that spiral ramp / table set-up in a test table (I've got a few other bugs to post about / do screen shots / possible test tables for so got to pick which ones I get to with what time I have this weekend).
By the way, I've had the best results yet for smoothest gameplay on these latest builds by using the frame limiter but considering a couple things. For starters, using as high of a number that my system can sustain but is however still an exact multiple of my screen refresh (I'm using 75 on my mini-cab which helps on it's own for better visuals / game play but also can help pick-up ball stutter issues even better - generated from the application side of things). The other big thing I found the other day that made it noticeably better was incorporating your suggestion Mukuste for making it a multiple of the physics frame rate (100Hz). So, trying 600 which fit both those requirements, was noticeably smoother with very few periods of any macro-stutter / brief periods where the ball seems out of sync. It was the best results yet since test7 and pretty much on par I would say - maybe even better in some regards. The interesting thing was though, I had the option also mathematically and did some tests using 300 with the same logic (4 x monitor refresh also equalling 3 x physics rate) but that still yielded more or at least more discernible moments of the ball seemingly going out of sync and having a second or two of reasonable stutter / frame / rendering skipping type look (referring to this aspect as macro stutter as it is not what I would typically deem as the micro-stutter or in how micro-stutter is often more associated with being continuous albeit potentially smaller in it's jumpiness). It struck me that with double the average ms draw time by using 300 instead of 600, the moments when hickups may occur seemed to be more observable and / or slower to get resolved or resynced. I went back and forth from this a few times and 600 definitely beat out 300 and luckily my system, on the table in question could get about 690 without frame limiting so opened up the 600 option (it's a pretty beefy system i5-4670k with GTX 760).
One last thing I noticed and seems to have improved the potential "out of sync" ball rendering moments even farther, was that I actually changed the limit to 601 in my configuration as I had noticed that while on 600 the average FPS was only being reported as around 599 and pretty much the active FPS data was never hitting 600 and showed it alternating between 3 generally reported values of 599.8 and 599.2 and 598.8 in different amounts of time held on each which obviously would be needed to report a value of 599 average considering those 3 values on their own. When I switched to 601 I got an average now of actually 600 and mainly it was toggling between two "real-time" values for FPS of 600.4 and 599.8. All of this data though needs to be assessed only after the table has loaded and been running for a maybe a minute or so (if started then just with the ball in trough) as the initial values are off / not accurate to how it will be after some time passes as opposed to how it is when observed right after a table starts.
Edited by jimmyfingers, 14 March 2014 - 07:18 PM.
Top
are all trademarks of VPFORUMS.