Radiation Baygaiement Remover

Radiation Baygaiement Remover
Version 4.0.7
SkyRanger-1

Sujet du forum: http://www.bethsoft.com/bgsforums/index.php? showtopic=1069833
Page TESnexus: http://www.fallout3nexus.com/downloads/file.php? id=8886

Il s'agit d'un plugin FOSE qui fonctionne uniquement avec FOSE 1.2 bêta 1 ou version ultérieure.

Cela fonctionne uniquement avec la version 1.7 de Fallout 3.




0. Contenu:
====================================

0. Contenu
1. Aperçu général
2. Installation
3. Désinstallation
4. Modifications communes des paramètres
5. Tous les paramètres
6. Historique des versions
7. Comment ça fonctionne
8. Crédits



I. Généralité:


Ce plugin rend Fallout 3 moins "bégayant" et se sent généralement plus fluide ou mieux performant. Il peut empêcher ou atténuer de nombreux problèmes liés au bégaiement et à la fréquence d'images et peut réduire la fréquence des pannes liées au bégaiement. Pour plus de détails, voir rubrique 7: Comment cela fonctionne.

Notez toutefois que cela ne corrige généralement aucun problème avec vos pilotes, matériel ou codecs-si vous avez une cause profonde de mauvaise performance, cela ne vous aidera probablement pas beaucoup.

Il s'agit d'un port du dispositif d'élimination du bégaiement oublié (OSR) pour le rayonnement. Jusqu’à présent, il n’est pas aussi efficace que l’éliminateur de bégaiement d’oubli original, mais il devrait aider.

Cela devrait être compatible avec tout. La seule chose à noter est que les mods qui surveillent le FPS ne mesureront pas avec précision le FPS en dehors de la plage cible définie par ce plugin (10 à 30 par défaut). En effet, même les FPSE qui ne sont que proches de la cible FSR peuvent être difficiles à mesurer.



2. Installation:
====================================

Le processus d'installation est:

1.A. Si la version de FSR que vous installez est un fichier. zip, faites glisser simplement le dossier "Données" du fichier zip vers votre dossier oublié.

1.B. Si la version de FSR que vous installez n'est pas un fichier. zip, alors vous devez placer le fichier sr_Fallout_Stutter_Remover.dll dans le dossier Fallout\Data\fose\plugins. Si vous n'avez pas un tel dossier, créez-le. Si une ancienne version de FSR est installée, supprimez son fichier ini (Data\fose\plugins\sr_Fallout_Stutter_Remover.ini). S'il n'y a pas de fichier ini FSR existant, FSR générera un nouveau fichier ini avec les paramètres adaptés à votre version la prochaine fois que Fallout sera exécuté.



3. Désinstallation:


Il suffit de supprimer le fichier sr_Fallout_Stutter_Remover.dll du dossier Data\fose\plugins.
Il suffit également de déplacer ce fichier dans un autre répertoire.



4. Modifications communes des paramètres
====================================

D'une manière générale, FSR essaie d'avoir des paramètres par défaut décents afin que les utilisateurs n'aient pas à jouer avec eux. Cependant, dans certains paramètres, les valeurs par défaut peuvent ne pas vous convenir, soit parce que les valeurs par défaut ne correspondent pas à vos goûts, soit parce que FSR fait de mauvaises hypothèses sur votre ordinateur.

FSR enregistre ses paramètres dans le fichier Data\fose\plugins\sr_Fallout_Stutter_Remover.ini
Si le fichier n'existe pas, il suffit de démarrer Fallout avec FSR installé et FSR générera un nouveau fichier avec les paramètres par défaut pour votre version de FSR. Si vous avez fait une erreur dans vos paramètres ou si vous voulez revenir aux paramètres par défaut, il suffit de supprimer ce fichier ini et de lancer Fallout.

Vous trouverez des informations générales sur les paramètres dans la section 5, ainsi que des informations plus complètes sur chaque paramètre individuel.

Les paramètres que vous souhaitez probablement modifier sont les suivants:

FPS_Management\MaximumFPS: (par défaut 30, envisagez de changer à 0 ou une autre valeur)
Certaines personnes ne veulent pas du tout limiter leur fréquence d'images. Vous pouvez désactiver la limite FPS en la définissant sur 0. De plus, si le taux de rafraîchissement de votre écran lorsque vous jouez avec Fallout n'est pas de 60 Hz, vous pouvez essayer de le changer à votre taux de rafraîchissement de votre écran, soit à la moitié du taux de rafraîchissement de votre écran, soit à un tiers du taux de rafraîchissement de votre écran. Si Master\bManageFPS est modifié à 0, ce paramètre ne sera pas valide.

