Godot: Problème de bégaiement important dans un jeu 2D simple [Windows 10, Nvidia]

Salut, j'ai mis à jour mon rapport car je l'ai testé sur mon autre ordinateur (maison) et le problème est ici au même moment que je change l'animation. Ce n'est donc pas l'animation qui cause le problème. Je pense que j'y ai cru car quand j'ai vu que c'était sur mon ordinateur portable, il a un petit écran. Voici une vidéo du problème (la vidéo est à 60 FPS):
GodotStutter.zip

Si la vidéo est une représentation précise de ce qui est à l'écran en temps réel, alors c'est beaucoup plus de bégaiement que ce que j'ai jamais vu mentionné dans aucun problème lié au bégaiement ici. Il doit sérieusement y avoir quelque chose qui ne va pas avec cette configuration de Windows 10 / GTX 1060 (je vois pas mal d'articles sur Internet détaillant les problèmes de performances sur Windows 10 / Nvidia après les mises à jour majeures de Windows, mais je ne peux pas dire si c'est lié).

Voici une vidéo du projet de test sur mon système, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX avec des pilotes propriétaires récents (390.59). Pas de bégaiement du tout (sur Openbox - sur KWin, le compositeur gâche les choses et il y a un très léger bégaiement toutes les 10 s environ).
StutterTest_LinuxNvidia_OK.zip

BTW voici une version fixe du projet de démonstration firstGame_fixed.zip , l'original avait des fichiers répartis sur trois dossiers différents ("firstgame", "firstGame" et "FirstGame").

Le jeu me donne la même quantité de bégaiement que dans la vidéo.
Cependant, désactiver vsync élimine complètement le bégaiement (mais le jeu tourne à 4000 fps).
Windows 10 64 bits nVidia GTX 1060 aussi ici.

J'ai également testé comme @Zylann l'a suggéré ici et j'ai obtenu les mêmes résultats. J'ai aussi Win10 x64 et nVidia GTX 1060.

Edit: j'utilise ces pilotes de nVidia:
398.11-desktop-win10-64bit-international-whql

Win 7 64 bits testés GLES2 et GLES3, GeForce GTX 660 / PCIe / SSE2 ... pas de bégaiement. Activer Aero, avec l'éditeur 2d de godot derrière le jeu entraîne un peu de bégaiement (le rendu de l'éditeur Godot interfère avec le rendu du jeu).

Pourtant, le bégaiement de Godot est l'ennemi invisible géant, nous savons tous qu'il est là mais nous ne voulons pas regarder de très près car nous savons que la solution n'est pas simple.

Votre problème semble être différent de la physique des fps fixes avec le taux de rafraîchissement du moniteur, je vois ce genre de bégaiement dans les moniteurs qui n'ont pas le même hz que l'éditeur a configuré les fps physiques, mais cela peut être autre chose.

Votre problème semble être différent de la physique des fps fixes avec le taux de rafraîchissement du moniteur

La démo n'utilise pas la physique, seulement un simple _process .

C'est vrai ... je dis que je ne vois que ce lourd bégaiement dans ce cas, mais c'est vrai qu'il n'y a pas de processus physique impliqué. J'ai testé le changement hz de l'un des moniteurs et aucune différence, 0 bégaiement dans mon équipement.

Edit: j'ai gagné 7, 8,1 et 10 sur cet ordinateur et je prends le temps de tout tester. Aucun bégaiement dans la victoire 8.1. Je teste dans Win 10 maintenant et c'est très fluide ... pas de problème de Windows. Godot est en colère contre votre 1060?

Voici le même test avec mon ordinateur portable. Comme vous pouvez le voir, le problème est là aussi. Mais il semble que ce soit moins visible, mais c'est ici.

Spécifications de l'ordinateur portable: Windows 10 - Geforce 940M

Voici la vidéo de l'ordinateur portable (c'est une vidéo à 60 FPS):
GodotStutterLap.zip

Quelqu'un avec le problème de bégaiement peut-il essayer d'exécuter la démo en changeant dans Player.gd _process avec _physics_process?

Je vais tester ce soir sur mon PC à la maison c'est là que j'ai tout le temps le problème. Mais j'ai une chose étrange: ce matin, je vous ai donné une vidéo avec le projet sur mon ordinateur portable et comme vous pouvez le voir, vous avez le même genre de bégaiement. Le problème est que maintenant, si je l'exécute à nouveau, je n'ai plus ce bégaiement, comme si c'était aléatoire. Et je n'ai rien changé sur mon ordinateur portable, j'y ai travaillé toute la matinée sur une session TSE.

Attention: je ne parle que pour mon ordinateur portable. Sur mon ordinateur personnel équipé de la GTX 1060, le problème est toujours là. Mais sur mon ordinateur portable, le problème semble se produire au hasard. C'est pourquoi je pense que pour l'instant, je laisserai mon ordinateur portable sur le côté à des fins de test et je ne testerai que sur mon PC domestique qui a le problème tout le temps, pour pouvoir isoler le "bug".

@Ranoller Je l'ai testé et j'ai obtenu le même résultat. Le bégaiement est toujours là et il ressemble à peu près au même.

@Ranoller Fait le test et le même à @RaXaR qui ne change rien. J'ai le même problème.

Cela n'a pas l'air bien ...

Pour spécifier exactement le bogue, je ferais ces tests:

1) Plein écran activé - désactivé
2) Si plus d'un moniteur:
Désactiver - Activer le bureau partagé
3) Aero marche-arrêt

Vos cartes fonctionnent bien avec les autres jeux? ...

Lecture du premier article sur l'animation -> bégaiement / pas d'animation -> pas de bégaiement j'ai lu le code et je vois des trucs que je ne pense pas que ce soit correct ... exactement: changer l'animation à chaque image. Je pense que ce code devrait vérifier l'animation actuelle. Cela n'a probablement rien changé, mais si quelqu'un veut tester pour changer Player.gd de cette manière:

extends Area2D

# class member variables go here, for example:
# var a = 2
# var b = "textvar"
export (int) var SPEED #How fast the player will move (pixel/sec)
var screenSize #size of the game window
onready var AnimSprite = $AnimatedSprite


func _ready():
    # Called when the node is added to the scene for the first time.
    # Initialization here
    screenSize = get_viewport_rect().size
    #Engine.target_fps = 60
    pass

func _process(delta):
#   # Called every frame. Delta is time since last frame.
#   # Update game logic here.
    var velocity = Vector2() #Player movement vector
    if Input.is_action_pressed("ui_right") :
        velocity.x += 1
    if Input.is_action_pressed("ui_left") :
        velocity.x -= 1
    if Input.is_action_pressed("ui_down") :
        velocity.y += 1
    if Input.is_action_pressed("ui_up") :
        velocity.y -= 1
    if velocity.length() > 0 :
        velocity = velocity.normalized() * SPEED
        if !AnimSprite.is_playing():
            AnimSprite.play()
    else :
        if AnimSprite.is_playing():
            AnimSprite.stop()

    if velocity.x != 0 :
        if AnimSprite.animation != "right":
            AnimSprite.animation = "right"
        AnimSprite.flip_v = false
        AnimSprite.flip_h = velocity.x < 0
    elif velocity.y != 0 :
        if AnimSprite.animation != "up":
            AnimSprite.animation = "up"
        AnimSprite.flip_v = velocity.y > 0

    position += velocity * delta
    position.x = clamp(position.x, 0, screenSize.x)
    position.y = clamp(position.y, 0, screenSize.y)

C'est la dernière idée ... probablement pas de sens pour le problème, mais ... votre carte graphique est très courante chez les joueurs, donc godot devrait bien s'exécuter.

@Ranoller

Pour :

• Le premier point: déjà essayé en plein écran ou pas, ça ne change rien

• 2: J'ai déjà essayé de fonctionner avec un seul moniteur (c'est ma configuration commune mais j'ai aussi parfois un deuxième moniteur, alors j'ai essayé les deux) et cela ne change rien.

