낙하물 말뚝제거제

낙하물 말뚝제거제
버전 4.0.7
스카이렌저-1

포럼 스레드: http://www.bethsoft.com/bgsforums/index.php? showtopic=1069833
Tesnexus 페이지: http://www.fallout3nexus.com/downloads/file.php?info? id = 8886

이것은 fose 플러그인이며 fose 1.2 베타 1 이상에서만 작동합니다.

이것은 Fallout 3 버전 1.7에서만 작동합니다.




0. 내용:
====================================

0. 내용
1. 개요
2. 설치
3. 설치 제거
4. 일반적인 설정 변경
5. 모든 설정
6. 버전 내역
7. 이것이 어떻게 작동하는지
8. 학점



1. 개요:


이 플러그인은 포로아웃 3을 만들지 않고 "더듬거리는 것"만큼, 일반적으로 더 부드럽게 느끼거나 더 나은 성능. 이것은 말뚝과 프레임 속도와 관련된 여러 문제를 방지하거나 완화하고 말뚝과 관련된 충돌 빈도를 줄일 수 있다. 자세한 내용은 섹션 7: 이것이 어떻게 작동하는지를 참조하십시오.

그러나 이것은 일반적으로 드라이버, 하드웨어 또는 코덱에 문제를 해결하지 않는다는 점에 주의하십시오. 성능이 떨어지는 근본적인 이유가 있다면, 이것은 아마도 큰 도움이 되지 않을 것이다.

이것은 낙하물을 처리할 수 있는 OSR(Oblivion Sturter Dress)의 포트입니다. 지금까지, 그것은 원래의 잊혀진 말뚝을 제거하는 것만큼 잘 작동하지 않지만, 그것은 약간의 도움이 될 것입니다.

이것은 모든 것과 호환되어야 한다. 유일한 경고점은 fps를 모니터링하는 mods가 이 플러그인에 의해 설정된 대상 범위 밖의 fpses를 정확하게 측정할 수 없다는 것입니다 (기본적으로 10 ~ 30). 사실, 단지 fsr 목표에 가까운 fpses조차도 측정하기 어려울 수 있습니다.



2. 설치:
====================================

설치 과정은 다음과 같습니다.

1. a. 설치 중인 fsr 버전이. zip 파일로 나온 경우 zip에서 "Data" 폴더를 잊고 폴더로 드래그하십시오.

1. B. 설치 중인 fsr 버전이. zip 파일로 나오지 않은 경우 파일 sr_fallout_stutter_remover.dll 파일을 fallout\Data\fose\plugins 폴더에 배치해야 합니다. 이런 폴더가 없으면 만들어라. 이전 버전의 fsr를 설치한 경우, 그 ini 파일(Data\fose\plugins\sr_Fallout_Stutter_Remover.ini)을 삭제합니다. 기존 fsr ini 파일이 없다면 fsr는 다음에 fallout를 실행할 때 버전에 적합한 설정을 가진 새 ini 파일을 생성합니다.



3. 설치 제거:


데이터\fose\plugins 폴더에서 sr_fallout_stutter_remover.dll 파일을 삭제하기만 하면 됩니다.
이 파일을 다른 디렉토리로 이동하는 것도 충분합니다.



4. 일반적인 설정 변경
====================================

일반적으로 fsr은 사용자가 그들과 함께 원숭이를 사용할 필요가 없도록 좋은 기본 설정을 하려고 시도합니다. 그러나 기본값이 당신의 취향과 일치하지 않거나 fsr가 컴퓨터에 대해 잘못된 가정을 했기 때문에 기본값이 당신에게 적합하지 않을 수 있는 몇 가지 설정이 있습니다.

fsr은 파일 data\fose\plugins\sr_Fallout_Stutter_Remover.ini에 설정을 유지합니다.
그 파일이 존재하지 않으면, 단순히 fsr를 설치한 후 fsr가 당신의 버전의 fsr에 대한 기본 설정을 가진 새로운 하나를 생성합니다. 설정에서 무언가를 망쳤거나 다른 방법으로 기본 설정으로 복귀하려는 경우, 단순히 이 ini 파일을 삭제하고 포로아웃을 시작합니다.

섹션 5에서 설정에 대한 일반적인 정보와 각 개별 설정에 대한 보다 완전한 정보를 찾을 수 있습니다.

변경할 가능성이 가장 높은 설정은 다음과 같습니다.

FPS_Management\MaximumFPS: (기본값은 30, 0 또는 기타 값으로 변경하는 것을 고려합니다.)
어떤 사람들은 자신의 프레임 속도를 제한하는 것을 전혀 원하지 않습니다. 이를 0으로 설정하여 fps 제한을 닫을 수 있습니다. 또한, 발생물을 재생할 때 화면 새로 고침 속도가 60Hz가 아닌 경우, 화면 새로 고침 속도나 화면 새로 고침 속도의 절반 또는 화면 새로 고침 속도의 1/3으로 변경해 볼 수 있습니다. master\bmanagefps가 0으로 변경되면 이 설정은 영향을 미치지 않습니다.

