You are not logged in. Please login or register.
I'll bring up the fixed time-step article again. 1) It points that the system process can get suspended in some way, in which case a lot of time will accumulate causing the game to spend a while catching up upon resume. 2) It suggests a method to avoid the visual stutter that's inherent to fixed time steps. I don't know how relevant it is in our case, but it's probably worth considering.
Last edited by parasti (2008-01-01 20:07:35)
That's a good article, and a great supporter of my motivation to implement lockstep. While that guy does propose a method for handling clock desync (your #2), it's really not worth the cost in my opinion. To implement it, we'd need to duplicate all of the game state in order to accommodate the extrapolated temporary.
I took the drift issue into account in my initial post when justifying the selection of the 90Hz update rate. Given that a time-accumulated step-locked physical simulation must at some point apply different numbers of physical updates per graphics update, I feel my solution is somewhat more elegant, and significantly less expensive.
Hmm. So I finally found time to actually do some testing. The automatic chase rotation does seem different... In fact, I am surprised I didn't notice this before. The view seems to be a lot lazier now, almost like the old lazy view. This can be best seen in the maze level. Previously I was able to play through the level with nearly no user-controlled rotation, but now I'm forced to use it.
Edit: generally seems to be most apparent when the ball changes directions often and travels short distances.
Last edited by parasti (2008-01-01 23:46:05)
I just discovered some unexpected behaviour in replay playback. The data/gui/demo1.nbr technique demonstration ends differently if game is compiled with debugging symbols ("-g" compiler flag) instead of the usual optimisations ("-O2").
By the way, view rotation seems to be a lot slower now. I've discovered that increasing the rotate slow/fast rates by 50 is sufficient to bring the old "feel" back.
I've made some tests, too, and found that the results are closest to the old behaviour when setting rotate_slow to 158. (Actually, the best match would be 157.5.)
Result with neverball-r1490+decal-changes-setup.exe: 194 coins (correct)
Results with my own Windows builds (r1526):
-O0: Fall-out
-O1, -O2, -O3: 188 coins
Which build (compiler, version) did you use to record the replay? Here's what I get with r1526:
cc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
-O0: Fall-out, 181 coins;
-O1: Fall-out, 150 coins;
-O2: Fall-out, 150 coins;
-O3: no outcome, 145 coins;
-Os: Goal, 152 coins.
i586-mingw32msvc-cc (GCC) 4.2.1-sjlj (mingw32-2)
wine-0.9.44
-O0: Fall-out, 181 coins;
-O1: Goal, 194 coins;
-O2: Goal, 194 coins;
-O3: Goal, 194 coins;
-Os: Goal, 194 coins.
Which build (compiler, version) did you use to record the replay?
If I remember right, I made it with your Windows build of r1490.
(Which is probably the reason why playback with that build also gives the expected result.)
It also appears that restructuring lumps (while keeping exactly the same surface for the ball to roll on) may change the outcome of a replay.
If this in fact turns out to be true, it would severely limit the ability of mappers to make even small, "under-the-hood" changes to their maps without breaking people's existing replays.
It also appears that restructuring lumps (while keeping exactly the same surface for the ball to roll on) may change the outcome of a replay.
If this in fact turns out to be true, it would severely limit the ability of mappers to make even small, "under-the-hood" changes to their maps without breaking people's existing replays.
Of course it's true. Replays no longer record the position of the ball. This is good, partly because it really helps prevent cheaters. I remember making a fun build with only half the tilt as normal. After saving a replay, the real build doubled each tilt, which, of course, caused the ball to fall-out. If there's a small map change, it most likely won't cause problems in replays. If a lump does, however, get in the way of ball's path, then the ball's outcome will be changed.
Last edited by Krabby Krap (2008-02-06 02:33:55)
Elviz: Do you mean you cut a lump in two halves and the ball's rolling behavior changes? This is an outrage!
Any ideas anyone why this can happen?
Retexturing without changes to the geometry hopefully doesn't affect the behavior?
Yikes, that does sound like a big problem. I'm totally baffled as to why such a thing would happen, though.
But does it? I'd like to see the replay and both versions of the map where this happens.
Elviz: Do you mean you cut a lump in two halves and the ball's rolling behavior changes?
Yes, that sort of thing. Cutting an existing lump into different pieces and/or merging lumps. By "keeping the same surface" I mean that all different lump constellations would result in the same big lump when merged. Nothing is actually added or removed.
Here's an example:
Map 1: museum-test.map
Map 2: museum-test2.map (created by merging all floor lumps of the first map)
Replay: bug10.nbr (references map-fwp/museum-test.sol)
(Reproducible with the executable installed by neverball-r1813+progress-setup.exe.)
Last edited by Elviz (2008-02-26 20:00:40)
My tests were done with the executable installed by neverball-r1709-setup.exe.
I'm sorry, Elviz, but I get the exact same result and path with both maps. Could the problem be caused by a high fps?
Last edited by Krabby Krap (2008-02-07 04:43:47)
I'm sorry, Elviz, but I get the exact same result and path with both maps.
Don't expect this to work (fail, really) with anything else than the r1709 Windows executable. See ticket #127.
Also, please don't always quote entire posts. Only quote what's needed to give the context.
Also, please don't always quote entire posts. Only quote what's needed to give the context.
Oops. I really need to brush up on my forum etiquette 
I'd like to see the replay and both versions of the map where this happens.
Now that these are online, are you able to reproduce the problem?
I'm sorry, I hadn't yet looked at those files. Had a glance after your comment. What I'm seeing is, well, interesting... If I compile the maps with the GNU+Linux mapc binary, the ball appears to behave consistently in both maps (moves through solid). If I compile them with the Windows mapc binary through Wine, ball acts normally in the first map and moves through solid in the second map. It also appears that MD5 checksums of the resulting SOLs are different. I don't trust myself, though, and this was just a quick test so I want to do a lot more testing before coming up with any conclusions.
By the way, I recently got a chance to try the latest Windows build on Windows XP. Compared to what I've used to see on Debian, the judder was very apparent and quite disturbing.
If I compile them with the Windows mapc binary through Wine, ball acts normally in the first map and moves through solid in the second map.
That's what I'm seeing. My only explanation is that it may be caused by the fact that in the second map some vertices of lumps on top of the floor no longer coincide with vertices of floor lumps. Visually, that's no problem at all but perhaps it's enough to introduce rounding differences in the physics computations.
If this is indeed the case, it would confirm my view that the new replay system is too fragile. As a player, I'm interested in reliable and lasting playback of my achievements rather than in a precise reproduction of an internal calculation sequence. The latter may be technically satisfying but it comes at too high a cost if it means that the tiniest change somewhere will invalidate my replays.
As a player, I'm interested in reliable and lasting playback of my achievements rather than in a precise reproduction of an internal calculation sequence. The latter may be technically satisfying but it comes at too high a cost if it means that the tiniest change somewhere will invalidate my replays.
I second this feeling. One of the most satisfying parts of Neverball is that not only can you accomplish really great runs/coin collecting/freestyles, but that you can save a replay and share it with others/watch it later and marvel at your own skill , etc. 
Yeah, replays need to be non-fragile!
I third that.
It's not just little map changes, but sometimes also code changes. Putt-collisions has an additional check for collisions with other balls, and a few other changes too. A replay saved from putt-collisions sometimes ends differently when viewed from the original trunk, and visa versa. They are pretty dang close, however.
Also, the lazy camera no longer works. I'll probably remove it sometime.
Can I assume that you haven't changed your mind about this? I'm working on some updates to the documentation, and I'm not sure what to do with those lazy camera refs.
rlk wrote:Also, the lazy camera no longer works. I'll probably remove it sometime.
Can I assume that you haven't changed your mind about this? I'm working on some updates to the documentation, and I'm not sure what to do with those lazy camera refs.
Didn't somebody fix it? I only wanted to remove it because I broke it and I didn't feel it was worth fixing. If it works, it stays.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 8 official extensions. Copyright © 2003–2009 PunBB.