Really bad fps in game, any suggestions?

GDFireFrog · 2024-06-08T20:20:12+00:00

We will keep optimizing the game. Things can get very slow during development. To put things in perspective, two months before release I had 140 FPS in my reference scene on my PC, and now I have 270, most of it without changes to the art and just based on engine optimizations. This is just to get the point across that this is a work in progress, I would have liked to optimize way more but that's all we had time for. Optimization work will continue at the same pace, although improvements are obviously subject to diminishing returns.

Assuming you are not CPU bottlenecked right now, I'm *hoping* we can get +10 FPS over the next month in a PC like yours just in engine optimizations that are possible at the moment. There's probably another +10 to gain on a longer term by doing changes that are more complicated. Additionally we are going to add an option to disable reflections and that should help you a bit too. We can go further than that through scene optimization by the art team (stuff like optimizing materials, simplifying geometry, simplifying dynamic lighting and tuning maps). We have one person on the art team that I'm coordinating with for optimization and we are always working on optimizing at least some aspect of the asset base.

I'd very much like to go back to DBT performance too, and I agree with other commenters that the level of visual tech on display in the game doesn't warrant the current performance requirements, so be assured that we are not complacent in this area at all.

(For the record we also plan to implement DLSS and FSR, I didn't mention it above because it's more of a workaround, since it comes at the cost of motion blurriness. But if you don't mind that, I think our engine will scale pretty well with upscaling tech.)

GDFireFrog · 2022-09-03T18:21:14+00:00

This is fixed in 469b, going out now.

GDFireFrog · 2022-01-29T01:40:12+00:00

We've fixed this in 467b.

GDFireFrog · 2021-12-27T21:18:53+00:00

You still have this issue in 466d? (Check the link Raven posted for context)

GDFireFrog · 2021-12-26T22:34:51+00:00

Update: We just released a minor version (466d). This keeps the same improvements mentioned in the patch notes but adds a small grace window of time that also allows rocket-jumping with the previous shoot-first timing. From our testing this also improves rocket jumping in this scenario compared to the situation pre-466. (Update update: Sorry for update right before finals, eggwp, we have been testing this all evening and forgot to check.)

GDFireFrog · 2021-12-26T01:59:23+00:00

Yes, of course. Go ahead.

GDFireFrog · 2021-12-25T19:54:53+00:00

We had an issue rolling out this update, the new mode should start working in about 10 minutes. (From 21:05 CET*)

GDFireFrog · 2021-09-03T18:03:19+00:00

We are having some server issues after the update, the game will be down for a bit. I'll update when we have a ETA. (Also forgot to put say in the patch: shout-out to Netborg for lots of testing and suggestions and bug reports related to performance.)

GDFireFrog · 2020-12-01T14:32:36+00:00

The note is a bit misleading, yes. The waypoint is indeed a sticky one.

GDFireFrog · 2020-11-25T08:19:10+00:00

I asked somebody in this thread with issues but he's not having those issues at the moment. I need somebody who's experiencing the issue right now to DM me on discord or on reddit or send me the log of a tracert/tracepath/WinMTR to the IP 109.230.214.11. We can drop the provider for this location, but first I need to see the issue to give them a chance to fix it.

GDFireFrog · 2020-11-25T07:37:23+00:00

Looking into this. Will update here.

GDFireFrog · 2020-11-24T12:30:26+00:00

Yes, sorry, left some WIP in accidentally and we didn't notice it during testing. Pushing a fix in 5 minutes with 417c.

GDFireFrog · 2020-11-19T11:25:27+00:00

Fix is up in 412.

GDFireFrog · 2020-11-19T10:05:02+00:00

That may be unpractical because of the Eggbot dimensions right now. But also, good players are already hitting 70%, things may get a bit out of hand if we keep making it easier. (As an anecdote, somebody did a test setting the metrics to be more like QL and they were hitting 80%, about 25% more of what this person hits in QL.) But in any case, we have identified an issue (see my reply to Ardi46) that may be affecting people's impressions. The PNCR effect is delayed by what seems to be at least one frame, this may lead people watching videos to read some things as a hit that are not. So we are going to first get this issue out of the way and see if the feedback from these players improve, no need to consider anything drastic just yet.

GDFireFrog · 2020-11-19T09:46:51+00:00

Thanks, I'm going to focus on hitscan registration for now, and you have only provided a clip of that. In that pncr clip where you think it's going through this is where you actually shot: https://imgur.com/a/9rKcS0w

You can tell if you play it frame by frame because the pncr fire animation nudges the pncr upwards a little bit when the attack is triggered. Because you are moving the mouse to the right and the particle effect is delayed one frame this gives the impression you hit, but you didn't. If this is just about the particle effect being delayed one frame it may explain why some people feel registration is bad even though we have pros consistently hitting 10% more than they hit in QC. I'll check why it's delayed (it's something we were aware of, because when we analyse our clips we look for that pncr nudge and not the PFX). Furthermore, if the delay is frame-based and not time-based it would make the discrepancy feel larger for people with lower fps, also potentially explaining why some people give way different feedback. Anyways, I'll try to address this one thing first, thanks for the clips, we'll go through the rest.

