metal gear rising revengeance pc performance tweaks

When we first started using Wwise, sometimes he was not happy. There are different logs that are saved too, which were effective for debugging. We would keep the capture function on and do test plays, and then go back to where we were concerned about, so it was very useful in checking various peak areas. These capture data can be saved and you can check the part where you want later on. We reviewed these items to make the final decision on memory and CPU. In this particular scene, Delay and RoomVerb are bypassed, so the load from effect calculations (Total Plug-in CPU) is smaller. The effects being used are: Meter, Peak Limiter, Compressor, Delay, and RoomVerb.

This is because when there is a switch in the in-game situation, a large number of objects are released, and this process results in a momentary increase in CPU load. When you look at where CPU peaks, it is at the same time as when the Number of Registered Objects is greatly reduced. You can also see from this graph that the CPU peak and the peak in the number of voices are not aligned. In the case of the PS3, a lot is done on the SPU, so the CPU load becomes far less. The load in the total context is about 4-5%. This is an Xbox 360 capture, and one hardware tread is used at about 23%. The number of voices is 106, the number of voices where the signals were actually controlled (Number of Voices (Physical) is 48, and CPU is 22.86%. On PS3, the Vorbis format is used, so it’s even smaller. Despite that, he thinks the wav data is small. In this scene, in order to reduce processing, some of the BGM is in memory. This is because there are always multiple streams running concurrently, and also to support areas where there are a great number of voices. We allocated more memory to the Wwise engine than the sample allocation. So the total used for the entire audio is about 22MB. In this particular scene, he checked the wav data total, and it was less than 12MB. However, wav data are basically not included. It’s quite a busy scene, and he hopes it will be a good reference for you. Many of you will be worried about performance, so he made some performance captures of an actual in-game scene. ・Quality and performance can be balanced by the sound team. ・Of course, the richer we make it, the heavier it becomes. After that, all that the programmer had to do was call up events, so work became very easy.

You have to create the event yourself.” Once we got used to it, the sound team started setting the necessary processing within the event. So if the sound team asked for the BGM volume to be lowered during pause, all he could say was, “You have to make that event.” When we first started using Wwise, he remembers saying over and over again, “There’s nothing the programmer can do. There’s not even an API to change the volumes. (There are parameter controls and other functions in Wwise, but the main feature is events.) From the programming side, the only thing they could do was execute events, and at first, it felt like their hands were tied. He explains that the biggest difficulty during the initial integration of Wwise was that they couldn’t do anything from the programming side. There are parts that will ultimately have to be adjusted, like I/O and streaming, but at first, we just kept the sample as is. In other words, what programmers can do is quite limited, as he will explain later.

It was built to have some level of compatibility with the existing sound system. He thinks it took about 2 weeks to build the basic sound system. ・If we didn’t know what to do, we just used the sample for the time being, and it would run. Ohmori received some questions after the presentation, so he would like to explain a little more on how long it took to integrate Wwise, as well as some points on how we worked with Wwise. Note that sound effects are turned off in the videos so you can hear the music better.

Metal gear rising revengeance pc performance tweaks