Godot: Problema de gagueira pesada em jogo 2D simples [Windows 10, Nvidia]

Olá, atualizei meu relatório porque testei em meu outro computador (casa) e o problema está aqui ao mesmo tempo que altero a animação. Portanto, esta não é a animação que causa o problema. Acho que acreditei porque quando vi que estava no meu laptop, tinha uma tela pequena. Aqui está um vídeo do problema (o vídeo está a 60 FPS):
GodotStutter.zip

Se o vídeo é uma representação precisa do que está na tela em tempo real, então é muito mais gagueira do que eu já vi mencionado em qualquer problema relacionado à gagueira aqui. Deve haver algo muito errado com esta configuração do Windows 10 / GTX 1060 (vejo alguns artigos na Internet detalhando problemas de desempenho no Windows 10 / Nvidia após as principais atualizações do Windows, mas não posso dizer se está relacionado).

Aqui está um vídeo do projeto de teste em meu sistema, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX com drivers proprietários recentes (390.59). Sem gagueira em tudo (no Openbox - no KWin o compositor bagunça as coisas e há uma gagueira muito leve a cada 10 s ou mais).
StutterTest_LinuxNvidia_OK.zip

BTW, aqui está uma versão corrigida do projeto demo firstGame_fixed.zip , o original tinha arquivos divididos em três pastas diferentes de alguma forma ("firstgame", "firstGame" e "FirstGame").

O jogo me dá a mesma quantidade de gagueira que no vídeo.
No entanto, desligar o vsync elimina completamente a trepidação (mas o jogo roda a 4000 fps).
Windows 10 64 bits nVidia GTX 1060 também aqui.

Eu também testei como @Zylann sugeriu aqui e obtive os mesmos resultados. Eu também tenho Win10 x64 e nVidia GTX 1060.

Edit: Eu uso esses drivers da nVidia:
398.11-desktop-win10-64bit-international-whql

Win 7 GLES2 de 64 bits e GLES3 testado, GeForce GTX 660 / PCIe / SSE2 ... sem interrupções. Ligar o Aero, com o editor 2d de godot por trás do jogo, resulta em um pouco de gagueira (a renderização do editor Godot interfere na renderização do jogo).

Porém, a gagueira de Godot é o gigante inimigo invisível, todos sabemos que está aí, mas não queremos olhar muito de perto porque sabemos que a solução não é simples.

Seu problema parece ser fps fixo de física diferente com taxa de atualização do monitor, vejo esse tipo de falha em monitores que não têm o mesmo hz que o fps físico configurado pelo editor, mas pode ser outra coisa.

Seu problema parece ser de fps fixos de física diferente com taxa de atualização do monitor

A demonstração não usa física, apenas um simples _process .

É verdade ... digo que só vejo aquela gagueira pesada nesse caso, mas é verdade que não há processo de física envolvido. Eu testo mudando hz de um dos monitores e sem diferenças, 0 gagueja no meu equipamento.

Edit: Eu ganhei 7, 8,1 e 10 neste computador e aproveitei para testar tudo. Sem gagueira na vitória 8.1. Estou testando no win 10 agora e está muito bom ... sem problemas com o windows. Godot está zangado com o seu 1060?

Aqui está o mesmo teste com meu laptop. Como você pode ver, o problema também está aqui. Mas parece que é menos visível, mas está aqui.

Especificações do laptop: Windows 10 - Geforce 940M

Aqui está o vídeo do laptop (é um vídeo de 60 FPS):
GodotStutterLap.zip

Qualquer pessoa com o problema de gagueira pode tentar executar a alteração demo em Player.gd _process com _physics_process?

Vou testar esta noite no meu PC doméstico, é aqui que tenho o problema o tempo todo. Mas eu tenho uma coisa estranha: esta manhã, eu dei a vocês um vídeo com o projeto no meu laptop e como vocês podem ver, vocês têm o mesmo tipo de gagueira. O problema é que agora, se eu executá-lo novamente, não terei mais essa gagueira, como se fosse aleatória. E não mudei nada no meu laptop, trabalhei nisso a manhã toda em uma sessão de TSE.

Aviso: falo apenas pelo meu laptop. No meu PC doméstico com GTX 1060, o problema está sempre aqui. Mas no meu laptop o problema parece ocorrer aleatoriamente. É por isso que acho que por enquanto, vou deixar meu laptop de lado para fins de teste e vou testar apenas no meu PC doméstico que está com o problema o tempo todo, para conseguir isolar o "bug".

@Ranoller eu testei e obtive o mesmo resultado. A gagueira ainda está lá e parece praticamente a mesma.

@Ranoller Fez o teste e mesmo à @RaXaR que não muda nada. Tenho o mesmo problema.

Isso não parece bom ....

Para especificar exatamente o bug, eu faria estes testes:

1) Tela inteira ligada - desligada
2) Se houver mais de 1 monitor:
Desativar- Ativar área de trabalho compartilhada
3) Aero liga-desliga

Suas cartas funcionam bem em outros jogos? ...

Lendo o primeiro post sobre a animação -> gagueira / sem animação -> sem gagueira li o código e vejo algumas coisas que não acho corretas ... exatamente: mudar a animação a cada frame. Acho que esse código deve verificar a animação atual. Provavelmente não mudou nada, mas se alguém quiser testar altere Player.gd desta forma:

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 é a última ideia ... provavelmente não faz sentido para o problema, mas ... sua placa de vídeo é muito comum nos jogadores, então godot deve executar bem nela.

@Ranoller

Para :

• O primeiro ponto: Já tentei em tela cheia ou não, não muda nada

• 2: Já tentei rodar com apenas um monitor (essa é minha configuração comum, mas às vezes também tenho um segundo monitor, então tentei os dois) e não mudou nada.