Hashtables\bAllowDynamicResizing: (기본값은 0으로, 1로 변경하는 것을 고려합니다)
이를 켜면 심각하게 변형된 게임에서 일반적인 성능/fps를 크게 향상시킬 수 있습니다. 불행하게도, 특히 특정 fose 명령을 사용하는 스크립트가 모든 프레임을 실행할 때 경주 조건과 일반적인 난장판을 일으킬 수 있습니다. 문제가 발생할 가능성을 0에 가까운 곳으로 줄이려고 했지만... 아직 더 많은 일이 필요할 수 있습니다. 이 기능은 기본적으로 비활성화됩니다. master\bhookhashtables를 0으로 변경하면 이 설정은 영향을 미치지 않습니다.

임계 단면 억제:(특수)
기본적으로 fsr은 발목이 없이는 더 잘 작동하는 것처럼 보이는 특정 중요한 부분을 억제합니다. 일부 사용자들은 문제를 일으키지 않고 억제할 수 있는 것처럼 보이지만, 다른 사용자들은 ctds를 억제할 때 내부-> 외부 전환이나 다른 문제를 경험합니다. 말뚝을 작은 개선시킬 뿐이기 때문에, 나는 보통 억제하는 것을 권장하지 않지만, 원한다면 억제할 수 있다. 그것을 억제하려면 ini 파일에서 "CallerAddress=0x70172A"라는 행을 찾고 그 바로 뒤에" Mode=5"라는 새로운 행을 추가하십시오. 사건이 중요하다는 점에 주의하십시오... 그것은 '모드'가 아니라 '모드'여야 한다. master\bhookcriticalsections 또는 criticalsections\buseoverrides가 0으로 설정되면 이 설정은 영향을 미치지 않습니다.
주의: 이 바로 위에 있는 readme의 삭제된 부분은 잊어버리기 위한 것이지, 파괴가 아니다; 낙하물에 해당하는 값이 있지만, 나는 아직 정확한 값을 찾아보지 못했다. 당분간 그것을 무시하세요.



5. 모든 설정
====================================

fsr은 파일 data\fose\plugins\sr_Fallout_Stutter_Remover.ini에 설정을 유지합니다.
그 파일이 존재하지 않으면, 단순히 fsr를 설치한 후 fsr가 당신의 버전의 fsr에 대한 기본 설정을 가진 새 파일을 생성합니다. 설정에서 무언가를 망가뜨렸거나 기본 설정으로 복귀하려는 경우, 단순히 이 ini 파일을 삭제하고 방해를 시작합니다.

fsr ini 파일의 형식이 fsr의 주요 버전 간에 변경되는 것을 유의하십시오-fsr2에서 fsr 버전 2 등과 함께 fsr 버전 1 ini 파일을 사용해서는 안 되며 ini 파일은 "SectionName {SettingName=Value}"와 같은 섹션으로 구성됩니다. 특정 설정을 sectionname\settingname로 참조하여 다른 섹션에서 같은 이름을 가진 다른 설정과 구별할 수 있습니다. 일반적으로 "i"로 시작하는 이름이 있는 설정은 정수 값(즉, 소수점이 없는 숫자)이고," b"로 시작하는 이름이 있는 설정은 부울 값(즉, 0 또는 1)이며, "f"로 시작하는 설정은 소수점이 있을 수 있는 숫자(즉, 3.14) 입니다. 일부 설정은 이러한 문자 중 하나로 시작되지 않으며, 이 경우 적절한 유형의 값이 무엇인지 명확하지 않을 수 있습니다.

이것은 설정 및 현재 기본값(100% 최신 값이 아닐 수 있습니다) 입니다.

섹션: 마스터 {}
이 섹션에는 fsr의 각 주요 서브시스템을 비활성화할 수 있는 옵션이 포함되어 있으며, fsr의 특정 서브시스템에 속하지 않는 것에 대한 몇 가지 설정이 포함되어 있습니다.

Master\bManageFPS(기본값: 1)
이를 0으로 설정하면 모든 fps 관리 사항이 비활성화되므로 fps_management 섹션의 모든 설정은 무의미하게 됩니다.

Master\bHookCriticalSections (기본값: 1)
이를 0으로 설정하면 모든 크리티컬 섹션이 비활성화되므로 criticalsections 섹션의 모든 설정은 의미가 없습니다.

Master\bHookLightCriticalSections (기본값: 1)
이를 0으로 설정하면 모든 라이트 크리티컬 섹션이 비활성화되어 lightcriticalsections 섹션의 모든 설정이 의미가 없게 됩니다.

Master\bHookHashtables (기본값: 1)
이를 0으로 설정하면 모든 해시테이블이 비활성화되므로 criticalsections 섹션의 모든 설정은 무의미하게 됩니다.

Master\bReplaceHeap (기본값: 0)
이를 1로 설정하면 더 재지정이 활성화되어 더 섹션의 설정이 의미가 있게 됩니다.

Master\bLogToConsole(기본값: 0)
fsr은 다양한 정보 비트를 로그 파일에 기록합니다. 이 설정을 1로 변경하면 fsr은 콘솔에 해당 정보를 인쇄할 수 있습니다.
로그 파일은 fallout 디렉토리의 sr_fallout_stutter_remover.log입니다. fsr가 설치되어 있을 때마다 fallout가 실행될 때마다 생성되거나 덮어쓰게 됩니다.

