Oh! Thanks much for listening!
You should take a look here as well: Micro-stuttering / Game catches up when you stop moving
Itās a very similar issue, might be caused by the same thing, and has videos to show it off.
Yup, that particular thread I already bookmarked. I also have animation freezing, companionās Coursing animation discrepancy, and skills having to be used more than once to actually work.
If thereās something else I missed please let me know, thank you.
Here is a better summary of the situation that I would send instead of the spaghetti thoughts Iāve had so far in the thread:
I would specifically tell them to look at code relating to their TCP protocol because I suspect itās somehow causing the overall game process to idle and consume fewer CPU (and probably GPU) resources (perhaps because it is blocked and waiting for repeatedly lost packets).
Our initial tests showed that the ToS client .exe does not appear to be CPU limited because only 2 out of 4 active cores of an Intel i5-4460 is enough to achieve 60 FPS when there are not a lot of other players around. The ToS client .exe is likely not GPU limited either because as shown in the opening post, even when there are a lot of players, the GPU does not appear to be very active. Furthermore, even when using an Intel HD Graphics 530 card, a player can achieve 40 FPS in a city map when no other players or NPCs are around.
The biggest giveaway is that restricting the Client_tos.exe to only 1 core reduces FPS by 25 when there are few players around, but restricting Client_tos.exe to only 1 core reduces FPS by only 5 when there are a lot of players around. This suggests that something about having a lot of players around causes less draw calls (resulting in lower FPS).
EDIT: Special thanks go to @ridleyco, @Maavy, @sksben for collecting much of the data and the useful back and forth.
Thanks also to @nizidr for prodding me into taking a deeper look at the whether the ToS client was truly multi-threaded or not. Turns out it is multi-threaded, but turns out the performance hits might have nothing to do with CPU or GPU.
I guess this proves that IMC has some pretty bad programmers.
On top of the FPS rate, their network programming is also pretty bad. If you lag, your character would glitch to attack twice or freeze in animation. Itās too server side heavy in terms of processing data.
And now this post here proves that their engine is also badly designed. Inefficient and not optimized.
i think the problem is that one core just cant do 1080p even a i7 , i dropped my res to 1600x 900 and the fps is alot better :S , the solution is getting a 720p monitor xD.
They were in iCBT2.
40+ players Dullahan was hell. (Yep, 2fps, you named it.)
I too had the feeling (even in āemptyā field) that drooping packets were harming TOO MUCH my performance. (Things like attack/skills not triggering, or with seconds delay.) This only happened on ābadā (=unlucky) days.
I remember this one boss monster attack in iCBT2 that really killed the framerate when it was used. They seem to have removed it from the game now. This bullet hell thing.
Now with the eyes on Lag through TCP stuff it might make sense because every bullet probably had to be synced and wait for a response and thuse immediately cause huge lags > low framerates.
Allthough, in field boss fights when thereās a lot going on and now we think the low framerates are not caused by gpu/cpu but TCP waiting.
I remember occasionally having graphical glitches when there are a lot of spells on screen.
This is also a screen from iCBT 2, but iāve already had this happen recently in fights, just didnāt capture it anymore.
Notice especially those blocky sprites popping up near my reflect shield. I Think the flames over the screen were also wrong.
People who have been in big field boss fights may know this flickering issue.
So that clearly has to be a GPU issue, no? (Iām using an i7-4790k @ 4.00 GHz & Geforce GTX 980)
So about tcp stuff if i understand well a customer with low ping have a best framerate than the one with average ping but the game is hosted in NA actualy isnāt he ?
So we can say when they will merge server in eu our framerates will up more or less ? did i understand or iām totaly wrong
There might be something up with the UI in general as well. Chat bubbles (especially from megaphones) cause FPS dips (PLEASE PLEASE PLEASE tell the Dev team we want an option to completely turn off global chat), and I just took a video to show the freezes that happen when you have to pick up a lot of objects:
http://puu.sh/ogBbj/c5c1c56533.avi
I guess it could just be the network code, too, but without fail whenever something new has to appear on screen, like a notification you just looted something, the game decides to freeze.
Iāve read somewhere in reddit from a user with wireshark, that the main issue seems to be positioning other players. Basically it was stated that other playerās movement need to be synced which resulted in a LOT of packets. Considering the boss that had bullet hell, this would perfectly explain what the problem was.
Concerning global chat spam lag, you could fix it just by adding a firewall rule that prevented the TOS client from even receiving those messages, and by not having to process them in the client the FPS was higher and smoother (you could do this with windows firewall for example).
This also explains a bit about the world, ToS has instances because this network model doesnāt scale, so you canāt have huge maps with everyone in it sendind position packets of everything to everyone. Another possible fix would be to not receive data concerning users/enemies who arenāt close to your viewport. So basically if theres a player on the other side of the map, you donāt need to see him or acknowledge where he is/what he is doing. Im not sure how the game works, but I assume that you receive data from every player on the map. This could easily be tested, just go to a crowded map and stand in an edge far away from everyone else. If you still have big Lag spikesm then the issue is confirmed. On my experience in cities, it seems to be the case since even standing at the edge of the city I still see Lag quite often.
TOS is a server-side centric, and considering how sparse the player population is at the moment it certainly explains a lot of issues. So one quick solution would be to have more servers closer to the playerbase. So one server that is actually in Europe, another in South America, another in USA West Coast and maybe some others places as wellā¦
But the real solution seems to be optimizations on how player position/action is syncronized.
@Nyyppa: Youāre correct. Every client-sided information is a possible path for cheating, although thatās how mob collision works right now (your client tells the server āI hit the X mob with Y skillā and the server calculates the damage.
@chronosanct: A āhand-implementedā packet confirmation for UDP pretty much makes it become one of the various other protocols mentioned in that paper, according to implementation. Most of them are based on UDP (as all network traffic supported by our infrastructure is either TCP or UDP nowadays).
(Also, the HD Graphics 530 can deliver over 50fps on Bioshock Infinite @1080p on High settings; itās a pretty solid GPU)
For documentation, my testing was done from Brazil, with a ping of about 230ms.
@Staff_Julie: Thanks for listening! Good to know that our voice is being heard. I hope to see fruits from this!
@miguelc0611: I donāt think that the issue is server-sided. They use AWS, the server should be set up with more than enough processing power for any MMORPG.
@Minto: Care to provide some numbers? Our testing didnāt involve multiple resolutions, but we pretty much showed that processing power isnāt the issue with the FPS drops. Maybe reducing the resolution also reduces your field of vision (which is a bad move), decreasing the number of player objects? Iām not online to test this myself right now.
@herbafina: Yes. Ping should directly affect framerate, as youāll spend less time waiting for TCP confirmationā¦ assuming the server isnāt taking long to deliver this confirmation due to a high CPU load on the server.
You donāt get input from players directly out of your viewport; they donāt even have to be close. Thatās why sometimes player models take a while to load right when they come in your screen.
Party members are an exception. You get a part of their movement packets to update map position.
I dunno if you guys also go on reddit, but they have a similar thread related to performance that covers a lot of similar bases (but also includes some potential fixes)
Based on what Iāve read, the problem isnāt just that the gameās networking is only in TCP. The bigger issues seems to be that all of the networking is done on the gameās main thread and networking is done using TCP. Meaning your computer is waiting on packets to draw frames. Meaning high packet loss = a significant drop in FPS.
Are you sure? Because if this is true then going to an empty place in Klaipedia should allow you to retain your max FPS, and I have the feeling I have lower FPS in cities no matter where I am, even if no other players is rendered in my viewport. I will test this later.
@asphidel: We went through this already; moving to another thread seems sensible although it can give us some rendering issues.
@teonimesic: Well, thatās what happens on my end.
Quoting this from the reddit subforum cause its pretty important:
āYou can see this if you watch the packets in wireshark. The chat spam packet length is about 150-300. A character load in length is about 4500.ā
Which is exactly what you described Maavy
Alright, so Iām not sure if @ridleyco or @Maavy has already started running some of the proposed experiments. But would 15-20 volunteers be interested in meeting up in Orsha channel 15 (on Klaipeda server) at ~10:30 PM EST tonight to do some FPS testing?
That seems like a lot for a character load? As far as I can figure, as long as a player is non-hostile, we really only need to know a playerās position, costume, hair, hat, name, health, and SP on load? Maybe status effects I guess? That seems like itād be easily storable in less data? Am I way off base here?