• 3: Eu tenho que testar (deveria ser capaz de fazer isso, esta noite (Horário da França).

• 4: Eu tenho que testar seu código (deveria ser capaz de fazer isso, esta noite (Horário da França).

Acabei de testar seu código e não muda nada :(

Embora este problema possa não estar diretamente relacionado a godot, godot deve revisar bem as questões de gagueira ... não é verdade que todos os jogos engasgam como foi dito em outro tópico. Hoje eu estava jogando n ++, tela cheia, janela, tentando ver qualquer gagueira e não .... sem gagueira em tudo. Mesmo com Ori e a floresta cega, para muitas coisas ruins tem que fazer para ter qualquer gagueira neste jogo (janela com outros programas em segundo plano, etc .... e apenas 2 ou 3 pula quadros em uma hora ...). Godot, ao iniciar a execução, sempre gagueja x número de segundos, depois estabiliza, mas a cada X segundos você vai ter pulos de frames (se não tiver o problema do gtx1060 é claro). Não devemos tratar esse assunto como um problema menor.

Tento fazer o meu melhor para isolar o problema, mas no meu nível é um pouco difícil. Tentei testar configurações diferentes, mas sem resultado. Eu também testei uma imagem de fundo em vez de usar uma cor com tela clara. Eu já vi (não se lembre de quem) um motor com esse problema por causa da renderização de um sprite 2D em uma "tela vazia" causa esse problema, mas parece que não é o caso aqui. Então eu não tenho nenhuma ideia por enquanto.

Por curiosidade, tente traçar o perfil de quanto tempo SwapBuffers leva context_gl_win.cpp torno da linha 68. Se demorar mais de 16 ms, então você provavelmente está perdendo um quadro aqui.

Se alguém que conhece as fontes de Godot pudesse testar que estou interessado no resultado (desculpe pelo meu inglês ...)

Eu estava brincando com esse problema ontem e ele se resolveu magicamente depois que as janelas do jogo funcionaram por cerca de 60 segundos. Aí ficou tranquilo, isso me diz que poderia ser uma coisa de cache?

Por curiosidade, tente traçar o perfil de quanto tempo leva SwapBuffers em context_gl_win.cpp em torno da linha 68. Se demorar mais de 16 ms, então você provavelmente está perdendo um quadro aqui.

Talvez possa ser útil saber se o problema ocorre no GLES2, não testamos isso

Tentei brincar com as opções em Godot sobre isso, mas não muda nada para mim, será que não sei exatamente o que mudar?

Tentei deixar o jogo por mais de 2 minutos mas o problema sempre aqui não está resolvido para mim após 60 s.

Tive um problema semelhante com 3.0.3. (Win10 64 bits, Nvidia 660) Não percebi no 3.0.2.

Acho que tem algo a ver com o nó AnimatedSprite porque vejo os problemas de desempenho com os níveis que têm esse nó. Recebo o shuttering ao executar a partir do IDE ou se eu exportar para Win 32bit, mas se eu exportar para Win 64bit tudo funciona como deveria, sem gagueira.

.. curiosamente, não tenho o problema com o projeto de exemplo 'FirstGame.zip' ... mas ainda tenho com o meu jogo, FPS cai para 5 quando executado a partir do IDE e versão de 32 bits, GPU fica em cerca de 2% .. .mas, com a exportação de 64 bits, a GPU está em 30% e está tudo bem.

Olá, alguma novidade sobre esse problema? Acabei de testar com o demo do pong (não fiz isso antes, apenas com o jogo tutorial) e parece que o problema está aqui com este projeto de amostra também. Eu uso a última versão do Godot no Steam para testá-lo.

A atualização dos drivers da Nvidia não mudou nada, então venho levar algumas novidades sobre esse assunto. Eu não descobri como me livrar disso ainda.

Agora tenho um computador com geforce gtx 1060 (3gb- barato) e não tenho o problema no windows 10 home. Pode ser algum aplicativo de fundo? Algumas configurações específicas de hardware AMD-Nvidia Intel-Nvidia ....? Não tenho nenhum aplicativo de jogo neste computador (está no meu estúdio de gravação de música) mas o godot funciona perfeitamente mesmo com 3 telas conectadas ao computador. Qualquer pessoa com o problema pode verificar se há algum software de monitoramento de jogo em execução em segundo plano, ou no Steam, ou algo assim ...? E se conseguir tentar dissable?

É difícil desligar o Steam quando você o usa para lançar Godot ... Godot funciona muito bem, o problema é o jogo que você faz com ele. Já tentei desabilitar tudo o que posso desabilitar, isso não muda nada. Fiz muitos testes sem sucesso. Eu também tentei redefinir os drivers da nvidia por exemplo, atualizá-los etc ... mas não mudou nada.

Por outro lado, tenho vários motores que funcionam perfeitamente, então por que não Godot? Foi isso que tentei encontrar. Mas, por enquanto, não encontro nada. Há algo em algum lugar, mas o quê e onde, essa é a questão :-)

Esse problema é muito "específico do mecanismo de desenvolvimento" para encontrar uma solução aceitável pela própria pesquisa. posso procurar por horas no código do godot e sei que nunca terei qualquer possibilidade de encontrar algo relacionado a isso ... eu sei que os desenvolvedores de motores gostam de mais novas funcionalidades de código e "correção de bug" é considerado mais "trabalho júnior " ou algo parecido com isto. Mas com esse tipo de problema não é o caso. Precisamos de algum mecanismo de desenvolvimento para atribuir automaticamente este problema e outras correções de bug de "nível fantasma-complicado-difícil de pagar" ...

Digo que já experimentei a versão dev (sem Steam) e o problema é o mesmo.

Olá, eu tive exatamente o mesmo problema de gagueira (usando Godot 3.1 da fonte Git), qualquer movimento atrasou para mim, exatamente como no seu vídeo, seja move_and_slide ou apenas movimento do jogador de animação. mas ligar o V-Sync na configuração do projeto resolveu completamente o problema de gagueira no jogo 2D.

Estou meio confuso porque @Zylann disse que desligar o V-Sync removeu a gagueira, mas para mim é o oposto.

@Qws desligá -lo E fazer o jogo rodar a mais de 60fps (o que acontecia na época) fez a gagueira passar para mim, mas traz outros problemas (usar toda a potência disponível e fazer falhar tudo que não usava um delta adequado Tempo). Se você travar com o V-sync desativado, isso pode ser devido a um tempo delta impróprio ou a uma situação em que o jogo precisa esperar / processar mais do que um quadro para atualizar a tela.

Primeiro teste que fiz com o novo gtx 1060 não deu problema ... mas depois sinto aquela gagueira. A única coisa que mudei foi a conexão dvi para hdmi (e alguns programas instalados) ... isso é um pouco estranho. A única coisa que me convenci é que o problema não está no lado do windows 10.

Eu direi muito isso. Estou trabalhando em um tutorial de jogo 2D "Hoppy Days" dos tutoriais Gamedev.tv. EU ESTAVA usando o 3.0.2 para desenvolvê-lo e estava funcionando bem. Percebi que o tutorial estava usando 3.0.4, então literalmente HOJE decidi atualizar para 3.0.6. Agora há um atraso perceptível no jogo. _O lag não estava lá no 3.0.2_ . Ele está aí agora. Todas as outras configurações são iguais.

Meu laptop é um laptop para jogos da série Dell Inspiron 7000 relativamente novo (comprado em março de 2017). O processador é Intel Core i7-7700HQ Quad Core de 7ª geração (6 MB de cache, até 3,8 GHz). A placa de vídeo é NVIDIA GeForce GTX 1050Ti com 4 GB GDDR5. A RAM é 16 GB, 2400 MHz, DDR4. O disco rígido é um SSD Samsung. Windows 10.

Para mim, parece que algo mudou no 3.0.4 ou 3.0.6 ... Nada mais mudou. Nem mesmo o jogo (como em ... Eu não mudei / editei / atualizei o nível em tudo).

@ emo10001 Você poderia testar o 3.0.3? Foi quando mudamos o sistema de construção usado para fazer os binários 3.0.x (3.0 até 3.0.2 foram construídos em AppVeyor CI com MSVC 2015, 3.0.3 até 3.0.6 foram construídos com GCC 8 via MinGW).

Se o seu laptop tiver gráficos comutáveis ​​/ Optimus, pode ser que seu sistema tenha colocado na lista de permissões o binário 3.0.2 para ser usado com a GPU Nvidia, enquanto 3.0.3+ teria como padrão um IGP. Ou pode ser que 3.0.2 tenha sido colocado na lista de permissões por seu antivírus, enquanto 3.0.3+ são vistos como vindo de uma fonte diferente (o que é verdade) e ainda não considerado seguro, então o antivírus executaria suas verificações completas e impactaria o desempenho.
Essas são apenas suposições, mas, do contrário, não tenho certeza de qual mudança real de Godot afetaria o desempenho como essa, então só posso pensar em mudanças no sistema de construção.

CC @hpvb

Estou tendo o mesmo problema! Meu projeto gagueja por 20 a 30 segundos e depois funciona sem problemas. Baixei o projeto no OP post e é exatamente a mesma coisa.
Desligar o V-Sync remove o problema e funciona a mais de 4000 fps.

Estou executando a versão 3.0.6 no Linux Mint 19 (então acho que a tag do Windows é imprecisa, hein?) E GTX 760 com os drivers proprietários mais recentes.

Estou executando a versão 3.0.6 no Linux Mint 19 (então acho que a tag do Windows é imprecisa, hein?) E GTX 760 com os drivers proprietários mais recentes.

Não, mas provavelmente este é um problema diferente. A gagueira no Linux geralmente acontece devido à composição do gerenciador de janelas (por exemplo, tenho alguns com KWin, nenhum com Openbox).

Meu projeto gagueja por 20 a 30 segundos e depois funciona sem problemas

Percebo muito isso, se eu executar a cena que estou editando, há gagueira e algum rasgo (com o vsync ativado) por cerca de 15-30 segundos, mas se eu iniciar o projeto no menu principal e abrir a cena com o seletor de cenas ... bem, não há gagueira na mesma cena (há eventualmente, mas nunca). Existe alguma explicação sobre este evento? Godot? Janelas? Quantos frames são necessários para estabilizar a reprodução? ... será ótimo saber essas coisas porque são necessárias para o design do jogo.

Não, mas provavelmente este é um problema diferente.

Ah, entendi. O que eu quis dizer é que esse problema específico provavelmente é multiplataforma, pois muitas pessoas estão enfrentando os mesmos problemas.

Estive brincando e percebi que dois corpos cinemáticos gaguejam exatamente ao mesmo tempo, tanto para move_and_slide () quanto para move_and_collide ().

Conectando uma câmera a um enquanto os dois oscilam, tudo na cena vacila, exceto os dois nós cinemáticos. Uma câmera estática mostra apenas os dois nós cinemáticos gaguejando.

Não parece importar quais configurações gráficas eu altero, nem _process ou _physics_process. nem usar uma variável delta diferente.

Acho que este projeto não é representativo do uso real ... projetos mais complicados funcionam um pouco suavemente. Eu acho que o windows não lida bem com um tempo excessivamente grande do godot ocioso ... Eu encontrei outro problema relacionado, não só para o godot, mas ele sofre muito com isso: no multimonitor com desktop estendido o jogo fica mais suave no monitor 1 se este é apresentado como "monitor principal". Se o monitor principal for diferente de 1, há gagueira no monitor secundário (o youtube sofre com isso, mas não os jogos comerciais unitários como ori). Com tela cheia no monitor secundário, aero no win 7 e monitores trocados (ej: monitor 2 como primário) o cenário é o pior e há uma grande gagueira (não só godot, mas nem game maker ou unidade) ... Eu sei que multimonitor com área de trabalho estendida em 2 telas de 1080p é difícil para GPUs baratas, mas outros jogos são mais suaves (godot não perde fps, apenas gagueja). Se este teste continuar, devemos fazer um exemplo mais complexo.

@Ranoller minha configuração é um monitor duplo em um gtx 760, segundo monitor marcado como 'primário', linux mint 19 com canela. Eu estava tentando entender a condição específica do projeto, mas não conseguia descobrir. Esses pequenos projetos às vezes gaguejam, às vezes não (apenas gagueja, sem perda de fps). Além disso, quando ele gagueja (executando em configurações de teste de godot em janelas), geralmente tenho uma ou mais janelas cromadas no segundo monitor (não o principal) e, quando as minimizo, a gagueira desaparece ... depois de minimizar / restaurando nas janelas cromadas, a gagueira desapareceu totalmente.

Eu tenho 2 computadores -> um com i5 gtx660 2 telas 1080p e outro com i7 gtx 1060 3 telas (2 1080p e outro hdready) ... bem, eu tenho esse problema de gagueira relacionado a monitores secundários em gtx660, acho que relaciona-se exclusivamente com renderização, gagueira de godot e cromo, game maker e unidade não (jogos comerciais, exatamente HiperLightDrifter e Ori, não testei demos ou templates). Windows aero gagueja mais em tela cheia (acho que não é realmente tela cheia) mas tem muito fps, sem aero no win 7 eu tenho no meu projeto 130-140 fps sem vsync, com aero eu passo 400 fps, mas. .. gagueja (muito) em certas condições (com e sem vsync). Eu não consigo fazer o godot gaguejar no i7 gtx 1060 (com projeto real, o demo neste tópico gagueja e eu explico jet minha opinião sobre). Eu acho que é um problema de otimização / OpenGL, ej: Light2D é praticamente inutilizável, qualquer modo de mixagem diferente de "mix" pode falhar se o sistema não for muito poderoso, mas godot deve lidar com o permormance no mesmo nível que o game maker ou a unidade faz. Provavelmente assim que o 3.1 foi lançado, o trabalho de otimização poderia começar (se o problema puder ser corrigido e não for um Direct3D / OpenGL - problema do Windows é claro ... não sei como encontrar jogos GLES2 / 3 no windows para testar e disccard um problema direto OpenGL - Aero / Win7-8-10) ... Eu entendo que o permormance de godot nunca será o mesmo do proprietário -> um motor baseado em jogo (Ex: Origens de Rayman funciona bem em um laptop antigo que eu tenho , godot 2 não), mas deve renderizar pelo menos no mesmo nível estável que o game maker (o Unity provavelmente será melhor otimizado que godot por muito tempo, você sabe, o dinheiro ...). Por enquanto eu sinto que godot tem um bom desempenho apenas em hardware topo de linha ou em telas de baixa resolução (eu testei em um computador gráfico i5 win7 32bit 15 "intel hd e tem um bom desempenho, mas eu não acho que com uma tela hd este computador irá correr bem) ...

Claro que tudo isso são minhas opiniões / experiências, posso estar errado (e espero estar .. se isso fosse uma correção simples de uma linha, isso poderia ser ótimo !!!)

Por outro lado, lembro-me de ler reduz a escrita de algo relacionado à "prioridade do processo" do executável do godot, mas no windows não há diferença se você alterar manualmente a prioridade do godot na execução, o godot não tem baixo desempenho (quem, eu tenho inventou uma palavra?), a execução do programa não tem picos, é a renderização, algo relacionado com nvidia / godot e a área de trabalho do computador (no windows não tento no linux)

Olá, então, há alguma notícia sobre esse problema? ^^ Vou testar novamente com a versão mais recente mas parece que o problema ainda está aí.

isso sai na plataforma Android ou iOS agora？ existem alguns jogos na google store feitos pelos primeiros godot que também têm o problema do obturador. como: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Isso existe em todas as plataformas testadas em certas circunstâncias, com diversos GPUs e diversos sistemas operacionais ... não está documentado em consoles.

Eu testei no Linux e no Windows e funcionou bem com pequenas falhas ocasionais, eu tenho uma placa de vídeo baytrail integrada Intel hd low end

Depois de muitas horas tentando descobrir a causa da gagueira, pelo menos no meu caso, por acaso rastreei a gagueira consistente de 1s até ter a opção 'Mudança automática para árvore de cena remota' habilitada em 'Configurações do Editor'. Desmarcar isso resolve os problemas de gagueira e desempenho para mim. (possivelmente ainda há uma leve gagueira, mas é quase imperceptível.)

Godot build 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64 bits, NVIDIA GeForce GTX 660, driver v416.81

Eu também tenho o problema de gagueira com meu jogo. A única coisa que parece torná-lo melhor é desligar e ligar a tela cheia enquanto o jogo está rodando ... E mesmo assim há uma leve gagueira que se arrasta depois. Parece acontecer completamente ao acaso. Às vezes, o jogo será executado quase perfeito, outras vezes ocorre a gagueira.

Projeto 2D com personagens cinemáticos.
CPU Intel i5-2550K
16gb ram
Geforce GTX 970
Win10 64bit
Godot 3.0,6

Na vitória 10 gagueja acontece mais em tela cheia, e é porque Aero (E pode ser desativado). Parece que Godot usa menos CPU e mais GPU com windows Aero, mas isso provoca mais gagueira. No windows 7, desabilitando o windows Aero, a tela cheia tem menos gagueira que a janela e usa mais CPU. Acho que o win 10 não tem tela inteira real ....

Comecei a fazer um protótipo de jogo de pinball 2D e fico muito nervoso com o movimento da bola, tenho apenas um corpo rígido que cai com a gravidade. Estou no Win10 / NVidia GTX 560 Ti 1Go (com os drivers mais recentes) / 8 Go Ram, meu computador não é dos melhores, mas meu projeto tem apenas uma bola e StaticBody2D para as bordas e posso ver claramente o tremor acontecendo com frequência, já tentei com e sem vsync, com opengl 3.0 e 2.0, em janela e fullscreen, com mais e menos fps físico, o problema ainda está aqui.
Minha versão Godot é 3.1 alpha.
Acho que é um grande problema, talvez difícil de corrigir, mas não deve ser ignorado, é importante ter um movimento 2D suave para um jogo 2D.

Você está certo, Godot agora tem a melhor usabilidade de todos os principais engines (minha opinião, claro). O lado da usabilidade supera todos eles. Mas ... o lado do desempenho .... o lado da exportação .... é como se godot estivesse vencendo com o sistema operacional, não como as exportações de unidade ou game maker que são mais fluidas (até que a construção em cromo seja mais fluida ), e não é porque gdscript lentidão (acontece com e sem GDScript), há "outra coisa indeterminada", espero que um dia alguém possa encontrar uma linha rebel em um arquivo cpp e alterar um simples "!" este problema será resolvido ... (esperança é grátis como Godot!)

Tenho vários projetos em mente e adoraria realizá-los com Godot, vai demorar muito do meu tempo (para não dizer todo o meu tempo livre), mas me entristece dizer que se o motor não pode garantir um movimento 2D suave na animação com uma cena simples, o motor, apesar de todos esses prós, é simplesmente inútil. Nesse caso, talvez a escolha mais sensata para mim seja não arriscar perder tempo dessa forma.

Entendo que esse problema aparece apenas em algumas configurações (drivers do Windows 10 e NVidia, por exemplo), mas gostaria de saber:

• Este problema (ou similar) já está planejado em um marco ou não?
• Esse problema pode ser colocado de lado, esperando a substituição do OpenGL pelo Vulkan no marco 3.2?

PS: Já tentei com outro pc:

• Intel i7 4790K 4,00 Ghz
• Win10 64 bits 16 Go RAM
• NVidia GTX 1060 3Go (com os drivers mais recentes)
• Godot 3.1 alfa oficial
  e tenho o mesmo problema com cenas simples.

Acho que esse tipo de configuração de PC (placas Win10 + Nvidia) é muito comum, e espero que a comunidade Godot (que faz um ótimo trabalho) corrija esse problema muito em breve e que bons jogos 2D comecem a ser lançados para mostrar que podemos fazer com Godot, mas com esse tipo de problema para mim é simplesmente impossível.

Talvez seja algum tipo de problema de foco do programa? Quando eu começo um jogo em tela cheia, vejo a gagueira basicamente todas as vezes. Mas se (enquanto o jogo está rodando) eu mudar para o modo de janela e voltar para tela inteira, parece que funciona perfeitamente todas as vezes. Se eu tiver feito isso, posso programar para que aconteça automaticamente, mas parece estranho. Alguém mais pode confirmar que a mudança de tela inteira para janela em tela inteira novamente corrige a gagueira?

Edit: Ah, e outra coisa ... Quando desativei o aplicativo Geforce Experience, as coisas pareceram melhorar.

Projeto 2D com personagens cinemáticos
Godot 3.0.6
Win10 64bit
CPU Intel i5-2550K
16gb ram
Geforce GTX 970

Tentei o que você propõe, desativei o Geforce Experience, tentei mudar de tela inteira para janela e para tela inteira novamente, com vsync ativado e desativado (é pior com vsync desativado), mas a intermitência parece sempre lamentável para mim.
É bem aleatório, mas nunca passei dos 15-20 segundos sem gaguejar.

Obrigado por tentar! Isso é tão estranho, suas especificações são melhores que as minhas. O problema comigo é que é tão aleatório ... É difícil de reproduzir com precisão. Às vezes vai funcionar bem, outras vezes vai gaguejar. Tenho quase certeza de que tem algo a ver com o próprio Godot, entretanto. Eu nunca experimentei gagueira em jogos feitos no Unity, ou qualquer outro motor de jogo para esse assunto.

Só notei essa gagueira.

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

Como outros já mencionaram, este é um problema sério para Godot. Esta semana decidi criar um protótipo para um jogo muito simples. Eu procurei por um framework ou engine (encontrei muitos deles) e decidi ir com Godot - já que é gratuito e aberto. Então notei a gagueira, encontrei esse problema - e fiquei surpreso ao ver que parece não haver progresso. Acho que vou fazer um protótipo da minha ideia em Godot de qualquer maneira. Mas se eu quisesse criar um jogo lançável, provavelmente tentaria outro motor. (Isso parece muito duro ... Eu só acho que Godot pode perder muitos adotantes em potencial se o problema não for resolvido.)

Não há progresso porque não há ninguém trabalhando nisso e, sim, é um problema sério. Mas, por enquanto, se você precisar lançar o jogo comercial, pode prototipar em godot e portar para a unidade (você pode usar C #). Você precisa ter em mente a abordagem cena-gameobjeto-componente e você pode replicar em godot e se as obras vão para a unidade para fluxo de fluido e desempenho, ou se for 2D, vá para gamemaker. Estou trabalhando em um plugin para tentar converter um projeto godot para outros engines e tentar portar gdscript para um módulo, para gml ou para a unidade C #, mas é uma tarefa muito grande (não sei se vale a pena o esforço muito tempo sem funcionar no jogo) e sempre será imperfeito (não consigo obter todos os tipos, ej: objeto retornado por colisão). Eu tenho um pequeno analisador para os scripts e irei iniciar um analisador para tscn e tres, mas converter o resultado do analisador de gdscript para unidade c # ou gamemaker GML requer uma tonelada de código e eu não sei a "legalidade" sobre isso (i precisa de todos os nomes de API ej. em arquivos json e não sei sobre o IP disso). As animações são outro problema, não sei por enquanto como abordar isso, mas usar espinha / ossos de dragão será fácil de portar. Minha ideia principal de fazer isso era começar em godot e terminar em unidade ou gm, mas para niw é uma dor de cabeça ... Se a unidade fosse igualmente portátil (eu preciso disso), pequena e rápida para desenvolver como godot (e ter um 32 bits editor) Transformei meu projeto principal meses atrás, adoro godot, mas para um projeto de tamanho médio em uma equipe pequena (ou um homem solteiro como eu) é um risco, ninguém garante a você que um projeto acabado não vai dar muito problemas. Mas se houver um bom programador C ++ em sua equipe, é outra coisa, você sempre pode adaptar godot ao seu jogo (na unidade você não pode, mas é menos bugado) ....
Odeio esse problema como odeio o baixo desempenho do editor em um projeto intermediário e no jogo exportado, mas odeio mais unidade (por que preciso da Internet em todos os computadores para abrir o editor? Tenho um computador sem isso!) E odeio tão profundamente visual studio ... tenho certeza de que se godot parar a gagueira e trabalhar na performance e exportação, poderemos começar a ver ótimos jogos futuros.

Para verificar novamente esse problema hoje, fiz o seguinte, ainda no Windows 10 com nVidia GTX 1060:

Abri The Binding of Isaac, modo de janela. Correu em círculos, sem gaguejar (com isso em diante, quero dizer por pelo menos 30 segundos). Não sei se o jogo tem V-sync ou não, ele não tem essa configuração.

Abri o Minecraft, modo de janela. Carregou um mundo plano olhando para o chão onde o lag seria inexistente, sem gagueira.

Abri o Factorio, ainda no modo de janela, com uma fábrica de jogos final bastante grande. Corria em linha reta, sem gagueira. No entanto, o V-sync está desativado. Se eu ligar e reiniciar o jogo ... ainda sem gagueira.

Abri um jogo Java antigo que fiz usando Slick2D (OpenGL), nem um único gaguejar (ainda estou para ver um Oo). Verificando as opções, V-sync foi habilitado. Se eu desligar o V-sync, recebo gagueira regular a cada segundo ou assim. Se eu dobrar o limite da taxa de quadros, não recebo gagueira.

Agora, eu abri um projeto 3D com Godot 3.1 alpha3, com um mapa com alguns ativos e um personagem em movimento: quase sem gagueira, só consigo ver apenas um a cada 20 segundos, talvez, o que é sutil demais para incomodar.

Eu também tentei meu projeto 2D Wallrider que portei no Godot 3.0.6: mesmo, gagueira insuficiente para incomodar (uma aleatória a cada 20 segundos).

Todos esses projetos acima têm isso em comum: eles não desenham apenas um sprite na tela.

Se eu tentar o projeto de teste @crystalnoir com Godot 3.1 alpha3, obtenho uma gagueira frequente e irregular, que só vai embora se eu esperar cerca de 30 segundos depois de ter sido mostrado / maximizado pela última vez. Tentei mudar para _physics_process e até tentei delta = 1.0 / 60.0 , é tudo a mesma coisa. Se eu imprimir delta , isso mostra que há uma flutuação a cada segundo, mas o jogo mostra que gagueja várias vezes por segundo que delta não reflete de forma alguma. Também acontece se eu iniciar o jogo sem o editor.
Também tentei portá-lo para Godot 2.1.5, e o mesmo problema acontece (projeto: Stuttering_issue19783.zip )

E agora, é aqui que fica interessante:
Se eu abrir meu jogo 3D E o teste de @crystalnoir na tela, ambos rodarão sem problemas imediatamente. O jogo 2D ainda gagueja um pouco, mas não tanto. Se eu fechar o jogo 3D, ele ainda parece funcionar bem, mas se eu reduzir o jogo 2D e maximizá-lo novamente, ele volta a gaguejar horrivelmente.

Ainda não é o fim!
Agora tentei adicionar uma câmera 3D no jogo 2D. E magicamente, a gagueira é reduzida drasticamente e imediatamente, apenas fazendo isso.
Você pode tentar fazer isso sozinho com PlayerWith3D scene: Stuttering_issue19783.zip
Veja como é suave por padrão. Agora aperte o botão magic , veja como fica uma merda se nenhum ambiente 3D for mostrado (nem sempre volta 100% para a merda, mas vejo que PlayerWith3D.tscn sempre parece melhor do que Player.tscn )

Eu gostaria de ir mais longe e ver o que acontece se eu mudar o painel de controle da nVidia de Optimal Power (o padrão) para Maximum performance , mas ... erhm ...

De qualquer forma, tudo que posso adivinhar disso é (mas é um palpite, então considere com cautela): não é diretamente culpa de Godot. São os drivers gráficos tentando ser "inteligentes".

Pelo deus da gagueira !!! 😂😂😂

Apenas jogando isso lá fora ... Em novembro de 2018, as 14 principais placas de vídeo no Steam eram Nvidia. Vamos dar uma olhada nas cartas principais em cada categoria de GPU:

NVIDIA GeForce GTX 1060: 14,60% dos usuários do Steam.
Gráficos AMD Radeon R7: 1,06% dos usuários do Steam.
Intel HD Graphics 4000: 1,06% dos usuários do Steam.

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

Dados os dados acima, parece que esse problema deve ter prioridade. A esmagadora maioria dos jogadores usa placas Nvidia, de longe a configuração mais comum. A quantidade de usuários de gráficos Radeon e Intel é minúscula em comparação.

@Ranoller ... Você está me matando. Dizer às pessoas para prototipar em Godot, mas portar para Unity para seu título comercial (em um tópico de edição de Godot) é a coisa mais ridícula que já ouvi, sem ofensa.

@Zylann Eu tentei definir o modo de gerenciamento de energia para "Perfer maximum performance" com sucesso, mas não vi nenhuma melhora na gagueira.

@ behelit2 Sem ofensa

@Zylann Coloquei uma câmera 3D que renderiza uma malha na frente de uma cena que renderiza um mapa de blocos com texturas animadas e o problema da gagueira de Godot alguns segundos após o ganho de foco não foi corrigido. Não há outro tipo de sttuter anteriormente (apenas o "inicial") naquela cena, então não sei se esse truque consertou alguma coisa, mas é interessante que você descubra. Vou testar seus arquivos. Acho também que o tempo ocioso godot faz algo no computador ficar "preguiçoso", mas provavelmente é o sistema operacional, porque as diferenças em vitória com e sem aero em FPS, uso de CPU e gagueira são muito altas. Provavelmente é o SO que tenta ser inteligente e não a placa gráfica.

Gosto da ideia do Zylann de analisar o que os outros jogos fazem. Não sei se isso é offtopic, mas fiz alguns testes.
Em primeiro lugar, parece que 95% dos jogos Steam são de 32 bits (os lançamentos recentes também). Parece que a mesma porcentagem dos jogos é renderizada pelo DirectX. Capturo os processos que os jogos executam e tento ver o que está acontecendo com a renderização. Algumas informações por trás (não é para tirar conclusões, é apenas informações):

Jogo / bits executáveis ​​/ mecanismo / processo que usa para renderizar no Windows 7 64 bits e notas.

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

• Ori e a floresta cega -> 32 bits / Unity / Windows GDI. Executa um processo denominado OPENGL32 como godot, mas é uma espécie de invólucro no Windows GDI. Nem uma única chamada do OpenGL32, todas as chamadas são do Windows GDI.
  

• Poeira: Uma cauda Elysyian -> 32 bits / Microsoft XNA / Windows GDI. Possui gameoverlayrenderer.dll e todas as chamadas são deste (ClientToScreen). Não possui dll OpenGL.

• SuperMeatBoy -> 32 bits, execução dentro do Steam Overlay, Windows GDI

• ΔV: Rings of Saturn (demo) -> 64 bit, godot / Executa chamadas OpenGL e Windows GDI, faz uma única chamada para OpenGl SwapBuffers - GetPixelformat com um valor de 8. Faça muitas chamadas para Windows GDI. Faça chamadas duplicadas? para WindowsFromDC- SetRect (tamanho da janela), OffsetRect.
  

• Bastion -> 32 bits / SDL2 / Executa chamadas OpenGL puras, sem GDI do Windows, faz uma chamada exclusiva de swapBuffers - GetPixelFormat o tempo todo com um valor de 10.

• SouthPark the stick of truth -> 32 bits / motor desconhecido / Executa todas as chamadas no Windows GDI, parece direct3D v 9 (tem d3d9.dll mas faz poucas chamadas por este processo), a maioria das chamadas são de gameoverlayrenderer de steam e uxtheme.dll que executa OffsetRect e IsRectEmpty e outras funções de janela.
  

• Sine Mora -> 32 bits / mecanismo desconhecido / Executa todas as chamadas no Windows GDI por overlay do Steam, dicect3d 9

• Apotheon -> 32 bits / Microsoft XNA / Todas as chamadas no Windows GDI, uma única chamada do Steam overlay (Cliente para a tela), uma única chamada do Microsoft XNA (ScreenToClient) e chamadas de um processo chamado uxtheme.dll (gerenciamento de janela em Windows?) para IsRectEmpty e PtInrect (todos booleanos).
• Ovos voltam para casa -> 64 bits / Godot / Chamadas de OpenGL e de windows GDI, mesmo que o Anel de Saturno.
• Guacamelee! Super turbo .... -> motor de 32 bits / desconhecido, mas para os arquivos pode ser semelhante ao sine mora. Este jogo permite redimensionar a tela./ Todas as chamadas do Windows GDI.
• Não é um herói -> 32 bits / SDL2 (a wikipedia diz ClickTeam Fusion) / Todas as chamadas do Windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 bits (sim, há um) / Intro diz Firebird, nada a ver agora sobre processos / Todas as chamadas do Windows GDI, mas, há muito, muito poucas chamadas, poucas nos outros jogos, algumas chamadas por segundo (ej, você mal pode seguir as chamadas da Api Godot, há toneladas por segundo). Mas este jogo queima de GPU.

Percebo que a maioria dos jogos em foco perdidos param o processo e pausam (talvez uma boa prática?) E poucos jogos permitem redimensionar manualmente a tela (ej: não é um herói). Infelizmente, tenho o problema de perda de foco / ganho de foco em ΔV: Rings of Saturn (demo).

Edit: Parece que godot é o único motor que usa o processo OpenGL32 e WindowsGDI ao mesmo tempo.
Aplicativo usado: API Monitor v2

(Editar: nome correto de ΔV: anéis de Saturno (demonstração))

Se por Anéis de Saturno você quer dizer ΔV: Anéis de Saturno (demonstração), ele foi construído com Godot 3.1, mas não tenho certeza sobre a revisão exata que eles usaram?

Depois de muitas horas tentando descobrir a causa da gagueira, pelo menos no meu caso, por acaso rastreei a gagueira consistente de 1s até ter a opção 'Mudança automática para árvore de cena remota' habilitada em 'Configurações do Editor'. Desmarcar isso resolve os problemas de gagueira e desempenho para mim. (possivelmente ainda há uma leve gagueira, mas é quase imperceptível.)

Godot construir 8849d3b
Win10 64 bits, NVIDIA GeForce GTX 660, driver v416.81

Eu tive o mesmo problema de gagueira e desmarcar Mudança automática para árvore remota era o culpado.

Estou tendo o mesmo problema aqui. Existem vários problemas sobre este jitter, mas a maioria deles não parece ter as soluções adequadas e eu realmente preciso de ajuda.

Estou prestes a assinar um contrato com um editor com meu jogo que fiz com Godot e, por causa da instabilidade, posso ter que mover todos os meus códigos para o Unity. Tempo e custo para mover todos os códigos deixados de lado, estou relutante em mudar para um motor diferente porque gosto muito da filosofia de design de Godot e do próprio Godot.

Também notei que em 3.1 'Physics Jitter Fix' a opção foi adicionada no menu de configurações (https://twitter.com/reduzio/status/984783032459685890), mas isso também não ajuda.

Versão Godot:
Godot 3.0.6

Sistema operacional / dispositivo incluindo versão:
MacOS 10.14.1
MacBook (Retina, 12 polegadas, 2017)
1,2 GHz Intel Core m3
LPDDR3 de 8 GB 1867 MHz
Intel HD Graphics 615 1536 MB
(Mas esse problema ocorre em vários dispositivos, incluindo PC e jogos exportados no celular e PC.)

Descrição do problema:
Qualquer objeto em movimento parece gaguejar ou tremer periodicamente, acompanhado de congelamento da tela.

Passos para reproduzir:
Crie um novo projeto com um KinematicBody2D ou até mesmo um AnimatedSprite e modifique a posição com move_and_slide () ou set_position () após adicionar um Camera2D como um nó filho. (Mas ainda acontece mesmo sem o Camera2D.)

E parece acontecer com mais frequência em dispositivos com baixo poder de processamento.

Projeto de reprodução 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 64 bits, GTX 660 (drivers 391.35), Godot 3.0.6 e 3.1-beta1

Ei, eu ajustei o projeto original (parei as animações, usei o corpo rígido em vez de ajustar manualmente as posições, adicionei um fundo levemente animado, etc)

Aqui está: FirstGame_2.zip

Testado com a janela de tamanho ~ 500x500 e resolução de monitor de 1920x1080

Agora minhas observações:

• Jitter é omnidirecional (não apenas vertical, como problemas comuns de vsync)
• Quanto menor for o tamanho da janela, mais frequente é o jitter
• Desligar o vsync remove o jitter (os próximos marcadores são com o vsync ativado)
• Executar o jogo sem o editor na tela ao mesmo tempo (minimizá-lo, para que seja apenas a área de trabalho - ícones, papel de parede, barra de tarefas e talvez algumas janelas estáticas como gerenciador de arquivos ou terminal) remove o jitter
• O jogo exportado ou executado a partir do editor não importa
• Se eu executar o jogo com quakespasm-sdl2 na mesma tela (com um zumbi atacando o jogador debaixo d'água), vejo pouca vibração
• Se eu executar o jogo com um site shadertoy (esta demonstração: https://www.shadertoy.com/view/ll3fz4), não pausado, na mesma tela, vejo muito tremor
• Se eu executar o jogo com um site shadertoy, mas pausado, na mesma tela, vejo pouca instabilidade
• Se eu executar o jogo com o editor na mesma tela, com uma cena mostrada no editor não atualizando (Player.tscn), vejo pouca instabilidade
• Se eu executar o jogo com o editor na mesma tela , com uma cena exibida no editor atualizando-se com frequência (main.tscn, tenho um shader animado lá), vejo muito jitter

Não tentei com o Aero desligado, esqueceu como alternar rapidamente para frente e para trás?

@ starry-abyss para desligar o aero, vá para o painel de configuração, escolha "aparência e personalização", lá você deve ser capaz de mudar para um tema antigo como "Windows Classic", que não possui efeitos visuais (e então não use Aero) ou "Windows 7 Classic".

OK, então com o tema clássico o jogo, com shadertoy / editor na tela também, vai e volta do estado de gagueira para suavizar (cada estado pode permanecer por vários segundos). E a gagueira é acompanhada de ruptura vertical da estrutura neste modo. Dito isso, até a rolagem do Firefox rasga com o tema clássico: 'D

Estou tendo exatamente o mesmo problema que diiiiiiiii está tendo, o caso de uso dele com move_and_slide é o mesmo que o meu. Se você observar de perto, não é o objeto do jogador tremendo, mas o fundo de paralaxe por trás dele.

Projeto 2D com personagens cinemáticos
Godot 3.0.6
Win10 64bit
CPU Intel i5-2550K
16gb ram
Geforce GTX 970

Como isso acontece em muitos tipos diferentes de dispositivos, não acho que seja estritamente relacionado às configurações de hardware. Isso acontece até mesmo em jogos exportados em execução em dispositivos ios.

Se você observar de perto, não é o objeto do jogador tremendo, mas o fundo de paralaxe por trás dele.

@ behelit2 Não tenho certeza sobre isso. https://youtu.be/YVFtkbuyqEQ Nesta filmagem, se você olhar para o objeto do player, ele até balança sozinho. Pode ser um problema separado, mas fica muito pior quando a suavização da câmera está ativada ou o objeto é alternado para Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
Isso é o que acontece quando a suavização da câmera está ativada e o objeto é alternado para 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)

Posso ter amplificado o jittering usando apply_impulse () assim, mas modificar a posição do objeto diretamente usando set_position () não fez muita diferença.

@diiiiiiiii Acho que você deveria abrir um problema separado então. Caso contrário, o tópico estará cheio de afirmações contraditórias porque as pessoas estão testando coisas diferentes.
Por exemplo, estou tentando o projeto OP por enquanto, não o seu (desculpe).

@ starry-abyss Entendi;)
Embora já existam muitos problemas sobre jittering e eu acho que eles estão intimamente relacionados e podem ter a mesma causa raiz.

Atualização sobre a questão do OP. Encontrei algumas opções em Godot para limitar o fps sem usar v-sync. Então, para mim, são 60 fps com v-sync desativada e não ~ 4000 agora.
E o próprio fato de desligar a v-sync resolve o problema para mim.

Eu me pergunto se a v-sync faz sentido no modo de janela. O Windows parece usar v-sync por si só, e provavelmente luta com o jogo Godot, que irá preparar o quadro mais rápido depois que o sinal v-sync for recebido. Além disso, outros jogos do IIRC só funcionam em tela cheia com o v-sync desativado, e não no modo de janela.

Para sua informação, o problema de diiiiiiiii continua aqui: # 25162

Além da abordagem v-sync off, eu encontrei uma maneira específica do Windows interessante (pela descrição do commit pode ser esse problema), não tenho certeza se Godot já usa isso, mas talvez alguém tenha tempo para tentar:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Isso também está relacionado: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

No entanto, há também este tópico que vai em mais detalhes e com abordagens diferentes:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
E isso é complementar, mais curto e mais direto, mas também com algumas emoções no início: https://www.vsynctester.com/firefoxisbroken.html

Palavra de gagueira alterada para jitter em meu relatório acima, já que foi isso que experimentei (consulte https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Minha ideia era desligar o v-sync apenas no modo de janela (ou seja, pode ser feito a partir do código, até pode consultar a taxa de atualização do monitor para limite de fps), mas como os desenvolvedores principais não suportam a abordagem, não há nada para reconsiderar ainda. :) Existem outras maneiras mais específicas do Windows, mas ainda temos que provar que funcionam bem e não são muito hacky.

Atualização sobre a questão do OP. Encontrei algumas opções em Godot para limitar o fps sem usar v-sync. Então, para mim, são 60 fps com v-sync desativada e não ~ 4000 agora.
E o próprio fato de desligar a v-sync resolve o problema para mim.

Eu me pergunto se a v-sync faz sentido no modo de janela. O Windows parece usar v-sync por si só, e provavelmente luta com o jogo Godot, que irá preparar o quadro mais rápido depois que o sinal v-sync for recebido. Além disso, outros jogos do IIRC só funcionam em tela cheia com o v-sync desativado, e não no modo de janela.

como você limitou seu fps a 60?

Usando o campo "Force fps" em algum lugar na categoria Debug das configurações do projeto

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

Atualização sobre a questão do OP. Encontrei algumas opções em Godot para limitar o fps sem usar v-sync. Então, para mim, são 60 fps com v-sync desativada e não ~ 4000 agora.
E o próprio fato de desligar a v-sync resolve o problema para mim.
Eu me pergunto se a v-sync faz sentido no modo de janela. O Windows parece usar v-sync por si só, e provavelmente luta com o jogo Godot, que irá preparar o quadro mais rápido depois que o sinal v-sync for recebido. Além disso, outros jogos do IIRC só funcionam em tela cheia com o v-sync desativado, e não no modo de janela.
como você limitou seu fps a 60?
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Eu não vi pessoas postando suas CPUs com sistemas, exceto para e I5-2500K que tem uma GPU Intel integrada.

Meu laptop tem uma GPU integrada da Intel e uma placa Nvida dedicada. Estou apenas me perguntando se poderia haver um problema entre os dois gpu / drivers e Godot

Talvez. Mas não parece dependente de gpu / cpu. No i7 2700 + 1080ti pode ser gaguejado (com janela) e suave no mobile i5 com intel 4000 (1st gen surface pro) - em tela cheia.

Engraçado você dizer que se eu executar o projeto demo em meus laptops de 940m, vejo a gagueira. No entanto, quando executo o aplicativo usando o Intel 530 dedicado, não vejo gagueira alguma.

Windows 10 home
CPU i3-6100H a 2,70 GHz,
GeForce 940M (26.21.14.3064)
Intel (R) HD Graphics 530 (26.20.100.6709)

A gagueira é visível neste projeto ? (Mova pressionando as teclas de seta.)

Acabei de fazer uma exportação rápida, deixando a interpolação ativada e configurando a física para 60:
940M houve solavancos ocasionais, mas não houve cisalhamento
Intel 530 não houve empurrões, mas às vezes corte vsync óbvio,

Eu faço mais tarde e te aviso.

Parece que tive algum sucesso em limitar meu FPS a 60. Não tenho certeza se 60 é um número mágico, minha tela pode suportar 144, tentei definir o limite em 144, mas a gagueira ainda era visível. Baixei meu FPS para 120, a gagueira ainda era visível, mas não tão "borrada", o que me faz pensar que está ocorrendo apenas em um intervalo menor. Seguido com a redução do FPS para 80 e o mesmo resultado de antes, mas agora visivelmente mais lento. Além disso, devo dizer, desativei o v-sync e executando em modo de janela, testei em tela cheia, mas mesmo resultado. Há algum processo no motor limitado a 60 FPS?

Há algum processo no motor limitado a 60 FPS?

Por padrão, a física é simulada a 60 FPS, o que significa que haverá uma discrepância visível quando o FPS de renderização for maior do que o FPS da física (desde que a tela seja rápida o suficiente para mostrar a diferença). O FPS físico pode ser alterado nas Configurações do projeto ( Física> Comum> Fps física ).

Ele pode ser aliviado pela interpolação de corpos físicos, mas não há suporte oficial para isso. No 3.2alpha, você pode usar este complemento de suavização que torna mais fácil interpolar nós.

Há algum processo no motor limitado a 60 FPS?

Por padrão, a física é simulada a 60 FPS, o que significa que haverá uma discrepância visível quando o FPS de renderização for maior do que o FPS da física (desde que a tela seja rápida o suficiente para mostrar a diferença). O FPS físico pode ser alterado nas Configurações do projeto ( Física> Comum> Fps física ).

Ele pode ser aliviado pela interpolação de corpos físicos, mas não há suporte oficial para isso. No 3.2alpha, você pode usar este complemento de suavização que torna mais fácil interpolar nós.

Incrível, obrigado, isso pode explicar por que os personagens gaguejam enquanto o movimento é tratado na chamada do processo físico

Ainda pode reproduzir em 3.1.1 BTW, a maneira mais fácil é com Shadertoy aberto no Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

Eu tropecei aqui esperando que houvesse uma solução, mas depois de tentar quase todos os conselhos que vi neste tópico, ainda não houve dados. Para mim, o tremor só acontece quando executo o projeto na placa NVIDIA. Se eu executá-lo usando a GPU Intel integrada, ele funciona perfeitamente. : /

Estou usando a versão alfa mais recente do Godot 3.2 no Windows 10

Eu tropecei aqui esperando que houvesse uma solução, mas depois de tentar quase todos os conselhos que vi neste tópico, ainda não houve dados. Para mim, o tremor só acontece quando executo o projeto na placa NVIDIA. Se eu executá-lo usando a GPU Intel integrada, ele funciona perfeitamente. : /

Estou usando a versão alfa mais recente do Godot 3.2 no Windows 10

Acho que não dá para consertar no windows, isso não acontece no linux, pode ser corrigido no 4.0 com o novo renderizador vulkan.

Eu tropecei aqui esperando que houvesse uma solução, mas depois de tentar quase todos os conselhos que vi neste tópico, ainda não houve dados. Para mim, o tremor só acontece quando executo o projeto na placa NVIDIA. Se eu executá-lo usando a GPU Intel integrada, ele funciona perfeitamente. : /
Estou usando a versão alfa mais recente do Godot 3.2 no Windows 10

Acho que não dá para consertar no windows, isso não acontece no linux, pode ser corrigido no 4.0 com o novo renderizador vulkan.

Bem, isso é uma merda, a API Vulkan não se concentra apenas em dispositivos de ponta?

Eu viso especificamente o OpenGL 2.0 para que eu possa oferecer suporte a dispositivos de baixo custo. É meio bobo usar uma API gráfica de ponta apenas para um jogo 2D e excluir pessoas com computadores / laptops de ponta. 😕

Parece um mito. Talvez a gagueira de vez em quando não possa ser corrigida no ATM, mas o stutterware que estamos experimentando é um recurso exclusivo de Godot.

Parece um mito.

A que você estava se referindo com isso?

Esta é uma questão desafiadora. Por um lado, gostaria de corrigir isso pessoalmente o mais rápido possível. Mas não posso reproduzir, então não há nada que eu possa fazer. (Eu uso o Windows 10 com uma placa gráfica NVidia)

Alguém que pode reproduzir o problema precisa tentar consertá-lo, infelizmente. :(

Embora seja um problema incomum, parece ser comum o suficiente para atrair muitas pessoas para este tópico. Espero que um de vocês possa trabalhar nisso.

Ah, estou sempre esquecendo que o que experimento é chamado de jitter em termos oficiais do Godot doc.

_Alguém sabe capturar perfeitamente o problema em 60 FPS sem comprar algum hardware? _
Acho que algumas pessoas subestimam o quão ruim parece, e talvez também seja um problema de aparência diferente em PCs diferentes.

A que você estava se referindo com isso?

O mito: "é sempre assim no OpenGL (ou Windows, etc.). Só o Vulkan pode nos salvar".

OK então:

1. este é um vídeo do OBS: https://www.youtube.com/watch?v=osbJlk1XD8c O impacto do OBS é que apenas ter o OBS em execução já faz jitter no projeto Godot (mesmo quando a captura está desligada).
2. Sem OBS é suave até que eu desminimize o Firefox com shadertoy nele, então ele começa a gaguejar, mas não consegue capturar com OBS, porque 1.

Chips em minha própria gravação, isso é feito com Bandicam e na maior parte é assim que funciona com ou sem gravação. Como você pode ver, começa suavemente, mas aos poucos começa a ter problemas

@clayjohn Acho que seria corrigido com a implementação da interpolação física, mas reduz se opõe a tê-lo no núcleo por alguns motivos. Ainda assim, um método foi adicionado em 3.2alpha para expor a razão de passo da física atual, o que torna possível implementar uma interpolação física precisa manualmente.

@ starry-abyss Se você pode usar 3.2alpha, experimente o complemento de smoothing do gramado: ligeiramente_smiling_face:

Apenas um pensamento, há algo útil no motor irreal ou fonte physX para olhar?

Felicidades,
Victor Stan

Em 22 de outubro de 2019, às 4:17, Hugo Locurcio [email protected] escreveu:

@clayjohn Acho que seria corrigido implementando a interpolação física, mas reduz se opõe a tê-lo no núcleo.

@ starry-abyss Se você pode usar o 3.2alpha, experimente o complemento de suavização do gramado 🙂

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

@victorbstan Não devemos olhar para o código-fonte do Unreal, pois não está sob uma licença de código aberto. (Ele nem mesmo permite a redistribuição para usuários Unreal Engine não licenciados.)

Definitivamente, não retire código de código fechado, mas arquitetonicamente você pode
não colhe idéias disso? [não é advogado]

Na terça, 22 de outubro de 2019 às 11h07 Hugo Locurcio [email protected]
escrevi:

@victorbstan https://github.com/victorbstan Não devemos olhar para
Código fonte do Unreal, pois não está sob uma licença de código aberto. (Não faz
até mesmo permitir a redistribuição para usuários Unreal Engine não licenciados.)

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6VJPQ#issuecomment-545084606 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Eu ainda não recomendo olhar seu código-fonte. Se você quiser se inspirar em um algoritmo proprietário, deve realizar engenharia reversa de sala limpa para reduzir o risco legal associado.

Ainda assim, não precisamos fazer nada disso aqui. A solução é usar interpolação física, que os motores de jogos mais populares usam atualmente. Tem algumas desvantagens (como exigir trabalho do usuário para evitar a interpolação ao teletransportar objetos), mas acho que as vantagens superam em muito.

Eu entendo, a sugestão é ter uma ideia de possíveis caminhos para encontrar uma solução, não necessariamente plagiar. Eu não imagino que haja uma patente para resolver problemas de oscilação / gagueira, mas IANAL.

Felicidades,
Victor Stan

Em 22 de outubro de 2019, às 14h07, Hugo Locurcio [email protected] escreveu:

@victorbstan Não devemos olhar para o código-fonte do Unreal, pois ele não está sob uma licença de código aberto. (Ele nem mesmo permite a redistribuição para usuários Unreal Engine não licenciados.)

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

Em meus cenários, o gerador de perfil Godot mostra 60 FPS perfeitos, mesmo quando vejo jitter / stutter. Isso significa que o problema não está relacionado à interpolação ou estou faltando alguma coisa?

Minha suposição era que as temporizações de Godot foram implementadas de uma forma que interfere nas temporizações do compositor do Windows (e talvez SDL faça isso melhor do que GLFW Godot, portanto, outras engines apenas funcionam onde Godot falha).

(e talvez o SDL faça isso melhor do que o GLFW, portanto, outros motores simplesmente funcionam onde Godot falha).

Godot usa seu próprio código de gerenciamento de janela, não usa SDL nem GLFW: ligeiramente_smiling_face:

Tenho o Windows 10 e uma nVidia GeForce GTX 1070 e, com a versão 3.2 alpha2 com vsync habilitado, tenho instabilidade quando em modo de janela. O modo de tela inteira parece bom. O problema é particularmente grave se o editor não for minimizado quando o jogo for executado. O jogo que estou testando usa apenas _process() para atualizar as posições. Por causa disso, suspeitei que o problema tinha a ver com delta muito barulhento ou quadros perdidos (deltas grandes), mas esse não é o caso. O delta é realmente estável durante o jittering.

Com base na pesquisa de outros neste tópico, eu hackeei uma mudança para context_gl_windows.cpp para definir o intervalo de troca para 0 e chamei DwmFlush() em 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;
}

Isso se baseia no que os projetos glfw e Chromium fazem.

Fazer essa alteração parece corrigir o jitter no modo de janela. No modo de tela inteira, o jogo tem tearing, então o DWM provavelmente está desabilitado e o buffer duplo por meio de um valor de intervalo de 1 parece ser necessário. (Basicamente, o código precisa fazer o que faz atualmente.)

Se alguém mais estiver disposto e for capaz de experimentar, eu estaria interessado em saber como é.

Parece que wglSwapIntervalEXT(0); part é o mesmo que desligar a v-sync nas opções.

Parece wglSwapIntervalEXT (0); parte é o mesmo que desligar a v-sync nas opções.

Isto é. 1 - habilitar vsync, 0 - desabilitar, e também há -1 para "vsync adaptável" (desabilitar a sincronização em taxas de quadros baixas, habilitar em altas).

Eu testei o DwmFlush () acima com meus casos simples, no branch 3.1.x.

• Ele corrige a situação com o caso de teste do shadertoy;
• V-sync ativado ou desativado - parece o mesmo para mim (não apliquei patch na parte wglSwapIntervalEXT ());
• O caso OBS ainda está tremendo (parece o mesmo, eu acho), mas Godot agora relata queda de FPS para 40 (eu me pergunto se o profiler em Godot realmente está com a versão original de Godot);
• Também tentei chamar DwmFlush () após SwapBuffers (hDC) e todos os 3 pontos permaneceram os mesmos.

Não tenho certeza, mas acho que DwmFlush () após SwapBuffers (hDC) pode ser mais correto, já que Godot coloca o quadro na atualização do compositor mais próxima, não na próxima, que está depois do mais próximo.
Eu me pergunto se Godot deveria detectar melhor se o compositor está rodando e voltar para o método vanilla v-sync se não estiver.

Então, a próxima a tentar será o novo recurso de interpolação mencionado por Calinou.

ATUALIZAÇÃO: sim, no caso de OBS, o Godot relata 0,03 segundos de tempo de processo (mas FPS é relatado como 60), provavelmente o contador FPS de Godot não leva em consideração a falta do v-blank a cada duas vezes
ATUALIZAÇÃO 2: infelizmente, o plugin de interpolação não parece ajudar aqui; Ainda estou tendo jitter no caso de OBS e gagueira e / ou mistura de jitter no caso de shadertoy

Parece que wglSwapIntervalEXT(0); part é o mesmo que desligar a v-sync nas opções.

Correto, mas adicionar DwmFlush() em swap_buffers() fará com que o jogo use o compositor (DWM) para a sincronização. Quando o compositor está habilitado, você efetivamente tem buffer duplo, queira ou não. Você teria buffer triplo no caso de definir o intervalo de troca do OpenGL para 1. (Seus dois buffers e o do compositor.)

Também me pergunto por que os outros projetos chamam DwmFlush() antes de SwapBuffers() . Parece ao contrário, mas quase me convenci de que está certo.

No caso desses projetos, eles não estão usando o buffer duplo do OpenGL (quando o compositor está habilitado), portanto, fazer dessa forma parece ser a melhor maneira de entrar em sincronia com o período em branco vertical. Com um intervalo de troca OpenGL de 0, a chamada para SwapBuffers() não bloqueia, então você está apresentando ao compositor o próximo quadro assim que souber que terminou com o atual. Isso efetivamente tem o mesmo efeito que usar um intervalo de troca OpenGL de 1. (Quando o compositor não está interferindo - modo de tela inteira, por exemplo.)
>
>

Eu me pergunto se Godot deveria detectar melhor se o compositor está rodando e voltar para o método vanilla v-sync se não estiver.

Eu acho que você está certo. Parece óbvio que a sincronização v do OpenGL é interrompida quando o compositor é habilitado. Se você olhar o código do glfw e do Chromium, eles chamam isso (usando DwmFlush() ) de HACK. É provável que eles pensem que o OpenGL está quebrado neste caso e estão tendo que fazer algo que deveria.

@ starry-abyss Depois de reler sua postagem sobre o caso de OBS que não mudou, me pergunto se esse projeto tem vsync habilitado. Como você não mudou a chamada para wglSwapIntervalEXT() ter o vsync habilitado basicamente fará com que o jogo seja bloqueado em DwmFlush() e SwapBuffers() . Isso explicaria o tempo de processo de 0,03 segundos.

@TerminalJack Não, tentei todas as combinações. O tempo de processo sempre aumenta para 0,03 quando executo o OBS. É que Godot parece se esforçar muito para chegar a 60 FPS, mesmo quando não consegue atingir isso vários quadros em sequência.

Então, eu dividiria em duas questões:
1) Godot não é amigo do compositor;
2) Godot está muito ansioso para ter o máximo de FPS enquanto ele poderia fornecer 30 estáveis ​​sob carga.

Mas se houver uma maneira confiável de (des) provar se 0,03 é tempo de computação puro e não sincronizado, posso tentar.

@ starry-abyss Para fins de teste, você pode usar o Gerenciador de Tarefas para aumentar a 'prioridade' desse processo para 'alta'. Isso fará com que ele se sobreponha aos outros e receba a maior parte do tempo de processamento. Isto é, desde que esteja em um estado executável e não bloqueado em DwmFlush() e / ou SwapBuffers() .

Não tive muita chance de mexer com isso hoje, mas tentei executar a mudança em um sistema Windows 10 que tem uma GPU Intel UHD Graphics 620 integrada. (Uma GPU relativamente simples.)

Eu executei o jogo pela primeira vez (em modo de janela) com a versão 3.2 alpha2 mais recente e não teve nenhum instabilidade perceptível. Em seguida, executei o jogo com as alterações e funcionou bem também.

Acontece que eu registrei delta vezes durante as duas execuções e descobri que eles eram muito mais estáveis ​​com a chamada para DwmFlush() que sem ...

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

Compilação de teste

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)

(Os deltas altos no início aqui se devem ao fato de que foram tirados logo após o carregamento da cena. A construção alfa exibe o mesmo comportamento.)

Observe como a construção de teste finalmente se estabilizou e atingiu um estado estável. A versão 3.2 alpha2 nunca o fez.

Portanto, parece que não apenas as outras GPUs não serão adversamente afetadas por essa mudança, mas também se beneficiarão dela. Meu palpite é que o jitter fica pior à medida que a GPU fica mais poderosa e não depende do fabricante ou mesmo dos drivers.

Eu criei um fork que tem um único commit que deve resolver esse problema.

Eu testei apenas em duas máquinas Windows 10, no entanto, seria ótimo se outras pessoas pudessem construí-lo e testá-lo em outras versões do Windows. Além disso, eu o construí usando VC ++ 2019, então se alguém usando o mingw pudesse construí-lo, seria ótimo também.

Se você tiver sua própria bifurcação (recente) do projeto, deverá ser capaz de corrigir essa alteração nela sem problemas.

Estou no Windows 10 com um NVidia GTX 1050.

Não tenho gagueira no projeto de exemplo, a menos que tenha um shadertoy aberto e em execução (conforme descrito alguns comentários acima).

Com o commit de @TerminalJack , a gagueira ainda está presente quando o shadertoy está em execução.

@clayjohn Obrigado por testar isso. Eu me pergunto se o problema no seu caso é apenas uma questão de poder de processamento.

Posso executar um shadertoy 800 x 450 em segundo plano e um jogo Godot (executado a partir do editor) em uma janela em primeiro plano e obter muito pouco tremor com as alterações que fiz. A versão alpha2, por outro lado, tem tremulação severa nas mesmas circunstâncias. Eu sou uma das pessoas que tem tremores severos, mesmo sem nenhuma carga no meu sistema, então isso provavelmente é algo a se levar em consideração também.

@TerminalJack Bom argumento. Eu estava executando o sombreador de floresta tropical do iq :)

Acho que também há uma grande probabilidade de que haja vários problemas em jogo aqui. Como @Calinou apontou acima, muitos usuários corrigiram o problema ao usar a física interpolada.

Neste ponto, acho que você deve fazer o PR de seu commit, parece bom e fazer um PR dará mais visibilidade e tornará mais fácil para outros usuários construir e testar.

@clayjohn Sim, concordo que provavelmente existem outros problemas que se comportam de forma semelhante a este.

Na verdade, comecei tentando rastrear um problema com uma gagueira grave que acontece uma vez a cada 60 a 90 segundos e me deparei com este tópico. (Parece que algo está bloqueando o processo de 60ms a 100ms de vez em quando.) Eu estava executando meu jogo no modo de tela inteira e não estava apresentando nenhum tremor. Depois de encontrar este tópico, porém, tentei executá-lo em uma janela e, vejam só: sou um dos sortudos que podem reproduzir esse problema específico.

Provavelmente, removerei as instruções de depuração de minhas alterações e enviarei um PR em algumas horas.

@TerminalJack O fork não está mais disponível (ou está definido como privado). Você poderia disponibilizá-lo novamente?

@Calinou Desculpe. Eu levantei o repositório, então eu o excluí. Vou fazer um fork novamente e re-commitar as alterações aqui em breve.

@Calinou O novo commit está aqui .

@TerminalJack Sua correção parece ser apenas para Windows, mas eu enfrento o mesmo problema no Ubuntu.

@TerminalJack Sua correção parece ser apenas para Windows, mas eu enfrento o mesmo problema no Ubuntu.

Sim, esta é definitivamente uma correção exclusiva do Windows. Desculpa.

Não sei se é necessário fazer algo semelhante no Ubuntu ou não. Não tenho certeza se ele usa um compositor.

Não sei se é necessário fazer algo semelhante no Ubuntu ou não. Não tenho certeza se ele usa um compositor.

Na verdade, não há como desativá-lo em alguns gerenciadores de janela (incluindo o padrão do Ubuntu): ligeiramente_smiling_face:

@TerminalJack Também pode precisar de alguma lógica para quando o Aero está desabilitado, por exemplo, no Windows 7 (IIRC não faz v-sync, então Godot provavelmente ainda deve fazer v-sync neste caso)

@ starry-abyss, espero que esse caso seja descoberto. Eu tenho um laptop antigo com o Windows 7. Se ainda funcionar farei alguns testes com ele e verei se alguma mudança é necessária.

Liguei meu laptop de 10 anos que tem o Windows 7 e testei minhas alterações. Tive que usar o mais simples dos projetos para teste. (GPUs de laptop eram extremamente ruins naquela época.) Usei o projeto deste post. Eu adicionei o seguinte para que eu pudesse alternar para tela inteira / fora dela.

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

Eu executei o projeto com minhas alterações e sem e não houve diferenças perceptíveis de qualquer maneira. Com minhas mudanças, o compositor seria usado para v-syncing quando esperado (modo de janela, compositor habilitado) e OpenGL double-buffering seria usado em todos os outros casos.

A boa notícia é que não haverá nenhuma alteração necessária no _code_. O código detecta se o compositor está habilitado ou não como deveria. Ele ainda lida com o caso em que você ativa ou desativa o compositor enquanto o aplicativo está em execução. Este é um caso que eu não previ, portanto, não o incluí nos comentários em swap_buffers() relação aos casos em que a estratégia de sincronização v muda rapidamente. Então essa é a única coisa que preciso mudar até onde sei.

Uma das coisas levantadas no irc hoje discutindo isso (e o PR do TerminalJack) é isolar o erro no delta de entrada medido do erro no delta de saída.

Calinou apontou que podemos testar isso até certo ponto, executando com a opção de linha de comando --fixed-fps 60 . Isso tratará o delta de entrada como se fosse sempre 1/60 de segundo.

Seria muito útil se aqueles que estão tendo o problema (especialmente no Windows) nos informassem se isso tem algum efeito no jitter.

@lawnjelly Eu tentei rapidamente com e sem a opção de linha de comando, mas infelizmente não consigo reproduzir o problema hoje%) Exceto o caso OBS, que ainda é o mesmo.
O valor da opção armazenado entre as execuções do editor é por acaso?

