+ Reply to Thread
Page 2 of 12 FirstFirst 1 2 3 4 5 6 ... LastLast
Results 16 to 30 of 180
Like Tree145Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Tech Talk: RIFT Performance in 2.2

  1. #16
    Plane Touched marodeur's Avatar
    Join Date
    Jan 2011
    Posts
    213

    Default

    Quote Originally Posted by Slipmat View Post
    I've noticed that since Hotfix #9 last week, here on Icewatch (EU) every Volan event has been very smooth and very playable, even ones that have popped 8-9pm server prime time

    If that was just the start of the tweaking, i look forward to 2.2 and beyond
    Because Volan spams Dispel on himself like mad since one of those last hotfixes, try to DoT him and you will notice they get removed after a short period of time.
    Last edited by marodeur; 02-22-2013 at 12:01 PM.

  2. #17
    Plane Walker Zsokorad's Avatar
    Join Date
    Jun 2011
    Posts
    416

    Default

    You are now my favorite dev

    Thank you for actually posting thorough, detailed information about something.

    Edit: Another area that may need a look is crafting. Every time something is crafted and the cast bar goes across the screen, the entire game freezes for a second, and then unfreezes only to immediately freeze again because the next item was being crafted in the background. This is so far down the totem pole of problems so don't bother looking until you've gone through the things that can directly effect combat - but just wanted to mention it since we're on the subject of game performance and quality of life.
    Last edited by Zsokorad; 02-22-2013 at 12:06 PM.
    Deepwood | Aschana | H1325 | PA1427 | R94 | 20017 pts
    ~ Dedicated Chloromancer ~

  3. #18
    Prophet of Telara Frailaq's Avatar
    Join Date
    Jan 2012
    Posts
    1,181

    Default

    I'm still trying to figure out how I can like that opening post more than once
    Avatar by Rotaken on deviantART.

  4. #19
    Ascendant Shattered's Avatar
    Join Date
    Feb 2011
    Posts
    3,932

    Default

    Fantastic. I appreciate this sort of informative post and acknowledgement of the performance issues that have been the subject of untold numbers of threads more than I can say. And as a player with a slow CPU and fast graphics card, I feel I have something to look forward to. Thank you.
    RIFT- now Pay 2 Gamble 2 Win
    <Shattered Chain> of Faeblight .::. currently enjoying Guild Wars 2

  5. #20
    Rift Disciple FooFighter's Avatar
    Join Date
    Feb 2011
    Posts
    182

    Default

    Awesome post Zorba! Digging into the performance problems and resolving them is by far the best improvement you could make to Rift and will please many.

    -Foo
    NQ - Foo

  6. #21
    Telaran Mammothtruk's Avatar
    Join Date
    Apr 2011
    Posts
    91

    Default

    from the deepest place in my heart, thank you for the work you are doing for this.

  7. #22
    Rift Disciple
    Join Date
    May 2011
    Posts
    145

    Default

    Great post Zorba. Thanks for the detailed information. I appreciate it both as a customer and as a programmer.

  8. #23
    Sword of Telara Crovack's Avatar
    Join Date
    Jan 2012
    Posts
    809

    Default

    MultiCoreSupport++;
    I realize this isn't a simple request, but even splitting off some portion onto other cores could prove beneficial. Thoughts from someone who can't claim to have a full knowledge of the system: -could addons usage be pushed to a separate cpu more easily? -what about non-critical graphics processing, such as cloaks, shadows, etc?

    On a separate issue, could you implement a way in which to pick and choose what graphics to render? Ideally this could even be setup to difference circumstances (instance, open-world, pvp-wf/cq). Things like:
    Render Friendly Non-Beneficial Spell Effects (I don't really need to see when the mage-chloro next to me is casting void life)
    Render Friendly Beneficial Spell Effects (seeing things like Lava Field and Orchestra of the Planes actually is important)
    Render All Hostile Effects (obvious) vs. Render Only Area-Specific Hostile Effects (aoes)

    Allowing some of these effects to be selectively enabled/disabled could allow for a reduction of total processing on the system. I also believe I've seen games that have a 'bare minimum aoe' setting which essentially turns aoe effects into a flat green/blue area (beneficial) or red area (detrimental).

    Forgive me if any of the above have been asked/answered elsewhere.

  9. #24
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    Nice write up

    KBM, all plug-ins and associated libraries will be moving over to the next generation API system in Rift 2.2, which should future proof the engine for some time. As Zorba said though, you'll not notice much performance difference until the old system is removed.
    Rank 76 Guardian Mage

  10. #25
    Rift Master nacho's Avatar
    Join Date
    Jan 2011
    Posts
    678

    Default

    Great, thanks!
    I think most gaming PCs have a stronger GPU than CPU so any CPU efficiency improvements are greatly appreciated.

  11. #26
    Telaran
    Join Date
    Feb 2011
    Posts
    87

    Default

    Can we count this as our state of the game letter? :P

    I cannot like this post enough. So glad to see multithreading and performance issues are being taken care of.
    Formerly: Nanase - Rawrior | Camilah - Rogue | Krystie - Cleric | Myuria - Mage

  12. #27
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Greetings, fellow Telarans!

    Most of the time I work on RIFT’s Addon system, but lately I’ve been co-opted for some performance improvements. We want your stay in the world of Telara to be as smooth and beautiful as possible, and making the client fast is an important part of that.

    In 2.2 we’ve got a few fixes that might boost your framerate by around 10%, and I thought I’d give a quick explanation on the major things we improved and what our next steps are. Be warned: this might get a bit technical!

    First, I’m sure you’re all aware of the cloak physics simulation code that is now in the game. Every frame we update a “collision skeleton” for the cloak to bump into. This is a simplified model of the player character – it looks kind of like a balloon animal - that’s easy to do physics calculations with, so the cloak doesn’t move through your body and legs. Before the launch of 2.0 we updated our collision skeleton in a simple manner that worked fine for a simple model, especially given that the cloak simulation itself was rather slow.

    Since then, our artists have improved the collision model quite a bit, we’ve added support for dynamic mount collisions, and we’ve multithreaded the cloak simulation so it can take advantage of recent high-end processors. This all means that the collision skeleton update was turning into a major speed bottleneck. We solved this through caching a lot of the internal data and updating it only when necessary, as well as moving more of the skeleton update system into the multithreaded section. This took some work to get right, considering that we had to deal with polymorphs and mounts and the like, but this alone gave us around a 3% improvement in busy environments like cities and raids.

    The second issue was in the addon system. Our addon system tracks a lot of data internally so it can hand our addon authors compact and detailed messages. Without this work, writing an addon would be many times more difficult than it is today. Unfortunately, it turned out the addon system was doing a good deal of redundant and unnecessary work with abilities, often processing a lot of data and then throwing it away after it was discovered to be un-needed. Many of these checks have been moved earlier in the process, so that instead of throwing away the data, we just never generate it in the first place. (The fastest code is, of course, code that never runs ) We’re also in the middle of a major rework of the addon framework event system – you won’t see any performance gains from this right now, but once the old system can be removed, there are further improvements we can make to addon performance.

    Finally, we found a small stable of small performance losses in the ability button code. I know, I know, “it’s an ability button, how complicated can it be? You just check to see if it’s on cooldown!” RIFT’s abilities are actually really complicated!

    Some abilities require specific item types to be equipped (Druid’s Fervent Strike, for example). Some abilities require that the player or target has a buff (Necromancer’s Desecrate), some need to keep track of a past event (Bladedancer’s Reprisal). Some even share cooldowns with other abilities (Paladin’s Shield Throw and Void Knight’s Spark). Many of these checks had performance problems, and while none of them individually were huge, together they added up fast, especially given how many abilities a RIFT player usually juggles.

    For a specific example: Years ago, Rift was a much simpler game, with a small number of roles available and a maximum of two dozen ability buttons on the screen at once. Every frame, for each ability on your bar, it would have to unpack a small data structure and figure out whether it represented a Role ability or not. With a small number of buttons and a small number of roles, this wasn’t a problem . . . but now that you can fit over 130 ability buttons on the screen at once, and each button has six roles to check, it became an issue Easy to fix in many ways, via a more efficient search method and a little caching – we just needed to realize it was a problem. That’s one of the things optimization is all about – making sure that the code best represents the game as it is today, not as it was two years ago.

    Keep in mind that these fixes are all CPU improvements. They’ll be most noticeable to people with slow CPUs and fast graphics cards, ideally running at low detail settings. If you have a fast CPU and a slow graphics card, the gains might be smaller.

    So, what’s coming up next?

    First, realize that these are all possibilities, not guarantees. Performance improvements are uncertain at best!

    The work I’ve been doing up until now has been idle optimization, with a character standing in the middle of town or an empty field, or, at most, standing in the middle of a flock of a hundred test bots. Obviously there’s a lot of benefit in catching universal performance issues without combat muddying up the data. Equally obviously, if there are performance problems in combat, idle optimization won’t find them My next step is to take this on to live servers, running performance tools while standing shoulder-to-shoulder with you fighting zone event bosses.

    Next, there are several hotspots in our rendering pipeline that don’t seem justified. We seem to be using too much CPU to render models; we seem to be using too much CPU to calculate shadowing; we seem to be using too much CPU, ironically, on one of our performance optimization passes. It’s possible that these will be dead-end leads, but they’re worth looking into. Again, I want to reiterate that there’s no way to know if these will work – if I knew, I’d already have fixed them – but they’re all possibilities.

    Finally, those of you with modern multi-core computers may have noticed RIFT does most of its work in a single thread. Modern computers are capable of calculating many things simultaneously, but RIFT, by and large, does all its calculations in a straight-line order, not taking advantage of multiple cores or processors. I think there are opportunities to split RIFT’s work into several threads and really exercise modern gaming computers. The programmers reading this are cringing in sympathy right now, as adding support for multiple cores is often a nightmare, but it’s worth trying for the framerate boost that might be achievable.

    With luck, you’ll see a few of these issues fixed in 2.3. I hope you’ve enjoyed this look behind the curtain of RIFT development!
    And now you see why Rift addon authors are happy -- because this is the dev we get for our stuff.

    We should totally get some kind of graphics benchmark thing.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  13. #28
    Rift Disciple
    Join Date
    Sep 2010
    Location
    Saskatoon, SK
    Posts
    109

    Default

    As a professional software developer myself, I like how you admit to using profiling tools. Sometimes you get the output of them and go "no way, it couldn't be bottlenecking there!" and you improve that section, and you can actually see a huge difference. I applaud your methodology.

    As for optimization, and parallel frameworks, see these links:

    MSDN PPL (Parallel Patterns Library) : http://msdn.microsoft.com/en-us/library/dd492418.aspx (you're on windows for the client at least, so this'll be available)
    C++ <thread> header: http://en.cppreference.com/w/cpp/thread - If you're on 2012, this is really useful, but you're probably not. Stick to PPL, it's in VS 2010. If your server side is Linux/Unix though, this has been in GCC for a while.
    Boost Thread: http://www.boost.org/doc/libs/1_53_0...ml/thread.html If you're not on 2012, boost is always an option, and allows you to transition to the standard later easily.

    Even just using parallel_for_each in a few strategic places can have a surprising effect. Profiling will find that for you, which you already know.

    Good luck! I actually find this type of thing really fun. It can get really slagged down and not fun sometimes, but overall, it's one of the better parts of working on a large system IMO, if management lets you find the time to do it!

  14. #29
    Soulwalker Flycutter's Avatar
    Join Date
    Jan 2011
    Posts
    15

    Default

    Can you fix this while your at it?


  15.   Click here to go to the next Rift Team post in this thread.   #30
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Flycutter View Post
    Can you fix this while your at it?

    Actually, now that I have the tools set up to debug clients on live servers, this bug is on the list - we've been unable to duplicate it locally, but (hopefully) I can figure out what's going on while I'm tracking down performance problems.

    No promises, unfortunately, because I've already tried to fix it twice and failed. It's proven quite slippery.

+ Reply to Thread
Page 2 of 12 FirstFirst 1 2 3 4 5 6 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts