Godot: Problema de tartamudeo grave en un juego simple en 2D [Windows 10, Nvidia]

Hola, he actualizado mi informe porque lo probé en mi otra computadora (casa) y el problema está aquí al mismo tiempo que cambio la animación. Entonces, esta no es la animación que causa el problema. Creo que lo creí porque cuando vi que estaba en mi computadora portátil, tenía una pantalla pequeña. Aquí hay un video del problema (el video está a 60 FPS):
GodotStutter.zip

Si el video es una representación precisa de lo que está en la pantalla en tiempo real, entonces es mucho más tartamudeo de lo que jamás he visto mencionado en cualquier problema relacionado con el tartamudeo aquí. En serio, debe haber algo mal con esta configuración de Windows 10 / GTX 1060 (veo bastantes artículos en Internet que detallan el problema de rendimiento en Windows 10 / Nvidia después de las principales actualizaciones de Windows, pero no puedo decir si está relacionado).

Aquí hay un video del proyecto de prueba en mi sistema, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX con controladores propietarios recientes (390.59). Sin tartamudeo en absoluto (en Openbox, en KWin, el compositor estropea las cosas y hay un tartamudeo muy ligero cada 10 s aproximadamente).
StutterTest_LinuxNvidia_OK.zip

Por cierto, aquí hay una versión fija del proyecto de demostración firstGame_fixed.zip , el original tenía archivos divididos en tres carpetas diferentes de alguna manera ("firstgame", "firstGame" y "FirstGame").

El juego me da la misma cantidad de tartamudeo que en el video.
Sin embargo, desactivar vsync elimina la tartamudez por completo (pero el juego se ejecuta a 4000 fps).
Windows 10 64 bits nVidia GTX 1060 también aquí.

También probé como sugirió @Zylann aquí y obtuve los mismos resultados. Yo también tengo Win10 x64 y nVidia GTX 1060.

Editar: uso estos controladores de nVidia:
398.11-escritorio-win10-64bit-international-whql

Win 7 GLES2 y GLES3 de 64 bits probados, GeForce GTX 660 / PCIe / SSE2 ... sin tartamudeos. Al encender Aero, con el editor 2d de godot detrás del juego, se produce un pequeño tartamudeo (el renderizado del editor de Godot interfiere con la renderización del juego).

Sin embargo, la tartamudez de Godot es el gigante enemigo invisible, todos sabemos que está ahí pero no queremos mirar muy de cerca porque sabemos que la solución no es sencilla.

Su problema parece que se corrigieron fps de física diferentes con la frecuencia de actualización del monitor, veo este tipo de tartamudeo en monitores que no tienen los mismos hz que el editor configuró fps de física, pero puede ser otra cosa.

Su problema parece que se corrigieron fps de física diferentes con la frecuencia de actualización del monitor

La demostración no usa física, solo un simple _process .

Es cierto ... digo que solo veo ese tartamudeo pesado en este caso, pero es cierto que no hay ningún proceso físico involucrado. Probé cambiando hz de uno de los monitores y no hay diferencias, 0 tartamudeo en mi equipo.

Editar: Gané 7, gano 8.1 y gano 10 en esta computadora y me tomo el tiempo para probar todo. No tartamudea en win 8.1. Estoy probando en win 10 ahora y es muy suave ... no hay problema de Windows. ¿Godot está enojado con tu 1060?

Aquí está la misma prueba con mi computadora portátil. Como puede ver, el problema también está aquí. Pero parece que eso es menos visible pero está aquí.

Especificaciones del portátil: Windows 10 - Geforce 940M

Aquí está el video de la computadora portátil (es un video de 60 FPS):
GodotStutterLap.zip

¿Alguien con el problema de tartamudeo puede intentar ejecutar el cambio de demostración en Player.gd _process con _physics_process?

Lo probaré esta noche en mi PC de casa, aquí es donde tengo el problema todo el tiempo. Pero tengo una cosa extraña: esta mañana, les di un video con el proyecto en mi computadora portátil y como pueden ver tienen el mismo tipo de tartamudeo. El problema es que ahora, si lo ejecuto de nuevo, no tengo este tartamudeo de nuevo, como si fuera aleatorio. Y no cambié nada en mi computadora portátil, trabajé en ello toda la mañana en una sesión de TSE.

Advertencia: hablo solo por mi computadora portátil. En mi PC de casa con GTX 1060, el problema siempre está aquí. Pero en mi computadora portátil, el problema parece ocurrir al azar. Es por eso que creo que por ahora, dejaré mi computadora portátil a un lado para fines de prueba y probaré solo en la PC de mi hogar que tenga el problema todo el tiempo, para poder aislar el "error".

@Ranoller Lo probé y obtuve el mismo resultado. El tartamudeo sigue ahí y prácticamente se ve igual.

@Ranoller Hizo la prueba y lo mismo à @RaXaR que no cambia nada. Tengo el mismo problema.

Esto no se ve bien ....

Para especificar exactamente el error, haría estas pruebas:

1) Pantalla completa encendida - apagada
2) Si hay más de 1 monitor:
Deshabilitar: habilitar el escritorio compartido
3) Aero encendido-apagado

¿Tus cartas funcionan bien en otros juegos? ...

Leyendo el primer post sobre la animación -> tartamudeo / sin animación -> sin tartamudeo leo el código y veo algunas cosas que no creo que sean correctas ... exactamente: cambiando la animación en cada cuadro. Creo que el código debería verificar la animación actual. Probablemente no cambió nada, pero si alguien quiere probar para cambiar Player.gd de esta manera:

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)

Esta es la última idea ... probablemente olfato para el problema, pero ... tu tarjeta gráfica es muy común en los jugadores, así que godot debería funcionar bien en ella.

@Ranoller

Por :

• El primer punto: ya probé la pantalla completa o no, no cambia nada

• 2: Ya intenté ejecutar con un solo monitor (esa es mi configuración común, pero a veces también tengo un segundo monitor, así que probé ambos) y no cambia nada.

