X4 Performance Troubleshooting Suggestions

[Imperial Good]

Even with all my mods in late game with thousands of ships, I have literally 0 lag or stutter and that is also with my game running on Ultra graphics on 1440p@144hz.
I have read online its AMD that makes these CPU affinity drivers for each game.
Could Egosoft contact AMD to ask if they can add a default CPU affinity for X4? so that we do not have to do this task manually or figure out some way to add the CPU affinity through registry or a shortcut ourselves?

AMD uses Xbox Game Bar and their latest chipset drivers to determine when to limit an application only to the high cache cores. Any application that Xbox game bar triggers for will likely induce the desired automatic behaviour. Try setting X4 to windowed fullscreen (recommended) and make sure your Windows 11 Xbox game bar is configured so that it detects games being run. Hopefully that should detect X4 running, or be able to be made to detect it, and that would trigger the desired core affinity behaviour.

This issue is one of the reasons I would recommend gamers get the R7 7800X3D over the technically better R9 X3D chips. The 7800X3D just has 8 high cache cores so there is no reason to play around with core affinity and should be significantly cheaper. Of course there are still benefits to the R9 X3D variants for some non-gaming workloads that can benefit from the extra cores or higher frequency.

If you can't do this Id suggest making a pinned AMD Ryzen 9 7950x/7950X3D guide on the Egosoft forum and Steam discussions, as ive read the CPU latency between CCD0 and CCD1 is also high and can cause lag/stutter, since the latency between Core 0 and Core 34 is a whooping 88ns. Though what I have not tested yet, which I will do after work today is test and measure FPS on Core 0-15 and Core 16-31, and compare the results and user experience.

The core to core latency is unlikely the main issue. I think the issue is that the high cache cores run typical X4 workloads much, much, faster than the high clock low cache cores. The high clock low cache cores end up holding X4 back while it waits for them to finish executing tasks. On top of that the high clock low cache cores will generate significant heat and use significant power which could even reduce the performance of the high cache cores.

[Dipluz]

Even with all my mods in late game with thousands of ships, I have literally 0 lag or stutter and that is also with my game running on Ultra graphics on 1440p@144hz.
I have read online its AMD that makes these CPU affinity drivers for each game.
Could Egosoft contact AMD to ask if they can add a default CPU affinity for X4? so that we do not have to do this task manually or figure out some way to add the CPU affinity through registry or a shortcut ourselves?

AMD uses Xbox Game Bar and their latest chipset drivers to determine when to limit an application only to the high cache cores. Any application that Xbox game bar triggers for will likely induce the desired automatic behaviour. Try setting X4 to windowed fullscreen (recommended) and make sure your Windows 11 Xbox game bar is configured so that it detects games being run. Hopefully that should detect X4 running, or be able to be made to detect it, and that would trigger the desired core affinity behaviour.

This issue is one of the reasons I would recommend gamers get the R7 7800X3D over the technically better R9 X3D chips. The 7800X3D just has 8 high cache cores so there is no reason to play around with core affinity and should be significantly cheaper. Of course there are still benefits to the R9 X3D variants for some non-gaming workloads that can benefit from the extra cores or higher frequency.

If you can't do this Id suggest making a pinned AMD Ryzen 9 7950x/7950X3D guide on the Egosoft forum and Steam discussions, as ive read the CPU latency between CCD0 and CCD1 is also high and can cause lag/stutter, since the latency between Core 0 and Core 34 is a whooping 88ns. Though what I have not tested yet, which I will do after work today is test and measure FPS on Core 0-15 and Core 16-31, and compare the results and user experience.

The core to core latency is unlikely the main issue. I think the issue is that the high cache cores run typical X4 workloads much, much, faster than the high clock low cache cores. The high clock low cache cores end up holding X4 back while it waits for them to finish executing tasks. On top of that the high clock low cache cores will generate significant heat and use significant power which could even reduce the performance of the high cache cores.

I tried the Xbox game bar, did not help me I patched my pc with the newest AMD chipset drivers as well.