O valor da opção armazenado entre as execuções do editor é por acaso?

Não, é apenas um argumento de linha de comando (que não tem estado).

ESTÁ BEM. Além disso, BTW, a opção está disponível no Godot 3.1.1 (a versão na qual faço a maioria dos testes aqui)?

ESTÁ BEM. Além disso, BTW, a opção está disponível no Godot 3.1.1 (a versão na qual faço a maioria dos testes aqui)?

Se você estiver usando 3.1.1 para testar isso, você precisará mover objetos a uma distância proporcional ao delta durante _process, visto que não há interpolação de tempo fixo.

@ starry-abyss Esse argumento de linha de comando foi adicionado no 3.1, então ele deve estar disponível no 3.1.1 também.

Portanto, --fixed-fps 60 não ajudou com o problema para mim. E executar o jogo diretamente na linha de comando também não ajudou (eu ainda tinha uma instância separada do editor na tela para reproduzir mais rapidamente).

E também tentei os dois ao mesmo tempo, caso a solicitação --fixed-fps 60 implicasse isso, ainda estava nervoso.

A dificuldade de reproduzir ontem foi porque eu tinha o v-sync desativado nas opções de testes anteriores. : /

não há interpolação de tempo fixo.

Claro, estou testando métodos um por um, não todos de uma vez (não como o plugin de interpolação + dwmflush + qualquer ideia nova).
Além disso, da próxima vez, inclua as etapas específicas para experimentar a nova ideia, para não ter que adivinhar as versões de Godot, para executar o editor ou jogo diretamente, etc. Não tenho o desejo de tentar todas as combinações possíveis de tudo (com cada ideia dobrando a quantidade de combinações). : P