Hashtables\bAllowDynamicResizing: (0 par défaut, considérez le changer à 1)
L’activation de ceci améliore considérablement les performances/FPS globales des jeux très modifiés. Malheureusement, cela peut entraîner des conditions de course et une confusion générale, surtout lorsque les scripts utilisant certaines commandes fose s'exécutent à chaque image. J'ai essayé de réduire les chances que quelque chose ne tourne pas mal à zéro, mais... Cela pourrait nécessiter plus de travail. Dans le même temps, cette fonction est désactivée par défaut. Si Master\bHookHashtables est modifié à 0, ce paramètre n'a pas d'effet.

Inhibition du secteur critique: (spécial)
Par défaut, le FSR supprime une partie critique spécifique sans laquelle le rayonnement semble fonctionner mieux. Il y a une autre partie critique connexe, certains utilisateurs semblent être capables de supprimer sans causer de problèmes, mais d'autres utilisateurs rencontrent des CTD ou d'autres problèmes sur la transition interne-> externe lorsqu'ils suppriment. Cela ne produira qu'une petite amélioration dans le bégaiement, donc je ne recommande généralement pas de le supprimer, mais vous pouvez si vous voulez. Pour le supprimer, trouvez la ligne dans le fichier ini qui dit "CallerAddress = 0x70172A" et ajoutez une nouvelle ligne qui dit "Mode = 5" après elle. Notez que les cas sont importants là-bas... Cela devrait être "mode", pas "mode". Ce paramètre n'est pas valide si Master\bHookCriticalSections ou CriticalSections\bUseOverrides est défini à 0.
Remarque: la partie barrée directement au-dessus du fichier README est destinée à oublier, pas à rayonner; Il y a un équivalent pour le rayonnement, mais je n'ai pas encore trouvé sa valeur exacte. Ignorez cela pour l'instant.



5. Tous les paramètres
====================================

FSR enregistre ses paramètres dans le fichier Data\fose\plugins\sr_Fallout_Stutter_Remover.ini
Si le fichier n'existe pas, il suffit de démarrer Fallout avec FSR installé et FSR générera un nouveau fichier avec les paramètres par défaut pour votre version de FSR. Si vous avez fait une erreur dans vos paramètres ou si vous voulez revenir aux paramètres par défaut, il suffit de supprimer ce fichier ini et de lancer Fallout.

Veuillez noter que le format des fichiers ini de FSR varie d'une version majeure de FSR-vous ne devez pas utiliser les fichiers ini de la version 1 de FSR avec la version 2 de FSR, etc. Dans FSR 2, les fichiers ini sont organisés en sections comme "SectionName {SettingName=Value}". Un paramètre particulier peut être appelé SectionName\SettingName pour le distinguer des autres paramètres portant le même nom dans différentes sections. D'une manière générale, les paramètres dont le nom commence par "i" sont des valeurs entières (c'est-à-dire des nombres sans virgule), les paramètres dont le nom commence par "b" sont des valeurs booléennes (c'est-à-dire 0 ou 1) et les paramètres commençant par "f" sont des nombres susceptibles d'avoir une virgule (c'est-à-dire 3,14). Certains paramètres ne commencent pas par l'une de ces lettres, auquel cas il peut ne pas être clair quel est le type de valeur correct.

Voici les paramètres et leurs valeurs par défaut actuelles (qui peuvent ne pas être 100% à jour):

Section: maître {}
Cette section contient une option pour désactiver chacun des principaux sous-systèmes du FSR, ainsi que certains paramètres qui ne font partie d'un sous-système particulier du FSR.

Master\bManageFPS (valeur par défaut: 1)
En définissant cette valeur à 0, tout le contenu de gestion FPS sera désactivé, rendant chaque paramètre de la section FPS_Management inutile.

Master\bHookCriticalSections (valeur par défaut: 1)
Le définir à 0 désactivera tout le contenu des sections critiques, rendant chaque réglage dans la section CriticalSections sans sens.

Master\bHookLightCriticalSections (valeur par défaut: 1)
La mise sur 0 désactivera le contenu de toutes les sections LightCriticalSections, rendant chaque réglage de la section LightCriticalSections inutile.

Master\bHookHashtables (valeur par défaut: 1)
Le définir à 0 désactivera tout le contenu de la table de hachage, rendant chaque réglage dans la section CriticalSections sans sens.

Master\bReplaceHeap (valeur par défaut: 0)
Le réglage à 1 permet de permettre le remplacement du tas, ce qui donne un sens aux réglages dans la section du tas.

