0.2.8.0_rc1: Release process and bugs

Help test release candidates for the next release
User avatar
joda.bot
Match Winner
Posts: 421
Joined: Sun Jun 20, 2004 11:00 am
Location: Germany
Contact:

Post by joda.bot »

osc: As far as I can remember you are very good at making many fast turns :)... perhaps you can make a recording of a really extreme run with the new camera (RC1) and then z-man, can test changes to fix the camera, just by playing back your recording...

You should try to get all the different problems covered.
180s (left/right) ... also fast combinations might be difficult to handle for the smart cam.

osc: AFAIK the problem to get the old smart cam back is that many changes have been applied which require the new cam... thus if the old camera is restored all those changes have to be removed, too (new glancing, I guess).
User avatar
Z-Man
God & Project Admin
Posts: 11710
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

The "new zones" are only active if you disable alpha blending. I figured that if you disable that, you may want to save some fillrate with the zones as well.

A short recording of the camera problems would be nice. Something like you entering a server, saying "now I'm mazing, see how the camera jerks around?". Camera code changes don't break recordings, so I'll be able to optimize things nicely.

The camera init bug may be the camera giving up to focus on a player (because the client does not yet konw about any) and going to free mode. I'll see what I can do, but everything that does not happen while you're playing is not high priority and may need to go to the trunk.

The mini-freezers could also use a recording. They won't show directly, but the timer values are recorded and I'll see where the freezers are and may be able to determine the cause. Waiting syncs, maybe?

The framerate drop may be rendering walls twice when it's not needed again. I'll run a profile on whatever recording you send.

The camera again: I think the only problem with reverting will be the one I mentioned before, with the focal point and glancing. That's where the changes started, I implemented meri's glancing idea, then the automatic turning looked bad, I fixed this, and then one thing led to the other. It should not be too much of a problem to find a different fix, like blending the focal point smoothly from something to whatever the smart cam would do when glancing is turned off.
User avatar
Z-Man
God & Project Admin
Posts: 11710
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Silly: Smart camera movement code is reverted. You really can get seasick from the new code.

Joda: So far, I had time to look at the first and fourth BUG on the server side, both missing rubber cries. In the fourth, the server's cycle was a bit ahead relative to your client's cycle, maybe because it got more acceleration from a teammate's wall. Old client compatibility code was in effect then. Your rubber from the previous grind was already half full, and the aheadness was only worth .3 rubber. I'll count it as a case of "shit happens" for now.
The first one is different. it's a subtle effect, too, where one frame meant the difference between life and death (/me wonders how you spot them): your turn was executed one server frame late. A fix has been applied to Fortress, it's a purely server side bug.
User avatar
joda.bot
Match Winner
Posts: 421
Joined: Sun Jun 20, 2004 11:00 am
Location: Germany
Contact:

Post by joda.bot »

z-man wrote: ... (/me wonders how you spot them):...
@z-man: Guess that's easy, ... I play too much
User avatar
joda.bot
Match Winner
Posts: 421
Joined: Sun Jun 20, 2004 11:00 am
Location: Germany
Contact:

Post by joda.bot »

RC1 (Windows 2000) bug with fullscreen mode...
I had problems with either RC1 or an earlier build switching between windows / fullscreen mode.

After removing cygwin and other sources (which use open source dlls) from the PATH environment variable , it's working fine right now ... though I'm not sure if that was the reason.

Another player "burn..." reported the same problem (he logged on CVS Fortress).
AFAIK he did test RC1 (Windows XP) without Cygwin on PATH and it did not work any better... I'll try to get this reproduceable. Guess a recording does not help once I got it ... any ideas/suggestions ?

EDIT: Aw, forgot the problem is you switch from fullscreen to windowed and there is no window visible you can switch back to fullscreen though.
Once this occurs it's deterministic (window is always not visible, taskbar/switchbar entries are there).
User avatar
Z-Man
God & Project Admin
Posts: 11710
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

I had the same problem a while ago, there's a prio 4 bug entry for it on SF. For me, it went away when we reverted to SDL 1.2.7. Maybe a different version of SDL is in your and the other guy's path? Or I screwed up the build. It really is an SDL problem, we don't tell the app to mimimize or hide (which is basically what it does) when you switch from fullscreen to windowed.
Post Reply