Master\bFix64Hertz (기본값: 1)
이를 1로 설정하면 "마이크로 스터터"를 일으키는 발산물의 문제가 해결됩니다. 이 문제는 때때로 "64 Hertz 문제"라고 불린다. 특히 문제는 바로 초의 1/64분의 해상도에서 발생하는 게임 논리 타이밍이며, 스크린 새로 고침 속도는 일반적으로 vsync가 제한될 때 초당 60프레임을 그릴 수 있다는 것이다. 이러한 조합은 프레임속도가 최대화될 때, 초당 4개의 프레임이 56개의 프레임보다 두 배의 게임 시간이 지나가는 일종의 비트 주파수를 만든다. fsr은 초의 1/64가 아니라 초의 1/1000의 해상도로 시간을 사용하도록 강력한 발산을 적용하는 수정법입니다.

Master\bFlushLog(기본값: 1)
이것은 fsr에게 로그 메시지를 메모리에 버퍼하는 대신 즉시 파일에 로그 메시지를 쓰도록 알려줍니다. 더 많은 디스크 액세스 수로 인해 성능을 약간 감소시킬 수 있지만 충돌 직전에 발생하는 문제와 관련된 메시지가 로그 파일에 성공적으로 쓰여질 가능성이 더 높습니다.

Master\iSchedulingResolution(기본값: 1)
fsr은 윈도우 스케줄러를 이 몇 밀리초 해상도로 실행하도록 요청합니다. 이 세트가 1인 경우, fsr과 fallout은 일반적으로 더 잘 작동합니다. 그러나 노트북의 배터리 수명을 약간 줄일 수 있습니다.

섹션: FPS_Management {}
이 섹션에는 fsr가 프레임 속도와 게임 시간의 흐름을 관리하는 방법을 조정하는 설정이 포함되어 있습니다.

FPS_Management\bAllowSlowMotion(기본값: 1)
이를 0으로 설정하면 fsr이 게임 시간의 정상적인 흐름을 덮어쓰려는 시도를 방지합니다. 과거에는 fsr의 arison이 그렇게 했다(가장 악명 높은 것은 nearby-npcs-drop-dead-on-cell-transitions bug)지만, 이것은 지금은 수정되었다고 믿는다. 문제가 있을 수 있다고 의심하는 경우, 이 설정을 사용하여 모든 fsr 게임 시간 조정을 강제로 비활성화할 수 있습니다. 이름에도 불구하고, 이것을 0으로 설정하면 fsr가 게임 시간을 빠르게 전달하는 것을 막을 수 있지만, fsr은 설정과 상황의 매우 희귀한 조합에서만 그렇게 하려고 합니다.

FPS_Management\MaximumFPS (기본값: 30)
이것은 최대 fps이며, fsr은 폭발이 초과되지 않도록 허용합니다. 나는 일반적으로 이것을 충분히 높은 프레임 속도로 설정하여 초당 추가 프레임에 대해 별로 신경 쓰지 않을 것이다. 여기서 fsr은 실제로 "초당 프레임"을 처리하지 않으며, 그 값을 프레임당 밀리초 번호로 변환하고 각 프레임을 개별적으로 고려합니다. 프레임이 너무 빠르게 완료되면 fsr은 올바른 밀리초 수가 지나갈 때까지 fallouts 메인 스레드가 수면에 들어갈 수 있습니다. fallouts 메인 스레드를 sleep에 넣으면 fallouts 백그라운드 스레드에 사용하거나 백그라운드에서 실행될 수 있는 다른 프로그램에 사용할 수 있는 리소스를 자유롭게 할 수 있습니다. 아무것도 추가 자원을 사용하고 싶지 않다면, 당신의 CPU 및/또는 gpu는 더 차가워지고 전력을 적게 사용할 것입니다.

FPS_Management\MinimumFPS (기본값: 10)
이것은 fsr이 폭발을 허용하지 않는 최소 fps입니다. 그러나 이것은 실제 초를 다루는 것이 아니라 초의 게임 시간을 다루는 것이다. 그래서 컴퓨터가 정말 느리다면 여전히 fps를 1로 할 수 있지만, 이것은 게임 시간을 정상의 10%로 늦출 수 있기 때문에 초당 최소 10프레임의 게임 시간이 항상 있을 수 있습니다. 예를 들어, 모든 숫자는 실제 fps 1과 최소 fps 설정 10(기본값)을 기반으로 합니다. 또한 maximumfps와 마찬가지로 이것은 실제로 초당 프레임 대신 프레임당 밀리초를 처리하는 단일 프레임 기준으로 작동한다는 점에 유의하십시오.
저는 일반적으로 이것을 원격으로 재생할 수 있는 낮은 fps로 설정합니다. 이 설정의 큰 목적은 fps가 너무 낮을 때 게임 논리가 미치는 것을 방지하는 것이다. 이것이 방지하는 문제에는 적이 프레임 사이에 당신을 주위로 돌아갈 수 있기 때문에 불가능한 싸움이 포함되며, fallout가 공격 키가 전체 프레임에 대해 아래로 떨어져 있거나 전체 프레임에 대해 아래로 떨어지지 않는다고 생각하기 때문에 컨트롤이 망가졌기 때문에 공격이 의도되었을 때 전력 공격이 발생할 수 있으며, 다른 많은 유사한 문제들이 포함됩니다.