• 3: Tengo que hacer una prueba (debería poder hacer esto esta noche (hora de Francia).

• 4: Tengo que probar su código (debería poder hacer esto esta noche (hora de Francia).

Acabo de probar su código y no cambia nada :(

Aunque este problema puede no estar directamente relacionado con godot, godot debe revisar bien los problemas de tartamudeo ... no es cierto que todos los juegos tartamudean como se dijo en otro hilo. Hoy estaba jugando n ++, pantalla completa, ventana, tratando de ver cualquier tartamudeo y no ... ningún tartamudeo en absoluto. Lo mismo ocurre con Ori y el bosque ciego, para que haya muchas cosas malas que hacer para tener algún tartamudeo en este juego (ventanas con otros programas en segundo plano, etc .... y solo 2 o 3 saltos de fotogramas en una hora ...). Godot, al iniciar la ejecución, siempre tartamudea x número de segundos, luego se estabiliza, pero cada X segundos vas a tener saltos de fotogramas (si no tienes el problema del gtx1060 claro). No debemos tratar este tema como un problema menor.

Intento hacer todo lo posible para aislar el problema, pero a mi nivel es un poco difícil. Intenté probar diferentes configuraciones pero sin resultado. También probé una imagen de fondo en lugar de usar un color con pantalla clara. Ya he visto (no lo recuerde) un motor con este problema porque la renderización de un sprite 2D en una "pantalla vacía" causa este problema, pero parece que ese no es el caso aquí. Entonces no tengo ni idea por ahora.

Por curiosidad, intente perfilar cuánto tiempo tarda SwapBuffers en context_gl_win.cpp alrededor de la línea 68. Si tarda más de 16 ms, es probable que esté dejando caer un marco aquí.

Si alguien que conoce las fuentes de Godot pudiera probar que soy interesante en el resultado (perdón por mi inglés ...)

Ayer estuve jugando con este problema y se resolvió mágicamente después de que las ventanas del juego se estuvieran ejecutando durante unos 60 segundos. Entonces fue suave, ¿esto me dice que podría ser una cosa de almacenamiento en caché?

Por curiosidad, intente perfilar cuánto tiempo tarda SwapBuffers en context_gl_win.cpp alrededor de la línea 68. Si tarda más de 16 ms, es probable que esté dejando caer un marco aquí.

Quizás podría ser útil saber si el problema ocurre en GLES2, no probamos eso

Intenté jugar con opciones en Godot al respecto, pero no cambia nada para mí, ¿puede ser que no sepa exactamente qué cambiar?

Intenté dejar el juego durante más de 2 minutos, pero el problema siempre está aquí y no se resuelve para mí después de 60 s.

Tuve un problema similar con 3.0.3. (Win10 64 bit, Nvidia 660) No lo noté con 3.0.2.

Creo que tiene algo que ver con el nodo AnimatedSprite porque veo los problemas de rendimiento con los niveles que tiene este nodo. Obtengo el encofrado cuando ejecuto desde el IDE o si exporto a Win 32bit, pero si exporto a Win 64bit todo funciona como debería, sin tartamudeo.

... curiosamente, no tengo el problema con el proyecto de ejemplo 'FirstGame.zip' ... pero aún lo tengo con mi juego, el FPS cae a 5 cuando se ejecuta desde el IDE y la versión de 32 bits, la GPU se encuentra alrededor del 2% .. .pero, con la GPU de exportación de 64 bits está al 30% y todo está bien.

Hola, ¿hay alguna noticia sobre este problema? Acabo de probar con la demostración de pong (no hice eso antes, solo con el juego tutorial) y parece que el problema también está aquí con este proyecto de muestra. Utilizo la última versión de Godot en Steam para probarlo.

La actualización de los controladores de Nvidia no cambió nada, así que vengo a llevar algunas novedades sobre este tema. Todavía no encontré cómo librarme de él.

Ahora tengo una computadora con una geforce gtx 1060 (3gb- barata) y no tengo el problema en Windows 10 Home. ¿Puede ser alguna aplicación de fondo? Alguna configuración de hardware específica AMD-Nvidia Intel-Nvidia ....? No tengo ninguna aplicación de juego en esta computadora (está en mi estudio de grabación de música) pero godot funciona sin problemas incluso con 3 pantallas conectadas a la computadora. Cualquiera que tenga el problema puede comprobar si tiene algún software de monitorización de juegos ejecutándose en segundo plano, Steam o algo como esto ... ¿Y si lo tienes, intenta desactivarlo?

Es difícil apagar Steam cuando lo usas para iniciar Godot ... Godot funciona muy bien, el problema es el juego con el que haces. Ya intenté deshabilitar todo lo que puedo deshabilitar, eso no cambia nada. Hice muchas pruebas sin éxito. También intenté restablecer los controladores de nvidia, por ejemplo, actualizarlos, etc. pero no cambia nada.

Por otro lado, tengo un montón de motores que funcionan sin problemas, ¿por qué no Godot? Eso es lo que traté de encontrar. Pero por ahora no encuentro nada. Hay algo en alguna parte pero qué y dónde, esa es la pregunta :-)

Este problema es demasiado "específico del desarrollador del motor" para encontrar una solución aceptable mediante una búsqueda propia. Puedo buscar durante horas el código de godot y sé que nunca tendré la posibilidad de encontrar algo relacionado con esto ... sé que a los desarrolladores de motores les gusta más código, nuevas funciones y "corrección de errores" se considera más "trabajo junior " o algo como esto. Pero con este tipo de problema no es el caso. Necesitamos un desarrollador de motores para autoasignar este problema y otras correcciones de errores "complicadas, fantasmas, de bajo nivel y difíciles de pagar"

Menciono que ya probé la versión dev (sin Steam) y el problema es el mismo.

Hola, tuve exactamente el mismo problema de tartamudeo (usando Godot 3.1 de la fuente Git), cualquier movimiento se retrasó para mí, exactamente como en su video, ya sea move_and_slide o simplemente movimiento del reproductor de animación. pero activar V-Sync en la configuración del proyecto resolvió completamente el problema de tartamudeo en el juego 2D.

Estoy un poco confundido porque @Zylann dijo que apagar V-Sync eliminó el tartamudeo, pero para mí es lo contrario.

@Qws apagarlo Y hacer que el juego se ejecute a más de 60 fps (lo que hizo en ese momento) hizo que el tartamudeo desapareciera para mí, pero trae otros problemas (usar toda la energía disponible y hacer fallar todo lo que no usó un delta adecuado hora). Si tienes tartamudeo con V-sync desactivado, entonces se debe a un tiempo delta inadecuado o una situación en la que el juego tiene que esperar / procesar más de un marco para actualizar la pantalla.

La primera prueba que hice con el nuevo gtx 1060 no dio ningún problema ... pero luego experimento ese tartamudeo. Lo único que cambié es la conexión dvi a hdmi (y algunos programas instalados) ... esto es un poco extraño. Lo único que me convenció es que el problema no está en el lado de Windows 10.

Diré esto mucho. Estoy trabajando en un tutorial de juego en 2D "Hoppy Days" de los tutoriales de Gamedev.tv. Estaba usando 3.0.2 para desarrollarlo, y estaba funcionando bien. Noté que el tutorial usaba 3.0.4, así que literalmente HOY decidí actualizar a 3.0.6. Ahora hay un retraso notable en el juego. _El retraso no estaba allí en absoluto en 3.0.2_ . Está ahí ahora. Todas las demás configuraciones son las mismas.

Mi computadora portátil es una computadora portátil para juegos Dell Inspiron 7000 series bastante nueva (comprada en marzo de 2017). El procesador es Intel Core i7-7700HQ Quad Core de séptima generación (caché de 6 MB, hasta 3,8 GHz). La tarjeta de video es NVIDIA GeForce GTX 1050Ti con 4GB GDDR5. La RAM es de 16 GB, 2400 MHz, DDR4. El disco duro es un SSD de Samsung. Windows 10.

Para mí, parece que algo cambió en 3.0.4 o 3.0.6 ..... Nada más ha cambiado en absoluto. Ni siquiera el juego (como en ... No he cambiado / editado / actualizado el nivel en absoluto).

@ emo10001 ¿Podrías probar 3.0.3? Fue entonces cuando cambiamos el sistema de compilación utilizado para crear binarios 3.0.x (3.0 hasta 3.0.2 se construyeron en AppVeyor CI con MSVC 2015, 3.0.3 hasta 3.0.6 se construyeron con GCC 8 a través de MinGW).

Si su computadora portátil tiene Optimus / gráficos intercambiables, es posible que su sistema haya incluido en la lista blanca el binario 3.0.2 que se usará con la GPU Nvidia, mientras que 3.0.3+ tendría un IGP predeterminado. O podría ser que 3.0.2 fue incluido en la lista blanca por su antivirus, mientras que 3.0.3+ se considera que proviene de una fuente diferente (lo cual es cierto) y aún no se considera seguro, por lo que el antivirus ejecutará sus comprobaciones completas e impactará el rendimiento.
Esas son solo conjeturas, pero de lo contrario no estoy seguro de qué cambio real de Godot afectaría el rendimiento de esa manera, por lo que solo puedo pensar en cambios en el sistema de compilación.

CC @hpvb

¡Estoy teniendo el mismo problema! Mi proyecto tartamudea durante 20 a 30 segundos, luego se ejecuta sin problemas. Descargué el proyecto en la publicación OP y es exactamente lo mismo.
Apagar V-Sync elimina el problema y funciona a más de 4000 fps.

Estoy ejecutando la versión 3.0.6 en Linux Mint 19 (así que supongo que la etiqueta de Windows no es correcta, ¿eh?) Y GTX 760 con los últimos controladores propietarios.

Estoy ejecutando la versión 3.0.6 en Linux Mint 19 (así que supongo que la etiqueta de Windows no es correcta, ¿eh?) Y GTX 760 con los últimos controladores propietarios.

No, pero probablemente este sea un problema diferente. El tartamudeo en Linux a menudo ocurre debido a la composición del administrador de ventanas (por ejemplo, tengo algunos con KWin, ninguno con Openbox).

Mi proyecto tartamudea durante 20 a 30 segundos, luego se ejecuta sin problemas

Me doy cuenta de esto mucho, si ejecuto la escena que estoy editando, hay tartamudeo y algo de desgarro (con vsync activado) alrededor de 15-30 segundos, pero si comienzo el proyecto desde el menú principal y abro la escena con el selector de escenas ... bueno, no hay tartamudeo en la misma escena (eventualmente lo hay, pero nunca). ¿Hay alguna explicación sobre este evento? Godot? Windows? ¿Cuántos fotogramas son necesarios para estabilizar la reproducción? ... será genial saber esas cosas porque son necesarias para el diseño del juego.

No, pero probablemente este sea un problema diferente.

Hmm ya veo. Lo que quise decir es que este problema específico probablemente sea multiplataforma ya que muchas personas están experimentando los mismos problemas.

Estuve jugando y noté que dos cuerpos cinemáticos tartamudean exactamente al mismo tiempo, tanto para move_and_slide () como para move_and_collide ().

Conectando una cámara a uno mientras ambos oscilan, todo en la escena tartamudea excepto los dos nodos cinemáticos. Una cámara estática muestra sólo los dos nodos cinemáticos tartamudean.

No parece importar qué configuración gráfica cambie, ni _process o _physics_process. tampoco el uso de una variable delta diferente.

Creo que este proyecto no es representativo del uso real ... los proyectos más complicados funcionan sin problemas. Creo que Windows no maneja bien un tiempo inactivo de godot excesivamente grande ... Encontré otro problema relacionado, no solo para godot sino que sufre mucho con eso: en multimonitor con juego de escritorio extendido es más suave en el monitor 1 si esto se etiqueta como "monitor principal". Si el monitor principal es distinto de 1, hay tartamudeo en el monitor secundario (youtube sufre de eso, pero no juegos comerciales de unidad como ori). Con pantalla completa en monitor secundario, aero en win 7 y monitores intercambiados (ej: monitor 2 como primario) el escenario es el peor y hay un gran tartamudeo (no solo godot, sino ni game maker o juegos de unidad) ... Sé que multimonitor con escritorio extendido en 2 pantallas de 1080p es difícil para GPU baratas, pero otros juegos son más suaves (godot no pierde fps, solo tartamudea). Si esta prueba continúa, deberíamos hacer un ejemplo más complejo.

@Ranoller mi configuración es un monitor dual en un gtx 760, segundo monitor etiquetado como 'primario', linux mint 19 con canela. Estaba tratando de entender la condición específica que tartamudea el proyecto, pero no pude entender. Estos pequeños proyectos a veces tartamudean, a veces no (solo tartamudean, sin pérdida de fps). Además, cuando tartamudea (ejecutándose en ventanas, configuración de prueba de godot), generalmente tengo una o más ventanas de Chrome en el segundo monitor (no el principal), y cuando las minimizo, el tartamudeo desaparece ... después de minimizar / restaurando las ventanas cromadas, el tartamudeo ha desaparecido por completo.

Tengo 2 computadoras -> una con i5 gtx660 2 pantallas 1080p y otra con i7 gtx 1060 3 pantallas (2 1080p y otra hdready) ... bueno, tengo este problema de tartamudeo relacionado con monitores secundarios en gtx660, creo que está relacionado exclusivamente con renderizado, godot y chrome stutters, game maker y unity don´t (juegos comerciales, exactamente HiperLightDrifter y Ori, no probé demos ni templates). Windows aero tartamudea más en pantalla completa (creo que no es realmente pantalla completa) pero tiene muchos fps, sin aero en win 7 tengo en mi proyecto 130-140 fps sin vsync, con aero paso 400 fps, pero. .. tartamudea (mucho) en determinadas condiciones (con y sin vsync). No puedo hacer que godot tartamudee en el i7 gtx 1060 (con un proyecto real, la demostración en este hilo tartamudea y explico mi opinión sobre Jet). Creo que es un problema de optimización / OpenGL, ej: Light2D es apenas inutilizable, cualquier modo de mezcla que no sea "mix" puede tartamudear si el sistema no es demasiado poderoso, pero godot debería manejar la permormancia en el mismo nivel que el creador de juegos o la unidad. Probablemente una vez que se lanzó 3.1, el trabajo para la optimización podría comenzar (si el problema se puede solucionar y no es un problema de Direct3D / OpenGL - Windows, por supuesto ... no sé cómo encontrar juegos GLES2 / 3 en Windows para probar y tarjeta de disco un problema directo OpenGL - Aero / Win7-8-10) ... Entiendo que la permanencia de godot nunca será la misma que la propiedad -> motores basados ​​en un juego (Ej: Rayman origins funciona sin problemas en una computadora portátil vieja , godot 2 no), pero debería renderizarse al menos al mismo nivel estable que el creador de juegos (Unity probablemente estará mejor optimizado que godot durante mucho tiempo, ya sabes, el dinero ...). Por ahora, siento que godot funciona bien solo en hardware de gama alta o en pantallas de baja resolución (pruebo en una computadora gráfica Intel HD i5 win7 de 32 bits y 15 "y funciona bien, pero no creo que con una pantalla HD esta computadora funcione bien. corre sin problemas) ...

Por supuesto, todas esas son mis opiniones / experiencias, puedo estar equivocado (y espero estarlo ... si esto fuera una solución simple de una línea, ¡podría ser genial!)

Por otro lado, recuerdo leer reduz escribiendo algo relacionado con la "prioridad de proceso" del ejecutable godot, pero en Windows no hay diferencia si cambias manualmente la prioridad de godot en la ejecución, godot no tiene un rendimiento inferior ¿inventó una palabra?), la ejecución del programa no tiene picos, es el renderizado, algo relacionado con nvidia / godot y el escritorio de la computadora (en windows, no intento en linux)

Hola, entonces, ¿hay alguna noticia sobre este problema? ^^ Volveré a probar con la versión más reciente pero parece que el problema sigue ahí.

¿Esta salida en la plataforma Android o iOS ahora? Hay algunos juegos en la tienda de Google creados por Godot temprano que también tienen problemas con el obturador, como: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Esto existe en todas las plataformas probadas en determinadas circunstancias, con diversas GPU´sy diversos sistemas operativos ... no está documentado en consolas.

Lo probé tanto en Linux como en Windows y funcionó sin problemas con el pequeño tartamudeo ocasional, tengo una tarjeta gráfica integrada de gama baja Intel HD Graphics Baytrail

Después de muchas horas de intentar averiguar la causa del tartamudeo, al menos en mi caso, por casualidad rastreé el tartamudeo de 1s constante hasta tener el 'Cambio automático al árbol de escena remota' habilitado en 'Configuración del editor'. Desmarcar esto me resuelve los problemas de tartamudeo y rendimiento. (Es posible que todavía haya un tartamudeo muy leve, pero apenas se nota).

Godot compilación 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit, NVIDIA GeForce GTX 660, controlador v416.81

También tengo el problema de la tartamudez con mi juego. Lo único que parece mejorarlo es apagar y encender la pantalla completa mientras se ejecuta el juego ... E incluso entonces hay un ligero tartamudeo que se repite después. Parece suceder completamente al azar. A veces, el juego se ejecutará casi a la perfección, otras veces se produce el tartamudeo.

Proyecto 2D con personajes cinemáticos.
CPU Intel i5-2550K
16 gb de ram
Geforce GTX 970
Win10 de 64 bits
Godot 3.0,6

En win 10 se producen tartamudeos más en pantalla completa, y es porque Aero (Y se puede desactivar). Parece que Godot usa menos CPU y más GPU con Windows Aero pero esto provoca más tartamudeo. En Windows 7, al deshabilitar Windows Aero, la pantalla completa tiene menos tartamudeo que la ventana y usa más CPU. Creo que win 10 no tiene pantalla completa real ...

Empecé a hacer un prototipo de juego de pinball 2D y me tengo demasiado nerviosa en el movimiento de la bola, solo tengo un cuerpo rígido que cae con la gravedad. Estoy en Win10 / NVidia GTX 560 Ti 1Go (con los controladores más recientes) / 8 Go Ram, mi computadora no es la mejor, pero mi proyecto solo tiene una bola y StaticBody2D para los bordes y puedo ver claramente que los temblores ocurren muy a menudo. Lo he intentado con y sin vsync, con opengl 3.0 y 2.0, ventana y pantalla completa, con más y menos fps físicos, el problema sigue aquí.
Mi versión de Godot es 3.1 alpha.
Creo que es un problema importante, tal vez difícil de solucionar, pero no debe omitirse, es importante tener un movimiento 2D fluido para un juego 2D.

Tienes razón, Godot tiene ahora la mejor usabilidad de todos los motores principales (mi opinión, por supuesto). El lado de la usabilidad los supera a todos. Pero ... el lado del rendimiento ... el lado de la exportación ... es como si godot estuviera latiendo con el sistema operativo, no como las exportaciones de unit o game maker que son más fluidas (hasta que la construcción en Chrome es más fluida ), y no es porque la lentitud de gdscript (sucede con y sin GDScript), hay "otra cosa indeterminada", espero que algún día alguien pueda encontrar una línea rebelde en un archivo cpp y cambiar un simple "!" este problema se solucionará ... (¡la esperanza es gratis como Godot!)

Tengo varios proyectos en mente y me encantaría hacerlos con Godot, me llevará mucho tiempo (por no decir todo mi tiempo libre), pero me entristece decir que si el motor no puede garantizar un movimiento 2D suave en la animación con una escena simple, el motor a pesar de todos estos pros es simplemente inútil. En este caso, quizás la opción más sabia para mí sea no arriesgarme a perder el tiempo de esta manera.

Entiendo que este problema aparece solo en algunas configuraciones (controladores de Windows 10 y NVidia, por ejemplo) pero me gustaría saber:

• ¿Este problema (o uno similar) ya está planeado en un hito o no?
• ¿Es posible que este problema se deje de lado esperando el reemplazo de OpenGL por Vulkan en el hito 3.2?

PD: lo he intentado con otra PC:

• Intel i7 4790K 4,00 Ghz
• Win10 64 bits 16 Go RAM
• NVidia GTX 1060 3Go (con los controladores más recientes)
• Godot 3.1 alpha oficial
  y tengo el mismo problema con escenas simples.

Creo que este tipo de configuraciones de PC (tarjetas Win10 + Nvidia) son muy comunes, y espero que la comunidad Godot (que por cierto hace un gran trabajo) solucione este problema muy pronto y que los buenos juegos 2D comiencen a lanzarse para mostrar que podemos hacer con Godot pero con este tipo de problema para mí es simplemente imposible.

¿Quizás es algún tipo de problema de enfoque del programa? Cuando comienzo un juego en pantalla completa, veo el tartamudeo básicamente todo el tiempo. Pero si (mientras el juego se está ejecutando) cambio al modo de ventana y vuelvo a la pantalla completa, parece que funciona perfecto en todo momento. Si yo también lo hice, puedo programar esto para que suceda automáticamente, pero parece chiflado. ¿Alguien más puede confirmar que el cambio de pantalla completa a ventana, a pantalla completa nuevamente corrige la tartamudez?

Editar: Ah, y otra cosa ... Cuando desactivé la aplicación Geforce Experience, las cosas parecieron mejorar.

Proyecto 2D con personajes cinemáticos
Godot 3.0.6
Win10 de 64 bits
CPU Intel i5-2550K
16 gb de ram
Geforce GTX 970

Probé lo que propones, deshabilité Geforce Experience, intenté cambiar de pantalla completa a ventana, a pantalla completa nuevamente, con vsync habilitado y deshabilitado (es peor con vsync deshabilitado) pero la tartamudez parece siempre desafortunada para mí.
Es bastante aleatorio, pero nunca he superado los 15-20 segundos sin tartamudear.

¡Gracias por intentarlo! Eso es tan extraño, tus especificaciones son mejores que las mías. El problema conmigo es que es tan aleatorio ... Es difícil reproducirlo con precisión. A veces funcionará muy bien, otras veces tartamudeará. Sin embargo, estoy bastante seguro de que tiene algo que ver con Godot. Nunca experimento tartamudeo en juegos hechos en Unity, o cualquier otro motor de juego para el caso.

Acabo de notar este tartamudeo.

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

Como ya han mencionado otros, este es un problema serio para Godot. Esta semana decidí crear un prototipo para un juego muy simple. Busqué un marco o motor (encontré muchos de ellos) y decidí ir con Godot, ya que es gratis y abierto. Luego noté el tartamudeo, encontré este problema y me sorprendió que no pareciera haber ningún progreso. De todos modos, supongo que haré un prototipo de mi idea en Godot. Pero si quisiera crear un juego liberable, probablemente probaría con otro motor. (Esto suena demasiado duro ... solo creo que Godot podría perder muchos adoptantes potenciales si el problema no se soluciona).

No hay avances porque no hay nadie trabajando en esto, y sí, es un tema grave. Pero por ahora, si necesitas lanzar un juego comercial, puedes hacer un prototipo en godot y portar a la unidad (puedes usar C #). Debes tener en cuenta el enfoque de escena-juego-objeto-componente y puedes replicar en godot y si funciona ir a la unidad para flujo fluido y rendimiento, o si es 2D, ir a gamemaker. Estoy trabajando en un complemento para intentar convertir un proyecto de godot a otros motores e intentar portar gdscript a un módulo, a gml o a la unidad C #, pero es una tarea muy grande (no sé si el esfuerzo vale la pena es demasiado tiempo sin trabajar en el juego) y siempre será imperfecto (no puedo obtener todos los tipos, ej: objeto devuelto por colisión). Tengo un pequeño analizador para los scripts e iniciaré un analizador para tscn y tres, pero convertir el resultado del analizador de gdscript a unity c # o gamemaker GML requiere una tonelada de código y no sé la "legalidad" de esto (i Necesito todos los nombres de api, ej. en archivos json y no sé la IP de esto). Las animaciones son otro problema, no sé por ahora cómo abordar eso, pero usar spine / dragonbones será fácil de portar. Mi idea principal de hacer eso era comenzar en godot y terminar en unity o gm, pero para niw es un dolor de cabeza ... Si la unidad fuera igualmente portátil (lo necesito), pequeña y rápida de desarrollar como godot (y tener 32 bits editor) Hice portar mi proyecto principal hace meses, me encanta Godot, pero para un proyecto de tamaño medio en un equipo pequeño (o un hombre soltero como yo) es un riesgo, nadie te garantiza que un proyecto terminado no dará una tonelada de problemas. Pero si hay un buen programador de C ++ en tu equipo, es otra cosa, siempre puedes adaptar godot a tu juego (en unidad no puedes, pero tiene menos errores) ...
Odio este problema como odio el bajo rendimiento del editor en un proyecto intermedio y el juego exportado, pero odio más unidad (¿por qué necesito Internet en todas las computadoras para abrir el editor? ¡Tengo una computadora sin eso!) Y odio tan profundamente visual studio ... Estoy seguro de que si godot detiene la tartamudez y trabaja en el rendimiento y la exportación, podemos empezar a ver grandes juegos en ascenso.

Para volver a verificar este problema hoy, hice lo siguiente, todavía en Windows 10 con nVidia GTX 1060:

Abrí The Binding of Isaac, modo ventana. Corrí en círculos, sin tartamudear (de aquí en adelante, quiero decir durante al menos 30 segundos). No sé si el juego tiene V-sync o no, no tiene esa configuración.

Abrí Minecraft, modo ventana. Cargó un mundo plano mirando al suelo donde el retraso sería inexistente, sin tartamudeo.

Abrí Factorio, todavía en modo ventana, con una fábrica de juegos finales bastante grande. Corrió en línea recta, sin tartamudear. Sin embargo, V-sync está desactivado. Si lo enciendo y reinicio el juego ... todavía no hay tartamudeo.

Abrí un viejo juego de Java que hice usando Slick2D (OpenGL), ni un solo tartamudeo (todavía no he visto uno Oo). Verificando las opciones, se habilitó V-sync. Si desactivo V-sync, obtengo un tartamudeo regular cada segundo aproximadamente. Si doblo el límite de velocidad de fotogramas, no tartamudeo.

Ahora, abrí un proyecto 3D con Godot 3.1 alpha3, con un mapa que tiene algunos recursos y un carácter en movimiento: casi sin tartamudeo, solo puedo ver uno cada 20 segundos, tal vez, lo cual es demasiado sutil para molestar.

También probé mi proyecto 2D Wallrider que porté en Godot 3.0.6: lo mismo, no hay suficiente tartamudeo para molestar (uno al azar cada 20 segundos).

Todos estos proyectos anteriores tienen esto en común: no solo dibujan un objeto en la pantalla.

Si pruebo el proyecto de prueba _physics_process , e incluso probé delta = 1.0 / 60.0 , es lo mismo. Si imprimo delta , muestra que hay una fluctuación cada segundo, pero el juego muestra tartamudeos varias veces por segundo que delta no refleja en absoluto. También sucede si inicio el juego sin el editor.
También intenté portarlo a Godot 2.1.5, y ocurre el mismo problema (proyecto: Stuttering_issue19783.zip )

Y ahora, aquí es donde se pone interesante:
Si abro mi juego 3D Y la prueba de @crystalnoir en la pantalla, ambos se ejecutan sin problemas, de inmediato. Sin embargo, el juego 2D todavía tartamudea un poco, pero no tanto. Si cierro el juego en 3D, todavía parece funcionar bien, pero si reduzco el juego en 2D y lo maximizo de nuevo, vuelve a tartamudear horriblemente.

¡Aún no es el final!
Ahora intenté agregar una cámara 3D en el juego 2D. Y mágicamente, el tartamudeo se reduce drásticamente e inmediatamente, simplemente haciendo eso.
Puede probar esto usted mismo con PlayerWith3D scene: Stuttering_issue19783.zip
Vea lo suave que es por defecto. Ahora presione el botón magic , vea cómo va a la mierda si no se muestra un entorno 3D (aunque no siempre vuelve al 100%, pero veo que PlayerWith3D.tscn siempre se ve mejor que Player.tscn ).

Me gustaría ir más allá y ver qué sucede si cambio el panel de control de nVidia de Optimal Power (predeterminado) a Maximum performance , pero ... erhm ...

De todos modos, todo lo que puedo adivinar de esto es (pero es una suposición, así que tómalo con un grano de sal): no es directamente culpa de Godot. Son los controladores de gráficos que intentan ser "inteligentes".

¡Para el dios de los tartamudos! 😂😂😂

Solo lanzando esto ... A partir de noviembre de 2018, las 14 mejores tarjetas de video en Steam son Nvidia. Veamos las mejores tarjetas en cada categoría de GPU:

NVIDIA GeForce GTX 1060: 14,60% de los usuarios de Steam.
Gráficos AMD Radeon R7: 1.06% de los usuarios de Steam.
Intel HD Graphics 4000: 1.06% de los usuarios de Steam.

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

Dados los datos anteriores, parece que este problema debería tener la máxima prioridad. Una abrumadora mayoría de jugadores usa tarjetas Nvidia, es la configuración más común con diferencia. La cantidad de usuarios de gráficos Radeon e Intel es minúscula en comparación.

@Ranoller ... Me estás matando. Decirle a la gente que haga un prototipo en Godot pero que se traslade a Unity por su título comercial (en un hilo de problemas de Godot) es lo más ridículo que he escuchado en mi vida, sin ofender.

@Zylann Intenté configurar el modo de administración de energía en "Perfer máximo rendimiento" con éxito, pero no vi ninguna mejora en la tartamudez.

@ behelit2 Sin ofender

@Zylann Puse una cámara 3D que renderiza una malla frente a una escena que renderiza un mapa de mosaicos con texturas animadas y el problema de godot tartamudeando algunos segundos después de la ganancia de enfoque no se soluciona. No hay otro tipo de sttuter anteriormente (solo la "inicial") en esa escena, así que no sé si este truco soluciona algo, pero es interesante que descubras. Probaré con tus archivos. También creo que el tiempo de inactividad de godot hace que algo en la computadora se vuelva "perezoso", pero probablemente sea el sistema operativo, porque las diferencias en ganar con y sin aerodinámica en FPS, uso de CPU y tartamudeo son muy altas. Probablemente sea el sistema operativo el que intente ser inteligente y no la tarjeta gráfica.

Me gusta la idea de Zylann de analizar lo que hacen otros juegos. No sé si esto es fuera de tema, pero hice algunas pruebas.
En primer lugar, parece que el 95% de los juegos de Steam son de 32 bits (los lanzamientos recientes también). Parece que el mismo porcentaje de juegos se renderiza por directx. Capturo los procesos que ejecutan los juegos e intento ver qué está pasando con el renderizado. Alguna información detrás (no es para sacar conclusiones, es solo información):

Juego / Bits ejecutables / Motor / Proceso que se usa para renderizar en Windows 7 de 64 bits y notas.

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

• Ori y el bosque ciego -> 32 bits / Unity / Windows GDI. Ejecuta un proceso llamado OPENGL32 como godot pero es una especie de contenedor en Windows GDI. Ni una sola llamada de OpenGL32, todas las llamadas son de Windows GDI.
  

• Dust: An Elysyian Tail -> 32 bits / Microsoft XNA / Windows GDI. Tiene gameoverlayrenderer.dll y todas las llamadas son de este (ClientToScreen). No tiene OpenGL dll.

• SuperMeatBoy -> 32 bits, ejecución dentro de Steam Overlay, Windows GDI

• ΔV: Rings of Saturn (demo) -> 64 bit, godot / Ejecuta llamadas OpenGL y Windows GDI, realiza una sola llamada a OpenGl SwapBuffers - GetPixelformat con un valor de 8. Realiza muchas llamadas a Windows GDI. ¿Hacen llamadas duplicadas? a WindowsFromDC- SetRect (tamaño de la ventana), OffsetRect.
  

• Bastion -> 32 bit / SDL2 / Ejecuta llamadas OpenGL puras, sin GDI de Windows, realiza una llamada única de swapBuffers - GetPixelFormat todo el tiempo con un valor de 10.

• SouthPark la vara de la verdad -> 32 bits / Motor desconocido / Ejecuta todas las llamadas en Windows GDI, parece direct3D v 9 (tiene d3d9.dll pero hace pequeñas llamadas mediante este proceso), la mayoría de las llamadas son de gameoverlayrenderer de steam y uxtheme.dll que ejecuta OffsetRect e IsRectEmpty y otras funciones de ventana.
  

• Sine Mora -> 32 bits / Motor desconocido / Ejecuta todas las llamadas en Windows GDI mediante superposición de vapor, dicect3d 9

• Apotheon -> 32 bit / Microsoft XNA / Todas las llamadas en Windows GDI, una sola llamada desde la superposición de Steam (Cliente a la pantalla), una sola llamada de Microsoft XNA (ScreenToClient) y llamadas desde un proceso llamado uxtheme.dll (administración de ventanas en windows?) a IsRectEmpty y PtInrect (todos booleanos).
• Los huevos regresan a casa -> 64 bits / Godot / Llamadas desde OpenGL y desde Windows GDI, igual que Ring of Saturn.
• ¡Guacamelee! Super turbo .... -> 32 bit / Motor desconocido pero para los archivos puede ser similar a sine mora. Este juego permite cambiar el tamaño de la pantalla. / Todas las llamadas desde Windows GDI.
• No es un héroe -> 32 bits / SDL2 (wikipedia dice ClickTeam Fusion) / Todas las llamadas desde Windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 bits (sí, hay uno) / Intro dice Firebird, nada hasta ahora sobre procesos / Todas las llamadas desde Windows GDI, pero hay muy, muy pocas llamadas, pocas que en los otros juegos, algunas llamadas por segundo (por ejemplo, puede seguir las llamadas de la API de godot, hay toneladas por segundo). Pero este juego quema la GPU.

Noto que la mayoría de los juegos en foco perdido detienen el proceso y pausan (¿quizás una buena práctica?) Y muy pocos juegos te permiten cambiar el tamaño de la pantalla manualmente (ej: no un héroe). Lamentablemente, tengo el problema de la pérdida de enfoque / ganancia de enfoque en ΔV: Rings of Saturn (demo).

Editar: Parece que godot es el único motor que usa el proceso OpenGL32 y WindowsGDI al mismo tiempo.
Aplicación utilizada: API Monitor v2

(Editar: nombre correcto de ΔV: Anillos de Saturno (demostración))

Si por Anillos de Saturno te refieres a ΔV: Anillos de Saturno (demo), fue construido con Godot 3.1, pero no estoy seguro de la revisión exacta que usaron.

Después de muchas horas de intentar averiguar la causa del tartamudeo, al menos en mi caso, por casualidad rastreé el tartamudeo de 1s constante hasta tener el 'Cambio automático al árbol de escena remota' habilitado en 'Configuración del editor'. Desmarcar esto me resuelve los problemas de tartamudeo y rendimiento. (Es posible que todavía haya un tartamudeo muy leve, pero apenas se nota).

Godot build 8849d3b
Win10 64bit, NVIDIA GeForce GTX 660, controlador v416.81

Tuve el mismo problema de tartamudeo y el culpable fue desmarcar Auto Switch to Remote Tree.

Tengo el mismo problema aquí. Hay varios problemas con este jitter pero la mayoría de ellos no parecen tener ninguna solución adecuada y realmente necesito ayuda.

Estoy a punto de firmar un trato con un editor con mi juego que hice con Godot y, debido al nerviosismo, podría tener que mover todos mis códigos a Unity. El tiempo y el costo para mover todos los códigos dejados de lado, soy reacio a cambiar a un motor diferente porque realmente me gusta la filosofía de diseño de Godot y Godot en sí.

También noté que en 3.1 se agregó la opción 'Physics Jitter Fix' en el menú de configuración (https://twitter.com/reduzio/status/984783032459685890) pero eso tampoco ayuda.

Versión de Godot:
Godot 3.0.6

Sistema operativo / dispositivo incluida la versión:
MacOS 10.14.1
MacBook (Retina, 12 pulgadas, 2017)
Intel Core m3 de 1,2 GHz
LPDDR3 de 8 GB y 1867 MHz
Gráficos Intel HD 615 1536 MB
(Pero este problema ocurre en varios dispositivos, incluidos PC y juegos exportados en dispositivos móviles y PC).

Descripcion del problema:
Cualquier objeto que se mueva parece tartamudear o temblar periódicamente acompañado de congelación de la pantalla.

Pasos para reproducir:
Cree un nuevo proyecto con un KinematicBody2D o incluso un AnimatedSprite y modifique la posición con move_and_slide () o set_position () después de agregar un Camera2D como un nodo secundario (pero aún sucede incluso sin el Camera2D).

Y parece ocurrir con más frecuencia en dispositivos con poca potencia de procesamiento.

Proyecto de reproducción mínima:
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 de 64 bits, GTX 660 (controladores 391.35), Godot 3.0.6 y 3.1-beta1

Oye, modifiqué el proyecto original (detuve las animaciones, hice uso de un cuerpo rígido en lugar de ajustar manualmente las posiciones, agregué un fondo ligeramente animado, etc.)

Aquí está: FirstGame_2.zip

Probado con una ventana de tamaño ~ 500x500 y una resolución de monitor de 1920x1080

Ahora mis observaciones:

• Jitter es omnidireccional (no solo vertical, como los problemas habituales de vsync)
• Cuanto menor es el tamaño de la ventana, más frecuente es la fluctuación
• Apagar vsync elimina la fluctuación (los siguientes puntos de viñeta son con vsync activado)
• Ejecutar el juego sin el editor en la pantalla al mismo tiempo (minimizarlo, por lo que es solo el escritorio: íconos, fondo de pantalla, barra de tareas y tal vez algunas ventanas estáticas como el administrador de archivos o la terminal) elimina el jitter
• No importa el juego exportado o ejecutado desde el editor
• Si ejecuto el juego con quakespasm-sdl2 en la misma pantalla (con un zombi atacando al jugador bajo el agua), veo un poco de nerviosismo
• Si ejecuto el juego con un sitio de Shadertoy (esta demostración: https://www.shadertoy.com/view/ll3fz4), sin pausar, en la misma pantalla, veo mucha inestabilidad
• Si ejecuto el juego con un sitio Shadertoy, pero me detengo, en la misma pantalla, veo un poco de nerviosismo
• Si ejecuto el juego con el editor en la misma pantalla, con una escena que se muestra en el editor que no se actualiza (Player.tscn), veo un pequeño jitter
• Si ejecuto el juego con el editor en la misma pantalla , con una escena que se muestra en el editor actualizándose con frecuencia (main.tscn, tengo un sombreador animado allí), veo mucho jitter

¿No probé con Aero apagado, olvidó cómo cambiarlo rápidamente de un lado a otro?

@ starry-abyss para apagar aero, vaya al panel de configuración, elija "apariencia y personalización", allí debería poder cambiar a un tema antiguo como "Windows Classic", que no presenta efectos visuales (y luego no t use Aero) o "Windows 7 Classic".

De acuerdo, con el tema clásico, el juego, con el editor de sombra / editor en la pantalla también, va y viene del estado de tartamudeo al suave (cada estado puede permanecer durante varios segundos). Y el tartamudeo se acompaña de un desgarro vertical del marco en este modo. Dicho esto, incluso Firefox desplaza lágrimas con el tema clásico: 'D

Estoy teniendo exactamente el mismo problema que tiene diiiiiiiii, su caso de uso con move_and_slide es el mismo que el mío. Si miras de cerca, no es el objeto del jugador que se mueve, sino el fondo de paralaje detrás de él.

Proyecto 2D con personajes cinemáticos
Godot 3.0.6
Win10 de 64 bits
CPU Intel i5-2550K
16 gb de ram
Geforce GTX 970

Dado que esto sucede en muchos tipos diferentes de dispositivos, no creo que esto esté estrictamente relacionado con las configuraciones de hardware. Incluso ocurre en juegos exportados que se ejecutan en dispositivos ios.

Si miras de cerca, no es el objeto del jugador que se mueve, sino el fondo de paralaje detrás de él.

@ behelit2 Sin embargo, no estoy seguro de eso. https://youtu.be/YVFtkbuyqEQ En este metraje, si miras el objeto del reproductor, incluso se sacude solo. Puede ser un problema separado, pero empeora mucho cuando el suavizado de la cámara está activado o el objeto se cambia a Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
Esto es lo que sucede cuando el suavizado de la cámara está activado y el objeto se cambia a 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)

Es posible que haya amplificado el jittering usando apply_impulse () así, pero modificar la posición del objeto directamente usando set_position () no hizo mucha diferencia.

@diiiiiiiii Creo que debería tener un problema separado abierto entonces. De lo contrario, el hilo estará lleno de declaraciones contradictorias porque la gente está probando cosas diferentes.
Por ejemplo, estoy probando el proyecto OP por ahora, no el tuyo (lo siento).

@ starry-abyss Entendido;)
Aunque ya hay muchos problemas relacionados con el jittering y creo que están estrechamente relacionados y pueden tener la misma causa raíz.

Actualización sobre el problema de OP. Encontré algunas opciones en Godot para limitar los fps sin usar v-sync. Entonces, para mí, son 60 fps con v-sync desactivado y no ~ 4000 ahora.
Y el solo hecho de desactivar v-sync me soluciona el problema.

Me pregunto si v-sync tiene sentido en el modo de ventana. Windows parece usar v-sync por sí mismo, y probablemente pelea con el juego Godot que preparará el marco más rápido después de que se reciba la señal de v-sync. Además, otros juegos de IIRC solo se cortan en pantalla completa con v-sync desactivado, y no en modo de ventana.

Para su información, el problema de diiiiiiiii continúa aquí en su lugar: # 25162

Además del enfoque v-sync off, encontré una forma interesante específica de Windows (según la descripción de confirmación, podría ser este problema), no estoy seguro de si Godot ya usa esto, pero tal vez alguien tenga tiempo para probar:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
También esto está relacionado: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

Sin embargo, también existe este hilo que entra en más detalle y con diferentes enfoques:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
Y esto es complementario, más corto y más al grano, pero también con algunas emociones al principio: https://www.vsynctester.com/firefoxisbroken.html

Cambié la palabra tartamudeo a jitter en mi informe anterior, ya que eso es lo que experimenté (ver https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Mi idea era desactivar v-sync solo en modo de ventana (es decir, se puede hacer desde el código, incluso podría consultar la frecuencia de actualización del monitor para el límite de fps), pero dado que los desarrolladores principales no admiten el enfoque, no hay nada reconsiderar todavía. :) Hay otras formas más específicas de Windows, pero aún tenemos que demostrar que funcionan bien y que no son demasiado piratas.

Actualización sobre el problema de OP. Encontré algunas opciones en Godot para limitar los fps sin usar v-sync. Entonces, para mí, son 60 fps con v-sync desactivado y no ~ 4000 ahora.
Y el solo hecho de desactivar v-sync me soluciona el problema.

Me pregunto si v-sync tiene sentido en el modo de ventana. Windows parece usar v-sync por sí mismo, y probablemente pelea con el juego Godot que preparará el marco más rápido después de que se reciba la señal de v-sync. Además, otros juegos de IIRC solo se cortan en pantalla completa con v-sync desactivado, y no en modo de ventana.

¿Cómo limitaste tus fps a 60?

Usar el campo "Forzar fps" en algún lugar de la categoría Depuración de la configuración del proyecto

Воскресенье, 17 февраля 2019, 9:25 +03: 00 от FabiánLC [email protected] :

Actualización sobre el problema de OP. Encontré algunas opciones en Godot para limitar los fps sin usar v-sync. Entonces, para mí, son 60 fps con v-sync desactivado y no ~ 4000 ahora.
Y el solo hecho de desactivar v-sync me soluciona el problema.
Me pregunto si v-sync tiene sentido en el modo de ventana. Windows parece usar v-sync por sí mismo, y probablemente pelea con el juego Godot que preparará el marco más rápido después de que se reciba la señal de v-sync. Además, otros juegos de IIRC solo se cortan en pantalla completa con v-sync desactivado, y no en modo de ventana.
¿Cómo limitaste tus fps a 60?
-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

No he visto personas publicando sus CPU con sistemas, excepto I5-2500K que tiene una GPU Intel integrada.

Mi computadora portátil tiene una GPU integrada Intel y una tarjeta Nvida dedicada. Me pregunto si podría haber un problema entre los dos controladores / gpu y godot

Tal vez. Pero no parece dependiente de gpu / cpu. En i7 2700 + 1080ti se puede tartamudear (ventana) y suavizar la mantequilla en el i5 móvil con intel 4000 (1.a generación Surface Pro), en pantalla completa.

Es curioso que digas que si ejecuto el proyecto de demostración en mis computadoras portátiles 940m veo el tartamudeo. Sin embargo, cuando ejecuto la aplicación con el Intel 530 dedicado, no veo ningún tartamudeo.

Inicio de Windows 10
CPU i3-6100H a 2.70 GHz,
GeForce 940M (26.21.14.3064)
Gráficos Intel (R) HD 530 (26.20.100.6709)

¿La tartamudez es visible en este proyecto ? (Muévase presionando las teclas de flecha).

Acabo de hacer una exportación rápida dejando la interpolación activada y estableciendo la física en 60:
940M hubo sacudidas ocasionales pero no cizallamiento
Intel 530 no hubo sacudidas pero a veces obvio cizallamiento vsync,

Hago más después y te lo haré saber.

Parece que he tenido cierto éxito con limitar mi FPS a 60. No estoy seguro de si 60 es un número mágico, mi pantalla puede admitir 144, intenté establecer el límite en 144, pero el tartamudeo aún era visible. Bajé mi FPS a 120, el tartamudeo todavía era visible, pero no tan "borroso", lo que me hace pensar que solo está ocurriendo en un intervalo más bajo. Seguido con la reducción de FPS a 80, y el mismo resultado que antes, pero tartamudeando ahora visiblemente más lento. Además, debo decir, desactivé v-sync y ejecuté en modo de ventana, lo he probado con pantalla completa, pero el mismo resultado. ¿Hay procesos en el motor con un límite de 60 FPS?

¿Hay procesos en el motor con un límite de 60 FPS?

De forma predeterminada, la física se simula a 60 FPS, lo que significa que habrá una discrepancia visible cuando el FPS de renderizado sea más alto que el FPS de física (siempre que la pantalla sea lo suficientemente rápida para mostrar la diferencia). El FPS de física se puede cambiar en la Configuración del proyecto ( Física> Común> Fps de física ).

Puede aliviarse interpolando cuerpos físicos, pero no hay apoyo oficial para esto. En 3.2alpha, puede usar este complemento de suavizado que facilita la interpolación de nodos.

¿Hay procesos en el motor con un límite de 60 FPS?

De forma predeterminada, la física se simula a 60 FPS, lo que significa que habrá una discrepancia visible cuando el FPS de renderizado sea más alto que el FPS de física (siempre que la pantalla sea lo suficientemente rápida para mostrar la diferencia). El FPS de física se puede cambiar en la Configuración del proyecto ( Física> Común> Fps de física ).

Puede aliviarse interpolando cuerpos físicos, pero no hay apoyo oficial para esto. En 3.2alpha, puede usar este complemento de suavizado que facilita la interpolación de nodos.

Impresionante, gracias, eso podría explicar por qué los personajes tartamudean mientras se maneja el movimiento en la llamada al proceso de física.

Todavía se puede reproducir en 3.1.1 Por cierto, la forma más fácil es con Shadertoy abierto en Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

Me topé aquí con la esperanza de que hubiera una solución, pero después de probar casi todos los consejos que vi en este hilo, todavía no hay dados. Para mí, el temblor solo ocurre cuando ejecuto el proyecto en la tarjeta NVIDIA. Si lo ejecuto usando la GPU Intel integrada, funciona como la seda. : /

Estoy usando la última versión alfa de Godot 3.2 en Windows 10

Me topé aquí con la esperanza de que hubiera una solución, pero después de probar casi todos los consejos que vi en este hilo, todavía no hay dados. Para mí, el temblor solo ocurre cuando ejecuto el proyecto en la tarjeta NVIDIA. Si lo ejecuto usando la GPU Intel integrada, funciona como la seda. : /

Estoy usando la última versión alfa de Godot 3.2 en Windows 10

No creo que puedas arreglarlo en Windows, esto no sucede en Linux, esto podría arreglarse en 4.0 con el nuevo renderizador vulkan.

Me topé aquí con la esperanza de que hubiera una solución, pero después de probar casi todos los consejos que vi en este hilo, todavía no hay dados. Para mí, el temblor solo ocurre cuando ejecuto el proyecto en la tarjeta NVIDIA. Si lo ejecuto usando la GPU Intel integrada, funciona como la seda. : /
Estoy usando la última versión alfa de Godot 3.2 en Windows 10

No creo que puedas arreglarlo en Windows, esto no sucede en Linux, esto podría arreglarse en 4.0 con el nuevo renderizador vulkan.

Bueno, eso apesta, ¿no la API de Vulkan solo se enfoca en dispositivos de gama alta?

Me dirijo específicamente a OpenGL 2.0 para poder admitir dispositivos de gama baja. Es un poco tonto usar una API de gráficos de muy alta gama solo para un juego 2D y excluir a las personas con computadoras / portátiles de gama baja. 😕

Suena a mito. Tal vez el tartamudeo de vez en cuando no se pueda arreglar en un cajero automático, pero el tartamudeo que estamos experimentando es una característica exclusiva de Godot.

Suena a mito.

¿A qué te refieres con esto?

Este es un tema desafiante. Por un lado, me gustaría arreglar esto personalmente lo antes posible. Pero no puedo reproducirme, así que no puedo hacer nada. (Yo uso Windows 10 con una tarjeta gráfica NVidia)

Alguien que pueda reproducir el problema debe intentar solucionarlo, lamentablemente. :(

Si bien es un problema poco común, parece ser lo suficientemente común como para atraer a muchas personas a este hilo. Así que espero que alguno de ustedes pueda trabajar en esto.

Ah, siempre me olvido de que lo que experimento se llama jitter en términos oficiales de documentación de Godot.

_¿Alguien sabe cómo capturar perfectamente el problema en 60 FPS sin comprar hardware? _
Creo que algunas personas subestiman lo horrible que se ve, y tal vez también sea un problema de aspecto diferente en diferentes PC.

¿A qué te refieres con esto?

El mito: "esto siempre es así en OpenGL (o Windows, etc.). Solo Vulkan puede salvarnos".

OK entonces:

1. este es un video de OBS: https://www.youtube.com/watch?v=osbJlk1XD8c El impacto de OBS es que el simple hecho de tener OBS en ejecución hace que este jitter en el proyecto Godot (incluso cuando la captura está desactivada).
2. Sin OBS es suave hasta que elimino al mínimo Firefox con shadowrtoy en él, luego comienza a tartamudear, pero no puede capturar con OBS, porque 1.

Añadiendo mi propia grabación, esto se hace con Bandicam y en su mayor parte así es como funciona con o sin grabación. Como puede ver, comienza sin problemas, pero gradualmente comienza a tener problemas

@clayjohn Creo que se solucionaría implementando la interpolación física, pero reduz se opone a tenerlo en el núcleo por algunas razones. Aún así, se agregó un método en 3.2alpha para exponer la relación de paso de física actual, lo que hace posible implementar una interpolación física precisa de forma manual.

@ starry-abyss Si puedes usar 3.2alpha, prueba el complemento de suavizado de césped: mild_smiling_face:

Solo un pensamiento, ¿hay algo útil en Unreal Engine o PhysX Source para mirar?

Salud,
Victor Stan

El 22 de octubre de 2019, a las 4:17 a.m., Hugo Locurcio [email protected] escribió:

@clayjohn Creo que se solucionaría implementando la interpolación física, pero reduz se opone a tenerlo en el núcleo.

@ starry-abyss Si puedes usar 3.2alpha, prueba el complemento suavizante de grassjelly 🙂

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

@victorbstan No hay

Definitivamente no extraiga el código de código cerrado, pero arquitectónicamente puede
¿No extraes ideas de esto? [no un abogado]

El martes 22 de octubre de 2019 a las 11:07 a.m. Hugo Locurcio [email protected]
escribió:

@victorbstan https://github.com/victorbstan No debemos mirar
El código fuente de Unreal, ya que no está bajo una licencia de código abierto. (No lo hace
incluso permitir la redistribución a usuarios sin licencia de Unreal Engine).

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HS4DFVREXWHG43WNMV84 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Todavía no recomendaría mirar su código fuente. Si alguna vez desea inspirarse en un algoritmo patentado, debe realizar ingeniería inversa de sala limpia para reducir el riesgo legal asociado.

Aún así, no necesitamos hacer nada de esto aquí. La solución es utilizar la interpolación física, que utilizan los motores de juegos más populares en la actualidad. Tiene algunas desventajas (como requerir trabajo del usuario para evitar la interpolación al teletransportar objetos), pero creo que las ventajas las superan con creces.

Entiendo, la sugerencia es tener una idea de las posibles vías para encontrar una solución, no necesariamente plagiar. No me imagino que hay una patente para resolver problemas de parpadeo / tartamudeo, pero IANAL.

Salud,
Victor Stan

El 22 de octubre de 2019, a las 2:07 p.m., Hugo Locurcio [email protected] escribió:

@victorbstan No deberíamos mirar el código fuente de Unreal, ya que no está bajo una licencia de código abierto. (Ni siquiera permite la redistribución a usuarios de Unreal Engine sin licencia).

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

En mis escenarios, el generador de perfiles de Godot muestra 60 FPS perfectos, incluso cuando veo jitter / tartamudeo. ¿Significa esto que el problema no está relacionado con la interpolación o me falta algo?

Mi suposición era que los tiempos de Godot se implementaron de una manera que interfiere con los tiempos del compositor de Windows (y tal vez SDL lo hace mejor que GLFW Godot, por lo tanto, otros motores simplemente funcionan donde falla Godot).

(y tal vez SDL lo hace mejor que GLFW, por lo tanto, otros motores simplemente funcionan donde falla Godot).

Godot usa su propio código de administración de ventanas, no usa SDL ni GLFW: mild_smiling_face:

Tengo Windows 10 y una nVidia GeForce GTX 1070 y, con la versión 3.2 alpha2 con vsync habilitado, tengo nerviosismo cuando estoy en modo ventana. El modo de pantalla completa parece estar bien. El problema es particularmente grave si el editor no se minimiza cuando se ejecuta el juego. El juego que estoy probando usa solo _process() para actualizar posiciones. Debido a esto, sospeché que el problema tenía que ver con un delta muy ruidoso o marcos caídos (deltas grandes), pero ese no es el caso. El delta es realmente estable durante el jittering.

Basado en la investigación de otros en este hilo, pirateé un cambio a context_gl_windows.cpp para establecer el intervalo de intercambio en 0 y llamar a DwmFlush() en 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;
}

Esto se basa en lo que hacen los proyectos glfw y Chromium .

Al hacer este cambio, parece que se soluciona el jitter en el modo de ventana. En el modo de pantalla completa, el juego se ha desgarrado, por lo que es probable que el DWM esté desactivado y parezca necesario un doble búfer mediante un valor de intervalo de 1. (Básicamente, el código debe hacer lo que hace actualmente).

Si alguien más está dispuesto y es capaz de probar esto, entonces me interesaría saber cómo funciona.

Parece que wglSwapIntervalEXT(0); part es lo mismo que desactivar v-sync en las opciones.

Parece wglSwapIntervalEXT (0); parte es lo mismo que desactivar v-sync en las opciones.

Es. 1 - habilitar vsync, 0 - deshabilitar, y también hay -1 para "Adaptive vsync" (deshabilite la sincronización en velocidades de cuadro bajas, habilite en alta).

Probé lo DwmFlush () desde arriba con mis casos simples, en la rama 3.1.x.

• Soluciona la situación con el caso de prueba Shadertoy;
• V-sync activado o desactivado - se ve igual para mí (no parcheé la parte wglSwapIntervalEXT ());
• El caso de OBS todavía está temblando (parece el mismo, creo), pero Godot ahora informa que el FPS ha caído a 40 (me pregunto si el generador de perfiles en Godot realmente se encuentra con la versión original de Godot);
• También intenté llamar a DwmFlush () después de SwapBuffers (hDC), y los 3 puntos permanecen igual.

No estoy seguro, pero supongo que DwmFlush () después de SwapBuffers (hDC) podría ser más correcto ya que Godot coloca el marco en la actualización del compositor más cercano, no en el siguiente, que es posterior al más cercano.
Me pregunto si Godot debería detectar mejor si el compositor se está ejecutando y volver al método vanilla v-sync si no lo está.

Entonces, el próximo intento será la nueva función de interpolación mencionada por Calinou.

ACTUALIZACIÓN: sí, en el caso de OBS, Godot informa un tiempo de proceso de 0.03 segundos (pero FPS se informa como 60), probablemente el contador de FPS de Godot no tiene en cuenta la falta del v-blank cada dos veces
ACTUALIZACIÓN 2: lamentablemente, el complemento de interpolación no parece ayudar aquí; Todavía tengo jitter en el caso de OBS y tartamudeo y / o mezcla de jitter en el caso de shadowrtoy

Parece que wglSwapIntervalEXT(0); part es lo mismo que desactivar v-sync en las opciones.

Correcto, pero agregar DwmFlush() en swap_buffers() hará que el juego use el compositor (DWM) para la sincronización. Cuando el compositor está habilitado, efectivamente tiene doble búfer, lo quiera o no. Tendría triple búfer en el caso de que establezca el intervalo de intercambio de OpenGL en 1. (Sus dos búferes y el del compositor).

También me pregunto por qué los otros proyectos ponen la llamada a DwmFlush() antes de SwapBuffers() . Parece al revés, pero casi me he convencido de que es correcto.

En el caso de esos proyectos, no están usando el doble búfer de OpenGL (cuando el compositor está habilitado), por lo que hacerlo de esta manera parece ser la mejor manera de sincronizarse con el período en blanco vertical. Con un intervalo de intercambio de OpenGL de 0, la llamada a SwapBuffers() no se bloquea, por lo que le está presentando al compositor el siguiente cuadro tan pronto como sepa que ha terminado con el actual. Esto efectivamente tiene el mismo efecto que usar un intervalo de intercambio de OpenGL de 1. (Cuando el compositor no interfiere, por ejemplo, en modo de pantalla completa).
>
>

Me pregunto si Godot debería detectar mejor si el compositor se está ejecutando y volver al método vanilla v-sync si no lo está.

Creo que tienes razón. Parece obvio que la sincronización v de OpenGL se rompe cuando el compositor está habilitado. Si miras el código de glfw y Chromium, lo llaman (usando DwmFlush() ) un HACK. Es probable que piensen que OpenGL está roto en este caso y que tengan que hacer algo que debería estar haciendo.

@ starry-abyss Después de volver a leer su publicación sobre el caso de OBS que no cambia, me pregunto si ese proyecto tiene habilitado vsync. Como no cambiaste la llamada a wglSwapIntervalEXT() tener vsync habilitado básicamente hará que el juego se bloquee tanto en DwmFlush() como en SwapBuffers() . Eso explicaría el tiempo de proceso de 0,03 segundos.

@TerminalJack No, probé todas las combinaciones. El tiempo de proceso siempre aumenta a 0.03 cuando ejecuto OBS. Es solo que Godot parece esforzarse mucho para estar a 60 FPS, incluso cuando no pudo lograr esto varios cuadros seguidos.

Entonces lo dividiría en dos números:
1) Godot no es amigo del compositor;
2) Godot está demasiado ansioso por tener un FPS máximo, mientras que podría ofrecer 30 estables si está bajo carga.

Pero si hay una forma confiable de (des) probar si 0.03 es tiempo de cálculo puro y no sincronizado, puedo probarlo.

@ starry-abyss Para propósitos de prueba, puede usar el Administrador de tareas para aumentar la prioridad de ese proceso a 'alta'. Esto hará que se adelante a los demás y le otorgue la mayor parte del tiempo de procesamiento. Es decir, siempre que esté en un estado ejecutable y no bloqueado en DwmFlush() y / o SwapBuffers() .

No he tenido muchas oportunidades de jugar con esto hoy, pero intenté ejecutar el cambio en un sistema Windows 10 que tiene una GPU Intel UHD Graphics 620 integrada. (Una GPU de gama bastante baja).

Primero ejecuté el juego (en modo ventana) con la última versión 3.2 alpha2 y no tenía ningún jitter notable. Luego ejecuté el juego con los cambios y también funcionó bien.

Sucedió que registré los delta veces durante las dos ejecuciones y descubrí que eran mucho más estables con la llamada a DwmFlush() que sin ...

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

Prueba de construcción

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)