When you say Windowed fullscreen, I dont have that option. I only have three options which are Fullscreen, Windowed and Borderless Window.

[Imperial Good]

When you say Windowed fullscreen, I dont have that option. I only have three options which are Fullscreen, Windowed and Borderless Window.

Borderless Window is what I meant. Fullscreen does not exist on Windows 10 and 11 due to fullscreen optimisation, which at best converts it to borderless window anyway.

[NilusBavarius]

...
I set the (nvidia) option in control panel:
Vulkan/OpenGL present method... to: prefer layered on DXGI swap chain
...
And the game is actually buttery smooth now (played for about 2.5 hours without a single stutter). BUTTERY smooth.
...
Curious for someone else with an nvidia card on win10/11 to try setting Vulkan/OpenGL present method to use the DXGI swap chain.

Thanks for the Info - tried it and you are right, smooth!
Win11

Have a great holiday!

[Nico07091980]

Hello,

sometimes you get calls from someone when walking on stations or ships or sitting in cockpit. I noticed an issue when I get called from Dal Busta or Boso Ta who are on my HQ.
I play the plots late in my current game so my HQ is somewhat hugh in terms of station modules. Everytime Dal or Boso are calling me I get something like 1 FPS what is especially anoying when flying a ship. If any other plot character from another location is calling me I don't have any performance issues. Is there a setting or something else I can do besides shrinking down my beloved HQ to prevent an impact from station size in callings?

Cheers

[Imperial Good]

sometimes you get calls from someone when walking on stations or ships or sitting in cockpit. I noticed an issue when I get called from Dal Busta or Boso Ta who are on my HQ.
I play the plots late in my current game so my HQ is somewhat hugh in terms of station modules. Everytime Dal or Boso are calling me I get something like 1 FPS what is especially anoying when flying a ship. If any other plot character from another location is calling me I don't have any performance issues. Is there a setting or something else I can do besides shrinking down my beloved HQ to prevent an impact from station size in callings?

Determining what is causing the performance bottleneck might be a good idea. For example, is it due to your system running out of free memory? Or free VRAM? Is it a GPU bottleneck from rendering so much geometry in the background? Is it a CPU bottleneck because your CPU is getting on in age? Is the SSD that you installed X4 to performing well enough to avoid an I/O bottleneck? You did install X4 to a SSD? Maybe try turning down some visual sittings in case that helps.

I also recommend making a thread about it so it is more likely the devs will notice your feedback. Perhaps Boso Ta and Dal Busta could be moved to a dummy lab at a dummy, easy to render, station for such calls made when they are not near the player.

[Daemonjax]

It would be cool if when mousing over the various graphics options, it would say whether the setting affects the performance of:

Code: Select all

a) just CPU
b) just GPU 
c) both CPU and GPU, and then an additional qualifier:
   i) mostly CPU
   ii) mostly GPU
   iii) about evenly

... and then a qualifier that denotes how much it should affect that component's performance, something like:

Code: Select all

1) major
2) moderate
3) minor

[alt3rn1ty]

It would be cool if when mousing over the various graphics options, it would say whether the setting affects the performance of:

Code: Select all

a) just CPU
b) just GPU 
c) both CPU and GPU, and then an additional qualifier:
   i) mostly CPU
   ii) mostly GPU
   iii) about evenly

... and then a qualifier that denotes how much it should affect that component's performance, something like:

Code: Select all

1) major
2) moderate
3) minor

Like the settings in No Man's Sky, with explanatory text for .. literally .. everything

[Daemonjax]

Like the settings in No Man's Sky, with explanatory text for .. literally .. everything

I knew I saw it somewhere and really liked it, I just couldn't remember which game it was.

[Daemonjax]

FINALLY I was able to solve my "seemingly audio-related" stutter (to be clear, these were framedrops, NOT simple audio stuttering, but still WERE audio-related) issue by modifying alsoft.conf in the game's folder and add the line:

Code: Select all

periods = 6

I was able to devise a test that's repeatable: start a new game, Stranded start. Talk to axiom in his cell, after that save the game (so you can reload it at this point if you want to). Now you just have to run down the hallway until he contacts you remotely -- takes like 10 seconds. If his audio causes frame stutters when he contacts you remotely, then that's the same thing I was experiencing elsewhere (i.e. I zoom and boom, first landed hit causes huge frame drop), and the above fix does fix that. Just quit the game and reload to test. it's repeatable, no need to reboot to clear the cache (I don't think this game caches much, or at least it defeats my attempts to pre-cache -- this engine is SUPER aggressive about limiting ram usage)... Just alt-tabbing might be enough, dunno. I got that setting from here: https://github.com/kcat/openal-soft/blo ... trc.sample

Basically it's the number of buffers. Maybe the default is 3... maybe it's 1... who knows. Afaict X4 uses an older version of that openal dll and default values change over time. If the default isn't 3, it's close to 3 or less. I still get the stutter when manually set to 3. Up to around 8 is playable without really noticing the audio delay. Each increment of the value is like another buffer that adds close to 20ms audio delay (depends on your audio frequency but it's close to 20ms). The max is 16, but that's causes really bad audio lag -- but it's cool that you can set the value high enough to be like "Yeah, that setting definitely has an effect." If the max was a sane value like 8, it would be hard to 100% Know if I'm wasting my time testing it. Anyways, 6 is totally fine -- >I< can't tell there's additional audio lag, seriously, at least during gameplay... I haven't tested cutscenes with lipsyncing and stuff (but I don't really gaf about that). I tried all other possible settings, and this is the ONE that fixes it (EDIT: I didn't try calculating a period_size that would be less than my target frametime, but I wouldn't expect that to work the way I'd want it to -- I'd probably have to modify the openal code).

Any OTHER stutters I have... maybe it's LOD loading. Maybe it's nvidia drivers changes (I can only go back so far with this newer video card, 4070ti super) with how vulkan over DXGI swapchain works (this is what I'm leaning towards). Maybe it's 7.0 performance regressions. But they're minor compared to this.

I spent SO MUCH TIME figuring this out. You're welcome.

Here's my complete alsoft.conf file in case any cares (it's setup for headphones, the section I marked with "HRTF stuff") -- I modified it to include all the settings I tested, but it's also tweaked for better positioning for scanning stations because the default values... kinda suck for positioning (with headphones, at least). These settings are WAY better for finding those things using your ears than the default settings, but if you don't use headphones you're gonna have to change/remove them (the settings between "HRTF stuff" start/end):

Spoiler

Show

[general]

## sources:
# Sets the maximum number of allocatable sources. Lower values may help for
# systems with apps that try to play more sounds than the CPU can handle.
# DJ: As low as 64 seemed to work ok. X4 default is 4096
#
# sources = 256
sources = 4096

## slots:
# Sets the maximum number of Auxiliary Effect Slots an app can create. A slot
# can use a non-negligible amount of CPU time if an effect is set on it even
# if no sources are feeding it, so this may help when apps use more than the
# system can handle.
# DJ: As low as 4 seemed to work ok. X4 default is 256
#
# slots = 64
slots = 256

## sends:
# Limits the number of auxiliary sends allowed per source. Setting this higher
# than the default has no effect.
#
# sends = 6

## rt-prio: (global)
# Sets the real-time priority value for the mixing thread. Not all drivers may
# use this (eg. PortAudio) as those APIs already control the priority of the
# mixing thread. 0 and negative values will disable real-time priority. Note
# that this may constitute a security risk since a real-time priority thread
# can indefinitely block normal-priority threads if it fails to wait. Disable
# this if it turns out to be a problem.
#
# rt-prio = 1
rt-prio = 1