Master\bLogToConsole (valeur par défaut: 0)
Le FSR enregistre diverses informations dans ses fichiers journaux. Si vous changez ce paramètre à 1, FSR imprimera également ces informations sur la console.
Le fichier journal est sr_Fallout_Stutter_Remover.log dans le répertoire Fallout. Il est créé ou écrasé à chaque fois qu'un rayonnement sur lequel un FSR est installé.

Master\bFix64Hertz (valeur par défaut: 1)
Régler ceci à 1 corrige un problème dans le rayonnement qui provoque un « micro-bégaiement ». Ce problème est parfois appelé le « problème 64 Hz ». Plus précisément, le problème est que le rythme logique du jeu Fallout se produit généralement à une résolution de 1/64 de seconde, et lorsque la vsync est limitée, le taux de rafraîchissement de l'écran permet généralement à Fallout de dessiner 60 images par seconde. Lorsque la fréquence d'images atteint son maximum, cette combinaison produit une fréquence de battement dans laquelle le temps de jeu de 4 images par seconde est deux fois supérieur à 56 images. Le rayonnement forcé de réparation appliqué par FSR utilise le temps avec une résolution de 1/1000 de seconde au lieu de 1/64 de seconde.

Master\bFlushLog (valeur par défaut: 1)
Cela dit à FSR d'écrire immédiatement tous les messages de journal dans son fichier au lieu de les mettre en mémoire tampon. Il peut ralentir légèrement les performances en raison du nombre élevé d'accès au disque, mais il rend plus probable que tout message lié à un problème survenu peu avant le crash soit écrit avec succès dans le fichier journal.

Master\iSchedulingResolution (valeur par défaut: 1)
FSR demandera au planificateur Windows de s'exécuter avec une résolution de tant de millisecondes. Le FSR et le rayonnement fonctionnent généralement mieux lorsque cela est réglé à 1. Cependant, cela peut réduire légèrement la durée de vie de la batterie de votre ordinateur portable.

Chapitre: FPS_Gestion {}
Cette section contient des paramètres qui ajustent la façon dont FSR gère votre fréquence d'images et votre flux de temps de jeu.

FPS_Management\bAllowSlowMotion (valeur par défaut: 1)
La mise sur 0 empêchera le FSR d'essayer d'écraser le flux normal de temps de jeu. Dans le passé, le FSR en faisant cela entraînait quelques bugs (le plus notoire étant un bug de conversion de cellules mortes des PNJ à proximité), mais ceux-ci sont maintenant considérés comme réparés. Au cas où vous soupçonnez qu'il pourrait y avoir un problème, vous pouvez forcer la désactivation de tous les ajustements du temps de jeu FSR avec ce paramètre. Malgré son nom, le mettre à 0 empêche également FSR d'avancer rapidement le temps de jeu, bien que FSR n'essaie de le faire que dans des combinaisons très rares de paramètres et d'environnements.

FPS_Management\MaximumFPS (valeur par défaut: 30)
Il s’agit du FPS maximum que le FSR ne permet pas de rayonner. Je le régle généralement sur une fréquence d'images suffisamment élevée pour que je ne me soucie pas trop des images supplémentaires par seconde. Notez que FSR ne traite pas vraiment ici de "images par seconde", mais plutôt convertit cette valeur en millisecondes par image et considère chaque image individuellement. Si une trame est terminée trop rapidement, alors FSR entraînera le thread principal rayonnant dans l'état de veille jusqu'à ce que le bon nombre de millisecondes s'écoule. La mise en veille du thread principal de Fallouts permet de libérer des ressources pour les threads en arrière-plan de Fallouts ou d'autres programmes qui peuvent s'exécuter en arrière-plan. Si rien ne veut utiliser des ressources supplémentaires, alors votre CPU et/ou GPU fonctionnera plus froidement et consommera moins d’énergie.

FPS_Management\MinimumFPS (valeur par défaut: 10)
Il s'agit du FPS le plus bas auquel le FSR ne permet pas de rayonner. Cependant, il ne s'agit pas de traiter de secondes réelles, mais de secondes de temps de jeu. Ainsi, si votre ordinateur est vraiment lent, vous pouvez toujours avoir un FPS de 1, mais cela ralentira le temps de jeu à 10% du temps normal, de sorte que le temps de jeu est toujours au moins 10 images par seconde. Tous les chiffres sont seulement des exemples, basés sur le réel FPS de 1 et le paramètre minimum FPS de 10 (valeur par défaut). Notez également que, comme MaximumFPS, cela fonctionne en fait sur une seule image, traitant du nombre de millisecondes par image plutôt que du nombre d'images par seconde.
Je le définis généralement sur un FPS inférieur que je sens pouvoir jouer à distance. Le plus grand objectif de ce paramètre est d'éviter que la logique de jeu Fallout ne devienne folle lorsque le FPS est trop bas. Les problèmes que cela empêche comprennent des combats impossibles parce que les ennemis peuvent courir autour de vous entre les images, des contrôles gâchés parce que Fallout pense que la touche d'attaque est désactivée pendant toute l'image ou n'est pas désactivée pendant toute l'image, ce qui peut entraîner une attaque puissante lors de l'intention d'attaquer, et beaucoup d'autres problèmes similaires.

