Announcement

Collapse
No announcement yet.

Weird game speed in newly created maps

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Weird game speed in newly created maps

    When I create a new map and launch the game with it, game speed is different from what I get in any other map (even in those maps I created before).
    Basically, everything seems to be heavier and the game runs slightly faster than usual. Even the double click interval seems to be smaller.
    I can't track the roots of this problem, no mutators are launched and the map has nothing unusual in it, just BSP.
    Any idea why that could be?

    #2
    I would recommend going through the actor list in UEd to see if there are any "funny" non-standard typical actors (Edit-> Search For Actors). Also, are you using a different/non-standard game type or total conversion mod? The UnrealScript source code GameInfo.uc class uses text initializations options to set the game speed, which could vary depending on the gametype's default GameSpeed setting.

    Comment


      #3
      I think you might be hitting the overflowing framerate issue. If you create a map that is extremely simple and thus your hardware can render it at hundreds of frames per second, the engine gets confused and stuttering and other strange things start to happen. Check "stat fps" to see if that is the case. Setting the framerate limit to 100 FPS should help.

      Comment


        #4
        Originally posted by GreatEmerald View Post
        I think you might be hitting the overflowing framerate issue. If you create a map that is extremely simple and thus your hardware can render it at hundreds of frames per second, the engine gets confused and stuttering and other strange things start to happen. Check "stat fps" to see if that is the case. Setting the framerate limit to 100 FPS should help.
        Yeah, that's probably the case. The fps varies between 600 and 2000.
        How do I lock it? I know it's possible to lock fps for online play but I don't know how to do it offline.

        Comment


          #5
          Yea, that's definitely your problem there. Well, you can try a few things. The simplest one is to enable VSync in your graphics control panel. The second thing is to edit your UT2004.ini, under your renderer's section put "FramerateLimit=100" (although I'm not sure which, if any, renderers support this option).

          Comment


            #6
            MaxClientFrameRate=200, it depends on your system. If u have newer pc i suggest using 64bit patch, even so there are some bugs, the game will run smoother, and u will gain more fps.
            When playing online change this in console, netspeed 15000, that will break fps limit, and make it your maxclientframerate.
            I suggest not to turn on vsync.

            Comment


              #7
              Isn't MaxClientFrameRate for online only?
              Yes, I suggest using the 64-bit versions of the game as well, but for the reason that 32-bit is legacy and there will be more and more issues with it down the road (already 32-bit compatibility is merely emulated).
              And I do suggest turning on VSync. You don't need more FPS. What you do need is to prevent screen tearing at these high framerates, and solve the performance issues with over-the-top FPS values that the engine cannot deal with. Sure, there can be some input lag increase as it's only considered every 60th of a second, but the difference between that and a 120th of a second or less is minuscule anyway.

              Comment


                #8
                I will upload my settings when I get home since i have no lag issues in single or multiplayer. Hope it will help.

                Comment


                  #9
                  Originally posted by GreatEmerald View Post
                  Yes, I suggest using the 64-bit versions of the game as well, but for the reason that 32-bit is legacy and there will be more and more issues with it down the road (already 32-bit compatibility is merely emulated).
                  Even though it's partly true, there isn't much to emulate. Compatibility layers are very thin and trivial. Most programs being released are still 32-bit nowadays, and they're working just fine.

                  Comment


                    #10
                    Originally posted by bass3 View Post
                    I will upload my settings when I get home since i have no lag issues in single or multiplayer. Hope it will help.
                    I doubt that would help, because you need to both have a very strong machine that can pump out hundreds of FPS and play very simple maps for this bug to happen. Also of note is that one must never use another person's entire configuration files, only change settings one by one or at most in sections.

                    Originally posted by WGH View Post
                    Even though it's partly true, there isn't much to emulate. Compatibility layers are very thin and trivial. Most programs being released are still 32-bit nowadays, and they're working just fine.
                    Most programs? On Windows, maybe. On Linux, I haven't seen any program released in 32-bit only since around 2006, aside from proprietary and horrible ones like Skype. 32-bit is a dead end. Microsoft themselves want to end 32-bit, but developers are so entrenched in it and afraid of changing their compiler options that they keep proliferating 32-bit software (and Microsoft themselves are partly to blame for this, by artificially limiting some x86_64 PCs to 32-bit Windows if they didn't pay MS to upgrade to a higher tier). Though I wouldn't be surprised if Microsoft dropped WOW64 in Windows 9 or so, like they dropped WOW (16-bit support).

                    Comment


                      #11
                      Originally posted by GreatEmerald View Post
                      Most programs? On Windows, maybe. On Linux, I haven't seen any program released in 32-bit only since around 2006, aside from proprietary and horrible ones like Skype. 32-bit is a dead end. Microsoft themselves want to end 32-bit, but developers are so entrenched in it and afraid of changing their compiler options that they keep proliferating 32-bit software (and Microsoft themselves are partly to blame for this, by artificially limiting some x86_64 PCs to 32-bit Windows if they didn't pay MS to upgrade to a higher tier). Though I wouldn't be surprised if Microsoft dropped WOW64 in Windows 9 or so, like they dropped WOW (16-bit support).
                      Most programs on Linux are released in source code form, so you'll just compile them for any architecture you want . AFAIK most games e.g. on Steam still require x86 compatibility layers.

                      WOW64 and WOW are very different. After all, 16-bit is the real mode, which means almost no memory protection, segmented (as opposed to flat) memory model, no privilege rings, etc. When compared to the real mode, protected and long modes aren't that different.

                      Basically, almost the only thing you get with 64-bit applications is huge memory space, which most applications don't need anyway. There's a bunch of new registers and instructions, that's true, and it's pretty great, but it's not something radical. The only problem is that you have to have multiple versions of libraries intalled at the same time to support running both 32-bit and 64-bit.

                      Still, I do support the transition towards x86-64. 2038 is near, after all . What I wanted to say is that there're no drastic differences when you switch from 32-bit to 64-bit application.

                      Comment


                        #12
                        Originally posted by WGH View Post
                        Most programs on Linux are released in source code form, so you'll just compile them for any architecture you want .
                        Not exactly, there is also the issue of not presuming things. I had the unfortunate opportunity of working on an open-sourced program (which I wanted to port to Linux), and it at first didn't compile for 64-bit due to it using inline assembly, then after clearing that it compiled but was broken, as the authors presumed static sizes for things ("allocate 4 bytes and put a pointer in it" as opposed to the proper "allocate enough bytes to put a pointer in and put a pointer in it"). Of course, these things are very easy to avoid when keeping in mind that 64-bit exists, and it's not very hard to fix when things are open-source. The problem only happens when coders are completely ignorant of that. Or if they code everything well, but simply don't compile for 64-bit.

                        Oh, and there is also the x32 ABI on Linux, which was supposed to give the extra registers and all other nice things of x86_64, but the pointer sizes of 32-bit programs to save space, and it's again a problem since people now presume that x86_64 means large pointers...

                        Originally posted by WGH View Post
                        AFAIK most games e.g. on Steam still require x86 compatibility layers.
                        Mostly those that were ported straight from Windows. UT2004 itself is natively 64-bit, the last game I purchased (Expeditions: Conquistador on Unity3D) has a native 64-bit version, etc. Also of interest is that Unreal Engine 4 says "64-bit Windows", which might mean it won't even support 32-bit Windows any more (might as well, there is no 32-bit only hardware capable of running UE4 for sale these days anyway).

                        Originally posted by WGH View Post
                        WOW64 and WOW are very different. After all, 16-bit is the real mode, which means almost no memory protection, segmented (as opposed to flat) memory model, no privilege rings, etc. When compared to the real mode, protected and long modes aren't that different.

                        Basically, almost the only thing you get with 64-bit applications is huge memory space, which most applications don't need anyway. There's a bunch of new registers and instructions, that's true, and it's pretty great, but it's not something radical. The only problem is that you have to have multiple versions of libraries intalled at the same time to support running both 32-bit and 64-bit.

                        Still, I do support the transition towards x86-64. 2038 is near, after all . What I wanted to say is that there're no drastic differences when you switch from 32-bit to 64-bit application.
                        Those are, of course, fair points. It's just that it's long overdue for developers, game or otherwise, to move on from 32-bit software.

                        Also, is it just me or are we on a tangent here?

                        Comment


                          #13
                          Don't see a reason to switch to 64bit because I'm on windows anyway...
                          Oh well... Back on topic!
                          So Vsync basically locks framerate at 60 and adds horrible mouse smoothing (why?) and MaxClientFrameRate only works online
                          Any other way of capping it?

                          Comment


                            #14
                            Check your game options, there are different options for mouse smoothing there.

                            Comment


                              #15
                              Originally posted by UnShame View Post
                              Don't see a reason to switch to 64bit because I'm on windows anyway...
                              Oh well... Back on topic!
                              So Vsync basically locks framerate at 60 and adds horrible mouse smoothing (why?) and MaxClientFrameRate only works online
                              Any other way of capping it?
                              UseVSync=True
                              DesiredRefreshRate=85 <--- set this line to your native pc refresh rate and it should be normal.

                              What you have is input lag caused by vsync to reduce screen tearing.

                              Comment

                              Working...
                              X