## sample-type:
# Sets the default output sample type. Currently, all internal mixing is done with
# 32-bit float and then converted to the output sample type (as needed). Available
# values are:
# int8 - signed 8-bit int
# uint8 - unsigned 8-bit int
# int16 - signed 16-bit int
# uint16 - unsigned 16-bit int
# int32 - signed 32-bit int
# uint32 - unsigned 32-bit int
# float32 - 32-bit float
#
# sample-type = float32
sample-type = float32

## frequency:
# Sets the default output frequency. If left unspecified it will try to detect
# a default from the system, otherwise it will fallback to 48000.
#frequency =

## cf_level:
# Sets the crossfeed level for stereo output. Valid values are:
# 0 - No crossfeed
# 1 - Low crossfeed
# 2 - Middle crossfeed
# 3 - High crossfeed (virtual speakers are closer to itself)
# 4 - Low easy crossfeed
# 5 - Middle easy crossfeed
# 6 - High easy crossfeed
# Users of headphones may want to try various settings. Has no effect on non-
# stereo modes.
# DJ: Not good when I tried it -- muffled audio.
#
# cf_level = 0
cf_level = 0

## hrtf:
# Deprecated. Consider using stereo-encoding instead. Valid values are auto,
# off, and on.
# DJ: Leave this off.
#
# hrtf = auto
hrtf = off

# START ########################## HRTF stuff

## channels:
# Sets the default output channel configuration. If left unspecified, one will
# try to be detected from the system, with a fallback to stereo. The available
# values are: mono, stereo, quad, surround51, surround61, surround71,
# surround714, surround3d71, ambi1, ambi2, ambi3. Note that the ambi*
# configurations output ambisonic channels of the given order (using ACN
# ordering and SN3D normalization by default), which need to be decoded to
# play correctly on speakers.
#
# channels =
channels = stereo

## stereo-mode:
# Specifies if stereo output is treated as being headphones or speakers. With
# headphones, HRTF or crossfeed filters may be used for better audio quality.
# Valid settings are: auto, speakers, or headphones
#
# stereo-mode = auto
stereo-mode = headphones

## stereo-encoding:
# Specifies the default encoding method for stereo output. Valid values are:
# basic - Standard amplitude panning (aka pair-wise, stereo pair, etc) between
# -30 and +30 degrees.
# uhj - Creates a stereo-compatible two-channel UHJ mix, which encodes some
# surround sound information into stereo output that can be decoded with
# a surround sound receiver.
# hrtf - Uses filters to provide better spatialization of sounds while using
# stereo headphones.
# If crossfeed filters are used, basic stereo mixing is used.
#
# stereo-encoding = basic
stereo-encoding = hrtf

# END ########################## HRTF stuff

## periods:
# Sets the number of update periods. Higher values create a larger mix ahead,
# which helps protect against skips when the CPU is under load, but increases
# the delay between a sound getting mixed and being heard. Acceptable values
# range between 2 and 16.
# DJ: You want buffers, but not too many. 16 creates bad audio lag, so you
# want the highest number you can stand to fix stutters/skips, somewhere between 4 - 8.
# periods = 3
periods = 6

## period_size:
# Sets the update period size, in sample frames. This is the number of frames
# needed for each mixing update. Acceptable values range between 64 and 8192.
# If left unspecified it will default to 1/50th of the frequency (20ms, or 882
# for 44100, 960 for 48000, etc).
# DJ: Can just leave this alone and adjust periods instead.
#period_size =

## hrtf-mode:
# Specifies the rendering mode for HRTF processing. Setting the mode to full
# (default) applies a unique HRIR filter to each source given its relative
# location, providing the clearest directional response at the cost of the
# highest CPU usage. Setting the mode to ambi1, ambi2, or ambi3 will instead
# mix to a first-, second-, or third-order ambisonic buffer respectively, then
# decode that buffer with HRTF filters. Ambi1 has the lowest CPU usage,
# replacing the per-source HRIR filter for a simple 4-channel panning mix, but
# retains full 3D placement at the cost of a more diffuse response. Ambi2 and
# ambi3 increasingly improve the directional clarity, at the cost of more CPU
# usage (still less than "full", given some number of active sources).
#
# hrtf-mode = full