(Los deltas altos al principio aquí se deben al hecho de que se tomaron justo después de que se cargó la escena. La compilación alfa muestra el mismo comportamiento).

Observe cómo la construcción de prueba finalmente se estabilizó y alcanzó un estado estable. La versión 3.2 alpha2 nunca lo hizo.

Por lo tanto, parece que no solo otras GPU no se verán afectadas negativamente por este cambio, sino que también se beneficiarán de él. Supongo que la fluctuación empeora a medida que la GPU se vuelve más potente y no depende del fabricante ni de los controladores.

He creado una bifurcación que tiene una única confirmación que debería solucionar este problema.

Sin embargo, solo lo he probado en dos máquinas con Windows 10, por lo que sería genial si otras personas pudieran construirlo y probarlo en otras versiones de Windows. Además, lo construí usando VC ++ 2019, por lo que si alguien que usa mingw pudiera construirlo, también sería genial.

Si tiene su propia bifurcación (reciente) del proyecto, debería poder parchear este cambio sin ningún problema.

Estoy en Windows 10 con una NVidia GTX 1050.

No tengo tartamudeo en el proyecto de ejemplo a menos que tenga un shadowrtoy abierto y en funcionamiento (como se describe en algunos comentarios arriba).

Con el compromiso de

@clayjohn Gracias por probar esto. Me pregunto si el problema en su caso es solo una cuestión de potencia de procesamiento.