Claro, estou testando métodos um por um, não todos de uma vez (não como o plugin de interpolação + dwmflush + qualquer ideia nova).
Além disso, da próxima vez, inclua as etapas específicas para experimentar a nova ideia, para não ter que adivinhar as versões de Godot, para executar o editor ou jogo diretamente, etc. Não tenho o desejo de tentar todas as combinações possíveis de tudo (com cada ideia dobrando a quantidade de combinações). : P

Eu entendo que não é mencionado nos documentos e não há interpolação de timestep fixo no núcleo. Talvez eu deva tentar escrever algo sobre isso para os documentos, eu não adicionei a documentação antes.

_O resultado é este: _
Independentemente de outros problemas (delta, SO), se você usar física ou mover objetos em _physics_process, atualmente Godot apresentará jitter como resultado do aliasing entre tiques físicos e quadros reais. Isso ocorrerá até certo ponto em todas as combinações de taxa de tique da física / taxa de atualização do monitor, algumas serão piores do que outras.

O método 'jitter fix' foi uma tentativa de contornar esse aliasing, fazendo-o ocorrer de uma forma menos pronunciada (ainda ocorrerá). Pense em aliasing de escada.

A fim de evitar esse jitter 'nível básico', você atualmente precisa
1) (Disponível em todas as versões de Godot) Mova objetos em _process e mova-os por uma distância proporcional ao delta. Isso não é ideal para jogos, pois você não pode usar a física e o comportamento depende da taxa de quadros, no entanto, pode ser usado para testes de jitter.