## hrtf-size:
# Specifies the impulse response size, in samples, for the HRTF filter. Larger
# values increase the filter quality, while smaller values reduce processing
# cost. A value of 0 (default) uses the full filter size in the dataset, and
# the default dataset has a filter size of 64 samples at 48khz.
#
# hrtf-size = 0

## default-hrtf:
# Specifies the default HRTF to use. When multiple HRTFs are available, this
# determines the preferred one to use if none are specifically requested. Note
# that this is the enumerated HRTF name, not necessarily the filename.
#
# default-hrtf =

## hrtf-paths:
# Specifies a comma-separated list of paths containing HRTF data sets. The
# format of the files are described in docs/hrtf.txt. The files within the
# directories must have the .mhr file extension to be recognized. By default,
# OS-dependent data paths will be used. They will also be used if the list
# ends with a comma. On Windows this is:
# $AppData\openal\hrtf
# And on other systems, it's (in order):
# $XDG_DATA_HOME/openal/hrtf (defaults to $HOME/.local/share/openal/hrtf)
# $XDG_DATA_DIRS/openal/hrtf (defaults to /usr/local/share/openal/hrtf and
# /usr/share/openal/hrtf)
# hrtf-paths =

## drivers: (global)
# Sets the backend driver list order, comma-seperated. Unknown backends and
# duplicated names are ignored. Unlisted backends won't be considered for use
# unless the list is ended with a comma (e.g. 'oss,' will try OSS first before
# other backends, while 'oss' will try OSS only). Backends prepended with -
# won't be considered for use (e.g. '-oss,' will try all available backends
# except OSS). An empty list means to try all backends.
# DJ: the following seems to work in windows: winmm, wasapi
#
# drivers =


##
## WASAPI backend stuff
##
[wasapi]

## spatial-api:
# Specifies whether to use a Spatial Audio stream for playback. This may
# provide expanded capabilities for surround sound and with-height speaker
# configurations. Very experimental.
#
# spatial-api = false

## allow-resampler:
# Specifies whether to allow an extra resampler pass on the output. Enabling
# this will allow the playback device to be set to a different sample rate
# than the actual output can accept, causing the backend to apply its own
# resampling pass after OpenAL Soft mixes the sources and processes effects
# for output.
#
# allow-resampler = true

##
## Ambisonic decoder stuff
## ## DJ: Not sure
##
[decoder]

## hq-mode:
# Enables a high-quality ambisonic decoder. This mode is capable of frequency-
# dependent processing, creating a better reproduction of 3D sound rendering
# over surround sound speakers.
#hq-mode = true

## distance-comp:
# Enables compensation for the speakers' relative distances to the listener.
# This applies the necessary delays and attenuation to make the speakers
# behave as though they are all equidistant, which is important for proper
# playback of 3D sound rendering. Requires the proper distances to be
# specified in the decoder configuration file.
#distance-comp = true

## nfc:
# Enables near-field control filters. This simulates and compensates for low-
# frequency effects caused by the curvature of nearby sound-waves, which
# creates a more realistic perception of sound distance with surround sound
# output. Note that the effect may be stronger or weaker than intended if the
# application doesn't use or specify an appropriate unit scale, or if
# incorrect speaker distances are set. For HRTF output, hrtf-mode must be set
# to one of the ambi* values for this to function.
#nfc = false

## speaker-dist:
# Specifies the speaker distance in meters, used by the near-field control
# filters with surround sound output. For ambisonic output modes, this value
# is the basis for the NFC-HOA Reference Delay parameter (calculated as
# delay_seconds = speaker_dist/343.3). This value is not used when a decoder
# configuration is set for the output mode (since they specify the per-speaker
# distances, overriding this setting), or when the NFC filters are off. Valid
# values range from 0.1 to 10.
#speaker-dist = 1