• 3: Je dois tester (devrait pouvoir le faire, ce soir (heure de France).

• 4: Je dois tester votre code (je devrais pouvoir le faire, ce soir (heure de France).

Je viens de tester votre code et cela ne change rien :(

Bien que ce problème ne soit pas directement lié à godot, godot doit bien réviser les problèmes de bégaiement ... ce n'est pas vrai que tous les jeux bégayent comme cela a été dit dans un autre fil. Aujourd'hui je jouais à n ++, plein écran, fenêtré, essayant de voir n'importe quel bégaiement et non .... aucun bégaiement du tout. Même chose avec Ori et la forêt aveugle, il y a beaucoup de mauvaises choses à faire pour avoir un quelconque bégaiement dans ce jeu (fenêtré avec d'autres programmes en arrière-plan, etc .... et seulement 2 ou 3 sauts d'images en une heure ...). Godot, au démarrage de l'exécution, bégaye toujours x nombre de secondes, plus tard il se stabilise, mais toutes les X secondes vous allez avoir des sauts d'images (si vous n'avez pas le problème du gtx1060 bien sûr). Nous ne devrions pas traiter cette question comme un problème mineur.

J'essaye de faire de mon mieux pour isoler le problème mais à mon niveau c'est un peu difficile. J'ai essayé de tester différentes configurations mais sans résultat. J'ai également testé une image d'arrière-plan au lieu d'utiliser une couleur avec un écran clair. J'ai déjà vu (ne vous en souvenez pas) un moteur avec ce problème car le rendu d'un sprite 2D sur un "écran vide" cause ce problème, mais il semble que ce ne soit pas le cas ici. Donc je n'ai aucune idée pour l'instant.

Par curiosité, essayez de profiler combien de temps SwapBuffers prend en context_gl_win.cpp autour de la ligne 68. Si cela prend plus de 16 ms, alors vous perdez probablement une image ici.

Si quelqu'un qui connaît les sources de Godot pouvait tester que je suis intéressant dans le résultat (désolé pour mon anglais ...)

Je jouais avec ce problème hier et je l'ai résolu par magie après que les fenêtres du jeu aient fonctionné pendant environ 60 secondes. Ensuite, c'était fluide, cela me dit que cela pourrait être une chose de mise en cache?

Par curiosité, essayez de profiler le temps que prend SwapBuffers dans context_gl_win.cpp autour de la ligne 68. Si cela prend plus de 16 ms, alors vous perdez probablement une image ici.

Cela pourrait peut-être être utile de savoir si le problème survient dans GLES2, nous ne le testons pas

J'ai essayé de jouer avec les options de Godot à ce sujet, mais cela ne change rien pour moi, peut-être que je ne sais pas exactement quoi changer?

J'ai essayé de laisser le jeu pendant plus de 2 minutes mais le problème est toujours ici pas résolu pour moi après 60 s.

J'ai eu un problème similaire avec la version 3.0.3. (Win10 64 bits, Nvidia 660) Je ne l'ai pas remarqué avec la 3.0.2.

Je pense que cela a quelque chose à voir avec le nœud AnimatedSprite car je vois les problèmes de performances avec les niveaux qui ont ce nœud. J'obtiens l'obturation lors de l'exécution à partir de l'EDI ou si j'exporte vers Win 32 bits, mais si j'exporte vers Win 64 bits, tout fonctionne comme il se doit, pas de bégaiement.

.. intéressant, je n'ai pas le problème avec l'exemple de projet 'FirstGame.zip' ... mais toujours avec mon jeu, FPS tombe à 5 lorsqu'il est exécuté à partir de l'IDE et de la version 32 bits, le GPU se situe à environ 2% .. . mais, avec le GPU d'exportation 64 bits est à 30% et tout va bien.

Salut, y a-t-il des nouvelles de ce problème? Je viens de tester avec la démo de pong (je ne l'ai pas fait avant, juste avec le jeu de tutoriel) et il semble que le problème soit ici aussi avec cet exemple de projet. J'utilise la dernière version de Godot sur Steam pour le tester.

La mise à jour des pilotes Nvidia n'a rien changé, je viens donc prendre quelques nouvelles à propos de ce problème. Je n'ai pas encore trouvé comment m'en sortir.

J'ai maintenant un ordinateur avec un geforce gtx 1060 (3 Go - pas cher) et je n'ai pas le problème dans Windows 10 home. Cela peut être une application de fond? Certaines configurations matérielles spécifiques AMD-Nvidia Intel-Nvidia ....? Je n'ai aucune application de jeu sur cet ordinateur (est dans mon studio d'enregistrement de musique) mais godot fonctionne bien même avec 3 écrans connectés à l'ordinateur. N'importe qui avec le problème peut vérifier si un logiciel de surveillance de jeu fonctionne en arrière-plan, ou Steam, ou quelque chose comme ça ...? Et si vous avez essayé de dissable?

Difficile de désactiver Steam lorsque vous l'utilisez pour lancer Godot ... Godot fonctionne très bien le problème est le jeu avec lequel vous faites. J'ai déjà essayé de désactiver tout ce que je peux désactiver, cela ne change rien. J'ai fait beaucoup de tests sans succès. J'ai également essayé de réinitialiser les pilotes nvidia par exemple, de les mettre à jour etc ... mais cela ne change rien.

De l'autre côté, j'ai un tas de moteurs qui fonctionnent bien alors pourquoi pas Godot? C'est ce que j'ai essayé de trouver. Mais pour l'instant je ne trouve rien. Il y a quelque chose quelque part mais quoi et où, telle est la question :-)

Ce problème est trop "spécifique au développement du moteur" pour trouver une solution acceptable par sa propre recherche. Je peux chercher pendant des heures le code godot et je sais que je n'aurai jamais la possibilité de trouver quelque chose en rapport avec ça ... je sais que les développeurs de moteurs aiment plus de code, de nouvelles fonctionnalités et "bug-fix" est considéré comme plus "junior-work " ou quelque chose comme ça. Mais avec ce genre de problème, ce n'est pas le cas. Nous avons besoin d'un développeur de moteur pour attribuer automatiquement ce problème et d'autres correctifs de bogues "compliqués-fantômes-bas-difficiles à payer" ...

Je mentionne que j'ai déjà essayé la version dev (sans Steam) et le problème est le même.

Salut, j'ai eu exactement le même problème de bégaiement (en utilisant Godot 3.1 à partir de la source Git), tout mouvement retardé pour moi, exactement comme dans votre vidéo, que ce soit move_and_slide ou simplement le mouvement du lecteur d'animation. mais l'activation de V-Sync dans le cadre du projet a complètement résolu le problème de bégaiement dans le jeu 2D.

Je suis un peu confus parce que @Zylann a dit que la désactivation de V-Sync supprimait le bégaiement, mais pour moi, c'est le contraire.

@Qws l' éteindre ET faire tourner le jeu à plus de 60 ips (ce qu'il faisait à l'époque) a fait disparaître le bégaiement pour moi, mais cela pose d'autres problèmes (utiliser toute l'énergie disponible et faire échouer tout ce qui n'utilisait pas un delta approprié temps). Si vous avez un bégaiement avec V-sync désactivé, c'est soit à cause d'un temps delta incorrect, soit à une situation où le jeu doit attendre / traiter plus longtemps qu'une image pour mettre à jour l'écran.

Le premier test que j'ai fait avec la nouvelle gtx 1060 ne pose aucun problème ... mais plus tard, je ressens ce bégaiement. La seule chose que j'ai changé est la conexion dvi en hdmi (et certains programmes installés) ... c'est un peu bizarre. La seule chose que j'ai convaincue, c'est que le problème n'est pas du côté de Windows 10.

Je vais en dire beaucoup. Je travaille sur un tutoriel de jeu 2D "Hoppy Days" à partir des tutoriels Gamedev.tv. J'utilisais 3.0.2 pour le développer, et cela fonctionnait très bien. J'ai remarqué que le didacticiel utilisait la version 3.0.4, donc littéralement AUJOURD'HUI j'ai décidé de passer à la 3.0.6. Il y a maintenant un décalage notable dans le jeu. _Le décalage n'était pas du tout là dans 3.0.2_ . C'est là maintenant. Tous les autres paramètres sont identiques.

Mon ordinateur portable est un ordinateur portable de jeu Dell Inspiron 7000 assez récent (acheté en mars 2017). Le processeur est un processeur Intel Core i7-7700HQ Quad Core de 7e génération (6 Mo de mémoire cache, jusqu'à 3,8 GHz). La carte vidéo est NVIDIA GeForce GTX 1050Ti avec 4 Go de GDDR5. La RAM est de 16 Go, 2400 MHz, DDR4. Le disque dur est un SSD Samsung. Windows 10.

Pour moi, il semble que quelque chose ait changé dans la version 3.0.4 ou 3.0.6 ..... Rien d'autre n'a changé du tout. Pas même le jeu (comme dans ... je n'ai pas du tout changé / édité / mis à jour le niveau).

@ emo10001 Pourriez-vous tester la version 3.0.3? C'est à ce moment que nous avons changé le système de construction utilisé pour créer des binaires 3.0.x (3.0 à 3.0.2 ont été construits sur AppVeyor CI avec MSVC 2015, 3.0.3 à 3.0.6 ont été construits avec GCC 8 via MinGW).

Si votre ordinateur portable a des graphiques Optimus / commutables, il se peut que votre système ait ajouté à la liste blanche le binaire 3.0.2 à utiliser avec le GPU Nvidia, tandis que 3.0.3+ serait par défaut un IGP. Ou il se peut que la version 3.0.2 ait été ajoutée à la liste blanche par votre antivirus tandis que la version 3.0.3+ est considérée comme provenant d'une source différente (ce qui est vrai) et n'est pas encore considérée comme sûre, de sorte que l'antivirus exécute ses vérifications complètes et affecte les performances.
Ce ne sont que des suppositions, mais sinon, je ne suis pas sûr du changement réel de Godot qui aurait un impact sur les performances de cette manière, donc je ne peux penser qu'aux changements du système de construction.

CC @hpvb

J'ai le même problème! Mon projet bégaye pendant 20 à 30 secondes, puis se déroule sans problème par la suite. J'ai téléchargé le projet dans OP post et c'est exactement la même chose.
La désactivation de V-Sync supprime le problème et fonctionne à plus de 4000 fps.

J'utilise la version 3.0.6 sur Linux Mint 19 (donc je suppose que la balise Windows est inexacte, hein?) Et GTX 760 avec les derniers pilotes propriétaires.

J'utilise la version 3.0.6 sur Linux Mint 19 (donc je suppose que la balise Windows est inexacte, hein?) Et GTX 760 avec les derniers pilotes propriétaires.

Non, mais c'est probablement un problème différent. Le bégaiement sous Linux se produit souvent en raison de la composition du gestionnaire de fenêtres (par exemple, j'en ai avec KWin, aucun avec Openbox).

Mon projet bégaye pendant 20 à 30 secondes, puis se déroule sans problème par la suite

Je remarque beaucoup cela, si j'exécute la scène que je suis en train de modifier, il y a du bégaiement et des déchirures (avec vsync activé) environ 15-30 secondes, mais si je démarre le projet à partir du menu principal et ouvre la scène avec le sélecteur de scènes ... enfin, il n'y a pas de bégaiement dans la même scène (il y en a finalement, mais pas jamais). Il y a une explication à propos de cet événement? Godot? Les fenêtres? Combien d'images faut-il pour stabiliser la reproduction? ... ce sera formidable de savoir que les choses car il y en a du nécessaire au game-design.

Non, mais c'est probablement un problème différent.

Hmm je vois. Ce que je voulais dire, c'est que ce problème spécifique est probablement multi-plateforme car de nombreuses personnes rencontrent les mêmes problèmes.

J'ai déconné et j'ai remarqué que deux corps cinématiques bégayaient exactement en même temps, à la fois pour move_and_slide () et move_and_collide ().

En accrochant une caméra à une caméra alors qu'elles oscillent toutes les deux, tout dans la scène bégaie, à l'exception des deux nœuds cinématiques. Une caméra statique ne montre que les deux nœuds cinématiques bégayant.

Peu importe les paramètres graphiques que je modifie, ni _process ou _physics_process. ni l'utilisation d'une variable delta différente.

Je pense que ce projet n'est pas représentatif d'une utilisation réelle ... des projets plus compliqués se déroulent un peu sans problème. Je pense que les fenêtres ne gèrent pas bien un temps d'inactivité excessif de godot ... J'ai trouvé un autre problème lié, non seulement pour godot, mais cela en souffre beaucoup: en multimonitor avec un jeu de bureau étendu, c'est plus fluide dans le moniteur 1 si cela est classé comme "moniteur principal". Si le moniteur principal est autre que 1, il y a du bégaiement dans le moniteur secondaire (youtube en souffre, mais pas les jeux commerciaux unitaires comme ori). Avec le plein écran dans le moniteur secondaire, l'aero dans win 7 et les moniteurs échangés (ej: moniteur 2 comme primaire), le scénario est le pire et il y a un gros bégaiement (pas seulement godot, mais ni game maker ni jeux d'unité) ... Je sais que le multimonitor avec un bureau étendu sur 2 écrans 1080p est difficile pour les GPU bon marché, mais d'autres jeux sont plus fluides (godot ne perd pas de fps, seulement bégaiement). Si ce test se poursuit, nous devrions faire un exemple plus complexe.

@Ranoller ma configuration est un double moniteur dans un gtx 760, deuxième moniteur étiqueté comme «primaire», linux mint 19 avec de la cannelle. J'essayais de comprendre la condition spécifique du projet, mais je n'ai pas pu comprendre. Ces petits projets bégayent parfois, parfois non (seulement bégaiement, pas de perte de fps). De plus, quand il bégaie (s'exécutant dans des configurations de test fenêtrées, godot), j'ai généralement une ou plusieurs fenêtres chromées dans le deuxième moniteur (pas le principal), et lorsque je les minimise, le bégaiement est parti ... restauration sur les vitres chromées, le bégaiement est totalement parti.

J'ai 2 ordinateurs -> un avec i5 gtx660 2 écrans 1080p et un autre avec i7 gtx 1060 3 écrans (2 1080p et autres hdready) ... eh bien, j'ai ce problème de bégaiement lié aux moniteurs secondaires dans gtx660, je pense que est lié exclusivement au rendu, aux bégaiements de godot et de chrome, au créateur de jeux et à l’unité (jeux commerciaux, exactement HiperLightDrifter et Ori, je n’ai pas testé de démos ou de modèles). Windows aero bégaie plus en plein écran (je pense que ce n'est pas vraiment plein écran) mais a beaucoup de fps, sans aero dans win 7 j'ai dans mon projet 130-140 fps sans vsync, avec aero je passe 400 fps, mais. .. bégaie (beaucoup) dans certaines conditions (avec et sans vsync). Je ne peux pas faire bégayer godot dans le i7 gtx 1060 (avec un vrai projet, la démo dans ce fil bégaie et j'explique mon opinion sur le jet). Je pense que c'est un problème d'optimisation / OpenGL, ej: Light2D est à peine inutilisable, tout mode de mixage autre que "mix" peut bégayer si le système n'est pas trop puissant, mais godot devrait gérer la permormance au même niveau que le game maker ou unity. Probablement une fois que la version 3.1 a été lancée, des travaux d'optimisation pourraient commencer (si le problème est réparable et que ce n'est pas Direct3D / OpenGL - problème Windows bien sûr ... je ne sais pas comment trouver des jeux GLES2 / 3 dans Windows pour tester et ignorer un problème direct OpenGL - Aero / Win7-8-10) ... Je comprends que la permormance de godot ne sera jamais la même que celle de propietary -> un moteur basé sur un jeu (Ej: les origines de Rayman fonctionnent bien dans un vieil ordinateur portable que j'ai , godot 2 don´t), mais il devrait rendre au moins au même niveau stable que le game maker (Unity sera probablement mieux optimisé que godot pendant longtemps, vous savez, l'argent ...). Pour l'instant, je pense que godot fonctionne bien uniquement sur du matériel haut de gamme ou sur des écrans basse résolution (je teste sur un ordinateur graphique i5 win7 32bit 15 "Intel HD et fonctionne bien, mais je ne pense pas qu'avec un écran hd cet ordinateur sera run´s godot en douceur) ...

Bien sûr, tout cela sont mes opinions / expériences, je peux me tromper (et j'espère l'être ... si ce n'était qu'une solution simple en une ligne, cela pourrait être génial !!!)

D'autre part, je me souviens de lire reduz en écrivant quelque chose lié à la "priorité de processus" de l'exécutable godot, mais dans Windows il n'y a pas de différence si vous changez manuellement la priorité de godot lors de l'exécution, godot ne sous-performant pas (qui, j'ai a inventé un mot?), l'exécution du programme n'a pas de pointes, c'est le rendu, quelque chose lié à nvidia / godot et au bureau de l'ordinateur (sous windows, je n'essaye pas sous linux)

Salut, alors, y a-t-il des nouvelles de ce problème? ^^ Je vais tester à nouveau avec la dernière version mais il semble que le problème soit toujours là.

fait cette sortie dans la plate - forme Android ou ios maintenant il y a des jeux en magasin de Google a fait au début de godot qui ont également volet problem.like: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Cela existe dans toutes les plates-formes testées dans certaines circonstances, avec divers GPU et divers systèmes d'exploitation ... n'est pas documenté dans les consoles.

Je l'ai testé sur Linux et Windows et il a fonctionné sans problème avec le petit bégaiement occasionnel, j'ai une carte graphique baytrail graphique intel hd intégrée bas de gamme

Après de nombreuses heures à essayer de déterminer la cause du bégaiement, dans mon cas du moins, j'ai par hasard suivi le bégaiement constant des 1 jusqu'à l'activation de l'option `` Basculement automatique vers l'arborescence des scènes distantes '' dans les `` Paramètres de l'éditeur ''. Décocher cette option résout les problèmes de bégaiement et de performances pour moi. (il y a peut-être encore un très léger bégaiement, mais c'est à peine perceptible.)

Godot construire 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64 bits, NVIDIA GeForce GTX 660, pilote v416.81

J'ai aussi un problème de bégaiement avec mon jeu. La seule chose qui semble améliorer les choses est d'éteindre et de rallumer le plein écran pendant que le jeu est en cours d'exécution ... Et même alors, il y a un léger bégaiement qui rampe par la suite. Semble arriver complètement au hasard. Parfois, le jeu sera presque parfait, d'autres fois le bégaiement se produit.

Projet 2D avec personnages cinématiques.
Processeur Intel i5-2550K
16 Go de RAM
Geforce GTX 970
Win10 64 bits
Godot 3.0,6

Dans win 10 bégaiements se produit plus en plein écran, et c'est parce que Aero (et peut être désactivé). Il semble que Godot utilise moins de CPU et plus de GPU avec Windows Aero mais cela provoque plus de bégaiement. Dans Windows 7, en désactivant Windows Aero, le plein écran a moins de saccades que la fenêtre et utilise plus de CPU. Je pense que win 10 n'a pas de vrai plein écran ...

J'ai commencé à faire un prototype de jeu de flipper 2D et j'ai trop de tremblements dans le mouvement de la balle, je n'ai qu'un corps rigide qui tombe avec la gravité. Je suis sur Win10 / NVidia GTX 560 Ti 1Go (avec les derniers pilotes) / 8 Go Ram, mon ordinateur n'est pas le meilleur mais mon projet n'a qu'une balle et StaticBody2D pour les bordures et je peux voir clairement le gigue se produire très souvent, je 'ai essayé avec et sans vsync, avec opengl 3.0 et 2.0, fenêtré et plein écran, avec de plus en moins de fps physiques, le problème est toujours là.
Ma version Godot est 3.1 alpha.
Je pense que c'est un problème majeur, peut-être difficile à résoudre mais qui ne doit pas être ignoré, il est important d'avoir un mouvement 2D fluide pour un jeu 2D.

Vous avez raison, Godot a maintenant la meilleure convivialité de tous les meilleurs moteurs (à mon avis bien sûr). Le côté convivialité les bat tous. Mais ... côté performance .... côté exportation .... c'est comme si godot battait avec le système d'exploitation, pas comme les exportations d'unité ou de game maker qui sont plus fluides (jusqu'à ce que la construction en chrome soit plus fluide ), et ce n'est pas parce que la lenteur de gdscript (se produit avec et sans GDScript), il y a "autre chose indéterminée", j'espère qu'un jour quelqu'un pourra trouver une ligne rebelle dans un fichier cpp et en changer un simple "!" ce problème sera résolu ... (l'espoir est libre comme Godot!)

J'ai plusieurs projets en tête et j'adorerais les réaliser avec Godot, cela prendra beaucoup de temps (pour ne pas dire tout mon temps libre), mais ça m'attriste de dire que si le moteur ne peut garantir un mouvement 2D fluide dans l'animation avec une scène simple, le moteur malgré tous ces avantages est tout simplement inutile. Dans ce cas, peut-être le choix le plus sage pour moi est de ne pas risquer de perdre du temps de cette manière.

Je comprends que ce problème n'apparaît que dans certaines configurations (pilotes Windows 10 et NVidia par exemple) mais j'aimerais savoir:

• Ce problème (ou un problème similaire) est-il déjà prévu dans un jalon ou non?
• Ce problème est-il peut-être mis de côté en attendant le remplacement d'OpenGL par Vulkan dans le jalon 3.2?

PS: j'ai essayé avec un autre pc:

• Intel i7 4790K 4,00 Ghz
• Win10 64 bits 16 Go de RAM
• NVidia GTX 1060 3Go (avec les derniers pilotes)
• Godot 3.1 alpha officiel
  et j'ai le même problème avec des scènes simples.

Je pense que ces types de configurations PC (cartes Win10 + Nvidia) sont très communes, et j'espère que la communauté Godot (qui fait un excellent travail d'ailleurs) résoudra ce problème très bientôt et que de bons jeux 2D commenceront à sortir pour montrer que nous pouvons faire avec Godot mais avec ce genre de problème pour moi c'est tout simplement impossible.

Peut-être s'agit-il d'une sorte de problème d'orientation du programme? Quand je démarre un jeu en plein écran, je vois le bégaiement à chaque fois. Mais si (pendant que le jeu est en cours d'exécution) je passe en mode fenêtré et reviens en plein écran, il semble fonctionner parfaitement à chaque fois. Si je l'ai aussi, je peux programmer cela pour qu'il se produise automatiquement, mais cela semble insensé. Quelqu'un d'autre peut-il confirmer que le passage du plein écran, au fenêtré, au plein écran corrige à nouveau le bégaiement?

Edit: Oh et autre chose ... Lorsque j'ai désactivé l'application Geforce Experience, les choses semblaient s'améliorer.

Projet 2D avec personnages cinématiques
Godot 3.0.6
Win10 64 bits
Processeur Intel i5-2550K
16 Go de RAM
Geforce GTX 970

J'ai essayé ce que vous proposez, j'ai désactivé Geforce Experience, essayé de passer du plein écran à la fenêtre, au plein écran à nouveau, avec vsync activé et désactivé (c'est pire avec vsync désactivé) mais le bégaiement me semble toujours inconfortable.
C'est assez aléatoire mais je n'ai jamais dépassé environ 15-20s sans bégayer.

Merci d'avoir essayé! C'est tellement bizarre, vos spécifications sont meilleures que les miennes. Le problème avec moi, c'est que c'est tellement aléatoire ... C'est difficile à reproduire avec précision. Parfois, il fonctionnera très bien, d'autres fois, il bégayera. Je suis assez certain que cela a à voir avec Godot lui-même, cependant. Je n'ai jamais rencontré de bégaiement dans les jeux créés dans Unity, ou dans tout autre moteur de jeu d'ailleurs.

Je viens de remarquer ce bégaiement.

(Godot 3.0.6, Windows 10, 64 bits, i7-8550U, 16 Go de RAM, NVIDIA GeForce MX150)

Comme d'autres l'ont déjà mentionné, c'est un problème sérieux pour Godot. Cette semaine, j'ai décidé de créer un prototype pour un jeu très simple. J'ai cherché un framework ou un moteur (j'en ai trouvé beaucoup) et j'ai décidé d'aller avec Godot - car il est gratuit et ouvert. Ensuite, j'ai remarqué le bégaiement, trouvé ce problème - et j'ai été surpris qu'il ne semble y avoir aucun progrès. Je suppose que je vais de toute façon prototyper mon idée dans Godot. Mais si je voulais créer un jeu diffusable, j'essaierais probablement un autre moteur. (Cela semble trop dur ... Je pense juste que Godot pourrait perdre beaucoup d'adoptants potentiels si le problème n'est pas résolu.)

Il n'y a pas de progrès parce que personne ne travaille là-dessus, et oui, c'est un problème grave. Mais pour l'instant, si vous avez besoin de sortir un jeu commercial, vous pouvez prototyper en godot et porter à l'unité (vous pouvez utiliser C #). Vous devez avoir à l'esprit l'approche scène-jeu-objet-composant et vous pouvez répliquer dans godot et si les œuvres vont à l'unité pour un flux fluide et des performances, ou si la 2D est pour gamemaker. Je travaille dans un plugin pour essayer de convertir un projet godot vers d'autres moteurs et essayer de porter gdscript vers un module, vers gml ou vers unity C #, mais c'est une tâche très énorme (je ne sais pas si l'effort en vaut la peine il, trop de temps sans travail dans le jeu) et sera toujours imparfait (je ne peux pas obtenir tous les types, ej: objet retourné par collision). J'ai un petit analyseur pour les scripts et je vais démarrer un analyseur pour tscn et tres, mais convertir le résultat de l'analyseur de gdscript en unity c # ou gamemaker GML nécessite une tonne de code et je ne connais pas la "légalité" à ce sujet besoin de tous les noms d'API, par exemple, dans les fichiers json et je ne connais pas l'adresse IP de cela) Les animations sont un autre problème, je ne sais pas pour l'instant comment aborder cela, mais l'utilisation de spine / dragonbones sera facile à porter. Mon idée principale de faire ça était de commencer par godot et de se terminer par unité ou gm, mais pour niw c'est un casse-tête ... Si l'unité était tout aussi portable (j'ai besoin de ça), minuscule et rapide à développer comme godot (et avoir un 32 bits éditeur) J'ai porté mon projet principal il y a des mois, j'adore godot mais pour un projet de taille moyenne dans une petite équipe (ou un homme seul comme moi) est un risque, personne ne vous garantit qu'un projet fini ne donnera pas une tonne de problèmes. Mais s'il y a un bon programmeur C ++ dans votre équipe c'est autre chose, vous pouvez toujours adapter godot à votre jeu (dans l'unité vous ne pouvez pas, mais c'est moins bogué) ....
Je déteste ce problème comme je déteste les faibles performances de l'éditeur dans un projet intermédiaire et le jeu exporté, mais je déteste plus d'unité (pourquoi j'ai besoin d'Internet dans tous les ordinateurs pour ouvrir l'éditeur? J'ai un ordinateur sans cela!) Et je déteste studio si profondément visuel ... je suis sûr que si godot arrête le bégaiement et travaille sur les performances et l'exportation, nous pouvons commencer à voir de grands jeux à venir.

Pour revérifier ce problème aujourd'hui, j'ai fait ce qui suit, toujours sous Windows 10 avec nVidia GTX 1060:

J'ai ouvert The Binding of Isaac, en mode fenêtré. A couru en rond, pas de bégaiement (à partir de là, je veux dire pendant au moins 30 secondes). Je ne sais pas si le jeu a V-sync ou non, il n'a pas un tel paramètre.

J'ai ouvert Minecraft, en mode fenêtré. Chargé un monde plat regardant le sol où le décalage serait inexistant, pas de bégaiement.

J'ai ouvert Factorio, mode toujours fenêtré, avec une assez grande usine de fin de jeu. Ran en ligne droite, pas de bégaiement. Cependant, V-sync est désactivé. Si je l'allume et redémarre le jeu ... toujours pas de bégaiement.

J'ai ouvert un vieux jeu Java que j'ai créé en utilisant Slick2D (OpenGL), pas un seul bégaiement (je n'ai pas encore vu un Oo). En vérifiant les options, V-sync a été activé. Si je désactive V-sync, j'obtiens un bégaiement régulier toutes les secondes environ. Si je double la limite de framerate, je n'obtiens aucun bégaiement.

Maintenant, j'ai ouvert un projet 3D avec Godot 3.1 alpha3, avec une carte ayant des atouts et un personnage en mouvement: presque pas de bégaiement, je ne peux en voir qu'un toutes les 20 secondes peut-être, ce qui est trop subtil pour déranger.

J'ai aussi essayé mon projet 2D Wallrider que j'ai porté dans Godot 3.0.6: idem, pas assez de bégaiement pour déranger (un aléatoire toutes les 20 secondes).

Tous ces projets ci-dessus ont ceci en commun: ils ne dessinent pas seulement un sprite à l'écran.

Si j'essaie le projet de test @crystalnoir avec Godot 3.1 alpha3, j'obtiens un bégaiement fréquent et irrégulier immédiat, qui ne disparaît que si j'attends environ 30 secondes après sa dernière visualisation / maximisation. J'ai essayé de passer à _physics_process , et même essayé delta = 1.0 / 60.0 , c'est pareil. Si j'imprime delta , cela montre qu'il y a une fluctuation chaque seconde, mais le jeu montre des bégaiements plusieurs fois par seconde que delta ne reflète pas du tout. Cela arrive aussi si je démarre le jeu sans l'éditeur.
J'ai également essayé de le porter sur Godot 2.1.5, et le même problème se produit (projet: Stuttering_issue19783.zip )

Et maintenant, c'est là que ça devient intéressant:
Si j'ouvre à la fois mon jeu 3D ET le test de @crystalnoir sur l'écran, ils se déroulent tous les deux correctement, immédiatement. Le jeu 2D bégaie encore un peu, mais pas autant. Si je ferme le jeu 3D, il semble toujours fonctionner correctement, mais si je réduis le jeu 2D et le maximise à nouveau, cela revient à d'horribles bégaiements.

Ce n'est pas encore la fin!
J'ai maintenant essayé d'ajouter une caméra 3D dans le jeu 2D. Et comme par magie, le bégaiement est réduit de façon drastique et immédiate en faisant simplement cela.
Vous pouvez l'essayer vous-même avec PlayerWith3D scene: Stuttering_issue19783.zip
Voyez à quel point il est fluide par défaut. Maintenant, appuyez sur le bouton magic , voyez comment cela se passe si aucun environnement 3D n'est affiché (cela ne revient pas toujours à la merde à 100%, mais je vois que PlayerWith3D.tscn est toujours meilleur que Player.tscn ).

Je voudrais aller plus loin et voir ce qui se passe si je change le panneau de configuration nVidia de Optimal Power (par défaut) à Maximum performance , mais ... euh ...

Quoi qu'il en soit, tout ce que je peux deviner à partir de cela est (mais c'est une supposition alors prenez-le avec un grain de sel): ce n'est pas directement la faute de Godot. Ce sont les pilotes graphiques qui essaient d'être "intelligents".

Pour le dieu des bégaiements !!! 😂😂😂

Juste jeter ceci là-bas ... Depuis novembre 2018, les 14 meilleures cartes vidéo sur Steam sont Nvidia. Regardons les meilleures cartes de chaque catégorie de GPU:

NVIDIA GeForce GTX 1060: 14,60% des utilisateurs de Steam.
Graphiques AMD Radeon R7: 1,06% des utilisateurs de Steam.
Intel HD Graphics 4000: 1,06% des utilisateurs de Steam.

https://store.steampowered.com/hwsurvey/videocard/

Compte tenu des données ci-dessus, il semble que cette question devrait être la priorité absolue. Une écrasante majorité de joueurs utilisent des cartes Nvidia, c'est de loin la configuration la plus courante. Le nombre d'utilisateurs de graphiques Radeon et Intel est minime en comparaison.

@Ranoller ... Vous me tuez. Dire aux gens de prototyper dans Godot mais de porter sur Unity pour leur titre commercial (dans un fil de discussion Godot) est la chose la plus ridicule que j'ai jamais entendue, sans offenser.

@Zylann J'ai essayé de régler le mode de gestion de l'alimentation sur "Perfer maximum performance" avec succès, mais je

@ behelit2 Aucune infraction

@Zylann J'ai mis une caméra 3D qui rend un maillage devant une scène qui rend un tilemap avec des textures animées et le problème du bégaiement de godot quelques secondes après la mise au point de gain n'est pas corrigé. Il n'y a pas d'autre type de sttuter auparavant (seulement le "initial") dans cette scène donc je ne sais pas si cette astuce corrige quelque chose, mais c'est intéressant que vous découvrez. Je vais tester avec vos fichiers. Je pense aussi que le temps d'inactivité godot fait que quelque chose dans l'ordinateur devient "paresseux", mais c'est probablement le système d'exploitation, car les différences de victoire avec et sans aéro en FPS, l'utilisation du processeur et le bégaiement sont si élevées. C'est probablement le système d'exploitation qui essaie d'être intelligent et non la carte graphique.

J'aime l'idée de Zylann d'analyser ce que font les autres jeux. Je ne sais pas si c'est hors-sujet, mais j'ai fait quelques tests.
Tout d'abord, il semble que 95% des jeux Steam soient 32 bits (les versions récentes aussi). Il semble qu'un pourcentage égal des jeux soit rendu par directx. Je capture les processus exécutés par les jeux et j'essaie de voir ce qui se passe avec le rendu. Quelques informations derrière (ce n'est pas pour avoir des conclusions, ce n'est que des informations):

Jeu / Bits exécutables / Moteur / Processus qui utilise pour rendre dans Windows 7 64 bits et notes.

• HyperLightDrifter -> 32 bits / Game Maker / Windows GDI
• Hook -> 32 bits / Unity / Windows GDI
• Nidhogg -> 32 bits /? / Windows GDI

• Ori et la forêt aveugle -> 32 bits / Unity / Windows GDI. Exécute un processus appelé OPENGL32 comme godot mais est une sorte de wrapper dans Windows GDI. Pas un seul appel d'OpenGL32, tous les appels proviennent de Windows GDI.
  

• Poussière: An Elysyian Tail -> 32 bits / Microsoft XNA / Windows GDI. A gameoverlayrenderer.dll et tous les appels proviennent de ce (ClientToScreen). N'a pas de dll OpenGL.

• SuperMeatBoy -> 32 bits, exécution dans Steam Overlay, Windows GDI

• ΔV: Anneaux de Saturne (démo) -> 64 bits, godot / Exécute les appels OpenGL et Windows GDI, faites un seul appel à OpenGl SwapBuffers - GetPixelformat avec une valeur de 8. Faites beaucoup d'appels à Windows GDI. Faire des appels dupliqués? à WindowsFromDC- SetRect (taille de la fenêtre), OffsetRect.
  

• Bastion -> 32 bits / SDL2 / Exécute des appels OpenGL purs, pas de Windows GDI, faites un appel unique de swapBuffers - GetPixelFormat à tout moment avec une valeur de 10.

• SouthPark le bâton de la vérité -> Moteur 32 bits / Unknow / Exécute tous les appels dans Windows GDI, semble direct3D v 9 (a d3d9.dll mais fait peu d'appels par ce processus), la plupart des appels proviennent de gameoverlayrenderer de vapeur et uxtheme.dll qui exécute OffsetRect et IsRectEmpty et d'autres fonctions de fenêtre.
  

• Sine Mora -> 32 bits / Moteur inconnu / Exécute tous les appels dans Windows GDI par superposition de vapeur, dicect3d 9

• Apotheon -> 32 bits / Microsoft XNA / Tous les appels dans Windows GDI, un seul appel de la superposition de vapeur (client à l'écran), un seul appel de Microsoft XNA (ScreenToClient) et des appels d'un processus appelé uxtheme.dll (gestion de fenêtre dans windows?) à IsRectEmpty et PtInrect (tous des booléens).
• Les œufs retournent à la maison -> 64 bits / Godot / Appels d'OpenGL et de Windows GDI, même que Ring of Saturn.
• Guacamelee! Super turbo .... -> 32 bits / moteur inconnu mais pour les fichiers peuvent être similaires à sine mora. Ce jeu permet de redimensionner l'écran./ Tous les appels de Windows GDI.
• Pas un héros -> 32 bits / SDL2 (wikipedia dit ClickTeam Fusion) / Tous les appels depuis Windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 bits (ouais, il y en a un) / Intro dit Firebird, rien pour le moment sur les processus / Tous les appels depuis Windows GDI, mais, il y a très très très peu d'appels, peu que dans les autres jeux, quelques appels par seconde (ej, vous pouvez à peine suivre les appels godot api, il y en a des tonnes par seconde). Mais ce jeu brûle le GPU.

Je remarque que la plupart des jeux en focus perdu arrêtent le processus et mettent en pause (peut-être une bonne pratique?) Et très peu de jeux vous permettent de redimensionner manuellement l'écran (ej: pas un héros). Malheureusement, j'ai le problème du bégaiement de la perte de concentration / gain de concentration dans ΔV: Anneaux de Saturne (démo).

Edit: Il semble que godot soit le seul moteur qui utilise les processus OpenGL32 et WindowsGDI en même temps.
Application utilisée: API Monitor v2

(Edit: nom correct de ΔV: Anneaux de Saturne (démo))

Si par Anneaux de Saturne vous entendez ΔV: Anneaux de Saturne (démo), il a été construit avec Godot 3.1, mais je ne suis pas sûr de la révision exacte qu'ils ont utilisée?

Après de nombreuses heures à essayer de déterminer la cause du bégaiement, dans mon cas du moins, j'ai par hasard suivi le bégaiement constant des 1 jusqu'à l'activation de l'option `` Basculement automatique vers l'arborescence des scènes distantes '' dans les `` Paramètres de l'éditeur ''. Décocher cette option résout les problèmes de bégaiement et de performances pour moi. (il y a peut-être encore un très léger bégaiement, mais c'est à peine perceptible.)

Godot construire 8849d3b
Win10 64 bits, NVIDIA GeForce GTX 660, pilote v416.81

J'ai eu le même problème de bégaiement et décocher Auto Switch to Remote Tree était le coupable.

J'ai le même problème ici. Il y a plusieurs problèmes à propos de cette gigue, mais la plupart d'entre eux ne semblent pas avoir de solutions appropriées et j'ai vraiment besoin d'aide.

Je suis sur le point de signer un accord avec un éditeur avec mon jeu que j'ai fait avec Godot et à cause de la gigue, je pourrais avoir à déplacer tous mes codes vers Unity. Mis à part le temps et le coût pour déplacer tous les codes, je suis réticent à passer à un moteur différent car j'aime beaucoup la philosophie de conception de Godot et de Godot lui-même.

J'ai également remarqué que dans 3.1, l'option `` Physics Jitter Fix '' a été ajoutée dans le menu des paramètres (https://twitter.com/reduzio/status/984783032459685890) mais cela n'aide pas non plus.

Version Godot:
Godot 3.0.6

OS / appareil, y compris la version:
MacOS 10.14.1
MacBook (Retina, 12 pouces, 2017)
Intel Core m3 à 1,2 GHz
8 Go LPDDR3 à 1867 MHz
Carte graphique Intel HD 615 1536 Mo
(Mais ce problème se produit sur plusieurs appareils, y compris le PC et le jeu exporté sur mobile et PC.)

Description du problème:
Tout objet en mouvement semble périodiquement bégayer ou vaciller accompagné d'un gel de l'écran.

Étapes à suivre pour reproduire:
Créez un nouveau projet avec un KinematicBody2D ou même un AnimatedSprite et modifiez la position avec move_and_slide () ou set_position () après avoir ajouté un Camera2D en tant que nœud enfant (mais cela se produit toujours même sans Camera2D).

Et cela semble se produire plus fréquemment sur les appareils à faible puissance de traitement.

Projet de reproduction minimale:
Godot_Jitter.zip

KinematicBody2D, _physics_process (), move_and_slide ()

https://youtu.be/78S95yugRDk

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    motion = move_and_slide(motion, Vector2(0, -1))
    print(delta, position)

AnimatedSprite, _physics_process (), set_global_position ()

https://youtu.be/gdc6NOoWG4E

extends AnimatedSprite
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

KinematicBody2D, _process (), set_global_position ()

https://youtu.be/YVFtkbuyqEQ

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

Win 7 64 bits, GTX 660 (pilotes 391.35), Godot 3.0.6 et 3.1-beta1

Hé, j'ai peaufiné le projet original (animation arrêtée, utilisation d'un corps rigide au lieu d'ajuster manuellement les positions, ajout d'un arrière-plan légèrement animé, etc.)

Le voici: FirstGame_2.zip

Testé avec une fenêtre de taille ~ 500x500 et une résolution d'écran de 1920x1080

Maintenant mes observations:

• La gigue est omnidirectionnelle (pas seulement verticale, comme les problèmes de vsync habituels)
• Moins la taille de la fenêtre est petite, plus la gigue est fréquente
• La désactivation de vsync supprime la gigue (les points suivants sont avec vsync activé)
• L'exécution du jeu sans l'éditeur sur l'écran en même temps (minimisez-le, donc c'est juste un bureau - icônes, fond d'écran, barre des tâches et peut-être quelques fenêtres statiques comme le gestionnaire de fichiers ou le terminal) supprime la gigue
• Le jeu exporté ou exécuté depuis l'éditeur n'a pas d'importance
• Si je lance le jeu avec quakespasm-sdl2 sur le même écran (avec un zombie attaquant le joueur sous l'eau), je vois peu de gigue
• Si je lance le jeu avec un site shadertoy (cette démo: https://www.shadertoy.com/view/ll3fz4), sans pause, sur le même écran, je vois beaucoup de gigue
• Si je lance le jeu avec un site shadertoy, mais en pause, sur le même écran, je vois peu de gigue
• Si je lance le jeu avec l'éditeur sur le même écran, avec une scène affichée dans l'éditeur ne se mettant pas à jour (Player.tscn), je vois peu de gigue
• Si je lance le jeu avec l'éditeur sur le même écran , avec une scène affichée dans l'éditeur fréquemment mise à jour (main.tscn, j'ai un shader animé là-bas), je vois beaucoup de gigue

Vous n'avez pas essayé avec Aero désactivé, vous avez oublié comment le basculer rapidement dans les deux sens?

@ starry-abyss pour désactiver l'aero, allez dans le panneau de configuration, choisissez "apparence et personnalisation", là vous devriez pouvoir changer pour un vieux thème comme "Windows Classic", qui ne comporte pas d'effets visuels (et ensuite ne le fait pas) t utiliser Aero) ou "Windows 7 Classic".

OK, donc avec le thème classique, le jeu, avec shadertoy / éditeur à l'écran aussi, va et vient de l'état de bégaiement à l'état lisse (chaque état peut rester pendant plusieurs secondes). Et le bégaiement s'accompagne d'une déchirure verticale du cadre dans ce mode. Cela dit, même Firefox fait défiler les larmes avec le thème classique: 'D

J'ai exactement le même problème que diiiiiiiii, son cas d'utilisation avec move_and_slide est le même que le mien. Si vous regardez attentivement, ce n'est pas l'objet du joueur qui vacille, mais l'arrière-plan de parallaxe derrière lui.

Projet 2D avec personnages cinématiques
Godot 3.0.6
Win10 64 bits
Processeur Intel i5-2550K
16 Go de RAM
Geforce GTX 970

Étant donné que cela se produit sur de nombreux types d'appareils, je ne pense pas que cela soit strictement lié aux configurations matérielles. Cela se produit même sur les jeux exportés exécutés sur des appareils iOS.

Si vous regardez attentivement, ce n'est pas l'objet du joueur qui vacille, mais l'arrière-plan de parallaxe derrière lui.

@ behelit2 Je n'en suis pas sûr cependant. https://youtu.be/YVFtkbuyqEQ Dans cette séquence, si vous regardez l'objet joueur, il se trémousse même tout seul. C'est peut-être un problème distinct, mais cela devient bien pire lorsque le lissage de la caméra est activé ou que l'objet est basculé sur Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
C'est ce qui se passe lorsque le lissage de la caméra est activé et que l'objet passe à Rigidbody2D.

extends RigidBody2D
const SPEED = 7
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    apply_impulse(position, motion)

J'ai peut-être amplifié le jittering en utilisant apply_impulse () comme ça, mais la modification de la position de l'objet directement en utilisant set_position () ne faisait pas beaucoup de différence.

@diiiiiiiii Je pense que vous devriez alors ouvrir un autre problème. Sinon, le fil sera plein de déclarations contradictoires car les gens testent des choses différentes.
Par exemple, j'essaye le projet OP pour l'instant, pas le vôtre (désolé).

@ starry-abyss J'ai compris;)
Bien qu'il existe déjà de nombreux problèmes liés à la gigue et je pense qu'ils sont étroitement liés et peuvent avoir la même cause fondamentale.

Mise à jour sur le problème OP. J'ai trouvé quelques options dans Godot pour plafonner les fps sans utiliser v-sync. Donc, pour moi, c'est 60 fps avec v-sync désactivé et pas ~ 4000 maintenant.
Et le fait même de désactiver v-sync résout le problème pour moi.

Je me demande si v-sync a du sens en mode fenêtré. Windows semble utiliser v-sync par lui-même, et il se bat probablement avec le jeu Godot qui préparera l'image plus rapidement après la réception du signal v-sync. De plus, les autres jeux de l'IIRC ne se déchirent qu'en plein écran avec v-sync désactivé, et non en mode fenêtré.

Pour info, le problème de diiiiiiiii continue ici à la place: # 25162

Outre l'approche v-sync off, j'ai trouvé une manière intéressante spécifique à Windows (d'après la description du commit, cela pourrait être ce problème), je ne sais pas si Godot l'utilise déjà, mais peut-être que quelqu'un a le temps d'essayer:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Ceci est également lié: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

Cependant, il y a aussi ce fil qui entre plus en détail et avec différentes approches:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
Et c'est complémentaire, plus court et plus précis, mais aussi avec quelques émotions au début: https://www.vsynctester.com/firefoxisbroken.html

Changement du mot bégaiement en jitter dans mon rapport ci-dessus, car c'est ce que j'ai vécu (voir https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Mon idée était de désactiver la v-sync uniquement en mode fenêtré (c'est-à-dire que cela peut être fait à partir du code, voire interroger le taux de rafraîchissement du moniteur pour le plafond en fps), mais comme les développeurs principaux ne prennent pas en charge l'approche, il n'y a rien à reconsidérer encore. :) Il existe d'autres moyens plus spécifiques à Windows, mais nous devons encore prouver qu'ils fonctionnent bien et ne sont pas trop piratés.

Mise à jour sur le problème OP. J'ai trouvé quelques options dans Godot pour plafonner les fps sans utiliser v-sync. Donc, pour moi, c'est 60 fps avec v-sync désactivé et pas ~ 4000 maintenant.
Et le fait même de désactiver v-sync résout le problème pour moi.

Je me demande si v-sync a du sens en mode fenêtré. Windows semble utiliser v-sync par lui-même, et il se bat probablement avec le jeu Godot qui préparera l'image plus rapidement après la réception du signal v-sync. De plus, les autres jeux de l'IIRC ne se déchirent qu'en plein écran avec v-sync désactivé, et non en mode fenêtré.

comment avez-vous limité votre fps à 60?

Utilisation du champ "Force fps" quelque part dans la catégorie Déboguer des paramètres du projet

Воскресенье, 17 juillet 2019, 9:25 +03: 00 à FabiánLC [email protected] :

Mise à jour sur le problème OP. J'ai trouvé quelques options dans Godot pour plafonner les fps sans utiliser v-sync. Donc, pour moi, c'est 60 fps avec v-sync désactivé et pas ~ 4000 maintenant.
Et le fait même de désactiver v-sync résout le problème pour moi.
Je me demande si v-sync a du sens en mode fenêtré. Windows semble utiliser v-sync par lui-même, et il se bat probablement avec le jeu Godot qui préparera l'image plus rapidement après la réception du signal v-sync. De plus, les autres jeux de l'IIRC ne se déchirent qu'en plein écran avec v-sync désactivé, et non en mode fenêtré.
comment avez-vous limité votre fps à 60?
-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Je n'ai pas vu de personnes publier leurs processeurs avec des systèmes, à l'exception du I5-2500K qui intègre un GPU Intel.

Mon ordinateur portable a à la fois un GPU intégré Intel et une carte Nvida dédiée. Je me demande juste s'il pourrait y avoir un problème entre les deux gpu / drivers et godot

Peut être. Mais cela ne semble pas dépendre de gpu / cpu. Sur i7, 2700 + 1080ti peuvent être stuttery (fenêtré) et lisse sur le mobile i5 avec intel 4000 (surface pro de 1ère génération) - en plein écran.

C'est drôle, vous devriez dire que si je lance le projet de démonstration sur mes ordinateurs portables 940m, je vois le bégaiement. Cependant, lorsque je lance l'application à l'aide de l'Intel 530 dédié, je ne vois aucun bégaiement.

Accueil Windows 10
Processeur i3-6100H à 2,70 GHz,
GeForce 940M (26.21.14.3064)
Carte graphique Intel (R) HD 530 (26.20.100.6709)

Le bégaiement est-il visible dans ce projet ? (Déplacez-vous en appuyant sur les touches fléchées.)

Je viens de faire une exportation rapide en laissant l'interpolation activée et en définissant la physique sur 60:
940M il y avait des secousses occasionnelles mais pas de cisaillement
Intel 530 il n'y avait pas de saccades mais parfois un cisaillement vsync évident,

J'en ferai plus plus tard et je vous ferai savoir.

J'ai eu un certain succès il semble en plafonnant mon FPS à 60. Je ne sais pas si 60 est un nombre magique, mon écran peut supporter 144, j'ai essayé de fixer le plafond à 144, mais le bégaiement était toujours visible. J'ai abaissé mon FPS à 120, le bégaiement était toujours visible, mais pas comme "flou", ce qui me fait penser qu'il se produit juste à un intervalle inférieur. Suivi avec abaissement du FPS à 80, et le même résultat que précédemment, mais bégaiement maintenant visiblement plus lent. De plus, je devrais dire, j'ai désactivé v-sync et exécuté en mode fenêtré, j'ai testé avec plein écran, mais même résultat. Y a-t-il des processus dans le moteur plafonnés à 60 FPS?

Y a-t-il des processus dans le moteur plafonnés à 60 FPS?

Par défaut, la physique est simulée à 60 FPS, ce qui signifie qu'il y aura un écart visible lorsque le FPS de rendu est supérieur au FPS de physique (à condition que l'affichage soit suffisamment rapide pour montrer la différence). Le FPS physique peut être modifié dans les paramètres du projet ( Physique> Commun> Fps physique ).

Cela peut être atténué en interpolant les corps physiques, mais il n'y a pas de support officiel pour cela. Dans 3.2alpha, vous pouvez utiliser cet add-on de lissage qui facilite l'interpolation des nœuds.

Y a-t-il des processus dans le moteur plafonnés à 60 FPS?

Par défaut, la physique est simulée à 60 FPS, ce qui signifie qu'il y aura un écart visible lorsque le FPS de rendu est supérieur au FPS de physique (à condition que l'affichage soit suffisamment rapide pour montrer la différence). Le FPS physique peut être modifié dans les paramètres du projet ( Physique> Commun> Fps physique ).

Cela peut être atténué en interpolant les corps physiques, mais il n'y a pas de support officiel pour cela. Dans 3.2alpha, vous pouvez utiliser cet add-on de lissage qui facilite l'interpolation des nœuds.

Génial, merci, cela pourrait expliquer pourquoi les personnages bégaient lorsque le mouvement est géré dans l'appel de processus physique

Peut toujours se reproduire en 3.1.1 BTW, le moyen le plus simple est avec Shadertoy ouvert dans Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

Je suis tombé par hasard ici en espérant qu'il y aurait une solution, mais après avoir essayé presque tous les conseils que j'ai vu sur ce fil, toujours pas de dés. Pour moi, l'instabilité ne se produit que lorsque j'exécute le projet dans la carte NVIDIA. Si je l'exécute en utilisant le GPU Intel intégré, il fonctionne parfaitement. : /

J'utilise la dernière version alpha de Godot 3.2 sur Windows 10

Je suis tombé par hasard ici en espérant qu'il y aurait une solution, mais après avoir essayé presque tous les conseils que j'ai vu sur ce fil, toujours pas de dés. Pour moi, l'instabilité ne se produit que lorsque j'exécute le projet dans la carte NVIDIA. Si je l'exécute en utilisant le GPU Intel intégré, il fonctionne parfaitement. : /

J'utilise la dernière version alpha de Godot 3.2 sur Windows 10

Je ne pense pas que vous puissiez le réparer sur Windows, cela ne se produit pas sous Linux, cela pourrait être corrigé dans 4.0 avec le nouveau moteur de rendu vulkan.

Je suis tombé par hasard ici en espérant qu'il y aurait une solution, mais après avoir essayé presque tous les conseils que j'ai vu sur ce fil, toujours pas de dés. Pour moi, l'instabilité ne se produit que lorsque j'exécute le projet dans la carte NVIDIA. Si je l'exécute en utilisant le GPU Intel intégré, il fonctionne parfaitement. : /
J'utilise la dernière version alpha de Godot 3.2 sur Windows 10

Je ne pense pas que vous puissiez le réparer sur Windows, cela ne se produit pas sous Linux, cela pourrait être corrigé dans 4.0 avec le nouveau moteur de rendu vulkan.

Eh bien, ça craint, l'API Vulkan ne se concentre-t-elle pas uniquement sur les appareils haut de gamme?

Je cible spécifiquement OpenGL 2.0 afin de pouvoir prendre en charge les appareils bas de gamme. C'est un peu ridicule d'utiliser une API graphique très haut de gamme juste pour un jeu 2D et d'exclure les gens avec des ordinateurs / ordinateurs portables bas de gamme. 😕

Cela ressemble à un mythe. Peut-être que le bégaiement de temps en temps ne peut pas être réparé au guichet automatique, mais le stutterware que nous expérimentons est une fonctionnalité réservée à Godot.

Cela ressemble à un mythe.

À quoi faisiez-vous référence avec cela?

C'est une question difficile. D'une part, je voudrais personnellement résoudre ce problème dès que possible. Mais je ne peux pas me reproduire, donc je ne peux rien faire. (J'utilise Windows 10 avec une carte graphique NVidia)

Quelqu'un qui peut reproduire le problème doit essayer de le résoudre malheureusement. :(

Bien que ce soit un problème rare, il semble être assez courant pour attirer beaucoup de gens sur ce fil. J'espère que l'un de vous pourra y travailler.

Ah, j'oublie toujours que ce que j'expérimente s'appelle la gigue dans les termes officiels de Godot doc.

_ Est-ce que quelqu'un sait comment capturer parfaitement le problème en 60 FPS sans acheter de matériel? _
Je pense que certaines personnes sous-estiment à quel point cela a l'air merdique, et c'est peut-être aussi un problème d'apparence différente sur différents PC.

À quoi faisiez-vous référence avec cela?

Le mythe: "c'est toujours comme ça sur OpenGL (ou Windows, etc.). Seul Vulkan peut nous sauver".

D'accord alors:

1. ceci est une vidéo d'OBS: https://www.youtube.com/watch?v=osbJlk1XD8c L'impact d'OBS est que le simple fait d'avoir OBS en cours d'exécution rend cette gigue dans le projet Godot (même lorsque la capture est désactivée).
2. Sans OBS, c'est fluide jusqu'à ce que je minimise Firefox avec shadertoy dedans, puis il commence à bégayer, mais ne peut pas capturer avec OBS, car 1.

Chipping dans mon propre enregistrement, cela se fait avec Bandicam et pour la plupart, c'est comment il fonctionne avec ou sans enregistrement. Comme vous pouvez le voir, cela commence doucement mais commence progressivement à avoir des problèmes

@clayjohn Je pense que cela serait corrigé en implémentant une interpolation physique, mais reduz s'oppose à l'avoir dans le noyau pour plusieurs raisons. Pourtant, une méthode a été ajoutée en 3.2alpha pour exposer le rapport de pas de physique actuel, ce qui permet de mettre en œuvre manuellement une interpolation physique précise.

@ starry-abyss Si vous pouvez utiliser 3.2alpha, essayez le lissage-addon de pelousejelly: légèrement_smiling_face:

Juste une pensée, y a-t-il quelque chose d'utile dans un moteur irréel ou une source physX à regarder?

À votre santé,
Victor Stan

Le 22 octobre 2019 à 04h17, Hugo Locurcio [email protected] a écrit:

@clayjohn Je pense que cela serait corrigé en implémentant une interpolation physique, mais reduz s'oppose à l'avoir dans le noyau.

@ starry-abyss Si vous pouvez utiliser 3.2alpha, essayez l'addon de lissage de pelousejelly 🙂

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désabonnez-vous.

@victorbstan Nous ne devrions

Ne retirez certainement pas le code d'une source fermée, mais sur le plan architectural, pouvez-vous
pas glaner des idées de cela? [pas un avocat]

Le mar 22 octobre 2019 à 11 h 07 Hugo Locurcio [email protected]
a écrit:

@victorbstan https://github.com/victorbstan Nous ne devrions
Le code source d'Unreal, car il n'est pas sous licence open source. (Ce n'est pas
autorise même la redistribution aux utilisateurs d'Unreal Engine sans licence.)

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWWK3TUL52HS4DFVMD5CNFSM4FHBBLY2YY3PNVWWWK3TUL52HS4DFVMD3PNVWWK3TUL52HS4DFVMD5WWWWK3TUL52HS4DFV50VWWK3TUL52HS4DFV
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Je ne recommanderais toujours pas de regarder son code source. Si vous souhaitez vous inspirer d'un algorithme propriétaire, vous devez effectuer une rétro-ingénierie en

Pourtant, nous n'avons pas besoin de faire quoi que ce soit ici. La solution consiste à utiliser l'interpolation physique, que la plupart des moteurs de jeux populaires utilisent de nos jours. Il a quelques inconvénients (comme exiger du travail de l'utilisateur pour éviter l'interpolation lors de la téléportation d'objets), mais je pense que les avantages les dépassent de loin.

Je comprends, la suggestion est de se faire une idée des pistes possibles pour trouver une solution, pas forcément de plagier. Je n'imagine pas qu'il existe un brevet pour résoudre les problèmes de scintillement / bégaiement, mais IANAL.

À votre santé,
Victor Stan

Le 22 octobre 2019 à 14h07, Hugo Locurcio [email protected] a écrit:

@victorbstan Nous ne devrions pas regarder le code source d'Unreal, car il n'est pas sous une licence open source. (Il n'autorise même pas la redistribution aux utilisateurs d'Unreal Engine sans licence.)

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désabonnez-vous.

Dans mes scénarios, le profileur Godot montre parfaitement 60 FPS, même lorsque je vois de la gigue / du bégaiement. Cela signifie-t-il que le problème n'est pas lié à l'interpolation ou est-ce que je manque quelque chose?

Mon hypothèse était que les timings Godot ont été implémentés d'une manière qui interfère avec les timings des compositeurs de Windows (et peut-être que SDL le fait mieux que GLFW Godot, donc d'autres moteurs fonctionnent juste là où Godot échoue).

(et peut-être que SDL le fait mieux que GLFW, donc d'autres moteurs fonctionnent là où Godot échoue).

Godot utilise son propre code de gestion des fenêtres, il n'utilise ni SDL ni GLFW: légèrement_smiling_face:

J'ai Windows 10 et une nVidia GeForce GTX 1070 et, avec la version 3.2 alpha2 avec vsync activé, j'ai une gigue en mode fenêtré. Le mode plein écran semble bien. Le problème est particulièrement grave si l'éditeur n'est pas minimisé lorsque le jeu s'exécute. Le jeu avec lequel je teste n'utilise que _process() pour mettre à jour les positions. Pour cette raison, je soupçonnais que le problème était lié à un delta très bruyant ou à des trames perdues (grands deltas) mais ce n'est pas le cas. Le delta est en fait stable pendant le jittering.

Sur la base de la recherche d'autres personnes dans ce fil, j'ai piraté un changement de context_gl_windows.cpp pour définir l'intervalle de swap sur 0 et appeler DwmFlush() in swap_buffers() .

#include <dwmapi.h>

#pragma comment(lib, "dwmapi.lib")

...

void ContextGL_Windows::swap_buffers() {

    DwmFlush(); // Added this.
    SwapBuffers(hDC);
}

void ContextGL_Windows::set_use_vsync(bool p_use) {

    if (wglSwapIntervalEXT) {
        // changed this: wglSwapIntervalEXT(p_use ? 1 : 0);
        wglSwapIntervalEXT(0); // To this.
    }
    use_vsync = p_use;
}

Ceci est basé sur ce que font les projets glfw et Chromium .

Faire ce changement semble corriger la gigue en mode fenêtré. En mode plein écran, le jeu est déchiré, donc le DWM est probablement désactivé et un double tampon via une valeur d'intervalle de 1 semble être nécessaire. (Fondamentalement, le code doit faire ce qu'il fait actuellement.)

Si quelqu'un d'autre veut et peut essayer cela, je serais intéressé de savoir comment cela se passe.

Il semble que wglSwapIntervalEXT(0); part équivaut à désactiver v-sync dans les options.

Il ressemble à wglSwapIntervalEXT (0); Cela revient à désactiver la synchronisation virtuelle dans les options.

Il est. 1 - activer vsync, 0 - désactiver, et il y a aussi -1 pour "vsync adaptatif" (désactiver la synchronisation sur les fréquences d'images faibles, activer sur haut).

J'ai testé le truc DwmFlush () d'en haut avec mes cas simples, sur la branche 3.1.x.

• Il corrige la situation avec le cas de test shadertoy;
• V-sync on ou off - me ressemble (je n'ai pas patché la partie wglSwapIntervalEXT ());
• Le cas OBS est toujours instable (il a le même aspect je pense), mais Godot rapporte maintenant une chute de FPS à 40 (je me demande si le profileur de Godot se trouve réellement avec la version originale de Godot);
• J'ai également essayé d'appeler DwmFlush () après SwapBuffers (hDC), et les 3 points restent les mêmes.

Je ne suis pas sûr, mais je suppose que DwmFlush () après SwapBuffers (hDC) pourrait être plus correct puisque Godot met le cadre dans la mise à jour du compositeur le plus proche, pas sur le suivant, qui est après le plus proche.
Je me demande si Godot devrait mieux détecter si le compositeur est en cours d'exécution et revenir à la méthode vanilla v-sync si ce n'est pas le cas.

La prochaine fonctionnalité d'interpolation mentionnée par Calinou sera donc à essayer.

MISE À JOUR: oui, dans le cas OBS, le Godot signale un temps de traitement de 0,03 seconde (mais le FPS est signalé comme 60), probablement le compteur FPS de Godot ne prend pas en compte le fait de manquer le v-blank toutes les deux fois
UPDATE 2: malheureusement, le plugin d'interpolation ne semble pas aider ici; J'ai toujours de la gigue dans le cas OBS et du bégaiement et / ou un mélange de gigue dans le cas de shadertoy

Il semble que wglSwapIntervalEXT(0); part équivaut à désactiver v-sync dans les options.

Correct, mais l'ajout de DwmFlush() dans swap_buffers() amènera le jeu à utiliser le compositeur (DWM) pour la synchronisation. Lorsque le compositeur est activé, vous disposez effectivement d'un double tampon, que vous le vouliez ou non. Vous auriez un triple tampon dans le cas où vous définissez l'intervalle de permutation d'OpenGL sur 1. (Vos deux tampons et celui du compositeur.)

Je me demande aussi pourquoi les autres projets mettent l'appel à DwmFlush() avant SwapBuffers() . Cela semble en arrière mais je me suis presque convaincu que c'est juste.

Dans le cas de ces projets, ils n'utilisent pas le double tampon d'OpenGL (lorsque le compositeur est activé), donc le faire de cette manière semble être le meilleur moyen de se synchroniser avec la période vide verticale. Avec un intervalle d'échange OpenGL de 0, l'appel à SwapBuffers() ne se bloque pas donc vous présentez au compositeur l'image suivante dès que vous savez qu'elle a fini avec celle en cours. Cela a effectivement le même effet que l'utilisation d'un intervalle de permutation OpenGL de 1. (Lorsque le compositeur n'interfère pas - mode plein écran, par exemple.)
>
>

Je me demande si Godot devrait mieux détecter si le compositeur est en cours d'exécution et revenir à la méthode vanilla v-sync si ce n'est pas le cas.

Je pense que tu as raison. Il semble évident que la synchronisation virtuelle d'OpenGL s'arrête lorsque le compositeur est activé. Si vous regardez le code de glfw et de Chromium, ils appellent cela (en utilisant DwmFlush() ) un HACK. Il est probable qu'ils pensent qu'OpenGL est cassé dans ce cas et qu'ils doivent faire quelque chose qu'il devrait faire.

@ starry-abyss Après avoir relu votre article sur le cas OBS qui ne change pas, je me demande si ce projet a activé vsync. Puisque vous n'avez pas changé l'appel en wglSwapIntervalEXT() activation de vsync entraînera essentiellement le blocage du jeu dans DwmFlush() et SwapBuffers() . Cela expliquerait le temps de traitement de 0,03 seconde.

@TerminalJack Non, j'ai essayé toutes les combinaisons. Le temps de traitement augmente toujours à 0,03 lorsque j'exécute OBS. C'est juste que Godot semble faire de son mieux pour être à 60 FPS, même s'il ne pouvait pas atteindre plusieurs images de suite.

Je le diviserais donc en deux questions:
1) Godot n'est pas ami avec le compositeur;
2) Godot est trop désireux d'avoir un maximum de FPS alors qu'il pourrait simplement fournir 30 stables en cas de charge.

Mais s'il existe un moyen fiable de (dé) prouver si 0,03 est un temps de calcul pur et non de synchronisation, je peux l'essayer.

@ starry-abyss À des fins de test, vous pouvez utiliser le Gestionnaire des tâches pour augmenter la «priorité» de ce processus à «élevée». Cela l'amènera à devancer les autres et lui donnera la part du lion du temps de traitement. Autrement dit, tant qu'il est dans un état exécutable et non bloqué dans DwmFlush() et / ou SwapBuffers() .

Je n'ai pas eu beaucoup de chance de jouer avec cela aujourd'hui, mais j'ai essayé d'exécuter le changement sur un système Windows 10 doté d'un GPU Intel UHD Graphics 620 intégré. (Un GPU assez bas de gamme.)

J'ai d'abord lancé le jeu (en mode fenêtré) avec la dernière version 3.2 alpha2 et il n'y avait pas de gigue notable. J'ai ensuite lancé le jeu avec les modifications et cela a bien fonctionné également.

Il se trouve que j'ai enregistré les fois delta pendant les deux courses et j'ai trouvé qu'ils étaient beaucoup plus stables avec l'appel à DwmFlush() que sans ...

3,2 alpha2

0.016667 (10 times)
0.016501
0.016667 (15 times)
0.016628
0.016667 (3 times)
0.016646
0.016667 (5 times)
0.016659
0.016667 (6 times)
0.016571
0.016667 (2 times)
0.016661
0.016667 (10 times)
0.016626
0.016667 (13 times)
0.016567
0.016667 (8 times)
0.016653

Construire un test

0.018182
0.022628
0.018182 (3 times)
0.017982
0.016836
0.016781
0.016667 (5 times)
0.01671
0.016667 (129 times)
0.016935
0.016667 (13 times)
0.018094
0.016667 (2828 times)

(Les deltas élevés au début ici sont dus au fait qu'ils ont été pris juste après le chargement de la scène. La construction alpha présente le même comportement.)

Remarquez comment la version de test s'est finalement stabilisée et a atteint un état stable. La version 3.2 alpha2 ne l'a jamais fait.

Il semble donc que non seulement les autres GPU ne seront

J'ai créé un fork qui a un seul commit qui devrait résoudre ce problème.

Cependant, je ne l'ai testé que sur deux machines Windows 10, donc ce serait formidable si d'autres personnes pouvaient le construire et le tester sur d'autres versions de Windows. De plus, je l'ai construit en utilisant VC ++ 2019, donc si quelqu'un utilisant mingw pouvait le construire, ce serait bien aussi.

Si vous avez votre propre fork (récent) du projet, vous devriez pouvoir y appliquer ce changement sans aucun problème.

Im sur Windows 10 avec une NVidia GTX 1050.

Je n'ai pas de bégaiement dans l'exemple de projet à moins d'avoir un shadertoy ouvert et en cours d'exécution (comme décrit dans quelques commentaires ci-dessus).

Avec le commit de

@clayjohn Merci d'avoir testé cela. Je me demande si le problème dans votre cas n'est qu'une question de puissance de traitement.

Je peux exécuter un shadertoy 800 x 450 en arrière-plan et un jeu Godot (exécuté depuis l'éditeur) dans une fenêtre au premier plan et avoir très peu de gigue avec les modifications que j'ai apportées. La construction alpha2, en revanche, présente une gigue sévère dans les mêmes circonstances. Je fais partie des personnes qui ont une gigue sévère même sans aucune charge sur mon système, donc c'est probablement quelque chose à prendre en compte également.

@TerminalJack Bon point. J'utilisais le shader rainforest d'iq :)

Je pense qu'il y a aussi une forte probabilité qu'il y ait plusieurs problèmes en jeu ici. Comme @Calinou l' a souligné ci-dessus, de nombreux utilisateurs ont également résolu le problème lors de l'utilisation de la physique interpolée.

À ce stade, je pense que vous devriez PR votre commit, ça a l'air bien et faire un PR lui donnera plus de visibilité et facilitera la construction et le test pour les autres utilisateurs.

@clayjohn Oui, je suis d'accord qu'il y a probablement d'autres problèmes qui se comportent de la même manière.

En fait, j'ai commencé à essayer de localiser un problème avec un mauvais bégaiement qui se produit une fois toutes les 60 à 90 secondes et je suis tombé sur ce fil. (Il semble que quelque chose bloque le processus de 60 à 100 ms de temps en temps.) J'exécutais mon jeu en mode plein écran et je ne ressentais aucune gigue. Après avoir rencontré ce fil, j'ai essayé de l'exécuter dans une fenêtre et, voilà: je suis l'un des chanceux qui peuvent reproduire ce problème particulier.

Je vais probablement supprimer les déclarations de débogage de mes modifications et envoyer un PR dans quelques heures.

@TerminalJack Le fork n'est plus disponible (ou il est configuré pour être privé), pourriez-vous le rendre disponible à nouveau s'il vous plaît?

@Calinou Désolé. J'ai augmenté le référentiel alors je l'ai supprimé. Je vais le bifurquer à nouveau et réengager les modifications ici sous peu.

@Calinou Le nouveau commit est ici .

@TerminalJack Votre correctif semble être uniquement pour Windows mais je suis confronté au même problème sur Ubuntu.

@TerminalJack Votre correctif semble être uniquement pour Windows mais je suis confronté au même problème sur Ubuntu.

Oui, c'est certainement une solution Windows uniquement. Désolé.

Je ne sais pas s'il est nécessaire de faire quelque chose de similaire sur Ubuntu ou non. Je ne sais même pas s'il utilise un compositeur.

Je ne sais pas s'il est nécessaire de faire quelque chose de similaire sur Ubuntu ou non. Je ne sais même pas s'il utilise un compositeur.

En fait, il n'y a aucun moyen de le désactiver sur certains gestionnaires de fenêtres (y compris la valeur par défaut d'Ubuntu): légèrement_smiling_face:

@TerminalJack pourrait également avoir besoin d'une logique lorsque Aero est désactivé dans Windows 7, par exemple (IIRC ne se synchronise pas en v, donc Godot devrait probablement toujours se synchroniser lui-même dans ce cas)

@ starry-abyss J'espère que l'affaire sera prise. J'ai un vieil ordinateur portable sur lequel Windows 7 est installé. Si cela fonctionne toujours, je vais faire quelques tests avec lui et voir si des modifications sont nécessaires.

J'ai allumé mon ordinateur portable de 10 ans équipé de Windows 7 et j'ai testé mes modifications. J'ai dû utiliser le plus simple des projets pour tester. (Les GPU d'ordinateur portable étaient extrêmement mauvais à l'époque.) J'ai utilisé le projet de cet article. J'ai ajouté ce qui suit afin que je puisse basculer en plein écran / hors de l'écran.

func _input(event):
    if event is InputEventKey && event.scancode == KEY_F && event.pressed:
        # Switch into or out of full screen mode.
        OS.window_fullscreen = !OS.window_fullscreen

J'ai exécuté le projet avec mes modifications et sans et il n'y avait pas de différences notables dans les deux cas. Avec mes modifications, le compositeur serait utilisé pour la synchronisation virtuelle lorsque prévu (mode fenêtré, compositeur activé) et le double tampon OpenGL serait utilisé dans tous les autres cas.

La bonne nouvelle est qu'il n'y aura aucune modification nécessaire au _code_. Le code détecte si le compositeur est activé ou non comme il se doit. Il gère même le cas où vous activez ou désactivez le compositeur pendant que l'application est en cours d'exécution. C'est un cas que je n'avais pas prévu, donc je ne l'ai pas inclus dans les commentaires de swap_buffers() concernant les cas où la stratégie de synchronisation virtuelle change à la volée. C'est donc la seule chose que je dois changer pour autant que je sache.

L'une des choses évoquées sur irc aujourd'hui pour discuter de cela (et du PR de TerminalJack) est d'isoler l'erreur dans le delta d'entrée mesuré de l'erreur dans le delta de sortie.

Calinou a souligné que nous pouvons tester cela dans une certaine mesure en exécutant avec le commutateur de ligne de commande --fixed-fps 60 . Cela traitera le delta d'entrée comme s'il était toujours à 1 / 60e de seconde.

Il serait très utile que ceux qui rencontrent le problème (en particulier sous Windows) puissent nous faire savoir si cela a des effets sur la gigue.

@lawnjelly J'ai essayé rapidement avec et sans l'option de ligne de commande, mais malheureusement je ne peux pas reprocher le problème aujourd'hui%) Sauf le cas OBS, qui est toujours le même.
La valeur de l'option est-elle stockée entre les exécutions de l'éditeur par hasard?

La valeur de l'option est-elle stockée entre les exécutions de l'éditeur par hasard?

Non, ce n'est qu'un argument de ligne de commande (qui est sans état).

D'ACCORD. Aussi, BTW, l'option est-elle disponible dans Godot 3.1.1 (la version sur laquelle je fais la plupart des tests ici)?

D'ACCORD. Aussi, BTW, l'option est-elle disponible dans Godot 3.1.1 (la version sur laquelle je fais la plupart des tests ici)?

Si vous utilisez 3.1.1 pour tester cela, vous devrez déplacer des objets sur une distance proportionnelle au delta pendant _process, car il n'y a pas d'interpolation de pas de temps fixe.

@ starry-abyss Cet argument de ligne de commande a été ajouté dans la version 3.1, il devrait donc être également disponible dans la version 3.1.1.

Donc, --fixed-fps 60 n'a pas aidé avec le problème pour moi. Et exécuter directement le jeu à partir de la ligne de commande n'a pas aidé non plus (j'avais toujours une instance distincte d'éditeur à l'écran pour une reproduction plus rapide).

Et aussi essayé les deux à la fois, au cas où la requête --fixed-fps 60 impliquerait cela, toujours de la nervosité.

La difficulté à reproduire hier était parce que j'avais désactivé v-sync dans les options des tests précédents. : /

il n'y a pas d'interpolation de pas de temps fixe.

Bien sûr, je teste les méthodes une par une, pas toutes à la fois (pas comme le plugin d'interpolation + dwmflush + toute nouvelle idée).
Veuillez également inclure la prochaine fois les étapes spécifiques pour essayer la nouvelle idée, donc je n'ai pas à deviner les versions de Godot, à exécuter directement l'éditeur ou le jeu, etc. Je n'ai pas le désir d'essayer toutes les combinaisons possibles de tout (avec chaque idée doublant le nombre de combinaisons). : P

Bien sûr, je teste les méthodes une par une, pas toutes à la fois (pas comme le plugin d'interpolation + dwmflush + toute nouvelle idée).
Veuillez également inclure la prochaine fois les étapes spécifiques pour essayer la nouvelle idée, donc je n'ai pas à deviner les versions de Godot, à exécuter directement l'éditeur ou le jeu, etc. Je n'ai pas le désir d'essayer toutes les combinaisons possibles de tout (avec chaque idée doublant le nombre de combinaisons). : P

Je comprends car il n'est pas mentionné dans la documentation, et il n'y a pas d'interpolation de pas de temps fixe dans le noyau. Je devrais peut-être essayer d'écrire quelque chose à ce sujet pour les documents, je n'ai pas encore ajouté de documentation.

_Le résultat est le suivant: _
Indépendamment des autres problèmes (delta, OS), si vous utilisez la physique ou déplacez des objets dans _physics_process, actuellement Godot donnera de la gigue à la suite de l'aliasing entre les graduations physiques et les images réelles. Cela se produira dans une certaine mesure dans toutes les combinaisons de taux de ticks physiques / taux de rafraîchissement du moniteur, certaines seront pires que d'autres.

La méthode 'jitter fix' était une tentative de contourner ce crénelage en le faisant se produire d'une manière moins prononcée (cela se produira toujours). Pensez à l'aliasing d'escalier.

Afin d'éviter cette gigue de `` niveau de base '', vous devez actuellement soit
1) (Disponible dans toutes les versions de Godot) Déplacez les objets dans _process et déplacez-les d'une distance proportionnelle au delta. Ce n'est pas idéal pour les jeux car vous ne pouvez pas utiliser la physique et le comportement dépend de la fréquence d'images, mais cela convient aux tests de gigue.

2) (Disponible dans Godot 3.2 et les versions ultérieures) Interpolation à pas de temps fixe utilisée. Ceci n'est vraiment possible qu'en 3.2 avec la fonction Engine-> get_physics_interpolation_fraction (). Voir https://github.com/lawnjelly/smoothing-addon pour un exemple d'utilisation de cela.

Voici les conditions préalables AVANT de commencer à étudier la gigue. Ils donneront une relation linéaire entre la position d'un objet et le temps, ce que nous voulons.

Une méthode alternative (plus conviviale pour les débutants) pour y parvenir est le pas de temps semi-fixe, pour lequel j'ai un PR depuis juillet # 30798.

C'est la base de la recherche scientifique et des tests d'hypothèses. L'idée est de réduire autant que possible les effets de confusion et de les examiner un à la fois.

Il y a 3 facteurs principaux en jeu ici:

1) Relation linéaire entre la position de l'objet et le temps du jeu (voir ci-dessus)
2) Erreur dans les horaires d'entrée
3) Erreur dans les délais de sortie

Éliminez (1) comme ci-dessus. Eliminate (2) en utilisant l'argument de ligne de commande, vous pouvez alors examiner (3) de manière isolée.

En outre, pour toute enquête sur la gigue, vous devez déplacer des objets directement, pas via la physique, car la physique peut potentiellement ajouter de la gigue elle-même.

_Éditer:_
Je viens de jeter un oeil au projet de repro minimum dans ce fil (esquiver les creeps) et il se déplace avec la vitesse * delta dans _process, ce qui devrait être bien. Il repose sur is_action_pressed et personnellement, je supprimerais cela comme un problème possible, mais c'est probablement correct. Si vous utilisez un autre projet pour tester la gigue, faites attention aux points ci-dessus.

@lawnjelly je vois. J'avais l'impression que le plugin d'interpolation est toujours quelque chose de testé uniquement par quelques gars, et peut être bogué (et même ajouter à la gigue). J'ai donc pris ce qui est stable (3.1.1), c'est comme ça que "scientifique" fonctionne pour moi.
J'essaierai avec les nouvelles considérations la prochaine fois.

Je viens de jeter un œil au projet de repro minimum dans ce fil

J'utilise ma propre version du projet, car l'original utilise des animations (peut masquer la gigue) et a un sprite gris sur fond gris. Je vais l'ajuster pour qu'il réponde à vos critères.

Donc, --fixed-fps 60 n'a pas aidé avec le problème pour moi.

C'est une information très utile. Cela semble déplacer le doigt pointu du blâme vers le retard de sortie (et le compositeur), et donner du poids au type d'approche dans le PR. Cela suppose qu'il utilise une double / triple mise en mémoire tampon et maintient le pipeline alimenté, et ne laisse pas tomber les images.

Est-ce également le cas pour @TerminalJack avec l'argument de ligne de commande?

J'utilise mon propre projet, car l'original utilise des animations (peut masquer la gigue) et a un sprite gris sur fond gris. Je vais l'ajuster pour qu'il réponde à vos critères.

Ah bon, merci! : +1:

@lawnjelly je vois. J'avais l'impression que le plugin d'interpolation est toujours quelque chose de testé uniquement par quelques gars, et peut être bogué (et même ajouter à la gigue).

Un peu hors sujet, mais ça devrait aller (je n'y ai pas touché depuis quelques semaines), ne devrait pas introduire de gigue. Si vous trouvez des bugs, faites-le moi savoir sur le suivi des problèmes ou même faites un PR. : +1: J'ai l'intention de le mettre sur les addons officiels pour 3.2 _ quand j'y arriverai_: smile:.

@lawnjelly

Est-ce également le cas pour @TerminalJack avec l'argument de ligne de commande?

Désolé, je n'ai pas eu l'occasion d'essayer vos suggestions. Je suis en quelque sorte descendu dans un terrier de lapin sur le problème sur lequel je travaille.

@lawnjelly Suite à notre discussion dans le fil PR, j'ai juste pensé que je mentionnerais que vous aviez raison à propos de l'option de ligne --fixed-fps <fps> commande

Je me sers de cette option avec mes changements d'établir que l' utilisation DwmFlush() ne aide à l' extérieur lors de l' exécution de l'éditeur. Si vous désactivez DwmFlush() vous pouvez provoquer un bégaiement dans le jeu simplement en faisant glisser une autre fenêtre ou en passant votre souris sur l'une des tâches en cours dans la barre des tâches. De toute évidence, puisque le jeu fonctionne avec une priorité «Au-dessus de la normale», cela ne devrait pas se produire. (Et ce n'est pas le cas si DwmFlush() est utilisé.)