FPS_Management\iSmoothFrames (기본값: 0)
이를 0으로 설정하면 "스무딩" 논리는 아무것도 하지 않습니다. 스무딩 논리를 켜려면 이를 2로 설정하십시오. 그러나 보고서는 평평한 논리가 실제로 아무것도 가치가 없다는 것을 보여준다. 부드러운 논리는 더듬이와 기타 프레임 속도의 급속한 변화로 인한 다양한 문제를 방지하기 위한 것이다. 만약 ballowslowmotion이 0인 경우, 스무딩 논리는 효과가 없습니다.

FPS_Management\iSmoothMode(기본값: 0)
이것은 0, 1, 2 또는 3이어야 합니다. 만약 0이나 1이라면, 시간의 흐름에서 말뚝이사건을 필터링하려는 추가 논리를 사용할 수 있습니다. 이 논리는 결국 전체 게임 시간이 전체 실시간과 같지 않을 수 있습니다. 만약 fps가 갑자기 떨어진다면 만약 2이나 3이면 그 추가 논리는 비활성화됩니다. 0/2와 1/3의 차이는 어떤 프레임이 어떻게 그들 사이에 시간을 재분배하는지에 대한 미묘한 문제입니다.

FPS_Management\iSleepExtra (기본값: 2)
fsr은 초마다 이렇게 많은 밀리초 동안 수면하도록 강요합니다. 이렇게 하면 백그라운드 스레드 또는 기타 프로세스에 대한 리소스를 자유롭게 하거나 컴퓨터 구성 요소의 온도 및 전력 소비를 약간 줄일 수 있습니다. 주요 이점은, 어떤 백그라운드 스레드가 메인 스레드가 호그하는 특정 리소스를 얻기 위해 어려움을 겪고 있다면, 이것은 때때로 그 리소스를 얻을 수 있는 기회를 줄 수 있다는 것이다.
이가 -1로 설정되면 fsr fps 관리 코드는 절대 수면에 포로아웃을 넣지 않습니다-fps 그렇지 않으면 maximumfps를 초과하면 fsr 유휴 루프에서 시간을 낭비할 것입니다. 이 모드는 테스트 목적에만 제공되었기 때문에 권장되지 않습니다.

FPS_Management\bFPSConsoleSPAM(기본값: 0)
이렇게 하면 fsr은 각 프레임을 완료하는 데 걸리는 시간을 기록합니다. 그것은 프레임당 한 번씩 이렇게 할 것이며, 엄청난 양의 기록 시간을 만들 것이다.

FPS_Management\iSchedulingParanoia (기본값: 1)
이 설정은 밀리초 단위로 설정됩니다. 그것은 최대 fps 코드가 스케줄러에 대해 얼마나 편집적인지 결정합니다. 값이 높다면 maximumfps 코드는 절대 잠을 이루지 않고 유휴 루프에서 시간을 낭비할 수 없습니다. 값이 0인 경우 maximumfps 코드는 스케줄러가 요청된 시간에 메인 스레드 실행을 재개할 수 있도록 신뢰합니다. 일반적으로 나는 스케줄러에 대한 편집증을 1에서 타협하지만 여전히 여가 시간의 대부분을 건설적으로 사용할 수 있도록 허용한다.

FPS_Management\iHardMaxFrametime (기본값: 200)
이것은 밀리초 단위로 표시됩니다. 제 시간 흐름 조정 코드가 잘못된 시간에 너무 큰 시간을 넣으면 이상한 일이 일어난다는 것을 발견했습니다. 나쁜 일. 마치 근처의 npcs가 무작위로 떨어져 죽어가는 것처럼. 이 설정은 fsr이 일상적인 과정에서 한 번에 통과할 수 있는 밀리초 수에 절대 최대를 설정함으로써 그것을 방지합니다. 일반적으로 이 제한에 도달하기 전에 최소한에 도달하지만, 어떤 경우에서는 최소한에 도달하지만, 입술 움직임과 목소리를 동기화하는 것과 같은 부작용을 방지하기 위해 최소한에 도달하기는 포기됩니다. 그래서 이것은 2급 최소한에 도달하는 최소한에 도달하는 i-real-mean-it 최소한의 fps입니다. 이것을 너무 낮게 설정하면 대화에서 입술 움직임과 같은 동기화를 제거할 수 있고, 너무 높게 설정하면 npcs-dropping-dead-randomly 같은 버그가 발생할 수 있다. 나는 200을 타협으로 설정했습니다. 대화에서 프레임레이트가 5 미만으로 떨어지지 않는 한 입술이 동기화되지 않도록 해서는 안 됩니다. 그리고 당신이 5보다 낮은 프레임 속도로 파라우트를 재생하는 경우, 당신은 심각한 도움이 필요합니다.

Section: CriticalSections {}
이 섹션에서는 fsr이 fallouts critical_sections에 대한 모든 변경사항을 다루고 있습니다. critical_section 객체에 대해 알고 싶습니까? Fallout은 다양한 스레드가 실수로 서로를 죽이는 것을 방지하기 위해 그들을 사용합니다. 마이크로소프트는 그들을 위한 코드를 제공합니다. Fallout은 실행되는 윈도우의 어떤 버전에 따라 약간 다른 버전을 사용합니다. msdn에서 그들에 대해 자세히 읽을 수 있습니다.