## quad:
# Decoder configuration file for Quadraphonic channel output. See
# docs/ambdec.txt for a description of the file format.
#quad =

## surround51:
# Decoder configuration file for 5.1 Surround (Side and Rear) channel output.
# See docs/ambdec.txt for a description of the file format.
#surround51 =

## surround61:
# Decoder configuration file for 6.1 Surround channel output. See
# docs/ambdec.txt for a description of the file format.
#surround61 =

## surround71:
# Decoder configuration file for 7.1 Surround channel output. See
# docs/ambdec.txt for a description of the file format.
#surround71 =

## surround714:
# Decoder configuration file for 7.1.4 Surround channel output. See
# docs/ambdec.txt for a description of the file format.
#surround714 =

## surround3d71:
# Decoder configuration file for 3D7.1 Surround channel output. See
# docs/ambdec.txt for a description of the file format. See also
# docs/3D7.1.txt for information about 3D7.1.
#surround3d71 =

##
## UHJ and Super Stereo stuff
## DJ: Not sure
##
[uhj]

## decode-filter: (global)
# Specifies the all-pass filter type for UHJ decoding and Super Stereo
# processing. Valid values are:
# iir - utilizes dual IIR filters, providing a wide pass-band with low CPU
# use, but causes additional phase shifts on the signal.
# fir256 - utilizes a 256-point FIR filter, providing more stable results but
# exhibiting attenuation in the lower and higher frequency bands.
# fir512 - utilizes a 512-point FIR filter, providing a wider pass-band than
# fir256, at the cost of more CPU use.
#
# decode-filter = iir
decode-filter = iir

## encode-filter: (global)
# Specifies the all-pass filter type for UHJ output encoding. Valid values are
# the same as for decode-filter.
#
# encode-filter = iir
encode-filter = iir

##
## Per-game compatibility options (these should only be set in per-game config
## files, *NOT* system- or user-level!)
##
[game_compat]

## default-error: (global)
# An error value returned by alGetError when there's no current context. The
# default value is AL_INVALID_OPERATION, which lets the caller know the
# operation could not be executed. Some applications may erroneously call
# alGetError without a current context and expect 0 (AL_NO_ERROR), however
# that may cause other applications to think earlier AL calls succeeded when
# they actually failed.
#default-error = 0xA004

## nfc-scale: (global)
# A meters-per-unit distance scale applied to NFC filters. If a game doesn't
# use real-world meters for in-game units, the filters may create a too-near
# or too-distant effect. For instance, if the game uses 1 foot per unit, a
# value of 0.3048 will correctly adjust the filters. Or if the game uses 1
# kilometer per unit, a value of 1000 will correctly adjust the filters.
#nfc-scale = 1

## enable-sub-data-ext: (global)
# Enables the AL_SOFT_buffer_sub_data extension, disabling the
# AL_EXT_SOURCE_RADIUS extension. These extensions are incompatible, so only
# one can be available. The latter extension is more commonly used, but this
# option can be enabled for older apps that want the former extension.
#enable-sub-data-ext = false

## reverse-x: (global)
# Reverses the local X (left-right) position of 3D sound sources.
#reverse-x = false

## reverse-y: (global)
# Reverses the local Y (up-down) position of 3D sound sources.
#reverse-y = false

## reverse-z: (global)
# Reverses the local Z (front-back) position of 3D sound sources.
#reverse-z = false

With 64gb of ram, maybe putting all the game files on a decent ramdisk would also work. Dunno, I only have 32gb. I'm super sensitive to stutters, so I always need to go on a friggin quest to solve stutters for every game I'm playing. Pre-caching won't work for this game (it aggressively clears the filecache).

Sidenote: Newer nvidia drivers (> 552.xx) automatically set this game to use the dxgi swapchain. Older ones didn't (527.xx, on a 1070ti, at least). And I'm drunk.

[Endomatic]

Stuff ..