Puedo ejecutar un juego de sombras de 800 x 450 en segundo plano y un juego de Godot (ejecutado desde el editor) en una ventana en primer plano y obtener muy poco nerviosismo con los cambios que hice. La construcción alpha2, por otro lado, tiene un jitter severo en las mismas circunstancias. Sin embargo, soy una de las personas que tiene un jitter severo incluso sin ninguna carga en mi sistema, por lo que probablemente eso también sea algo a tener en cuenta.

@TerminalJack Buen punto. Estaba ejecutando el sombreador de selva tropical de iq :)

Creo que también hay una alta probabilidad de que haya varios problemas en juego aquí. Como @Calinou ha señalado anteriormente, muchos usuarios también tienen el problema solucionado cuando usan física interpolada.

En este punto, creo que deberías hacer publicidad de tu compromiso, se ve bien y hacer una relación de relaciones públicas le dará más visibilidad y hará que sea más fácil para otros usuarios construir y probar.

@clayjohn Sí, estoy de acuerdo en que es probable que existan otros problemas que se comporten de manera similar a este.

De hecho, comencé tratando de localizar un problema con un tartamudeo grave que ocurre una vez cada 60 a 90 segundos y encontré este hilo. (Parece que algo bloquea el proceso durante 60 ms a 100 ms de vez en cuando). Estaba ejecutando mi juego en modo de pantalla completa y no experimentaba ninguna fluctuación. Sin embargo, después de encontrarme con este hilo, intenté ejecutarlo en una ventana y, he aquí, soy uno de los afortunados que puede reproducir este problema en particular.