CriticalSections\bEnableProfiling(기본값: 0)
1로 설정하면 fsr은 fallout에서 중요한 단면 작업의 타이밍/성능에 대한 정보를 기록합니다. 이렇게 하는 것은 성과에 적지만 중대한 처벌을 초래한다. fsr은 로그 파일에 정보를 기록합니다. 이것은 잠재적으로 유용한 정보를 생성할 수 있습니다. 왜 여러분의 물질이 말이거나 느리게 작동하는지에 대한 유용한 정보를 생성할 수 있습니다. 이 정보는 fsr ini 파일의 오버라이드 섹션을 조정하는 데 사용될 수 있습니다.

CriticalSections\bEnableMessages (기본값: 0)
1로 설정하면 fsr은 중요한 섹션의 일부 타이밍/성능 이벤트에 대한 정보를 기록합니다. 성능 비용은 매우 적지만, 로그 파일을 혼란스럽게 만들 수 있으며, 그곳에서 비핵심 단면의 정보를 찾기가 어렵습니다.

CriticalSections\bUseOverrides(기본값: 1)
이가 1로 설정된 경우 fsr은 ini의 재지정 섹션의 설정을 사용하여 특정 중요한 섹션에 대해 어떻게 해야 하는지 결정합니다.

CriticalSections\iDefaultMode(기본값: 2)
이렇게 하면 재지정 목록에 모드 항목이 없는 중요한 섹션에 fsr가 어떤 작업을 하는지 결정됩니다.
1: 그것은 거의 정상적인 행동에서 그 중요한 부분을 떠난다.
2: 처리량을 대가로 공평성을 향상시키기 위해 그 중요한 부분을 조정합니다. 이렇게 하면 스레드가 크리티컬 섹션을 너무 많이 호그하는 것을 방지할 수 있지만, 그 크리티컬 섹션을 사용하여 작업을 수행할 수 있는 순속도를 제공할 수 있습니다.
3: 공평성과 처리량 사이의 타협을 시도하는데, 일반적으로 처리량을 최적화하지만 가끔 동작을 전환하여 공평성을 최적화한다.
5: 그 임계 섹션이 억제됩니다. 중요한 부분을 억제하는 것은 일반적으로 물이 충돌하지만 일반적으로 성능을 향상시킨다. 그러나 특정 중요한 부분은 다른 영향을 받을 수 있다.
6: 메인 스레드가 그 중요한 섹션에 대한 우선순위를 얻는다.
7: 그 백그라운드 스레드는 그 중요한 섹션에 대한 우선순위를 얻습니다.

CriticalSections\iDefaultSpin(기본값: 500)
이것은 스레드가 중요한 섹션에 들어가려는 시도를 계속 시도하기 전에 그 중요한 섹션이 사용 가능할 때까지 스케줄러에 수면 시도를 요청하기 전에 얼마나 오래 걸리는지에 영향을 미칩니다. 이론적으로 너무 작은 값은 스케줄러 오버헤드를 너무 많이 발생시키고, 너무 큰 값은 CPU 사이클을 낭비시킨다. 500은 사실 작은 값이라고 생각합니다. 소유한 코어/하드웨어 스레드의 수에 따라 이상적인 값이 증가할 수 있습니다.

CriticalSections\iStutterLevel (기본값: 4)
이 매개변수는 임계 단면 모드 2가 동작을 전환하는 빈도에 영향을 미칩니다. 중요 섹션 모드 2에 대한 자세한 내용은 idefaultmode를 참조하십시오. 작은 숫자는 빈번한 스위치를 의미하고, 큰 숫자는 빈번한 스위치를 의미한다. 이상적인 값은 아마도 3에서 6의 범위 안에 있어야 한다.

Section: LightCriticalSections {}
이 섹션에서는 fsr이 critical_sections와 비슷한 목적을 제공하지만 더 가벼운 포로아웃 오브젝트 카테고리에 대한 모든 변경사항을 다루고 있습니다.

LightCriticalSections\bFullHooks(기본값: 0)
1로 설정하면 라이트 크리티컬 섹션 후크의 보다 완전한 버전이 켜집니다. 불행하게도, 보다 완전한 버전은 여전히 버그가 있기 때문에 현재 기본적으로 비활성화되어 있습니다.

LightCriticalSections\bEnableProfiling(기본값: 0)
1로 설정하면 fsr은 fallout에서 라이트 크리티컬 세그먼트 작업의 타이밍/성능에 대한 정보를 기록합니다. 이렇게 하는 것은 성과에 적지만 중대한 처벌을 초래한다. fsr은 로그 파일에 정보를 기록합니다. 이것은 잠재적으로 유용한 정보를 생성할 수 있습니다. 왜 여러분의 물질이 말이거나 느리게 작동하는지에 대한 유용한 정보를 생성할 수 있습니다. 이 정보는 fsr ini 파일의 오버라이드 섹션을 조정하는 데 사용될 수 있습니다.

LightCriticalSections\bEnableMessages (기본값: 1)
1로 설정하면 fsr은 라이트 크리티컬 섹션의 일부 타이밍/성능 이벤트에 대한 정보를 기록합니다. 성능 비용은 매우 적지만, 로그 파일을 혼란스럽게 만들 수 있으며, 그곳에서 비핵심 단면의 정보를 찾기가 어렵습니다.

