About HTML5...

[Neebiru 36]

I remember the time when the devs. were blaming Flash as the reason for the game running like... well everyone knows how the game ran before the HMLT5 version; before? Hmm, wait. did it actually end? No, it did not. Sometimes I just see the FPS counter being stuck at 54-55, which is probably fake as well, since every program that is able to count the FPS of a game, seems to be showing a different number; well I don't actually know if this applies for Tanki, but for other games it applies for sure. (oh yeah, if someone dares say that my PC isn't 'strong' enough to run Tanki, I'm gonna find out how I can block him on Forum, I'm running  a Ryzen 1600 and an RX 5600XT).

So my point is... What's their excuse for now? What's up guys? Are they gonna say that HTML5 is not yet fully ready? And yes I know I'm not likely to get an answer. But what can I lose by writing an article? xD

[NooNooHead 121]

I use an AMD Phenom II for tanki and flash was unplayable and buggy. My internet is good though, 150 down/15 up. HTML5 works and I can hit the flying hacks (I mean hopper). I can't multitask too much when playing.

[Iron_Man 2,376]

17 hours ago, Neebiru said:

I remember the time when the devs. were blaming Flash as the reason for the game running like... well everyone knows how the game ran before the HMLT5 version; before? Hmm, wait. did it actually end? No, it did not. Sometimes I just see the FPS counter being stuck at 54-55, which is probably fake as well, since every program that is able to count the FPS of a game, seems to be showing a different number; well I don't actually know if this applies for Tanki, but for other games it applies for sure. (oh yeah, if someone dares say that my PC isn't 'strong' enough to run Tanki, I'm gonna find out how I can block him on Forum, I'm running  a Ryzen 1600 and an RX 5600XT).

So my point is... What's their excuse for now? What's up guys? Are they gonna say that HTML5 is not yet fully ready? And yes I know I'm not likely to get an answer. But what can I lose by writing an article? xD

Hello!

Please try uncapping max fps as shown here.

 

[ThirdOnion 4,898]

Thank you for creating this topic; I now know that I am not the only one frustrated by HTML5's performance on decent hardware.

From testing, I've noticed that the number of players in a battle is the main (maybe only) factor that affects FPS. Map size and various graphics settings hardly make any difference. As the number of players in a battle increases, counter-intuitively, hardware utilization decreases, as you can see in the below screenshots:

Empty battle. FPS is ~400, CPU usage at ~70%, GPU 0 usage at ~75%, GPU 1 usage at ~35%.

Spoiler

Battle with 29 players, same map, same spot on the map. FPS is ~100, CPU usage at ~55%, GPU 0 usage at ~20%, GPU 1 usage at ~15%.

Spoiler

I will point out that though the counter shows 100 FPS, the game stutters like crazy, so in the end it feels more like 40. Not sure why.

This leads me to believe that the bottleneck has to do with the netcode. Performance is limited by something related to communication with the server. There's a high likelihood that rendering/physics/game logic and networking code run on the same thread, and that the latter is a bottleneck.

Playing in a match with eight players or less usually yields a satisfactory image. With 16 players, things are OK but start to get unstable. More than that, the result is ridiculous. Yet the developers have upped the player count on a number of maps.

I've posted about this before in Bugs and Glitches reports, but nothing's come of it. When someone complains about glaring performance issues, or any issue for that matter, they usually get one of two canned responses: "clear you cache" or "uncap FPS" (or both). Great lot of good that will do.

Edited April 5, 2021 by ThirdOnion

[ThirdOnion 4,898]

Here's a post from another player in Bugs and Glitches that supports my theory:

The link doesn't work anymore, but the video basically shows how FPS over 100 suddenly drops to below 30 after the network connection gives out momentarily. Again, high likelihood of networking code being the culprit.

Edited April 5, 2021 by ThirdOnion

[alkyng 3,080]

Many player have left the PC version to the mobile version because of HTML5 lags.. HTML5 lags more

As developers said and I have tested that HTML5 runs way smoother than FLASH for the strong hardwares, and runs horribly bad and worse than FLASH for the weak hardwares.

In my old laptop HTML5 was incredibly lagging and I usually open Tanki with 2-3 other programs, so my laptop was about to explode with the HTML5.  But now in a stronger laptop, I think HTML5 runs too smooth and way more better than the FLASH.

