Differences between dedicated and nondedicated server

#1 Just to add a little more information...When I say jitter, I mean that all positional movement is jittering. Standing animations work smooth. But anything that moves seems to have to back track to re-sync. Like the client is way ahead of the server and has to backtrack each time. Even just moving the first person around or rotating the view jitters.

But all works smooth when the multi-player server is started from a client. The other clients, on other computers, don't jitter in that case.

Help please!!!

#2 I would love to hear some feedback from anyone on this issue. A little more information:

If I start the server from a client but comment out the "%conn.connectLocal()" call after creating the server, the problem is still there but not quite as bad. So here is a summary:

Start a multi-player game from a client = good, smooth gameplay on all clients that join.
Start a multi-player game from a client but don't connectLocal = not good nor smooth gameplay on clients.
Start a multi-player game from a -dedicated server = horrible graphics and not smooth at all on clients.

It's almost like the server gets too far ahead of the clients, when not tied into the same process which has graphics rendering. Or somehow the clients are too far ahead. Regardless, there is a horrendous amount of backtracking going on.

GG, anyone? Does anyone see this in other games when running -dedicated? I would even love to hear that someone is successful with -dedicated.

#3 Hey Joey -
yeah, i've been hoping someone would have some advice as well.
i've actually noticed a similar thing in our fairly heavily-modded TGE 1.3 codebase:
a "standalone" instance acting as both client & server runs quite smooth,
whereas a plain client connecting to a dedicated server on the same machine experiences what feels like lag.
not a *horrendous* amount, but noticable as you pan the camera, say.
when compiled & run on linux, the same codebase works as a dedicated server just dandy.

#4 Orion, thank you for responding. So, are you saying that with a dedicated linux server, a windows client can connect to it and it is much smoother graphically than with a windows server?

I've made all my modifications in 1.4. Is anyone doing dedicated windows servers in 1.5?

Also, I have not compiled things on Linux. Are the compilers and setup relatively straight forward? I have a lot of Sun-Solaris experience from years ago so unix doesn't scare me. I only see one Makefile in my source branch.

#5 I'd hesitate at saying that linux vs. windows is a for-sure factor w/ dedicated servers,
but with my particular machines etc, etc, yeah: a windows client connecting to a dedicated server on a remote linux host is smoother than the same client connecting to a dedicated server on the same windows box.

compiling for linux is fairly straight-forward, i think.

#6 Interesting finding...If I take the exact same installation to a slower computer and host from there (on Windows), it works fine. There must be something with the internal clock-syncing loop of Torque that isn't completely sound.

#7 I haven't seen anything like this in our TGEA 1.03 based codebase.

However, we ran into issues like those you describe but they were only affecting the control object.
Is this the case on your end?

#8 Stefan, so you mean the control object would be jittery, but other objects in the scene would be smooth ? interesting, i haven't looked that close. i'll check it out next week.

#9 Yeah. Or at least smooth enough not to be visible.

If that's the case, try commenting out the control-object return statement in your packUpdate/unpackUpdate functions. Then comment out writePacketData/readPacketData.

I guess it probably isn't identical to our issue, but it's worth a shot. Perhaps also try enabling precise floating-point calculations in your compiler?

#10 In my case, it was more than the control object. I had several AI objects running around and they were back tracking as well. Another interesting characteristic of the "faster" server which showed the problem is that it is a multi-cpu (AMD) machine. It's hard for me to believe a "faster" machine has the problem but easier for me to believe that there could be some threading issue which manifests itself only without the graphics. I'll be trying it out this week on other multi-cpu servers.

#11

Quote:whereas a plain client connecting to a dedicated server on the same machine experiences what feels like lag. not a *horrendous* amount, but noticable as you pan the camera, say.

I encountered a similar issue when connecting to a dedicated server hosted on the same machine. This was resolved based on the WinTimer code as detailed near the bottom of this thread in the post by Clark Fagot.

Checking back in our SVN logs here's the actual WinTimer code we ended up using:

class WinTimer
{
   private:
      U32 mTickCountCurrent;
      U32 mTickCountNext;
      S64 mPerfCountCurrent;
      S64 mPerfCountNext;
      S64 mFrequency;
      F64 mPerfCountRemainderCurrent;
      F64 mPerfCountRemainderNext;
      bool mUsingPerfCounter;
   public:
      WinTimer()
      {
         SetProcessAffinityMask( GetCurrentProcess(), 1 );
         
         mPerfCountRemainderCurrent = 0.0f;

         mUsingPerfCounter = QueryPerformanceFrequency((LARGE_INTEGER *) &mFrequency);
         if(mUsingPerfCounter)
            mUsingPerfCounter = QueryPerformanceCounter((LARGE_INTEGER *) &mPerfCountCurrent);
         if(!mUsingPerfCounter)
            mTickCountCurrent = GetTickCount();
      }
      U32 getElapsedMS()
      {
         if(mUsingPerfCounter)
         {
            QueryPerformanceCounter( (LARGE_INTEGER *) &mPerfCountNext);
            F64 elapsedF64 = (1000.0 * F64(mPerfCountNext - mPerfCountCurrent) / F64(mFrequency));
            elapsedF64 += mPerfCountRemainderCurrent;
            U32 elapsed = mFloor(elapsedF64);
            mPerfCountRemainderNext = elapsedF64 - F64(elapsed);
            return elapsed;
         }
         else
         {
            mTickCountNext = GetTickCount();
            return mTickCountNext - mTickCountCurrent;
         }
      }
      void advance()
      {
         mTickCountCurrent = mTickCountNext;
         mPerfCountCurrent = mPerfCountNext;
         mPerfCountRemainderCurrent = mPerfCountRemainderNext;
      }
};

#12 Thank you Gary. The above code seems to have fixed all my windows-dedicated-server-jitter problems. Much appreciated.