2) (Disponível em Godot 3.2 em diante) Usado interpolação de tempo fixo. Isso só é realmente possível no 3.2 com a função Engine-> get_physics_interpolation_fraction (). Consulte https://github.com/lawnjelly/smoothing-addon para obter um exemplo de como usar isso.

Estes são os pré-requisitos ANTES de você começar a investigar o jitter. Eles darão uma relação linear entre a posição de um objeto e o tempo, que é o que queremos.

Um método alternativo (mais amigável para iniciantes) de conseguir isso é com timestep semifixo, para o qual fiz um PR desde julho # 30798.

Esta é a base da investigação científica e do teste de hipóteses. A ideia é reduzir o máximo possível dos efeitos de confusão e examinar um de cada vez.

Existem 3 fatores principais em jogo aqui:

1) Relação linear entre a posição do objeto e o tempo do jogo (veja acima)
2) Erro nos tempos de entrada
3) Erro nos tempos de saída

Elimine (1) como acima. Elimine (2) usando o argumento da linha de comando, então você pode examinar (3) isoladamente.

Além disso, para qualquer investigação de jitter, você deve mover objetos diretamente, não por meio da física, pois a física pode potencialmente adicionar jitter em si.

_Editar:_
Acabei de dar uma olhada no projeto de reprodução mínima neste segmento (evite os arrepios) e ele está se movendo com velocidade * delta em _process, o que deve ser bom. Ele depende de is_action_pressed e, pessoalmente, eu removeria isso como um possível problema, mas provavelmente está tudo bem. Se estiver usando outro projeto para testar o jitter, tome cuidado com os pontos acima.