FPS_Management\iSmoothFrames (valeur par défaut: 0)
Si cela est défini à 0, la logique de "lissage" ne fait rien. Pour activer la logique de lissage, essayez de la définir sur 2. Toutefois, les rapports montrent que la logique de lissage n'a pas beaucoup de valeur. La logique de lissage est conçue pour éviter divers problèmes causés par le bégaiement et d'autres changements rapides de fréquence d'images. Si bAllowSlowMotion est 0, la logique de lissage ne fonctionnera pas.

FPS_Management\iSmoothMode (valeur par défaut: 0)
Cela devrait être 0, 1, 2 ou 3. S'il est 0 ou 1, alors il activera une logique supplémentaire pour tenter de filtrer les événements de bégaiement du flux temporel. Cette logique peut conduire à une quantité totale de temps de jeu qui ne soit pas exactement égale à la quantité totale de temps réel si le FPS diminue brusquement. S'il est 2 ou 3, alors les bits logiques supplémentaires sont désactivés. La différence entre 0/2 et 1/3 est une question très délicate, c'est-à-dire quelles trames redistribuent le temps entre elles et comment.

FPS_Management\iSleepExtra (valeur par défaut: 2)
Le FSR forcerait le rayonnement à dormir autant de millisecondes par seconde. Cela permet de libérer des ressources pour les threads en arrière-plan ou d'autres processus, ou de réduire légèrement la température et la consommation d'énergie des composants de l'ordinateur. L'avantage principal est que si un thread en arrière-plan est en train de récupérer une ressource spécifique occupée par le thread principal, cela peut lui donner la possibilité de récupérer cette ressource de temps en temps.
Si cela est réglé à -1, alors le code de gestion FSR FPS ne laissera jamais le rayonnement dormir-si le FPS dépasse le FPS maximum, alors le FSR perdra du temps dans la boucle d'inactivité. Ce mode n'est pas recommandé car il est utilisé uniquement à des fins de test.

FPS_Management\bFPSConsoleSPAM (valeur par défaut: 0)
Il en résultera que le FSR enregistre le temps nécessaire pour terminer chaque trame. Il sera exécuté une fois par trame, ce qui génère un temps d'enregistrement important.

FPS_Management\iSchedulingParanoia (valeur par défaut: 1)
Ce réglage est exprimé en millisecondes. Il détermine le degré de paranoïa du code MaximumFPS vis-à-vis du planificateur. Si cette valeur est élevée, alors le code MaximumFPS ne dormirait jamais, mais perdrait du temps dans une boucle inactive. Si la valeur est 0, le code MaximumFPS fait confiance au planificateur pour reprendre l'exécution du thread principal au moment entièrement demandé. En général, je fais un compromis au point 1 car je suis un peu paranoïaque sur les planificateurs, mais laisse quand même beaucoup de temps libre être utilisé de manière constructive.

FPS_Management\iHardMaxFrametime (valeur par défaut: 200)
Ceci est en millisecondes. Les gens ont découvert que des choses étranges se produisent lorsque mon code d'ajustement du flux temporel met trop de temps au mauvais moment. Mauvaises choses. Comme, les PNJ du quartier meurent au hasard. Ce réglage empêche cela en fixant au maximum absolu le nombre de millisecondes que le FSR autorise à passer dans un processus normal. Normalement, vous atteindrez le FPS minimum avant d'atteindre cette limite, mais dans certains cas, le FPS minimum est renoncé pour éviter les effets secondaires tels que les mouvements des lèvres qui ne sont pas synchronisés avec le son, donc c'est le deuxième niveau du FPS minimum, et je suis vraiment le FPS minimum. Une valeur trop faible peut entraîner une désynchronisation des mouvements des lèvres dans la conversation, et une valeur trop élevée peut entraîner des erreurs telles que la mort aléatoire des PNJ. Je prends 200 comme un compromis-il ne devrait pas provoquer une désynchronisation des lèvres, à moins que votre fréquence d'images ne tombe en dessous de 5 dans la conversation. Si vous jouez à Fallout à une fréquence d'images inférieure à 5, alors vous avez besoin d'une vraie aide.