Probablemente eliminaré las declaraciones de depuración de mis cambios y enviaré un PR en un par de horas.

@TerminalJack La bifurcación ya no está disponible (o está configurada para ser privada), ¿podría hacerla disponible nuevamente?

@Calinou Lo siento. Conecté el repositorio, así que lo borré. Lo bifurcaré nuevamente y volveré a confirmar los cambios aquí en breve.

@Calinou El nuevo compromiso está aquí .

@TerminalJack Su solución parece ser solo para Windows, pero me enfrento al mismo problema en Ubuntu.

@TerminalJack Su solución parece ser solo para Windows, pero me enfrento al mismo problema en Ubuntu.

Sí, esta es definitivamente una solución solo para Windows. Lo siento.

No sé si es necesario hacer algo similar en Ubuntu o no. Ni siquiera estoy seguro de si usa un compositor.

No sé si es necesario hacer algo similar en Ubuntu o no. Ni siquiera estoy seguro de si usa un compositor.

De hecho, no hay forma de deshabilitarlo en algunos administradores de ventanas (incluido el predeterminado de Ubuntu): mild_smiling_face:

@TerminalJack También podría necesitar algo de lógica para cuando Aero está deshabilitado, por ejemplo, en Windows 7 (IIRC no realiza sincronización v, por lo que Godot probablemente debería seguir sincronizando v en este caso)