@lawnjelly entendo. Fiquei com a impressão de que o plug-in de interpolação ainda é algo testado apenas por alguns caras e pode apresentar erros (e até aumentar o jitter). Então peguei o que é estável (3.1.1), é assim que "científico" funciona para mim.
Vou tentar com as novas considerações da próxima vez.

Acabei de dar uma olhada no projeto de reprodução mínima neste tópico

Estou usando minha própria versão do projeto, já que a original está usando animações (pode mascarar o jitter) e tem sprite cinza sobre fundo cinza. Vou ajustá-lo para atender aos seus critérios.

Portanto, --fixed-fps 60 não ajudou com o problema para mim.

Essa é uma informação muito útil. Isso parece mover o dedo pontudo da culpa em direção ao atraso de saída (e ao compositor) e emprestar peso ao tipo de abordagem no PR. Isso pressupõe o uso de buffer duplo / triplo e a manutenção do pipeline alimentado, e não a eliminação de quadros.

Este também é o caso de @TerminalJack com o argumento de linha de comando?

Estou usando meu próprio projeto, já que o original está usando animações (pode mascarar o jitter) e tem sprite cinza sobre fundo cinza. Vou ajustá-lo para atender aos seus critérios.

Ah bom, obrigado! : +1:

@lawnjelly entendo. Fiquei com a impressão de que o plug-in de interpolação ainda é algo testado apenas por alguns caras e pode apresentar erros (e até aumentar o jitter).

