Announcement

Collapse
No announcement yet.

How much is too much for Tick()

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

  • replied
    I'd suppose all ticks stem from "the native tick", like El Muerte's example illustrates in the "AllActors tick" line.

    Leave a comment:


  • replied
    Originally posted by Bonehed316
    Well, rendering the same thing over and over is better than rendering only once every 1/MaxTickRate seconds.
    Why? If it's already on the screen, what is there to gain by rendering it again?

    I would have thought all simulation/updating/whatever would be done from the native tick (indirectly, of course). Is this not the case?

    Leave a comment:


  • replied
    You could see it something like this:
    Code:
    function EngineEntryPoint()
    {
      while (dontQuit)
      {
        deltatime = lastTime-currenttime;
        EngineTick(deltatime);
      }
    }
    
    function EngineTick(deltatime)
    {
      foreach level.AllActors(class'Actor', a) a.tick(deltatime);
      if (client)
      {
        level.Render(deltatime);
        interactionMaster.Render(deltatime);
      }
    }
    well... something like that.
    you could rendering things in a tick event, but it's
    1) stupid, wasting resources
    2) and useless, whatever you render might not be visible on the screen because it's overdrawn

    Leave a comment:


  • replied
    yea figured, unpredictable as in, overlapping double renders?

    Leave a comment:


  • replied
    No, he said that the render pipeline is initialized from tick, meaning, I assume, that the "engine->Render()" call is made from tick inside of the engine. So in other words, the engine renders during (more likely AFTER) tick gets called. But of course you can always render from tick if you have a valid canvas reference, but you might not want to (results may be unpredictable).

    Leave a comment:


  • replied
    This is gettin SUPER interesting, so do you mean that Tick can be use to render stuff on the HUD? but since the server doesnt render anything it wont matter and look like a normal HUD render event?

    Leave a comment:


  • replied
    only dedicated servers use maxtickrate, this is to for one reduce the server load, otherwise it would (like the client) try to do as much things as fast as possible (resulting in 100% CPU load). This is, not really useful. Clients will try do to as much as possible as fast as possible (unless the framerate it capped). Servers don't have to do any of the rendering stuff or visual effect things.

    Just because the server ticks at 30Hz doesn't mean the client also ticks at 30Hz. The client ticks as fast as it can. It will only receive updates from the server every 1/30th second. In the time between the updates from the server the client will simulate the changes that it expects.

    Leave a comment:


  • replied
    Well, rendering the same thing over and over is better than rendering only once every 1/MaxTickRate seconds. Under the assumption that this was true in the case of standalone games, it makes more sense to render independant of tick. However, if this is not the case then tick must be called more frequently offline than online, which changes the whole dynamic of my understanding of the engine, and really makes more sense in the process.

    Leave a comment:


  • replied
    Originally posted by Bonehed316
    But tick gets called at most once every 1/MaxTickRate seconds, which is far less frequent than PostRender. Not calling PostRender every frame would result in horrible shimmer effects. And rendering only on tick would result in much fewer than 85 fps, or a much higher tick rate than necessary.

    I guess you could find the time delta between any two post render calls to proove it. I just assume that because HUD code takes up a majority of the execution time, that it must be called more often, ie every frame.
    Rendering twice in a row would be a waste of time. Nothing will have changed, so the exact same thing would be rendered all over again.

    I'd say if HUD code takes up the majority of execution time, that would be because rendering code is generally slower, not because it executes more often.

    Leave a comment:


  • replied
    you are completely right, in case of a server.
    but then again, on the server nothing is rendered.

    Leave a comment:


  • replied
    But tick gets called at most once every 1/MaxTickRate seconds, which is far less frequent than PostRender. Not calling PostRender every frame would result in horrible shimmer effects. And rendering only on tick would result in much fewer than 85 fps, or a much higher tick rate than necessary.

    I guess you could find the time delta between any two post render calls to proove it. I just assume that because HUD code takes up a majority of the execution time, that it must be called more often, ie every frame.

    Leave a comment:


  • replied
    Well, the rendering pipeline is initiated from tick. Every tick is a single frame.

    Leave a comment:


  • replied
    Uhhh...no.

    The script profiler will tell you that HUD code accounts for 50-60% of the script execution time. It also, for the most part, gets called every time the canvas renders, which if you are running 85fps, is 85 times per second, which is significantly more than the 30 or so times tick MIGHT get called per second. Therefor HUD code gets called more frequently than tick code. Generally your draw calls are a huge portion of your execution time, which is just about all of what the HUD does (not much point in doing something in the HUD if you dont draw it, right?).

    Leave a comment:


  • replied
    Originally posted by Bonehed316
    Not by a long shot. HUD code is far worse, lol. HUD code also gets run every FRAME, which is more often than every tick.
    now that's interesting, did you make up that yourself?

    Leave a comment:


  • replied
    Not by a long shot. HUD code is far worse, lol. HUD code also gets run every FRAME, which is more often than every tick.

    Leave a comment:

Working...
X