LightCriticalSections\bUseOverrides(기본값: 1)
이가 1로 설정된 경우 fsr은 ini의 재지정 섹션의 설정을 사용하여 특정 중요한 섹션에 대해 어떻게 해야 하는지 결정합니다. 전체 lcs 후크(위의 bfullhooks)가 활성화되지 않는 한 재지정은 효과가 없습니다.

LightCriticalSections\iDefaultMode(기본값: 2)
이것은 재지정 목록에 모드 항목이 없는 중요한 섹션을 조명하는 데 fsr가 어떤 작업을 하는지 결정합니다. 그것은 크리티컬 섹션과 유사한 모드 번호 지정 시나리오를 사용하려고 합니다. 자세한 내용은 위의 criticalsections\idefaultmode를 참조하십시오. 일부 모드는 bfullhooks가 활성화되었는지 여부에 따라 상당히 다른 동작을 할 수 있습니다.

LightCriticalSections\iDefaultSpin(기본값: 500)
이것은 재지정 목록에 스핀 항목이 없는 중요한 섹션을 조명하는 데 fsr가 어떤 작업을 하는지 결정합니다. 그것은 중요한 섹션과 비슷한 의미를 가지려고 시도합니다. 자세한 내용은 위의 criticalsections\idefaultspin을 참조하십시오. spins 의미는 bfullhooks가 활성화되었는지에 따라 다소 다를 수 있습니다.

LightCriticalSections\iStutterLevel (기본값: 4)
이 매개변수는 라이트 임계 단면 모드 2가 동작을 전환하는 빈도에 영향을 미칩니다. 크리티컬 섹션 모드 2에 대한 자세한 내용은 idefaultmode를 참조하십시오. 작은 숫자는 빈번한 스위치를 의미하고, 큰 숫자는 빈번한 스위치를 의미한다. 이상적인 값은 아마도 3에서 6의 범위 안에 있어야 한다.


Section:Heap {}
이 물건들은 아직 실제로 작동하지 않습니다. 사용하지 마세요.

섹션: 해시테이블 {}
포로아웃에는 모든 종류의 사항을 찾기 위한 해시테이블의 무더기가 포함됩니다. 그들은 일반적으로 끔찍한 해시테이블 구현을 사용하지만, 진정한 문제는 해시테이블의 크기를 조정하지 않는다는 것이다. 해시테이블이 너무 많아지면 성능이 떨어진다. 해시테이블이 아래에 있다면 작은 메모리가 낭비되고 캐시 상관성이 떨어질 수 있습니다. 불행하게도, 해시테이블 코드의 대부분이 모든 곳에 내선되어 있으며, fose는 해시테이블에 대해서도 다양한 가정을 하고 있으며, 관련 스레딩 모델이 무엇인지 전혀 분명하지 않기 때문에 안전하게 변경하는 것은 상당히 어렵습니다. 그럼에도 불구하고, 저는 해시테이블 후크를 가지고 있습니다. 그것들은 점점 좋아지고 있습니다.

Hashtables\bAllowDynamicResizing(기본값: 0)
이것이 1로 설정되면 fsr은 해시테이블이 너무 많아지면 해시테이블의 크기가 커집니다. 그러나 크기를 조정하는 행동은 문제로 가득 차 있다. 그것은 충돌이나 고장을 일으킬 수 있다. 내가 그것을 방지하기 위해 사용하는 방법은 작은 성능의 말뚝이나 다른 충돌이나 고장을 일으킬 수 있다. 그럼에도 불구하고, 이 시점에서는 그것이 좀 잘 작동할 수 있다고 생각합니다.

Hashtables\bUseOverrides (기본값: 0)
현재는 해시테이블 재지정이 없으며, 그것들을 지정하는 구문은 어색하며, 잘못된 값을 입력하면 묵묵히 실패하고 대신 다른 일을 할 수 있다. 이것은 결국 수정되지만 ini-file 지정된 후크가 가장 중요한 해시테이블의 초기화에 접속되어 나중에 크기를 조정할 필요가 없이 적절한 크기로 시작할 수 있도록 허용됩니다.

Hashtables\bEnableProfiling(기본값: 0)
이렇게 하면 해시테이블을 모니터링하고 해시테이블이 얼마나 가득 차 있는지, 액세스할 수 있는지에 대한 정보를 로그합니다.

Hashtables\bEnableMessages (기본값: 0)
만약 이것이 1이라면 해시테이블 코드는 때때로 작업에 대한 메시지를 기록할 수 있습니다.

Hashtables\iHashtableResizeScale1(기본값: 2)
Hashtables\iHashtableResizeScale2(기본값: 4)
ballowdynamic 크기가 1인 경우 ihashtableresizescale1은 해시테이블의 크기가 조정되는 최소 점유 수준을 결정하고 ihashtableresizescale2는 새 크기가 얼마나 큰 것인지를 결정합니다. 두 숫자는 실제로 2에 적용되는 지수입니다. 그래서 3의 설정은 8의 계수이고 5의 설정은 32의 계수입니다. 이론적으로 ihashtableresizescale1을 1로 줄이면 더 많은 해시테이블의 크기를 늘리기 때문에 성능을 더 향상시킬 수 있다. ihashtableresizescale2는 ihashtableresizescale1보다 1 또는 2로 설정되어야 합니다.