Pretty sure I owe you a big thanks!
I came back to the game after a 2 year hiatus and a new computer only to find I was getting some real odd lag in really odd places. Had NO CLUE what the cause was. Came here, browsed the thread, threw in your changes just to see what happened, and I basically had the same result as you did.
This is the smoothest the game has ever been for me, so thanks!

[steelman111]

FINALLY I was able to solve my "seemingly audio-related" stutter (to be clear, these were framedrops, NOT simple audio stuttering, but still WERE audio-related) issue by modifying alsoft.conf in the game's folder and add the line:

Oh man this fixed my FPS spikes too! I was getting sick of massive freezes when entering combat and now it's completely gone!

Thanks!

[Bad2DBone]

The game runs great for a long while (hours) and then I get into slowdown (haging for a few seconds).
I have to restart; but even then there may some game "feature" that causes problem.
Also I have lots of "tracks" on the screen that dont belong to my ships.
Is there an email I drop a screenshot and the savefile to see if anyhting is "wrong".
GPU: AMD Radeon RX 6800 XT
Win 11 Pro 64
i7-9700 3GHz (8 CPUs)
32GB Ram

Update:
As for the tracks; FRF REP is up to 27 and it's their ship traces I can see... I will try to find the option to turn them off.

Update:
[ ] Show Allied Orders <--- turn off.

[CBJ]

Please see the very first sticky thread at the top of the forum. It tells you the information you need to provide in order for us to be able to help, and explains how to link files to support that. I suggest you also start a new thread rather than hiding your issue away in a thread for troubleshooting solutions.

[Dante24]

game bought and installed via steam, fresh install but game is lagging, even i choose lower settings it still lags. Game has all DLCs and latest update.
My specs are:
i7 11800H 8 cores
RTX 3070 8gb
32GB DDR4
1TB m2 drive

[CBJ]

We can't do anything with just a brief overview of a few hardware components. Please read the very first thread at the top of the forum, entitled "Technical Support Requests - Please read this before posting!" and start a new thread, making sure you include all the information requested there. Then we might be able to help.

[Shadow1980]

FINALLY I was able to solve my "seemingly audio-related" stutter (to be clear, these were framedrops, NOT simple audio stuttering, but still WERE audio-related) issue by modifying alsoft.conf in the game's folder and add the line:

Code: Select all

periods = 6

This fixed the lagspike I was experiencing every single time combat started.

And that's with a 7800X3D,RTX 4090 and 64 MB DDR5 (6000mhz/CL30)
Game is on a PCIe 4 m.2 SSD.

There's definitely something happening here, but this fixed the lag completely.

[Gergin]

FINALLY I was able to solve my "seemingly audio-related" stutter (to be clear, these were framedrops, NOT simple audio stuttering, but still WERE audio-related) issue by modifying alsoft.conf in the game's folder and add the line:

Code: Select all

periods = 6

This fixed the lagspike I was experiencing every single time combat started.

And that's with a 7800X3D,RTX 4090 and 64 MB DDR5 (6000mhz/CL30)
Game is on a PCIe 4 m.2 SSD.

There's definitely something happening here, but this fixed the lag completely.

This and setting the Vulkan/OpenGL Presentation method to "Prefer Layered on DXGI Swapchain" resulted a massive improvement in the frame pacing for me as well. My game went from feeling really stuttery despite having solid FPS to as smooth as the displayed FPS should feel.

12700KF, 3080Ti and 32 GB DDR (3600 Mhz)

Genuinely an incredible find given that it seems to have virtually no noticeable impact to the audio but results in such a dramatic performance improvement.

[Daemonjax]

Happy to help!

You can go up to periods = 8 if you need to, but after that the increased audio lag from the buffering becomes very noticeable.

> this and setting the Vulkan/OpenGL Presentation method to "Prefer Layered on DXGI Swapchain"

I know that (on much older drivers) setting it to Auto did not default this game to use dxgi swapchain... and then one day a driver update dropped where it did. But that could've changed again with more recent drivers.
For this game at least, you _definitely_ want to have it use the dxgi swapchain. The reason this helps is because it'll make the game use independent flip presentation -- otherwise it'll use composite, which doesn't bypass dwm. You can verify this by using a tool like presentmon. If there was a fullscreen mode for this game, it would probably be better.