In my old laptop HTML5 was lagging especially in the interface but when entering a map my FPS came high and reasonable (about 40) which is really smooth compared to the interface.  Whatever I used more settings or less the performance stay the same, as my lag was in the interface.

But for the ones who FLASH was running too smooth with them but the HTML5 is lagging.. Yes it's a problem and Tanki have to solve it, as the replacement of FLASH should be in the same level of quality. They forced us to move to HTML5 (instead if you want to say it's Adobe's decision) it must be a usable.

My old Laptop specs were : Intel I3, 4th generation. 4GB RAMS LPPDR3, and for sure the GPU is built in processor. I can run FLASH in 60 FPS (with some graphics settings) while I'm running 2 other programs one of them was a Youtube video... But in HTML5, I wasn't able to do that thing.

[Neebiru 36]

On 4/5/2021 at 11:30 AM, Ironmantonystark said:

Hello!

Please try uncapping max fps as shown here.

 

I don't even know what to say. Like... man... do I really look like someone who's waiting for silly forum links? Or someone who doesn't know what's up with his PC? Hide yourself. 

On 4/5/2021 at 11:31 AM, ThirdOnion said:

Thank you for creating this topic; I now know that I am not the only one frustrated by HTML5's performance on decent hardware.

From testing, I've noticed that the number of players in a battle is the main (maybe only) factor that affects FPS. Map size and various graphics settings hardly make any difference. As the number of players in a battle increases, counter-intuitively, hardware utilization decreases, as you can see in the below screenshots:

Empty battle. FPS is ~400, CPU usage at ~70%, GPU 0 usage at ~75%, GPU 1 usage at ~35%.

  Hide contents

Battle with 29 players, same map, same spot on the map. FPS is ~100, CPU usage at ~55%, GPU 0 usage at ~20%, GPU 1 usage at ~15%.

  Hide contents

I will point out that though the counter shows 100 FPS, the game stutters like crazy, so in the end it feels more like 40. Not sure why.

This leads me to believe that the bottleneck has to do with the netcode. Performance is limited by something related to communication with the server. There's a high likelihood that rendering/physics/game logic and networking code run on the same thread, and that the latter is a bottleneck.

Playing in a match with eight players or less usually yields a satisfactory image. With 16 players, things are OK but start to get unstable. More than that, the result is ridiculous. Yet the developers have upped the player count on a number of maps.

I've posted about this before in Bugs and Glitches reports, but nothing's come of it. When someone complains about glaring performance issues, or any issue for that matter, they usually get one of two canned responses: "clear you cache" or "uncap FPS" (or both). Great lot of good that will do.

"I will point out that though the counter shows 100 FPS, the game stutters like crazy, so in the end it feels more like 40. Not sure why." 

