Hello IMC, please show us more about your progress with Multi Threading!
We want to see what we are going to have in a few patchs… IMC pls :c
7 Likes
It still surprises me that TOS only uses one core. The thing is Koreans have these super computers with one core or something?
I really dont know why they didn’t do multi threading coding from the head start. ToS, aka Project R1 started on 2011, I guess? They must have been extremely short on money or the project staff might be too young / unexperienced.
However, they already implemented and showed some nice results, I want to see more of their progress D:
In case if someone that didnt saw tos multi thread
I wouldnt expect too much from that video. The game fps isnt too bad when standing still/moving in a small area(after everything are loaded). The game lag the most when loading things. I have to question why does ToS has to reload everything whenever our character is a certain distance away. Ugh…those shops in fedimian that fall from the sky…it will be good if they can just delete those useless animations. Not cool at all when the animations are causing so much lag.
2 Likes
Answering your question, multi-threading often introduces a lot of bugs, and those aren’t simple to fix, since the logic involved in parallel operations are way more complex then in a linear one, so by introducing multi-threading to the game graphical part they might find a bug in map loading for example, that can only be fixed by changing something in the way the game loads the data from the server.
Tl;Dr they probably had problems during internal tests, so they are holding back until they fix the most glaring issues
1 Like
I just realized how useless (someone correct me if I’m wrong) that test they’re doing is, or at least how that would barely impact performance.
The character isn’t even moving around - just standing there.
The sharp drops in FPS often happens when a lot of new objects come into your draw distance.
Sure they may only happen for a few seconds, but there will always be instances when such would occur continuously for an extended amount of time e.g. when there’s a lot of people appearing in-&-out and skills happening in your draw radius - GvG is an example of that.
To prove, I was doing some test regarding VSync with this game some time ago - it’s a different matter but to show you - notice how at 0:08 the frame rate starts to significantly dip from 40+ to ~14 as soon as I entered the area with a lot of players around.
Did anyone ever feel like the video they shared seems sketchy? Why crop it? Why not show the graphic settings for each window? How are we sure they didn’t just install FPS Savior or SFX Toggle and then call it an improvement?
Besides FPS Savior, the only real performance improvement I’ve ever significantly felt in this game was when once I was using @Velcro’s workaround which unfortunately he’s discontinued due to too much time required for its upkeep each time there’s an update.
4 Likes
It is not that useless.
As far as I know, they’re multi threading animation updates, something that affects every scenario. Basically, an animation has a set start and finish point, i believe they’re multithreading each frame draw to multiple processors, decreasing total render time.
Also, they mentioned about resource management. Resource load is what makes the game to stutter, with multi threading I do expect a big improvment on this (please IMC don’t break my expectation), since what causes the stutter (sudden freeze) is: Main thread needs to wait the object to load, it will remain stopped while the object didn’t finish loading.
What causes this huge delay in object loading is connection speed - it is not related to cpu/gpu/hd speed. If you use some kind of net limiting software, reduce ToS bandwith and you will see that the stutter time will increase.
This is a huge flaw that i dont know why they coded that way, to not split object loading in multiple threads and sync them up.
By multi threading it, i hope the main thread keeps going and working asynchronous with the threads responsible of object loading, eliminating the stutter.
1 Like
I’m not much of a techie so can someone mind enlighten me, does this multi-threading make use of dual/quad cores more efficiently or will the game still be limited to run on one core?
Yep, exactly.
Instead of 1 core having to do all the work you send part of the work to other cores, and when they are done you merge everything
Multithreading will allow the game to utilize all cores.
Hope the multithread patch comes with a 64 bit client so it can use more than 4 gigs of RAM (1.7 after counting for all my other 32 bit programs)
Eh, I guess my analysis was too “just the surface” then.
Still, I find it weird that they didn’t show the comparison with a character moving around.
progress? updates? lol
20char
I’m not so sure if they will make it use all of cpu cores.
Using two CPU cores is a must, a standard nowadays. Past from two cores is another thing.
I’m novice at it but multi threading is not something easy that can be done in overnight. It’s kinda hard to find a game that uses up to four CPU cores, and when they uses more than it, there is a RAM/GPU bottleneck that will not take advantage of it.
It is really hard to parallel games, depending on what they do.
This video explain exactly why parallization is hard in games:
64 bit is something impossible. There are still many x86 processors out there, and the advantage would be unnoticeable for the required work to rewrite the code in 64 bits.
Also a game from ToS caliber will not ever use up to 4gb. If they do, the game has a severe memory leaking.
Judging by the new GvG videos progress was exactly 0.000000000 % better performance
Multi thread is not implemented yet, neither on ktos or itos.
what about jToS?
I dont know nothing about jTOS
This is so wrong…you were talking about how CPU helps with loading and suddenly you say it is internet related…if you limit the internet connection of ToS, of course it is going to slow down the process. It is called latency, aka lag. Stutter can come from many causes. Here IMC is assuming the problem comes from queued frames and resource management. These process happen in client’s pc, mainly affected by CPU. If done well, the game will very likely become more smooth but the fps probably wont increase much which is as the optimization video showed.
https://developer.nvidia.com/sites/default/files/akamai/gameworks/CN/Stuttering_Analysis_EN.pdf
1 Like
It is not wrong.
What happens is - New object is detected on your radius. It needs to wait the download of information of each then load the corresponding data
The problem lies that both player data and its corresponding object datas are loaded at the same time, so the main thread needs to wait to resume rendering.
If loading a object would be just the problem, it would not stutter when loading objects with same 3d models and textures previously loaded, since it is already cached on your RAM, thus, being ultra fast to load
Take for example a place moderately crowded with no much people on it - run nearby, it will stutter, then run away, then get close again, it will stutter again.
The ultimate proof that i’m not wrong is easy to obtain, open Process Explorer, increase refresh rate, go to tos.exe properties then go to threads
Whenever the game stutter you will see that the main thread CPU usage is at extremely low values, almost zero, also, no I/O activity (data being loaded from disk)
There is no reason for a game parking CPU usage while freezing to supposedly load object data (3d models and stuff)
1 Like
nope just tested running around fedimian with process explorer running side by side with the game and resource monitor, the cpu usage never fall low when stutter. Cpu usage showed in process explorer and resource monitor adds up correctly. I suspect you are talking about hang, not micro stutter.