Um pouco fora do assunto, mas deve ficar bem (não toquei nisso há algumas semanas), não deve apresentar instabilidade. Se você encontrar algum bug, avise-me no rastreador de problemas ou mesmo faça um PR. : +1: Pretendo colocá-lo nos addons oficiais para 3.2 _quando eu tiver tempo para isso_: smile:.

@lawnjelly

Este também é o caso de @TerminalJack com o argumento de linha de comando?

Desculpe, não tive a chance de experimentar suas sugestões. Eu meio que entrei na toca do coelho sobre o assunto em que estou trabalhando.

@lawnjelly Por nossa discussão no tópico de relações públicas, eu apenas pensei em mencionar que você estava correto sobre a opção de linha de comando --fixed-fps <fps> . Na verdade, ele mantém o vsync ativado. Então, como você estava dizendo, usá-lo é uma boa maneira de fatorar quaisquer problemas com o cálculo do delta. Devo ter errado quando tentei antes e tive gagueira porque não é o caso agora.

Eu tenho usado essa opção junto com as minhas alterações para estabelecer que o uso de DwmFlush() não ajuda quando executado fora do editor. Se você desabilitar DwmFlush() , poderá causar gagueira no jogo simplesmente arrastando alguma outra janela ou passando o mouse sobre uma das tarefas em execução na barra de tarefas. Obviamente, como o jogo está rodando com uma prioridade 'Acima do Normal', isso não deveria acontecer. (E não acontecerá se DwmFlush() estiver sendo usado.)