I couldn't have said better myself. Exactly. It shows 60, but it's not stable 60 FPS. And this is because the game is not optimized well. Lets say like... GTA 4. Everyone(well everyone who's not actually 10 years old) knows how badly GTA 4 ran, and it still does by the way. Well, Tanki runs badly for exactly the same reason, they didn't spend the time necessary to make it run. And I know it's all about budget. But do I/we look like I/we care? 

I'm actually glad that you replied. Feels good to read someone's reply who seems to be even MORE into this thing than me. High five dude. Lets hope they hear us.

Well, yes, that's with integrated graphics. You do have performance limitations. But we don't. A GTX 960M is a pretty decent card. And my AMD Radeon RX 5600XT is an absolute overkill for this game. And the experience is still poor. 

Edited April 8, 2021 by Ironmantonystark
Posts Merged

[Spy 14,687]

On 4/5/2021 at 9:00 AM, Ironmantonystark said:

Hello!

Please try uncapping max fps as shown here.

 

Uncapping FPS does not really help in such situations - For example, if your HZ is 60, you wouldn't feel any difference even if you uncapped your FPS and it showed 700 FPS. 

In such situations, I would recommend checking which part of your PC Tanki uses to run the game.

[alkyng 3,080]

1 hour ago, Neebiru said:

I don't even know what to say. Like... man... do I really look like someone who's waiting for silly forum links? Or someone who doesn't know what's up with his PC? Hide yourself.  

The solution of clearing the cache and such like.. Wont change a lot and if a certain PC is lagging, nothing will help even if we have lightened that PC as much as possible. But such a solutions are must be done to insure primarily that it's not an issue of those things, which is required and intuitive.

[Neebiru 36]

On 4/6/2021 at 9:23 PM, Spy said:

Uncapping FPS does not really help in such situations - For example, if your HZ is 60, you wouldn't feel any difference even if you uncapped your FPS and it showed 700 FPS. 

In such situations, I would recommend checking which part of your PC Tanki uses to run the game.

Actually, it might help now that I think about it.

On 4/6/2021 at 7:53 PM, Neebiru said:

I don't even know what to say. Like... man... do I really look like someone who's waiting for silly forum links? Or someone who doesn't know what's up with his PC? Hide yourself.  

I'm actually sorry about that, this might be a way to solve this problem

 

And yes. Uncapping the FPS limit solves the problem. 

Sorry for the harsh reply Ironmantonystark , you were right, and your advice is logical. 

So what was the problem? Tanki doesn't run smoothly. The FPS changes between 50 and 60. At this range, this makes a huge difference. 

But after uncapping the FPS, the change of FPS doesn't affect the actual gameplay, since my monitor is only 60HZ anyway. 

Even if I had a 300HZ display, it wouldn't matter at the range of 180-220 FPS. 

 

Edited April 8, 2021 by Ironmantonystark
Posts Merged

[ThirdOnion 4,898]

On 4/7/2021 at 1:19 AM, Neebiru said:

So what was the problem? Tanki doesn't run smoothly. The FPS changes between 50 and 60. At this range, this makes a huge difference. 

But after uncapping the FPS, the change of FPS doesn't affect the actual gameplay, since my monitor is only 60HZ anyway. 

Even if I had a 300HZ display, it wouldn't matter at the range of 180-220 FPS. 

I'm glad uncapping FPS solved the problem for you, but it hasn't solved it for me. Yes, I have a 60Hz screen, and in theory 100 FPS should look smooth, but in practice, it looks no better than 40 because of constant stutters. 100 FPS in TO feels far worse than 60 FPS in other applications. Heck, 100 uncapped FPS in a match with 24 players feels worse than 60 capped FPS with zero players. It's frustrating because it's really hard to communicate this to someone else - they see the number and say, "hey, everything's fine" on paper but if you were to look at my screen in-person you'd quickly see that things are not fine.

I suspect that the lack of smoothness is due to some frames being rendered much slower than others. The things is, the FPS counter just gives FPS averaged over a certain period. Suppose the counter records 100 FPS over one second. That could mean you had 100 FPS during that entire time interval, but it could also mean that you had 170 FPS for half a second, but 30 FPS for another half a second. 170 * 0.5 + 30 * 0.5 = 100. Sure, the counter shows 100 FPS, which is supposed to be good, but the truth is you are getting 30 FPS half of the time! The result is an extremely unsightly stuttery image. In fact I believe there was someone on the RU forum who profiled the TO application and found that this was indeed the case - most frames were rendered in the expected time, but some took much longer to render.

So this brings me back to my original hypothesis - that the problem lies in the netcode. Here's a possible scenario: suppose that the user's system is capable of rendering a frame in 10ms (100 FPS) when working at 100% capacity. Suppose that of those 10ms, the CPU spends 5ms performing calculations and preparing 3d data for the GPU, and the GPU spends the remaining 5ms rendering the frame.

Now suppose that every 250ms (four times per second), the server sends some information to the system, and the CPU spends 20ms processing that information. If the game runs on a single thread (or if at least rendering and networking code run on the same thread), then the system cannot render any frames for 25ms. Why? Because the GPU needs to wait for the CPU to finish processing the server information, which takes 20ms, and then wait another 5ms for the CPU to prepare 3d data. As a result, whenever the system receives information from the server, the frame rate drops from 100 down to 1s / 25ms = 40 FPS. That's a pretty big drop from 100! That drop only happens four times a second, but that's more than enough for the output to become choppy and uncomfortable.

This explains all three of the problems that I detailed earlier.

1. The number of players in a match makes a significant impact on FPS. More players -> more information from the server to process -> longer frame drops.
2. GPU usage drops when player numbers increase, because the GPU effectively sits idle while it waits for the CPU to finish processing information from the server.
3. The image is choppy despite high FPS. Frequent frame drops make the perceived FPS worse than the average FPS. For instance, 400 FPS 25% of the time + 20 FPS 75% of the time = 115 average FPS. But that number completely glosses over the fact that you actually get 20 FPS 75% of the time! As a result, you can see stutters even on a 60Hz screen.

Solution? I don't know for certain; I'm not a developer. But I suspect that threads (or rather, the lack of) are a problem here. Ideally, rendering should run on a separate thread. The CPU can perform to perform game logic calculations or process information from the server on another thread, and thus the GPU will not have to wait for the CPU to finish those calculations and will be able to output frames while the CPU is doing all that other stuff. There will be fewer stutters, and player count won't affect performance as much.

Now, my CPU is not exactly cutting-edge but it's no slouch either (i5-6300). I doubt that it gets hung up on processing information from the server to so great an extent. It is perhaps more likely that the problem is with receiving information from the server. For example, suppose five chunks of data are sent out from the server, and the system needs to receive all of them before rendering a frame. But for one reason or another, each chunk arrives one after the other with a 4ms delay in between. Even if the CPU can process that data instantly, there's still a 20ms period of nothing being done as the system waits for the data to come in. This would explain why some players with good hardware get a smooth image while others (like me) do not - they may have a better internet connection. Regardless, this problem could also be solved by threading. If an application is designed correctly, network latency should not have a significant effect on FPS.

Maybe threads are not the problem here. But other multiplayer 3d applications work fine; TO is the only one that I have problems with despite its aged graphics and low system requirements (in TX I had similar issues by the way). Anyway, the issue is frustrating and trying to convince others that it is an actual problem is also frustrating.

Edited April 8, 2021 by ThirdOnion

[Neebiru 36]

@ThirdOnion Yes, your arguments seem to be logical. 

But as for a fact, the performance on high maps is STILL not just sad, not just simply bad, it's a shame, and it's silly. 

And it's even worse that they don't talk about this problem. They don't involve us in the choices they are making. YES, YES, true, that's never been the russian style. Russians remain russians, what can we do. 

P.S.: No, I'm not being racist, I'm just being open minded. 

[Picassoo 191]

While the HTML5 version is faster, I can't maintain 60 FPS when the frame rate cap is on, despite my PC being able to run the game at frame rates multiple times higher — it keeps dropping to 59 — 57. On Flash the frame rate dropped more rarely and for negligible amounts of time, to 59 FPS. Playing on the new client with a cap just feels like a joke at times.

[TheRealHZFJ 707]

Problem with this thread is that no one says what GPU / CPU they using. Im using 1050Ti and 2500X and the game averages around 200 - 250FPS every match with everything graphical thing turned on except dust ( dust takes like 100FPS ). Also Siege is way more laggy than any other mode for some reason.

Edited April 8, 2021 by TheRealHZFJ

[Neebiru 36]

They should either think about removing the big maps or optimize the game further. Now they're using a modern code language, they just have to... I guess learn new ways of doing things. I'm sure that takes time... So that's understandable. But then again, they don't really communicate with us regarding this matter, which  is probably typical. And at the end of the day, the player, the consumer doesn't care. We want it as soon as possible, yesterday if possible. 

[Picassoo 191]

On 4/8/2021 at 8:08 AM, ThirdOnion said:

100 FPS should look smooth, but in practice, it looks no better than 40 because of constant stutters.

Your monitor refreshes at a constant rate, while your GPU produces new frames at differing one. However, if you cap your FPS at 60 whilst having a powerful enough graphics card to maintain such a frame rate, the frames will be timed roughly in sync with your 60 Hz monitor refreshes. On the other hand, with uncapped 100 FPS your monitor will often show frames that are old because they have been drawn sometime between the screen updates. Uncapped 400 FPS is fine but 100 or even 200 may feel juddery.

EDIT: cap your FPS at a number close to a multiple of your screen refresh rate, or don't cap it at all if you have a powerful graphics card.

Edited April 9, 2021 by Picassoo

[ThirdOnion 4,898]

1 hour ago, Picassoo said:

Your monitor refreshes at a constant rate, while your GPU produces new frames at differing one. However, if you cap your FPS at 60 whilst having a powerful enough graphics card to maintain such a frame rate, the frames will be timed roughly in sync with your 60 Hz monitor refreshes. On the other hand, with uncapped 100 FPS your monitor will often show frames that are old because they have been drawn sometime between the screen updates. Uncapped 400 FPS is fine but 100 or even 200 may feel juddery.

I'm not sure what you are trying to say. What makes uncapped 400 fine but uncapped 100 jittery? And regardless of whether 400 is better than 100, this doesn't explain why there is such a massive drop in FPS and GPU usage between matches with no players and matches with players.

Anyway I don't think the problem is with synchronization. I did a bit of quick profiling on the application when the framerate is capped to 60. On the top is FPS in a match with no players, while on the bottom is FPS in a match with 20+ players. The map, the route that I took on the map, and the graphics settings are all the same.

As you can see, FPS in an empty match is quite stable. But in the match with players, there are many significant drops in FPS - often to 30 or below! These drops are responsible for frequent and annoying stutters.

Now let's take a look at what I'd consider a "normal" frame. It rendered in 16.2 ms, which is about 60 FPS. There was even some time left over during which nothing was done. Note that the first 3/4 of the frame were dedicated to performing physics and game logic calculations (and something to do with particles, apparently), while the last 1/4 was spent actually rendering.

Now here is an "abnormal" frame, which took a whopping 96.2ms to render (about 10 FPS)!

Note how the second part of the frame is quite similar to the first. But before it some gargantuan task is performed - processing some data buffer, creating some entity, creating some particles - which slows everything down. This is not unique to this frame. I looked at a number of other frames which were rendered abnormally slowly, and a similar process took place in them as well. I'm not sure what exactly goes on here - I'll do more thorough investigations later. But I hope it should be clear now that this is a software problem, not a hardware problem.

Edited April 9, 2021 by ThirdOnion
https://imgur.com/a/6QWso5A

[alkyng 3,080]

They had to migrate from Flash to Unity, not to HTML5.   That's the problem

They couldn't make the game stable again, and the physics are weird even the old games that have more than 20 years old have a better physics than the current HTML5

[Picassoo 191]

1 hour ago, ThirdOnion said:

I'm not sure what you are trying to say. What makes uncapped 400 fine but uncapped 100 jittery?

For example's sake:

Let's say you have a 3 Hz monitor. If you cap your FPS to 3, your GPU will try to maintain a stable frame rate of 3 FPS, so the delay between when your frame has been drawn and the monitor's refresh cycle will be roughly constant (just roughly, because there always are times when the GPU doesn't catch up, even if it is powerful).

Now if you turned the cap off and got 4 FPS, every 3 screen refreshes you'd get 4 frames. Let's say the first refresh came right after the first frame was drawn. Your screen will refresh again in 333 ms, but the next frame will be drawn in 250 ms. So the first refresh displayed a frame 0 ms old, but by the second refresh an 83 ms old frame is showing. In another 250 ms the third frame will be drawn, but the screen will not be able to refresh yet. Depending on whether your GPU manages to draw the fourth frame right before the third screen refresh, you may get a perfectly timed frame or a 250 ms old one. Notice the inconsistency? This is what causes screen judder.

Third scenario: you upgraded your GPU and now get 1000 uncapped FPS. Your screen chooses the newest available frame each time it refreshes. With over 300 frames drawn every refresh cycle, the newest one will nearly always be perfectly timed.

 

 

Edited April 9, 2021 by Picassoo

[Neebiru 36]

@Picassoo What you are saying has no relevance in this situation. The problem is: no matter what you do, you won't get the performance you should get with a strong hardware.

[ThirdOnion 4,898]

On 4/9/2021 at 4:04 AM, Picassoo said:

 

Thanks for the explanation; I suspected this was what you meant but wasn't sure. But while poor synchronization may certainly contribute to stutters, I really don't think it is the main issue. My problem is basically this:

	FPS	GPU Usage	Image Quality
Capped, empty match	60	Low	Smooth
Capped, full match	40-60	Very low	Stuttery
Uncapped, empty match	350+	High	Very smooth
Uncapped, full match	70-100	Low	Stuttery

The GPU is being underutilized in full matches.

On 4/9/2021 at 3:53 AM, asem.harbi said:

They had to migrate from Flash to Unity, not to HTML5.   That's the problem

They couldn't make the game stable again, and the physics are weird even the old games that have more than 20 years old have a better physics than the current HTML5

I do not think the current game runs on Unity. And if I remember correctly at some point HTML5 had very similar physics to Flash; then they were changed at some point for some reason, probably intentionally.

Edited April 10, 2021 by ThirdOnion

[ThirdOnion 4,898]

So TheRealHZFJ pointed out that dust caused major FPS drops. I did some profiling and well . . . I'll let the results speak for themselves.

As you can see the time spent in the createDust function is absolutely absurd. In a "normal" 16.7ms frame, 7.07ms are dedicated to dust. That's more than 40%! By comparison, the entire rendering process takes only 3-4ms!

In an "abnormal" 53.1ms frame, 40.94ms are spent in various dust related functions. That's 77% of the entire frame. It is dust that causes a drop to less than 20 FPS.

What. The. Heck.

For comparison, here's a frame without dust processing:

I would really love some feedback from the developers regarding performance. Is there anything being done to address it? Am I the only one who notices these problems? Why is DUST so performance intensive? What is going on???

Edited April 12, 2021 by ThirdOnion
https://imgur.com/a/jztnOod

[juodsnukis 54]

it ran fine for me, and it runs fine now.

[featwasath 267]

Finally, a tread that addresses the issue I've been facing forever...!

@Neebiru Thank you so much for bringing this up. My special thanks to @ThirdOnion for this resourceful explanation. I'm very grateful for all the time & effort you've spent to look into this. I don't think even Tanki devs have cared about this problem this much. I knew a lagging problem with player count exist, but lacked the knowledge & resources to understand it. You've explained it so well.

 

My desktop, i3-3220 is running Windows 8.1 Pro with in-built GPU & 2GB RAM (crappy, I know). The PC is almost a decade old, but it could run the flash version of Tanki as smoothly as butter. They released HTML5 & I can't play even in mid-size maps. As you said, the lagging increases (exponentially, I think) with player count. I only play in 3 maps: Sandbox, Waves & Hill (because these maps house max 4 players per team). I can create private battles in the largest maps & roll everywhere in the map when only I'm in the map, but it becomes unplayable when others are there.

 

By the way, I could play that fire-wasp mode in Polygon during the celebration. Others are meh...

 

Following is what happens when I enter a battle (except for above 3 maps).

• I click to enter a battle.
• I'm being sent to the map.
• The screen freezes at a single frame & stays frozen for few seconds. I can hear a continuous noise from a hull or a turret (that happened to be near my spawn point, I guess)
• The screen changes to another frame & stays frozen. Then to another frame & stays frozen. This happens for about 2 minutes.
• Screen freezing finally ends & FPS becomes something like 30. Then everything happens smoothly.
• I can't do damage...!
• I reload the page (or close the window & open Tanki again, if playing via client), the above-mentioned freezing stuff happens again and, again I can't do damage.

 

I can patiently wait 2 minutes for all the freezing stuff to happen. But what's the point of waiting if I can't do damage no matter what I do. It's so frustrating.

Something I've noticed is that, damage stops after a huge freeze. I play a battle just fine & have fun killing enemies, screen freezes out of nowhere, screen becomes normal again, I can't do damage. Doing things like activating overdrive/supplies & even shooting can sometimes trigger a screen freeze.

 

As you said, this looks like a software issue from Alternativa's side. But I'm 100% sure that they will never address this. I mean, this issue was there ever since they released the HTML5 version, but they haven't done anything regarding this.

 

Before anyone asks, yes, I have tried cleaning cache & stuff. It doesn't work. Also, I'm using a good fiber connection with no VPNs. So, network isn't the problem.

Edited August 6, 2021 by featwasath

[ThirdOnion 4,898]

4 hours ago, featwasath said:

My desktop, i3-3220 is running Windows 8.1 Pro with in-built GPU & 2GB RAM (crappy, I know).

2GB RAM total or 2GB dedicated specifically to the GPU? Because if you have 2GB total, I'm not surprised that you have major issues with HTML5. That amount of RAM is simply not enough for modern computing. You were probably able to run Flash because it's memory requirements were very, very low. HTML5's memory usage is higher.

Edited August 6, 2021 by ThirdOnion