@ starry-abyss Espero que se descubra ese caso. Tengo una computadora portátil vieja que tiene Windows 7. Si aún funciona, haré algunas pruebas con él y veré si es necesario realizar algún cambio.

Encendí mi computadora portátil de 10 años que tiene Windows 7 y probé mis cambios. Tuve que usar los proyectos más simples para realizar pruebas. (Las GPU de las computadoras portátiles eran extremadamente malas en ese entonces). Usé el proyecto de esta publicación. Agregué lo siguiente para poder cambiar a pantalla completa o salir de ella.

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

Ejecuté el proyecto con mis cambios y sin ellos y no hubo diferencias notables de ninguna manera. Con mis cambios, el compositor se usaría para sincronización v cuando se esperaba (modo de ventana, compositor habilitado) y se usaría doble búfer OpenGL en todos los demás casos.

La buena noticia es que no habrá cambios necesarios en el _code_. El código detecta si el compositor está habilitado o no como debería. Incluso maneja el caso en el que habilita o deshabilita el compositor mientras la aplicación se está ejecutando. Sin embargo, este es un caso que no preví, así que no lo incluí en los comentarios en swap_buffers() respecto a los casos en los que la estrategia de sincronización virtual cambia sobre la marcha. Así que eso es lo único que necesito cambiar hasta donde yo sé.