Hashtables\iHashtableResizeDelay(기본값: 20)
이것은 해시테이블의 크기를 조정할 때 fsr이 정지할 수 있는 밀리초입니다. 다른 스레드가 해시테이블에 액세스하는 것을 막을 수 없지만 해시테이블에 액세스하는 것을 막을 수 있기를 바랍니다. 그래서 저는 충분히 오래 지연시켜 해시테이블에 접근한 누구든지 끝내고 제 일을 할 수 있을 겁니다. 불행하게도 fose에서는 작동하지 않습니다. 왜냐하면 fose는 fallout과 같은 일을 하지 않기 때문입니다. 게다가 그렇게 할 때에도 vtables를 사용하지 않기 때문입니다. 하지만 ATM 저는 fose가 메인 스레드에서만 액세스할 수 있다고 생각합니다. 그래서 제 크기 사이저가 메인 스레드에서 실행되면 fose에 대해 걱정할 필요가 없습니다. 아마도.

Section: 재지정 {}
이 섹션에는 fsr가 알고 있는 다양한 유형의 객체의 특정 인스턴스를 찾는 방법과 해당 유형의 객체의 기본 설정과는 다르게 해당 특정 인스턴스를 처리하는 방법을 fsr에 알려주는 정보가 들어 있습니다. 현재 여기에 실제로 나열된 것만이 대부분의 행동과 다른 몇 가지 특정 중요한 섹션입니다.



6. 버전 내역:
====================================

FPS Caper 버전 1:
이것은 fps capper라고 불렸습니다. 그것이 한 모든 것은 fps 관리뿐이었습니다. 이 버전은 수정된 obse dll 세트에 통합되었습니다.

FPS Caper 버전 2:
이것은 obse에서 분리된 자신의 dll을 가진 첫 번째 버전이었습니다. 이것은 fps capper라고 불렸습니다. 그것이 한 모든 것은 fps 관리뿐이었습니다.

잊어버린 말뚝을 제거하는 버전 3 베타 1:
최초의 버전은 Oblivion Sturter 제거기로 이름을 붙였다. 때때로 메인 메뉴에서 몇 분 동안 얼어붙는다. npc 음성과 얼굴의 움직임은 대화에서 망칠 수 있다.
버전 3 베타 2: npc 음성 및 얼굴 움직임은 대화에서 망칠 수 있습니다.

잊어버린 말뚝을 제거하는 버전 3 베타 6:
베타 5와 베타 6 사이에는 많은 알파 릴리스로 채워진 긴 지연이 있었다. 이것은 fsr의 첫 번째 버전이었고, 일반 사용자에게 말뚝을 줄이는 데 좋은 일을 했습니다. 이것은 새로운 기능 때문입니다: 중요한 단면 공평성 조정, 중요한 단면 억제, 더 바꾸기. 불행하게도 더 많은 사용자들에게 더 큰 문제가 있습니다. bfix64hertz는 ini에서 기본적으로 0으로 설정되었으며 대신 1이 되어야 합니다.

참고: 버전 3 최종 결과가 없었습니다. 만약 충분한 수요가 있다면, 나는 버전 3 베타 6 소스 코드를 기반으로 몇 가지 수정과 함께 하나를 만들 수 있다.

발물 말이기 제거기 버전 1 베타 1:
osr의 초기 포트는 낙하물로 나타납니다.

잊어버리기/발물 말이기 제거기 버전 4.1.0:
주요 변경 사항:
1.같은 코드 데이터베이스에서 Follout& Oblivion 둘 다 지원합니다.포로아웃 3에 많은 이점을 제공하지 않지만, 도움이 됩니다.
2.. ini 파일: 완전히 다른 ini 파일 형식
3.해시테이블 크기 조정: 성능 향상을 위한 새로운 기능
4.임계 단면 및 라이트 임계 단면:중요한 섹션에 대한 많은 특수 사례를 일반화했고, 이제 ini 파일에서 훨씬 더 조정할 수 있습니다. 라이트 크리티컬 코드의 "전체 후크"는 여전히 버그입니다.
5.더 바꾸기: 몇 가지 버그를 수정했지만, 여전히 문제가 있다고 생각합니다. 여전히 낙하물에 대해 전혀 작동하지 않습니다.
6.버전 이름:tesnexus에 출시된 버전은 이제 베타 버전이 아닌 릴리스 버전이라고 불립니다. 내 ftp 서버에 출시된 버전은 이제 알파 버전이 아니라 베타 버전이라고 불립니다. 버전 번호의 첫 번째 자릿수는 구성 또는 배포 형식에 주요 변경이 있을 때만 증가합니다. 버전 번호의 두 번째 자릿수는 각 릴리스 버전마다 증가됩니다. 버전 번호의 세 번째 자릿수는 베타 버전마다 한 번씩 증가합니다. 자릿수가 증가할 때마다 오른쪽의 모든 자릿수가 0으로 재설정됩니다.




7. 이것이 어떻게 작동하는지:


이것은 fose 플러그인 dll입니다. 그것은 기본적으로 후퇴를 해킹합니다.

