I forgot to say that my test was in update 3.
Last edited:
FPS - it seems to be the windows & glass, or the light reflections being rendered on them
- Thread starter Sighman
- Start date
I have mixed feelings about this work. On the one hand, doing what the developer seems incapable of doing to help solve a problem is good. On the other… For a $40 expansion, the community shouldn’t need to do this. Behavior like this seems to set precedents for FDev to rely even more on the community to do their job… I guess if this leads to a better experience, great, but FDev shouldn’t get a free pass on this mess.
I don't know how to delete a shader, to be honest. This is just playing the game vanilla without modifying anything.
Great finding!
Did someone report this already as a bug via official channels? I doubt devs read everything in this forum.
Did someone report this already as a bug via official channels? I doubt devs read everything in this forum.
I'm a developer. If a user sends me an email about an issue with screenshots, log files, etc, that pinpoint exactly what's happening, it's 10x more likely I'll be able to fix it. If someone says 'your spell checker sucks' I have little to go on.
Official bug report here: https://issues.frontierstore.net/issue-detail/37048
I'll add more infos in that report when i get home from work.
Right, but as a developer, the last person you want reporting your production bugs is your customer. I feel like customers needing to report bugs as frequently and and glaringly obvious as the ones in Odyssey should be a huge embarrassment for FDev, but they just seem to have made this part of their process…
it’s almost like this is their motto for software testing:
They arent getting a free pass though. EDO has a Mostly Negative rating on Steam, and ED's base game (formerly known as Horizons+ED) fell from Mostly Positive to Mixed.
This is hurting the ED brand across the board. They certainly are NOT "getting a free pass."
Programmer hat: software is complex, almost always has bugs, and is never perfect. It's a balancing act between providing new features and spending time fixing/improving old ones. (There's no money in fixing older problems. It's all in flashy new features. I should point out that I've been developing freeware for 25+ years, so in my particular case I can work on whatever I want, and I prefer stable and bug-free to flashy as I use my own software.)
End-user hat: If I can report a problem and have it fixed, I benefit. It will also help many other people.
Whenever I'm writing a program for slow hardware, I often stuff CPU clock polls at the beginnings or ends of functions and stuff every value for a cycle into a log file. I can plot and see how efficient certain functions are operating over time and see if any situations arise that cause too much delay. I use that to determine where my costs are and where I may need to reduce the order, accuracy, or data type of computations.
It's one of the most basic methods of performance debugging and often critical for cheap micro sized hardware. I'm curious if Frontier even bothered to do this. There's no reason to deploy a feature that increases compute time 3x without not just meaningful purpose, but any apparent purpose at all. The old style of rendering probably shouldn't have been touched without guaranteed increase in overall efficiency.
It's one of the most basic methods of performance debugging and often critical for cheap micro sized hardware. I'm curious if Frontier even bothered to do this. There's no reason to deploy a feature that increases compute time 3x without not just meaningful purpose, but any apparent purpose at all. The old style of rendering probably shouldn't have been touched without guaranteed increase in overall efficiency.
Yep, with several of my programs I'd log the time diff since the previous tick next to everything, automatically. If there was a delay there, I'd take a look at that code.
Visual Studio has profiling now but I've never looked at it. I'm writing complex applications that use a sum total of 95mb of ram, and still run on Windows XP. I've had 20 years to refine some of them.
Yep, I always set shadows to Low in Odyssey. But that's a general performance issue, like burning settlement buildings. It happens everywhere.
But these windows cause a huge fps drop as you approach them, and another user has already posted in this thread saying a certain shader is causing the issue. If enough people vote on the issue and FDev take it up, it might fix performance in a big way.
It's also possible the windows are causing a lesser fps drop from further away.
Good grief.
I think the NPC spawned inside the building. And if the walls are not tested for bullet collisions from that side (even not rendered), bullet goes through them
Here's a before and after disabling the shader, i'm the closest to the window before going below 60fps (colors are faded because i was trying to fix colors using elite's xml and no 3rd party)
Before : 60fps - 100% GPU usage, fps drops if i move closer
After : 60fps - 65% GPU usage, fps and GPU usage does not change if i move closer.
Before : 60fps - 100% GPU usage, fps drops if i move closer
After : 60fps - 65% GPU usage, fps and GPU usage does not change if i move closer.
Last edited:
In this settlement, in this place, NPCs often appear inside the textures. This NPC attacks, even when the player is inside the structure, this can be seen in the video.I think the NPC spawned inside the building. And if the walls are not tested for bullet collisions from that side (even not rendered), bullet goes through them