Una de las cosas que surgieron hoy en irc al discutir esto (y el PR de TerminalJack) es aislar el error en el delta de entrada medido del error en el delta de salida.

Calinou señaló que podemos probar esto hasta cierto punto ejecutando el interruptor de línea de comando --fixed-fps 60 . Esto tratará el delta de entrada como si fuera siempre 1/60 de segundo.

Sería muy útil si aquellos que tienen el problema (especialmente en Windows) pudieran informarnos si esto tiene algún efecto sobre el jitter.

@lawnjelly Intenté rápidamente con y sin la opción de línea de comando, pero lamentablemente no puedo reprogramar el problema hoy%) Excepto el caso OBS, que sigue siendo el mismo.
¿El valor de la opción se almacena entre las ejecuciones del editor por casualidad?

¿El valor de la opción se almacena entre las ejecuciones del editor por casualidad?

No, es solo un argumento de línea de comandos (que no tiene estado).

OKAY. Además, por cierto, ¿la opción está disponible en Godot 3.1.1 (la versión en la que realizo la mayoría de las pruebas aquí)?

OKAY. Además, por cierto, ¿la opción está disponible en Godot 3.1.1 (la versión en la que realizo la mayoría de las pruebas aquí)?

Si está usando 3.1.1 para probar esto, necesitará mover objetos a una distancia proporcional al delta durante _process, ya que no hay una interpolación de pasos de tiempo fija.