7.1: fps 관리:
fps 관리 코드는 프레임 속도를 모니터링하고 게임 시간 흐름을 조정합니다. 이것은 게임 논리가 더듬을 때 앞으로 건너뛰지 않도록 함으로써 더듬을 완화시킨다. 효과적으로, 오랜 시간이 걸리는 프레임은 슬로모션으로 나타납니다. 이것은 ifpsclamp가 minimumfps로 설정된 것처럼 fallout를 작동시키는 것으로 수행되지만 minimumfps보다 느린 프레임에만 해당합니다. 이것은 또한 안정성을 향상시킬 수 있다. 그것은 또한 최대 프레임 속도를 강요할 수 있다. 어떤 사람들은 프레임 속도가 새로 고침 속도의 절반을 초과하지 않는 것을 방지할 때 파라우트가 더 부드럽다고 생각하며, 게다가 이것은 파라우트 보조 스레드에 대한 리소스를 자유롭게 하는 데 도움이 된다.

fps 관리 코드는 또한 일부 사람들의 말뚝을 개선하기 위해 짧은 시간 동안 포로라우트의 메인 스레드를 잠들 수 있습니다(이 플러그인이 하는 다른 일로 인해 기능이 불필요하게 만들어질 수 있음에도 불구하고).

7.2: 중요한 섹션:
크리티컬 섹션은 마이크로소프트가 제공하는 스레드 동기화 요소이며, fallout은 스레드가 실수로 서로 손상되지 않도록 내부적으로 사용합니다. 기본적으로 fsr은 대부분의 중요한 섹션이 처리량을 대가로 공정하게 재생하려고 시도하므로 다른 스레드가 필요로 하는 리소스를 스레드가 호그하지 않는다는 것을 확인합니다. 그러나 한 개의 특정 임계 섹션은 약간 공평하지 않은 방법을 사용하기 위해 재정의되고, 다른 특정 임계 섹션은 전혀 효과가 없도록 억제됩니다. 이 모든 것은 ini 파일에서 매우 구성할 수 있습니다. 또한 스핀카운트가 무너지게 됩니다.

7.3: 더 바꾸기:
이 기능은 아직 Fallout 3에서 제대로 작동하지 않습니다.

7.4: 해시테이블:
포로아웃에는 모든 종류의 사물을 찾기 위한 해시테이블의 무더기가 포함됩니다. 그들은 일반적으로 끔찍한 해시테이블 구현을 사용하지만, 진정한 문제는 해시테이블의 크기를 조정하지 않는다는 것이다. 해시테이블이 너무 많아지면 성능이 떨어진다. 해시테이블이 아래에 있다면 작은 메모리가 낭비될 수 있습니다. 불행하게도, 해시테이블 코드의 대부분이 모든 곳에 내선되어 있으며, fose는 해시테이블에 대해서도 다양한 가정을 하고 있으며, 관련 스레딩 모델이 무엇인지 전혀 분명하지 않기 때문에 안전하게 변경하는 것은 상당히 어렵습니다.

그럼에도 불구하고, 저는 해시테이블 후크를 가지고 있습니다. 그것들은 점점 좋아지고 있습니다. fsr은 해시테이블이 너무 많아지면 크기를 늘릴 수 있습니다. 그러나 크기를 조정하는 행동은 문제로 가득 차 있다. 그것은 충돌이나 고장을 일으킬 수 있다. 내가 그것을 방지하기 위해 사용하는 방법은 작은 성능의 말뚝이나 다른 충돌이나 고장을 일으킬 수 있다. 그럼에도 불구하고, 이 시점에서 나는 그것이 좀 잘 작동할 수 있다고 생각한다. 앞으로 나는 특정 해시테이블의 초기 크기를 재정의하는 것으로 이것을 대체하거나 추가할 수 있다.


====================================
8. 학점:
====================================

이 플러그인은 제가 만들었습니다 (Christopher Doty-Humphrey).

포스 팀의 엄청난 노력 없이는 그럴 수 없었을 것이다. 게다가, 이안 패터슨(fose 팀의 사람)은 내가 많은 문제를 겪었던 곳을 통과할 수 있도록 도와주었다.

이 플러그인을 시작하도록 제가 촉구한 원래 스레드는 deviuscreed에 의해 시작되었습니다.

많은 테스터들이 유용한 피드백을 제공했습니다. 특히 어떤 설정이 그를 위해 어떤 결과를 만들었는지에 대한 마샤니의 정보는 왜 초기 버전이 예상치 못한 이점을 만들었는지 이해하는 데 도움이 되었고, 후기 버전의 기능과 설정의 수를 이끌었습니다.

저는 또한 badhair에 감사드리고 싶습니다. 너무 가득 찬 해시테이블을 성능 문제의 원인으로 가리키고 있습니다.

이 플러그인의 생산에 다음과 같은 도구가 사용되었습니다.
잊어버리기/낙태, by Bethesda
OBSE/fose 및 OBSE/fose 소스 코드
마이크로소프트 비주얼 c++ 2008 익스프레스 에디션
IDA Free (인터랙티브 디버거, 무료 버전, 버전 4.9)
cheat 엔진(버전 5.4)
윈도우 xp, 노트패드, 파이어폭스와 같은 명백한 물건들과 함께.

Oblivion/fallout 및 Windows xp를 제외하고, 이 모든 것은 무료로 사용할 수 있습니다.

나는 또한 Hex 워크샵과 ollydbg가 나에게 추천했지만 아직 시도하지 못했다.