Section: Section clé {}
Cette section décrit toutes les modifications apportées par FSR à Fallouts CRITICAL_SECTIONs. Vous voulez connaître l'objet CRITICAL_SECTION? Radiation les utilise pour empêcher ses différents fils de se tuer accidentellement. Microsoft leur fournit le code. Fallout utilise une version légèrement différente en fonction de la version de Windows sur laquelle il fonctionne. Vous pouvez en lire plus sur MSDN.

CriticalSections\bEnableProfiling (valeur par défaut: 0)
S'il est réglé à 1, le FSR enregistre des informations sur le temps et le rendement des opérations de la partie critique du rayonnement. Ce faisant aura un impact mineur mais important sur les performances. Le FSR enregistrera les informations dans ses fichiers journaux. Cela peut produire des informations utiles sur la raison pour laquelle votre radiation bégaie ou fonctionne lentement. Ces informations peuvent être utilisées pour ajuster la partie écrasée ou autre du fichier ini FSR.

CriticalSections\bEnableMessages (valeur par défaut: 0)
S'il est réglé à 1, le FSR enregistre des informations sur certains événements de temporisation/performances pour les sections critiques. Le coût de performance de cela est faible, mais cela encombrera le fichier journal et rend plus difficile la recherche de parties non critiques d'informations.

CriticalSections\bUseOverrides (valeur par défaut: 1)
Si cela est défini à 1, alors FSR utilisera les paramètres dans la section Overlay de ini pour déterminer ce qu'il faut faire pour une section critique spécifique.

CriticalSections\iDefaultMode (valeur par défaut: 2)
Ceci détermine comment le FSR traite les parties critiques qui n'ont pas d'entrée de schéma dans la liste de couverture.
1: Il met la partie critique dans un comportement approximativement normal.
2: Il ajuste les sections critiques au détriment du débit pour améliorer l'équité. Cela peut empêcher un thread d'occuper trop la section critique, mais le taux net peut être utilisé pour terminer les opérations avec cette section critique.
3: Tentative de compromis entre équité et débit, où il est souvent optimisé pour le débit, mais parfois commute le comportement pour optimiser l'équité.
5: la zone critique est supprimée. La suppression des parties critiques entraîne généralement un effondrement du rayonnement, mais elle améliore généralement également les performances. Toutefois, certains éléments clés pourraient être affectés de manière différente.
6: Le thread principal obtient la priorité de cette section critique.
7: Le thread arrière-plan obtient la priorité de cette section critique.

CriticalSections\iDefaultSpin (valeur par défaut: 500)
Cela affecte combien de temps un thread essaie d'entrer dans une section critique avant de demander au planificateur de le mettre en veille jusqu'à ce que la section critique devienne disponible. En théorie, une valeur trop petite entraînera une surcharge excessive du planificateur, tandis qu'une valeur trop grande entraînera un gaspillage de cycles CPU. Je pense que 500 est en fait une très petite valeur. La valeur idéale peut augmenter à mesure que le nombre de noyaux/threads matériels augmente.

CriticalSections\iStutterLevel (valeur par défaut: 4)
Ce paramètre affecte la fréquence du comportement de commutation du mode 2 de la section critique. Pour plus d'informations sur le mode de section critique 2, consultez iDefaultMode. Les chiffres plus petits indiquent des commutations fréquentes et les chiffres plus grands indiquent des commutations moins fréquentes. La valeur idéale devrait être comprise entre 3 et 6.

Section: LightCriticalSections {}
Cette section décrit toutes les modifications apportées par FSR à une classe d'objets rayonnants qui ont un usage similaire à CRITICAL_SECTIONs, mais sont plus légers.

LightCriticalSections\bFullHooks (valeur par défaut: 0)
Si elle est réglée à 1, cela ouvre une version plus complète du crochet de section critique légère. Malheureusement, la version plus complète est toujours défectueuse, donc elle est actuellement désactivée par défaut.

LightCriticalSections\bEnableProfiling (valeur par défaut: 0)
S'il est réglé à 1, le FSR enregistre des informations sur le rythme/les performances du fonctionnement de la zone critique légère dans le rayonnement. Ce faisant aura un impact mineur mais important sur les performances. Le FSR enregistrera les informations dans ses fichiers journaux. Cela peut produire des informations utiles sur la raison pour laquelle votre radiation bégaie ou fonctionne lentement. Ces informations peuvent être utilisées pour ajuster la partie écrasée ou autre du fichier ini FSR.

LightCriticalSections\bEnableMessages (valeur par défaut: 1)
S'il est réglé à 1, le FSR enregistre des informations sur certains événements de temporisation/performances pour la section critique légère. Le coût de performance de cela est faible, mais cela encombrera le fichier journal et rend plus difficile la recherche de parties non critiques d'informations.