EDIT: I just verified (using presentmon) that nvidia drivers 572.70 uses dxgi swapchain when it's set to Auto (which is the default), but yeah it's probably better to just set it yourself within X4's game profile -- just to be sure.

[Daemonjax]

On the quest for smoothness...

I fired the game up today (I think the last time I played was 7.1), and noticed it's a bit less smooth (although dlaa is much appreciated!). But that could just be because I've been playing other games.

One weird thing I'm trying to solve at the moment is:

with vsync disabled (I don't actually intend to play with vsync disabled, but I think it's a symptom of a problem) the game is very stuttery. I expect tearing, but it should otherwise be kinda smooth... but it's a stutterfest. Unplayable. Like it's 30 fps. Haven't figured it out yet.

Update: Well I didn't figure that out so I just moved on (using vsync) and noticed the following...

1) Different custom resolutions (using different vertical hz, front porch, backporch) didn't affect the stuttering with vsync off
2) Enabled vsync ingame was significantly smoother than forcing vsync through nvcp
3) Using adaptive vsync "works" in a sense, but it's pointless (for me) because without vsync working it's a stuttery mess... like there's zero framebuffering happening.
4) Disabling hags might help slightly, hard to tell (game uses less vram with hags ON, explain that one)
5) Using rtss framelimiter seems to help a bit
6) Increasing the max pre-rendered frames to 8 has no effect
7) Restricting core affinities didn't help and felt/looked like it made things worse (main thread loop looks like it's always on core 2, with some minor thread on core 3 which is on the same physical core as core 2 -- but if I restrict core 3 it just puts that minor thread on core 2 anyways).

I normally use rtss framelimiter to reduce input latency in games where input latency matters to me somewhat but I'm also using vsync (because I hate tearing) -- like in singleplayer fps games where I'm trying to make headshots. It keeps the framebuffers starved, reducing latency significantly. What's weird to me is that in this game, doing that has no effect whatsoever on input latency -- it's like the framebuffer is always kept starved no matter what. Feels like ULLM is always on.

Sidenote1: In this game at least, DLAA looks best with preset K when compared to Preset F (F with a reshade cas-based sharpener) only because K is more stable (less aliasing) when the camera moves, which matters more than still shots. And J
certainly is not any sharper than K, so use K.
Sidenote2: To compensate for the complete lack of motion blur, I reduced my lcd panel's repsonse time. Since motion data is now included in the renderer, why not implement per object motion blur?

Update:
So... it's looking like the best I can do is (I have a non-gsync display):

a) ingame vsync on
b) ensure actual vertical refresh in CRU matches what windows settings reports (windows rounds up from the 4th decimal place, but CRU only displays 3 decimal places of precision)
c) use rtss to cap frames to exactly vertical refresh rate, using front edge sync (kinda weird, since it's meant to be used with scanline sync, but whatever), and Disable passive waiting.
d) hags off, and don't force enable rebar
e) in config.xml, this change does have a very real effect (better performance) when flying near stations (EDIT: I think as high as 0.12 might be OK):

Code: Select all

  <trafficdensity>0.05</trafficdensity>

f) underclocked my lcd to 52hz using CRU -- my lcd can do between 49-75 before getting blurry, but 52 us the lowest I can go before it feels bad without motion blur, and also using the worst response time setting on lcd to introduce some ghosting for fake motion blur. This reduced stuttering way more than I expected it should. FG please?
g) set pagefile to 32gb (I have 32gb of ram; I've seen the mem commit size go up to 32gb once and it got choppy then when pagefile was 16gb, maybe 32gb will be better? Dunno)
ymmv

Note: I think some stations just naturally seem to pump out way more station traffic than others for some reason. Also, it only really seems to cause performance issues during or after the station's defenses become active (when the red spinning lights are active).