@ starry-abyss Ese argumento de la línea de comandos se agregó en 3.1, por lo que también debería estar disponible en 3.1.1.

Entonces, --fixed-fps 60 no me ayudó con el problema. Y ejecutar el juego directamente desde la línea de comandos tampoco ayudó (todavía tenía una instancia separada del editor en la pantalla para una reproducción más rápida).

Y también probé ambos a la vez, en caso de que la solicitud --fixed-fps 60 implicara esto, todavía está nervioso.

La dificultad para reproducir ayer fue porque tenía v-sync desactivado en opciones de pruebas anteriores. : /

no hay una interpolación de intervalos de tiempo fija.

Por supuesto, estoy probando los métodos uno por uno, no todos a la vez (no como el complemento de interpolación + dwmflush + cualquier idea nueva).
También la próxima vez incluye los pasos específicos para probar la nueva idea, así no tengo que adivinar las versiones de Godot, ejecutar el editor o el juego directamente, etc. No tengo el deseo de probar todas las combinaciones posibles de todo (con cada idea duplica la cantidad de combinaciones). :PAGS

Por supuesto, estoy probando los métodos uno por uno, no todos a la vez (no como el complemento de interpolación + dwmflush + cualquier idea nueva).
También la próxima vez incluye los pasos específicos para probar la nueva idea, así no tengo que adivinar las versiones de Godot, ejecutar el editor o el juego directamente, etc. No tengo el deseo de probar todas las combinaciones posibles de todo (con cada idea duplica la cantidad de combinaciones). :PAGS

Entiendo que no se menciona en los documentos, y no hay una interpolación de pasos de tiempo fija en el núcleo. Quizás debería intentar escribir algo sobre esto para los documentos, no he agregado documentación antes.

_El resultado es este: _
Independientemente de otros problemas (delta, SO), si usa la física o mueve objetos en _physics_process, actualmente Godot dará jitter como resultado del alias entre los ticks físicos y los marcos reales. Esto ocurrirá hasta cierto punto en todas las combinaciones de frecuencia de tick de física / frecuencia de actualización del monitor, algunas serán peores que otras.

El método de 'corrección de jitter' fue un intento de evitar este alias haciendo que ocurra de una manera menos pronunciada (seguirá ocurriendo). Piense en el alias de escaleras.

Para evitar esta fluctuación de 'nivel básico', actualmente necesita
1) (Disponible en todas las versiones de Godot) Mueva objetos en _process y muévalos a una distancia proporcional al delta. Esto no es ideal para juegos, ya que no puedes usar la física y el comportamiento depende de la velocidad de fotogramas, sin embargo, está bien para las pruebas de jitter.

2) (Disponible en Godot 3.2 en adelante) Se utilizó la interpolación de paso de tiempo fijo. Esto solo es realmente posible en 3.2 con la función Engine-> get_physics_interpolation_fraction (). Consulte https://github.com/lawnjelly/smoothing-addon para ver un ejemplo de cómo usar esto.

Estos son los requisitos previos ANTES de comenzar a investigar el jitter. Darán una relación lineal entre la posición de un objeto y el tiempo, que es lo que queremos.

Un método alternativo (más amigable para los novatos) para lograr esto es con un intervalo de tiempo semi-fijo, en el que he tenido un PR desde julio # 30798.

Esta es la base de la investigación científica y la prueba de hipótesis. La idea es reducir tantos efectos de confusión como sea posible y examinarlos uno por uno.

Hay 3 factores principales en juego aquí:

1) Relación lineal entre la posición del objeto y el tiempo del juego (ver arriba)
2) Error en los tiempos de entrada
3) Error en los tiempos de salida

Elimine (1) como arriba. Elimine (2) utilizando el argumento de la línea de comando, luego puede examinar (3) de forma aislada.

Además, para cualquier investigación de jitter, debe mover objetos directamente, no a través de la física, ya que la física puede potencialmente agregar jitter.

_Editar:_
Acabo de echar un vistazo al proyecto de reproducción mínima en este hilo (esquivar los escalofríos) y se está moviendo con velocidad * delta en _process, lo que debería estar bien. Se basa en is_action_pressed y personalmente lo eliminaría como un posible problema, pero probablemente esté bien. Sin embargo, si usa otro proyecto para probar el jitter, tenga cuidado con los puntos anteriores.

@lawnjelly ya veo. Tenía la impresión de que el complemento de interpolación todavía es algo probado solo por unos pocos chicos, y puede tener errores (e incluso aumentar el jitter). Así que tomé lo que es estable (3.1.1), así es como funciona "científico" para mí.
Intentaré con las nuevas consideraciones la próxima vez.

Acabo de echar un vistazo al proyecto de reproducción mínima en este hilo.

Estoy usando mi propia versión del proyecto, ya que la original usa animaciones (puede enmascarar el jitter) y tiene un sprite gris sobre un fondo gris. Lo ajustaré para que cumpla con sus criterios.

Entonces, --fixed-fps 60 no me ayudó con el problema.

Esa es una información muy útil. Esto parece mover el dedo puntiagudo de la culpa hacia el retraso de salida (y el compositor), y da peso al tipo de enfoque en las relaciones públicas. Esto es asumiendo que usa almacenamiento en búfer doble / triple y mantiene la tubería alimentada, y no descarta tramas.

¿Es este también el caso de @TerminalJack con el argumento de línea de comando?

Estoy usando mi propio proyecto, ya que el original usa animaciones (puede enmascarar el jitter) y tiene un sprite gris sobre un fondo gris. Lo ajustaré para que cumpla con sus criterios.

¡Ah bien, gracias! : +1:

@lawnjelly ya veo. Tenía la impresión de que el complemento de interpolación todavía es algo probado solo por unos pocos chicos, y puede tener errores (e incluso aumentar el jitter).

Un poco fuera de tema, pero debería estar bien (no lo he tocado en algunas semanas), no debería introducir nerviosismo. Si encuentra algún error, hágamelo saber en el rastreador de problemas o incluso haga un PR. : +1: Tengo la intención de ponerlo en los complementos oficiales para 3.2 _ cuando lo haga_: smile:.

@lawnjelly

¿Es este también el caso de @TerminalJack con el argumento de línea de comando?

Lo siento, no he tenido la oportunidad de probar tus sugerencias. Me hundí en un agujero de conejo en el tema en el que estoy trabajando.

@lawnjelly Según nuestra discusión en el hilo de relaciones públicas, pensé que mencionaría que tenías razón sobre la opción de línea de comandos --fixed-fps <fps> . De hecho, mantiene vsync habilitado. Entonces, como estaba diciendo, usarlo es una buena manera de descartar cualquier problema con el cálculo del delta. Debo haber metido la pata cuando lo probé antes y tartamudeé porque ese no es el caso ahora.

He estado usando esa opción junto con mis cambios de establecer que el uso de DwmFlush() sí ayuda cuando se ejecuta fuera del editor. Si desactivas DwmFlush() entonces puedes causar tartamudeo en el juego simplemente arrastrando alguna otra ventana o colocando el mouse sobre una de las tareas en ejecución en la barra de tareas. Obviamente, dado que el juego se ejecuta con una prioridad 'Superior a lo normal', esto no debería suceder. (Y no lo hace si se está utilizando DwmFlush() ).