LightCriticalSections\bUseOverrides (valeur par défaut: 1)
Si cela est défini à 1, alors FSR utilisera les paramètres dans la section Overlay de ini pour déterminer ce qu'il faut faire pour une section critique spécifique. L'écrasement n'aura aucune validité à moins que le crochet LCS complet (bFullHooks ci-dessus) soit activé.

LightCriticalSections\iDefaultMode (valeur par défaut: 2)
Ceci détermine comment le FSR éclaire les parties critiques de la liste de couverture qui n'ont pas d'entrée de mode. Il essaie d'utiliser un schéma de numérotation similaire à celui des sections critiques-voir CriticalSections\iDefaultMode ci-dessus pour plus d'informations. Selon que bFullHooks est activé ou non, certains modes peuvent se comporter différemment.

LightCriticalSections\iDefaultSpin (valeur par défaut: 500)
Ceci détermine comment le FSR éclaire les parties critiques de la liste de couverture qui n'ont pas d'entrée de rotation. Il essaie d'avoir une signification similaire à celle d'une section critique-voir CriticalSections\iDefaultSpin ci-dessus pour plus d'informations. Selon que bFullHooks est activé ou non, la signification de la rotation peut varier.

LightCriticalSections\iStutterLevel (valeur par défaut: 4)
Ce paramètre influence la fréquence du comportement de commutation du mode 2 de la section critique légère. Pour plus d'informations sur le mode de section critique 2, consultez iDefaultMode. Les chiffres plus petits indiquent des commutations fréquentes et les chiffres plus grands indiquent des commutations moins fréquentes. La valeur idéale devrait être comprise entre 3 et 6.


Partie: tas {}
Ce truc ne fonctionne pas encore contre les radiations. Ne pas utiliser.

Section: Tableau de hachage {}
Fallout comprend un ensemble de tables de hachage utilisées pour trouver une variété de contenus. Ils utilisent une implémentation généralement mauvaise de la table de hachage, mais le vrai problème est qu'ils ne redimensionnent jamais la table de hachage. Lorsque la table de hachage est trop pleine, les performances se dégradent. Si la table de hachage est insuffisante, alors un peu de mémoire peut être gaspillée et la cohérence du cache peut diminuer. Malheureusement, une grande partie du code de la table de hachage est en ligne partout, et FOSE fait diverses hypothèses sur la table de hachage, et je n'ai aucune idée claire de ce que devrait être le modèle de threading pertinent, donc il est assez difficile de les modifier en toute sécurité. Néanmoins, j'ai quelques crochets de table de hachage et ils s'améliorent progressivement.

Hashtable\bAllowDynamicResizing (valeur par défaut: 0)
Si vous le définissez à 1, alors FSR augmentera leur taille dès que les tables de hachage sont trop pleines. Cependant, le comportement de leur redimensionnement est plein de problèmes-il peut entraîner des plantages ou des dysfonctionnements, et la méthode que j'utilise pour l'empêcher de le faire peut entraîner de petites interruptions de performance ou autres plantages ou dysfonctionnements. Néanmoins, à ce stade, je pense que cela pourrait fonctionner un peu décemment.

Hashtable\bUseOverrides (valeur par défaut: 0)
Il n'y a actuellement aucune réécriture de la table de hachage, la syntaxe pour les spécifier est maladroite, et si une mauvaise valeur est saisie, il y a le risque d'échouer silencieusement et d'effectuer d'autres opérations. Cependant, cela sera finalement résolu en permettant aux hooks spécifiés par le fichier ini d'entrer dans l'initialisation des tables de hachage les plus importantes, de sorte qu'elles commencent avec une taille appropriée au lieu de devoir être redimensionnées ultérieurement.

Hashtable\bEnableProfiling (valeur par défaut: 0)
Cela surveillera les tables de hachage et enregistrera des informations sur leur pleine et combien ils ont été consultés.

Hashtable\bEnableMessages (valeur par défaut: 0)
Si c’est 1, alors le code de la table de hachage peut occasionnellement enregistrer des messages sur ce qu’il fait.

Hashtable\iHashtableResizeScale1 (valeur par défaut: 2)
Hashtable\iHashtableResizeScale2 (valeur par défaut: 4)
Si bAllowDynamicResizing est 1, iHashtableResizeScale1 déterminera le niveau d'occupation minimum pour le redimensionnement de la table de hachage et iHashtableResizeScale2 déterminera combien sa nouvelle taille sera plus grande. Ces deux chiffres sont en fait des exponents appliqués à 2, de sorte que la mise en 3 signifie un facteur de 8 et la mise en 5 signifie un facteur de 32. En théorie, réduire iHashtableResizeScale1 à 1 pourrait améliorer encore les performances, car cela augmentera la taille de la table HashtableResizeScale1. ihasTableResizeScale2 devrait probablement être défini de 1 ou 2 plus que ihasTableResizeScale1.