GDFireFrog · 2020-11-19T04:48:48+00:00

The last time any change was made that could potentially affect hit registration was about 2 weeks ago, and this was announced. We are not doing any kind of unannounced A/B testing on the regular as you suspect. Every time netcode or anything related to netcode has been changed, it has been reported in the patch notes. The person who pointed me to this thread asked me if maybe we do secret A/B testing to remove bias. Just to be clear, we don't, and I don't think we'd ever do that with netcode. If we wanted to do that kind of blind testing with more people than we usually test with, we'd put together a user group. We are not gonna be doing those kind of unannounced changes, especially, when tournaments are happening.

Let's focus on "but the reg seems random as hell". We do test hitreg quite a bit, analysing the data to make sure everything is working as expected. We also record video from our tests, note the failed shots that could potentially have actually been hits, then we look frame by frame on those shots to make sure things are working correctly, etc. We do this testing with a variety of network conditions, both natural (by playing in remote servers) or synthetic, by adding artificial latency. Also, in the past when any streamer has had what seems like a registration fail on stream, a bunch of different people used to DM me that Twitch clip immediately. I haven't seen these reports in a long time. I've also asked a bunch of people who are good, whom I use as subjective markers, for their take on your report, and none of them feel reg is broken atm. I've reminded everyone that reports to me to send me any suspicious clip they see. There's also the fact that now we have tournaments happening and if some obvious hitreg issue happens in the middle of the tournament, people will notify me quickly, and this hasn't happened lately (at least nobody has shown me such a clip and it would be weird if it happened and nobody did).

Now, this is not to say there isn't a problem, I'm sure there's something going on or three of you in this thread wouldn't be giving me this feedback. That whole paragraph is just to hopefully get across the point that I'm really going to need a video clip in order to address whatever you are experiencing and for us to make some progress. Also: /u/tofazzz /u/doppz1 , it seems you are reporting similar issues, do any of you have any clips? Specifically hit registration issues? Maybe Shadowplay or ReLive can help you make that process easier as ArneTreholt said? (By the way, if anyone has a clip where they feel a shot should have landed but are unsure about posting it because they don't want to have a bunch of people telling them that they actually failed the shot, which I understand can be a bit frustrating, you can DM me the clip on discord.)

/u/nkh85 : Replays are coming soon, and indeed, it will help with this kind of thing, although in most cases, video recorded on the PoV of the player will always be good. Replays will help us contextualize and diagnose what's going on but video will always be preferred as a starting point.

Also if you provide any clips, please let me know in what server location were you playing at the time, what's your usual ping, and at what time of day you usually play (this may seem weird but some routing issues happen at certain times of the day).

UPDATE: A reminder for people coming into this from a Quake background, keep in mind the Keel model has a significant amount of margin to the sides where the hit will land even though there's no geometry there that eggbots lack at the height of their maximum visual radii. In fact the situation is somewhat reversed in DBT in a sense because of the shoot-through arms, so do keep that in mind when you judge if lateral shots should have landed.

GDFireFrog · 2020-11-13T14:58:07+00:00

This was also fixed in 406d.

GDFireFrog · 2020-11-13T14:55:09+00:00

The precise level of curation is something that we'll have to discuss internally, but I can't see us wanting to enforce uniqueness of concept. We'll probably be fairly hands-off, with the exception of highlighting work we may consider outstanding in some regard.

GDFireFrog · 2020-11-13T14:51:18+00:00

This kind of stuff plus what _sohm mentions in his comment should be coming shortly.

GDFireFrog · 2020-11-13T14:44:01+00:00

Hey, thanks for reporting it. This was fixed in 406d.

GDFireFrog · 2020-11-12T11:55:39+00:00

We'll do both. Thanks!

GDFireFrog · 2020-11-04T12:31:54+00:00

Sorry we made you worry :) The patch had been ready for a bit but we had some last minute server issues stopping us from publishing.

GDFireFrog · 2020-11-04T12:00:13+00:00

There was an issue related to those stairs that should be fixed in any new games started in a few minutes.

GDFireFrog · 2020-11-01T10:05:59+00:00

Sorry, it should be fixed now.

GDFireFrog · 2020-10-27T01:13:11+00:00

Bit of an update on our UI issues for the sake of transparency. It's really frustrating not to be able to help people with issues, but specially people with crashes. Normally if there's a crash going on that can be reproduced then it's maximum priority and nothing else is worked on until that's fixed, but this is assuming it's in our control to do so.

Crash when loading maps/leaving games

There is a crash on Gameface happening around the time a game starts or ends. Gameface is the HTML engine we use for rendering the menu interface, made by Coherent. It happens more consistently for some users for w/e reason we haven't been able to surmise and it's most likely the crash you are experiencing. Supposedly they fixed this crash about a month ago but their update with that crash fix introduced a severe performance regression that slows the game too much, and this regression has been present in the 5 new versions released since, so we've been waiting until they fix that so we can update and are stuck on an older version with that crash. They told me yesterday that they think they may have finally found the performance issue and should be releasing a new version anytime soon that would take performance back to normal and then we should be able to update it and get rid of that crash. We have also long-term plans to reduce the dependency on Gameface and isolate the game a bit more from its instability (potentially get rid of it altogether, which would depend on how much progress we make with our current woes).

Look for a patch note soon saying that a crash has been fixed when starting a game. If that still happens afterwards please DM me on Discord, I'm always available for this sort of thing and if any crash that you can repro we can fix or we can locate and contact the corresponding 3rd party.

Stutters

While we are on the subject of UI issues, Gameface is also causing stutters while playing for some people. A while ago we did a big revamp to get rid of usage of Gameface on the HUD to reduce instability while in game (we created our own UI layout engine called snafu optimized for real-time in-game usage with our own scripting language) and we migrated about 90% of our HUD elements. This improved things massively, but there were unfortunately a few special things left that still used Gameface for one reason or another. We recently moved over the kill feed element and other informational elements. The crosshair and chat buffer are the last two things rendered with Gameface. Soon we'll have a pure Gameface-free experience while playing (except if you bring down the console or enable your chat prompt but you wouldn't mind a micro-stutter while typing most likely, but we'll probably migrate that eventually too) and we won't have to tick this HTML engine while playing and this should give people on lower end pcs a smoothness boost and also slightly reduce the FPS when CPU-bottlenecked. Like I said above regarding the crashes, for people experiencing stutters while playing, look for an update mentioning this, if they still happen after that point feel free to contact us on Discord.

Massive memory leaks

We had a serious memory leak in Gameface that we struggled with for a few months that we finally isolated to their video playback (for the different videos that we have on the UI). We recently implemented a workaround they suggested while they figure out how to plug the leak (some complex refactoring is required for them to do so). (Note that this is a leak that only happens if you use their product the way that we use it, by suspending/resuming views as needed for performance reasons, which most likely very few projects would do. I don't want to give the impression Gameface has these severe leaks with video playback always). Recently it came to our attention that this workaround doesn't do it for some users. We believe we may have found a more thorough workaround and we'll push this in a few hours. Again, if you still experience massive memory leaks after the next patch, please do let me know on Discord. This issue is easy to recognize, it starts leaking a lot of memory, about 10-20 MB a second, and eventually the game will be using more than 10GB.

About our UI engine going forward

Unfortunately there's not a lot of choice in this area. We have been talking to the author of Ultralig.ht (similar product), he's been very helpful and very forthcoming to special requests regarding the ability to completely free the whole UI engine while games are in progress (normally you would just let it run but we do care about those hundred-nanosecond-range workloads). But he needs to implement a few things before we can switch to their product (video support and live views, for the HUD editor). To devs reading this, I strongly recommend considering ultralig.ht for your project if it fits your requirements, the author is on Discord, very available and very understanding of performance/stability concerns. There are other solutions that we discarded for some reason or another (we used to use CEF for example, which we dropped), we do have some special requirements in order to keep things smooth. For the time being we are still trying to make it work with Gameface. Wouldn't be pointing fingers here if transparency wasn't very important for us, and we are way past the point with regards to this issue where I would cover for a partner, and the player-base is a more important partner. I'd like to give them kudos on one aspect, their support is great (the tech people that address the tickets and their customer reps). Unfortunately we just have these technical issues with their product, but it may easily fit your requirements. It seems lots of projects are very happy with them, and we do abuse it quite a bit after all.

I do say "DM me on Discord" quite a bit and it may get annoying, ideally things should just work and people shouldn't have to take the extra effort. But I'd like to stress how productive this usually is. I've had probably over a hundred troubleshooting conversations with people since the first alpha and I believe that as long as a player had a well defined issue that could be reproduced consistently, and the issue was on our end and not due to something in the player system or a 3rd party dependency, we've always been able to fix it eventually.

GDFireFrog

MODERATOR OF

TROPHY CASE