Hashtable\ihashtableSizeDelay (valeur par défaut: 20)
C'est le nombre de millisecondes pendant lesquelles le FSR sera suspendu lors de la redimensionnement de la table de hachage. L'idée est que même si je ne peux pas empêcher un autre thread d'accéder à la table de hachage pendant que je suis occupé, je peux, espérons-le, les empêcher de *commencer* à accéder à la table de hachage. Donc j'ai retardé assez longtemps que peut-être, peut-être, quiconque a déjà accédé à la table de hachage finira, et alors je fais mon truc. Malheureusement, cela ne fonctionne pas sur FOSE, car FOSE ne fait pas ce que Fallout fait, et même s'il le fait, il n'utilise pas vtables pour faire ces choses. Mais atm je pense que FOSE peut accéder à eux uniquement depuis le thread principal, donc si mon resizer s'exécute dans le thread principal, alors il n'a pas à s'inquiéter de FOSE. Peut-être.

Section: Couvrir {}
Cette section contient des informations indiquant à FSR comment trouver des instances spécifiques des différents types d'objets que FSR connaît et comment différencier ces instances spécifiques des paramètres par défaut pour ce type d'objet. Pour le moment, il n'y a que quelques sections clés spécifiques répertoriées ici qui se comportent différemment de la plupart.



6. Historique des versions:
====================================

FPS Capper Version 1:
Ceci est appelé une machine de capsulage FPS. Tout ce qu’il fait, c’est la gestion du FPS. Cette version est intégrée à un ensemble modifié de DLL OBSE.

FPS Capper Version 2:
C’est la première version à avoir une dll indépendante d’OBSE. Ceci est appelé une machine de capsulage FPS. Tout ce qu’il fait, c’est la gestion du FPS.

Oblivion Stutter Remover version 3 bêta 1:
La première version a été nommée Oblivion Stutter Removal. Parfois gelé pendant quelques minutes sur le menu principal. La voix et les mouvements faciaux du PNJ peuvent gâcher les conversations.
Version 3 bêta 2: Les mouvements vocaux et faciaux des PNJ peuvent gâcher les dialogues.

Oblivion Stutter Remover version 3 bêta 6:
Il y a un long délai entre la bêta 5 et la bêta 6, comblé par de nombreuses versions alpha. C’est la première version de FSR qui réduit vraiment le bégaiement pour l’utilisateur moyen. Ceci est dû aux nouvelles fonctionnalités: ajustement de l'équité de la section critique, suppression de la section critique et remplacement de la pile. Malheureusement, le remplacement des piles reste un problème majeur pour de nombreux utilisateurs. bFix64Hertz est défini à 0 par défaut dans ini, il devrait être 1.

Remarque: Il n’y a jamais de version finale de la version 3. S'il y a suffisamment de besoins, je peux apporter quelques corrections sur la base du code source de la version 3 bêta 6.

Radiation Stutter Remover version 1 bêta 1:
OSR vers le port initial du rayonnement.

Suppression de bégaiements oubliés/radiants version 4.1.0:
Principaux changements:
1.Prise en charge de Fallout et Forget dans la même base de code:Il n'offre pas beaucoup d'avantages dans Fallout 3, mais il aide.
2.Fichier. ini: Format de fichier ini complètement différent
3.Redimensionnement de la table de hachage: De nouvelles fonctionnalités pour améliorer les performances
4.Sections critiques et sections légères critiques:De nombreux cas particuliers des sections clés sont résumés, et plus d'ajustements peuvent maintenant être apportés à partir du fichier ini. Il y a toujours des problèmes avec le "crochet complet" pour les codes de section critique légère.
5.Remplacement de tas: Quelques bugs ont été corrigés, mais je pense qu'il est toujours problématique. Ça ne marche toujours pas contre les radiations.
6.Désignation de la version:Les versions publiées sur tesnexus sont maintenant appelées versions de version plutôt que des versions bêta. La version publiée sur mon serveur ftp est désormais appelée version bêta, pas version alpha. Le premier chiffre du numéro de version est incrémenté uniquement lorsque la configuration ou le format de distribution sont modifiés de manière significative. Le deuxième chiffre du numéro de version est incrémenté à chaque version. Pour chaque version bêta, le troisième chiffre du numéro de version est incrémenté une fois. Chaque fois qu'un chiffre est incrémenté, tous les chiffres de droite sont réinitialisés à 0.




7. Comment ça fonctionne:


Il s'agit d'un plugin FOSE dll. C'est essentiellement un rayonnement de piratage.

7.1: Gestion du FPS:
Le code de gestion FPS surveille la fréquence d'images et ajuste le flux du temps de jeu. Il atténue le bégaiement en faisant en sorte que la logique du jeu Fallout ne saute pas en avant quand il bégaie. En pratique, les trames qui prennent beaucoup de temps finissent par se retrouver au ralenti. Ceci est réalisé en faisant que le rayonnement se comporte comme si iFPSClamp était réglé sur MinimumFPS, mais uniquement pour les trames plus lentes que MinimumFPS. Cela peut également améliorer la stabilité. Il peut également imposer une fréquence d'images maximale-lorsque la fréquence d'images est empêchée de dépasser la moitié du taux de rafraîchissement, certains pensent que le rayonnement sera plus fluide et, en outre, cela aide à libérer des ressources pour les threads auxiliaires de rayonnement.

Le code de gestion FPS peut également mettre le thread principal de Fallout en veille pendant une courte période, ce qui a été surmonté pour améliorer le bégaiement de certaines personnes (bien que d'autres fonctionnalités du plugin aient peut-être été redondantes).

7.2: Partie critique:
La section critique est une primitive de synchronisation des threads fournie par Microsoft, que Fallout utilise en interne pour s'assurer que les threads ne se détruisent pas accidentellement. Par défaut, FSR permet à la plupart des parties critiques d'essayer d'égaliser la concurrence, même au détriment du débit, en s'assurant qu'aucun thread ne consomme les ressources nécessaires aux autres threads. Cependant, une section critique spécifique est écrasée pour utiliser une méthode légèrement moins équitable, tandis qu'une autre section critique spécifique est supprimée pour la rendre complètement inopérante. Tout cela peut être configuré à partir du fichier ini. Le compte de rotation est également écrasé.

7.3: Remplacement de tas:
Cette fonctionnalité ne fonctionne pas encore correctement sur Fallout 3.

7.4: Tableau de hachage:
Fallout comprend un ensemble de tables de hachage utilisées pour trouver une variété de contenus. Ils utilisent une implémentation généralement mauvaise de la table de hachage, mais le vrai problème est qu'ils ne redimensionnent jamais la table de hachage. Lorsque la table de hachage est trop pleine, les performances se dégradent. Si la table de hachage est insuffisante, alors un peu de mémoire peut être gaspillée. Malheureusement, une grande partie du code de la table de hachage est en ligne partout, et FOSE fait diverses hypothèses sur la table de hachage, et je n'ai aucune idée claire de ce que devrait être le modèle de threading pertinent, donc il est assez difficile de les modifier en toute sécurité.

Néanmoins, j'ai quelques crochets de table de hachage et ils s'améliorent progressivement. Une fois que les tables de hachage sont trop pleines, FSR augmente leur taille. Leur redimensionnement pose beaucoup de problèmes-il peut entraîner des plantages ou des dysfonctionnements, et la méthode que j'utilise pour l'empêcher de le faire peut entraîner de petits bégayements de performances ou d'autres plantages ou dysfonctionnements. Néanmoins, à ce stade, je pense que cela pourrait fonctionner un peu décemment. À l'avenir, je pourrais remplacer ou compléter cela en réécrivant la taille initiale de certaines tables de hachage.


====================================
8. Crédits:
====================================

Ce plugin a été créé par moi (Christopher Dotty-Humphrey).

Cela n’aurait pas été possible sans les efforts considérables de l’équipe FOSE. De plus, Ian Patterson (membre de l’équipe FOSE) m’a aidé à travers beaucoup d’endroits où j’ai eu des ennuis.

Le thread qui m'a initialement demandé de lancer ce plugin a été lancé par DeviusCreed.

De nombreux testeurs ont fourni des commentaires utiles. En particulier, les informations de mashani sur quels paramètres ont produit quels résultats pour lui m'ont aidé à comprendre pourquoi les versions antérieures ont produit des avantages inattendus et ont conduit à de nombreuses fonctionnalités et paramètres dans les versions ultérieures.

Je voudrais également remercier badhair de m'avoir souligné que la surpleine de la table de hachage est une cause de problèmes de performances.

Les outils suivants ont été utilisés dans la fabrication de ce plugin:
L'oubli/le rayonnement, par Bethesda
Code source OBSE/FOSE et OBSE/FOSE
Microsoft Visual C++ 2008 Express Edition
IDA Free (débogueur interactif, version gratuite, version 4.9)
Cheat Engine (version 5.4)
Ajoutez à cela des choses aussi évidentes que Windows XP, Notepad et Firefox.

Tout cela est gratuit, sauf Oblivion/Fallout et Windows XP.

J'ai aussi Hex Workshop et ollydbg qui m'ont été recommandés, mais je n'ai pas encore trouvé le temps de les essayer.