Apakah Anda mencoba tanpa melakukan spamming pada konsol? Ini dapat memiliki dampak yang cukup signifikan.
Sebagai contoh: hapus print(...) baris 15 _character.gd_ Anda

Sunting: Di sisi saya, saya dapat dengan jelas melihatnya gagap dengan panggilan cetak, dan bukan tanpa mereka.

@ Ploppy3 Yup saya mencoba tanpa itu. Saya berharap solusinya sesederhana itu ... Saya benar-benar tidak ingin beralih ke Unity.

Ini mungkin bekerja lebih baik ketika diekspor, mungkin mencoba bereksperimen dengan Vsync dalam pengaturan proyek. Jika Anda memiliki pengaturan monitor ganda dengan kecepatan refresh berbeda, ini dapat berdampak pada gagap dalam pengalaman saya. Dalam kasus saya ini akan bekerja dengan lancar di monitor pertama, sementara gagap terjadi saat men-debug game di monitor kedua, misalnya.

@Xrayez Saya membaca komentar di utas yang berbeda tentang menghidupkan atau mematikan Vsync membuat masalah hilang atau setidaknya kurang parah tetapi dalam kasus saya, tidak ada bedanya.
Satu-satunya hal yang tampaknya membuatnya kurang parah adalah menyetel fps fisika ke lebih tinggi dari 60. https://github.com/godotengine/godot/issues/17823#issuecomment -431084637
Tapi itu tidak membuat masalah hilang dan perbedaannya bisa diabaikan.

@diiiiiiiii dapatkah Anda mencoba dengan 3.1 beta? ada banyak perbaikan di KB2D, Camera2D dan Viewport, juga Kamera memiliki mode pembaruan baru (fisika) di properti yang dapat membantu dalam beberapa kasus.

EDIT: Mengubah mode proses kamera ke CAMERA2D_PROCESS_PHYSICS menyelesaikan jittering yang parah pada benda kaku itu sendiri.

@ eon-s Ya saya sudah menguji dengan 3.1beta2. Dan itu memperbaiki jitter objek bergerak itu sendiri saat penghalusan kamera aktif. Namun sayang gagap secara keseluruhan masih ada.

Sebagai solusi sementara ini sedang diselidiki, kamera dengan masalah halus dapat diganti dengan kode khusus untuk memindahkan area pandang dan membuat perataan yang bergerak dan memutar posisi pada proses fisika.

Masalah terkait (beberapa komentar mungkin menyebutkan solusi lain):

2667

16918

17823

23758

Tunggu, saya pikir saya telah salah membacanya, perbaikan yang diaktifkan dengan lancar beberapa jittering?

Saya bekerja di 3.1 beta 2, dan berpikir saya akan membagikan pengalaman saya.

Saya melihat adanya gagap secara berkala di latar belakang saya saat menjalankan mode berjendela dalam resolusi asli saya (640x360), tetapi sangat mulus dalam layar penuh. Ada gagap setiap setengah detik.

Saya juga memperhatikan bahwa FPS sementara berjendela berosilasi antara 58 dan 59, tetapi sementara dalam layar penuh itu mulus 60.

Mengubah mode proses kamera tidak berpengaruh.

Tidak yakin apakah ini terkait dengan masalah yang dilaporkan.

Menguji proyek sampel, mendapat beberapa gagap di latar belakang (Ubuntu, R5, godot 3.1b2), tidak teratur dan tampaknya tidak terkait dengan fisika, lebih terlihat seperti masalah presisi mengambang karena zoom rendah, gerakan juga lambat. ..

Saya juga menguji proyek sampel (Window 8, Intel HD Graphics 4600, 3.1b2).

Saya juga melihat adanya gagap di latar belakang. Bagi saya, itu lebih terasa dan terjadi hampir setiap detik. Mengomentari baris print() tidak membantu.

Ketika saya meletakkan proyek uji dalam layar penuh, saya tidak melihat adanya gagap.

Mencoba menangkap layar , tetapi kualitasnya tidak terlalu bagus, jadi saya tidak yakin itu akan banyak membantu.

Saya bermain sedikit dengan kecepatan refresh, dengan vsync mati memaksa fps untuk mencocokkan monitor (60 dan 40) gagap hilang, mungkinkah mesin tidak mengambil nilai vsync yang benar atau tidak menerapkannya?

saya mengubah _physics_process menjadi _process dan menghapus print , sepertinya jitter hilang untuk saya
OS; w10, 64-bit, 144hz monitor (gtx 950)

jika Anda masih mengalami masalah ini dan tidak ingin pindah ke kesatuan ... saya sarankan menggunakan _process dan gerakan kamera khusus di bawahnya (jika node camera2d adalah pelakunya, bagaimanapun, itu harus berfungsi dengan baik ada ada beberapa pekerjaan akhir-akhir ini)

dan ya jika saya menjalankannya menggunakan physics_process, itu sangat gelisah (tidak dapat dimainkan)

@ eon-s, saya mencoba ini juga, baik dalam proyek sampel maupun proyek skala penuh saya.

Saya menonaktifkan vsync dan meng-hard-code FPS agar sesuai dengan kecepatan refresh saya (60 Hz). Itu cukup banyak menyingkirkan gagap!

Saya bertanya-tanya mengapa ini terjadi. Seperti yang saya sebutkan sebelumnya, ketika vsync diaktifkan, saya tidak pernah memperhatikan gagap dalam layar penuh — hanya dalam jendela. Mungkinkah vsync berfungsi dengan baik dalam mode layar penuh tetapi tidak dalam mode berjendela?

RigidBody2D, _physics_process (), apply_impulse (), penghalusan kamera aktif

https://youtu.be/MGMlhl0tPTA

Pemulusan kamera @ eon-s diaktifkan hanya pada contoh kode terakhir. Dan tidak seperti gagap di seluruh layar atau objek, yang terjadi di semua contoh kode, saat penghalusan kamera diaktifkan, objek bergerak (RigidBody2D, KinematicBody2D, dll.) Itu sendiri bergetar bolak-balik dengan ganas. Dan mengubah mode proses kamera ke CAMERA2D_PROCESS_PHYSICS menyelesaikan gangguan pada objek bergerak itu sendiri tetapi tidak gagap secara keseluruhan.
Dan saya minta maaf jika saya membuat kebingungan. Bahasa Inggris bukanlah bahasa pertama saya.

Menguji proyek sampel, mendapat beberapa gagap di latar belakang (Ubuntu, R5, godot 3.1b2), tidak teratur dan tampaknya tidak terkait dengan fisika, lebih terlihat seperti masalah presisi mengambang karena zoom rendah, gerakan juga lambat. ..

Karena masalahnya tetap ada bahkan tanpa kamera, saya rasa ini tidak terkait dengan zoom.

KinematicBody2D, _process (), set_global_position ()

https://youtu.be/YVFtkbuyqEQ

@girng Dalam contoh kode ketiga, _process () digunakan sebagai ganti _physics_process (). Saya belum mencoba kode khusus untuk pergerakan kamera. Sekali lagi, ini terjadi bahkan tanpa kamera.

@sicienss Saya membaca beberapa komentar di utas terkait tentang memperbaiki fps dan saya mencoba memperbaikinya ke 60 dan 40. (Apakah Vsync diaktifkan atau tidak masalah) Dan sepertinya ketika fps diperbaiki ke 40 atau lebih rendah, gagap lebih jarang terjadi. Tapi mungkin karena fps terlalu rendah dan gagap menjadi sulit. Dan juga dalam kasus saya, tidak dapat menemukan perbedaan nyata antara mode layar penuh dan berjendela. Tapi saya akan mengujinya lagi untuk berjaga-jaga.

EDIT :
Pengujian: Layar Penuh
Pengujian: 40Fps, Vsync-False
Pengujian: 60Fps, Vsync-False
Tes: Tidak Ada Camera2D
Tes: 40Fps, Vsync-False, Tanpa Camera2D

(Fps telah diperbaiki menjadi 60 di pengaturan)

Saya tidak yakin ini normal atau bahkan terkait dengan masalah ini tetapi lonjakan delta proses ke-2 dan ke-3 terjadi ketika objek mulai bergerak. Apakah normal untuk melihat lonjakan semacam itu dalam proyek sederhana dan semuanya telah selesai dimuat sebelum pemindahan?

Saya mengalami masalah yang sama diiiiiiiii dalam kasus penggunaan move_and_slide-nya.

Proyek 2D dengan karakter kinematik
Godot 3.0.6
Win10 64bit
CPU Intel i5-2550K
RAM 16 GB
Geforce GTX 970

Hanya sebagai komentar sampingan, Anda dapat menggunakan move_and_slide di _process biasa sekarang di 3.1, ini dapat memperbaiki banyak masalah jitter karena harus menggunakannya dalam _physics_process. Meskipun saat ini tampaknya tidak terlalu menjadi masalah.

Juga gagap sebagian besar waktu terkait OS. Saat Anda menggunakan layar penuh, OSX dan Windows memberikan proses Anda lebih banyak prioritas sehingga lebih sedikit gangguan. Jika Anda tidak melihat gagap dalam layar penuh, sepertinya beberapa tugas latar belakang adalah penyebabnya.

Selain itu, menghapus cetakan, saya tidak melihat gagap sama sekali di demo Anda di bawah X11. Di Windows, saya melihat gagap sesekali (tugas latar belakang kemungkinan besar) saat berjendela dan tidak ada apa pun di layar penuh. Ini sangat diharapkan.

@ reduz Saya telah melihat hasil yang sama dengan yang Anda miliki dengan X11, ini berjalan dengan sempurna. Namun, menurut saya tidak bijaksana untuk segera menyalahkan masalah pada proses latar belakang di Windows dan OS-X. Bagaimanapun, game 2D di mesin / kerangka kerja lain (Unity, XNA, dll) berjalan dengan sempurna di Windows dan OS-X tanpa gagap yang terlihat. Itu memberi tahu saya bahwa ada sesuatu yang dilakukan mesin lain dengan benar, yang dilakukan Godot dengan salah. Jadi, ini bisa terkait OS, tetapi juga terkait Godot. Apakah logika saya salah di sini?

@reduz dapatkah Anda memberikan detail lebih lanjut tentang menggunakan metode bergerak di luar proses fisika? Itu mungkin perlu didokumentasikan dan disebutkan dalam tutorial juga.

Ping @id_tjahjadi @gest

@ behelit2 Saya tidak tahu. Jika Anda atau orang lain ingin menyelidiki, berikut adalah sesuatu yang saya sarankan untuk dicoba:

• Coba buat proyek serupa di Unity, XNA, atau apa pun yang Anda suka
• Coba jalankan proyek ini berjendela di DirectX dan OpenGL (saya pikir Anda dapat menggunakan OpenGL di Windows di Unity)
• Selidiki prioritas proses yang berjalan di pengelola tugas (buka detailnya).

Beri tahu saya jika Anda melihat sesuatu yang aneh.

Di Windows, Jika saya memaksakan prioritas demo ini di atas normal atau tinggi, gagap juga akan hilang sepenuhnya. Saya bertanya-tanya apakah mesin lain melakukan ini entah bagaimana caranya.

@ reduz Saya akan menulis hal serupa yang behelit2 telah ditujukan. Bahkan Mac saya adalah mesin bertenaga sangat rendah, ia menjalankan game 2D sederhana dengan cukup baik tanpa gagap, _dalam mode layar penuh atau tidak_ . Dan proyek contoh ini jauh lebih sederhana (hampir kosong) daripada game-game itu.

Di Windows, saya melihat gagap sesekali (tugas latar belakang kemungkinan besar) saat berjendela dan tidak ada apa pun di layar penuh. Ini sangat diharapkan.

Jadi agak sulit untuk setuju dengan Anda tentang gagap yang diharapkan pada proyek 2D sederhana seperti ini ketika tidak dalam mode layar penuh.

Juga seperti yang saya sebutkan di atas, ini terjadi di ios (termasuk iPad pro) juga yang menangani Fornite tanpa masalah. (Tapi sejujurnya saya belum mencoba proyek contoh di iPad pro. Hanya permainan lengkap saya. Saya berencana saat menguji proyek contoh di iPad pro besok atau lebih.)

@diiiiiiiii Saya mencoba demo Anda di Windows dengan prioritas tinggi dan gagap hilang ketika berjendela. Rupanya mengubah prioritas secara manual dimungkinkan di Windows:

https://forums.ogre3d.org/viewtopic.php?t=83225#p518528

Saya tidak begitu yakin itu mungkin di OSX.

Bagaimana dengan memaksakan pengaturan kinerja tinggi pada GPU? mungkin Godot terdeteksi sebagai aplikasi biasa dan pengoptimalan OS mencoba mengurangi sumber daya yang digunakan oleh program.

@ eon-s Saya rasa ini tidak terkait dengan GPU

@diiiiiiiii Saya menaikkan prioritas proses pada windows, ternyata bisa disetel di atas normal (tidak tinggi atau kritis). Ini menghilangkan gagap untuk saya (meskipun masih sedikit gagap selama 3/4 detik setelah memuat, kemudian berjalan lancar sepenuhnya).

Jika Anda dapat membangun dari master dan pengujian, beri tahu saya jika itu membantu. Pada unix, melakukan sesuatu seperti ini tidak mungkin (meskipun saya tidak melihat masalah pada X11). Mungkin OSX punya sesuatu yang mirip, tapi saya tidak tahu banyak tentang platformnya.

Saya pribadi tidak pernah melihat jitter / gagap di Android atau iOS. Silakan uji ini dengan Godot 3.1, yang memperbaiki beberapa masalah jitter di semua platform.

Untuk OSX tampaknya ada bug OS yang sangat aneh di layar penuh dan perbaikannya cukup hacky. Ini mempengaruhi sebagian besar mesin dan perpustakaan. Jika seseorang dengan OSX ingin menyelidiki dan mencoba salah satu solusi yang disebutkan di sini, silakan:

https://github.com/glfw/glfw/issues/772

Saya memiliki masalah yang sama dengan permainan tanpa akhir yang sederhana. Saya telah menguji pada perangkat Linux, Window10 dan Android (Samsung s6, Samsung Note 5, Xiaomi 6X) dan mencoba semua ide di atas, tetapi tidak berfungsi untuk semua perangkat uji :(

@homarox endless runner adalah jenis game yang masalah ini lebih terlihat. Saya ingat pernah melihatnya ketika membuat prototipe game beberapa waktu lalu.

@homarox endless runner adalah jenis game yang masalah ini lebih terlihat. Saya ingat pernah melihatnya ketika membuat prototipe game beberapa waktu lalu.

Apakah ada solusi terbaik untuk situasi ini? FPS terlihat bagus, saya juga mencoba VisibilityEnabler2D untuk mengaktifkan animasi hanya node pada viewport tetapi tidak membantu.
Dan itu terjadi lebih sering ketika game Anda berjalan cukup lama.

@homarox versi Godot apa yang Anda gunakan?

@homarox versi Godot apa yang Anda gunakan?

@ reduz Saya menggunakan Godot 3.1 Beta 2

Menambahkan panduan ini dengan harapan mendapatkan laporan yang lebih baik tentang masalah ini:
https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html

Bagi saya, proyek ini pada 3.1-beta2 di Win 7 kadang-kadang berjalan mulus, kadang-kadang gugup pada frekuensi yang berbeda (tetapi frekuensi jitter disimpan selama beberapa detik), tetapi sebagian besar waktu itu tersendat sekitar sekali dalam satu detik (baik sendiri atau bersama-sama dengan naik opelet). Yang saya maksud dengan "kadang-kadang" adalah bahwa kasus-kasus itu dialihkan selama menjalankan permainan yang sama.

Meningkatkan prioritas proses tampaknya tidak membantu.

Saya mendapat gagasan bahwa ini adalah jenis kesalahan yang mirip dengan jitter kamera dalam permainan seni piksel ketika posisi semuanya dibulatkan menjadi bilangan bulat setiap bingkai (dan karakteristik jitter bergantung pada hal-hal seperti pengaturan kamera dan bagian pecahan dari posisi pemain). Tetapi tidak memiliki gagasan yang jelas tentang bagaimana membuktikan atau menyangkal teori ini.

Windows diketahui menyebabkan gagap pada game berjendela.
Gagap mungkin terlihat di Desktop Linux, [...] terkait dengan [...] compositors.

Saya hampir yakin ini tentang # 19783, dan berpikir v-sync harus dimatikan secara otomatis (oleh mesin!) Ketika dalam mode berjendela. Tetapi membutuhkan lebih banyak umpan balik untuk mengonfirmasi.

Saat mematikan vsync membuatnya mulus, ini sepenuhnya karena kekerasan. Ini akan membuat game menggunakan CPU dalam jumlah besar (dan baterai di laptop) sehingga harus dihindari.

Saya masih tidak yakin apakah:

• Ini dapat dihindari di Windows dengan cara tertentu, mungkin juga tidak.
• Ini ada hubungannya dengan bagaimana OpenGL atau bagaimana OpenGL melakukan pertukaran buffer (inilah mengapa menurut saya menarik untuk menguji demo serupa di Unity yang berjalan di OpenGL dan DirectX. Relawan yang telah menginstal Unity dipersilakan.)

Sumber gagap pasti bukan berasal dari Godot, tapi saya ingin tahu apakah ada hal lain yang bisa dilakukan dari pihak kami.

Bagaimanapun, kita akan segera melihat bagaimana ini bekerja di Vulkan, yang melakukan semua swapchain bekerja secara manual .. seharusnya mudah untuk mengetahui apakah ada yang salah di sana.

@reduz Jadi ... Saya tidak yakin dari mana Anda mendapatkan gagasan bahwa Windows adalah sistem operasi yang rawan gagap. Ini adalah OS game paling umum untuk desktop dan laptop. Ini karena sebagian besar game, terlepas dari kesalahpahaman Anda, berjalan sangat baik untuk sebagian besar. Saya tidak mengerti mengapa Anda tidak menganggap Godot sebagai sumber potensial masalah.

Saya dapat memainkan Starbound (permainan 2d yang sangat kompleks dan canggih yang memanfaatkan generasi medan prosedural) selama berjam-jam (dalam mode berjendela dan layar penuh) bahkan tanpa sedikit pun gagap. Saya pergi untuk memeriksa prioritas proses, dan itu diatur ke normal. Semua jenis judul 2D yang diemulasi, dari sistem game 2D apa pun yang dapat Anda pikirkan, berjalan dengan sempurna tanpa gagap (dan telah melakukannya sejak 2001). Namun, game 2D sederhana di Godot dengan satu lapisan latar belakang sering mengalami gagap.

Saya tidak bermaksud menyinggung, tetapi sepertinya penjelasan Anda tentang proses latar belakang dan masalah OS menghindari masalah yang sah di sini. Cuphead, sebuah game dengan grafik 2D yang sangat detail, tidak akan terjual jutaan kopi jika sering dipamerkan gagap di Windows. Jika Anda benar-benar memainkan banyak game 2D di Windows, Anda akan menyadari bahwa proses latar belakang menyalahkan menggonggong pohon yang salah. Saya memahami bahwa menyelesaikan masalah ini mungkin tidak akan menjadi perbaikan yang mudah. Saya mengerti bahwa ini adalah sesuatu yang telah lama diperjuangkan oleh Godot. Tapi ini adalah masalah yang sangat nyata dan menyapunya di bawah karpet dengan mengarahkan jari Anda ke OS tidak akan membuatnya hilang. Semakin banyak pengguna yang mengadopsi Godot, semakin banyak orang yang akan memperhatikan hal ini, dan pada akhirnya Godot akan mendapatkan reputasi sebagai mesin game 2D yang buruk.

Ini bukan serangan, tapi perhatian yang tulus. Saya sangat suka Godot. Saya telah jatuh cinta dengan GDscript dan menurut saya antarmukanya sangat intuitif. Saya ingin melihatnya berhasil. Tapi gagap ini seperti duri di cakarnya ...

@reduz

Saat mematikan vsync membuatnya mulus, ini sepenuhnya karena kekerasan. Ini akan membuat game menggunakan CPU dalam jumlah besar (dan baterai di laptop) sehingga harus dihindari.

Tidak, karena selain menonaktifkan v-sync, saya juga menyarankan untuk membatasi framerate. Dengan cara ini game akan menggunakan jumlah CPU yang sama.
Saya melihat sinkronisasi-v sebagai ukuran untuk memperbaiki robekan bingkai vertikal, dan saya tidak mengerti mengapa hal itu diterima begitu saja di sini bahwa ini juga merupakan cara universal untuk membatasi framerate.

Saya baru-baru ini menguji proyek ini di masalah lain yang saya tunjuk, dan mematikan v-sync jelas membantu pada PC saya, sementara masih dengan framerate 60!

Saya tertarik untuk menguji demo gagap / jitter yang berbeda juga (Godot atau tidak) dan memberikan umpan balik. Mungkin kita harus membuat meta-issue pelacak tempat semua proyek / masalah tersebut dikumpulkan? (tanpa diskusi masalah panas, hanya petunjuk ke masalah dan ringkasan apa yang membantu dalam setiap kasus)
Juga, saya secara pribadi benar-benar setuju dengan semuanya ditangani _ setelah _ 3.1 dirilis.

Sumber gagap pasti bukan berasal dari Godot, tapi saya ingin tahu apakah ada hal lain yang bisa dilakukan dari pihak kami.

Saya setuju, tetapi jika beberapa pengaturan membuat kelancaran untuk 90% kasus, IMHO berkepentingan dengan proyek Godot untuk menjadikannya yang default.

Meskipun demikian, masalah yang kami hadapi berbeda dengan penyebab yang berbeda, dan beberapa di antaranya mungkin sangat spesifik untuk game dan hanya dapat ditangani dari sisi game. Jadi saya sarankan untuk membagi mereka dan memperlakukan satu per satu daripada melihat mereka sebagai satu kesatuan kekacauan yang tak terhindarkan.

@reduz Saya meluangkan sedikit waktu dan menguji dalam beberapa jenis pengaturan. Dan hasilnya adalah

• Pada 3.1 beta 2, umumnya gagap hampir hilang di Windows dan iOS.
• Dalam proyek contoh, itu benar-benar hilang.
• Masih ada sejumlah gagap yang tersisa dalam proyek game lengkap saya.
  
  
  
  • Tapi itu jauh lebih ringan dibandingkan dengan 3.0.6.
  
  
• Juga mengatur prioritas proses memang banyak membantu tetapi mode layar penuh tidak.
• MacOS adalah cerita yang sangat berbeda. Itu masih gagap dan gelisah seperti orang gila bahkan dalam proyek contoh.
  
  
  
  • Dan juga tidak ada perbedaan mencolok antara memainkannya dalam mode layar penuh atau tidak.
  
  

Perbaikan jitter di 3.1 berhasil dengan sangat baik. Jadi saya bertanya-tanya, bukankah itu berarti mungkin ada sedikit lagi yang bisa diperbaiki atau dioptimalkan di Godot?

@ behelit2 Saya tidak tahu apakah ini masalah Windows atau masalah driver OpenGL. Ini jelas bukan masalah Godot karena alasan sederhana bahwa:

1. Ini berfungsi dengan baik pada layar penuh, dan di sebagian besar platform lainnya
2. Godot sama sekali tidak melakukan apa pun yang dapat menyebabkan gagap dalam demo sesederhana itu. Tidak ada kode yang dapat diperiksa karena tidak ada platform yang bergantung yang dapat menyebabkan ini ada di basis kode.

Sebagian besar game di Windows adalah game DirectX, di mana Anda memiliki kontrol lebih besar tentang bagaimana vsync dilakukan, jadi sangat mungkin ini pasti terkait dengan OpenGL. Inilah mengapa saya meminta siapa pun yang tertarik untuk mencoba demo sederhana yang sama di Unity atau mesin berbasis OpenGL lainnya.

@ starry-abyss Menonaktifkan VSync dan membatasi FPS adalah ide yang buruk. Itu salah karena Anda mengandalkan penjadwal sistem yang memanggil fungsi delay (), yang memiliki 3 masalah:

• Ini adalah fungsi presisi yang relatif rendah
• waktu Anda menunggu dengan menggunakan penundaan () adalah waktu pemrosesan yang diambil dari game Anda.
• Ada monitor dengan kecepatan refresh berbeda, dan _will_ memberi Anda gangguan.

VSync dirancang untuk mengatasi masalah ini dan menjalankan game Anda seefisien mungkin. Ini bekerja menggunakan interupsi langsung dari GPU yang membuka blokir utas render Anda pada waktu yang sangat tepat. Ini harus _never_ dimatikan. Masalahnya di sini, menurut saya, terkait OS atau terkait OpenGL (driver atau wgl).

Sekali lagi, kita akan segera melihat bagaimana semua ini bekerja di Vulkan.

@reduz Saya tidak setuju dengan alasan Anda.

1. Ini TIDAK berfungsi dengan baik pada layar penuh. Saya mencoba contoh diiiiiiiii di 3.1 beta 2 di layar penuh dan gagap jelas masih ada di Windows 10. Mungkin tidak separah videonya, tapi itu benar-benar ada. Mungkin mencoba melakukan 2-3 lintasan melewati bar untuk melihatnya, ini semacam contoh singkat.

2. Saya menerima bahwa Anda adalah "veteran industri game dengan pengalaman lebih dari 20 tahun". Tapi mengatakan sama sekali tidak ada yang bisa menyebabkan gagap di Godot adalah keangkuhan. Mengatakan tidak ada kode yang dapat diperiksa, dalam pengaturan pengembangan yang masuk akal, itu konyol!

Contoh Starbound yang saya kutip ... Adalah OpenGL. Ini berjalan persis sama di Linux seperti di Windows 10. Layar penuh atau berjendela, itu berjalan berjam-jam tanpa satupun gagap. Saya mungkin dapat mengutip lusinan contoh serupa jika memang demikian. Game yang sangat rumit yang menggunakan OpenGL, yang menjalankan multiplatform ... Jalankan tanpa tersendat. Kita tidak perlu "membuktikannya" dengan proyek contoh di mesin game lain ... Karena ada SELURUH PERMAINAN di mana gagap semacam ini tidak pernah terjadi.

Maksud saya jangan tersinggung. Saya sangat menghormati usaha Anda dengan Godot. Tetapi pada titik tertentu, kenyataan harus memukul! Ada begitu banyak masalah yang belum terselesaikan dengan gagap 2D dan solusi yang saya lihat seperti palu godam, padahal ini jelas membutuhkan pisau bedah.

Sekali lagi, kita akan segera melihat bagaimana semua ini bekerja di Vulkan.

Bukankah lebih menarik terlebih dahulu untuk mencoba menyelesaikan masalah saat ini (seperti ini) sebelum mulai mengerjakan fungsi baru? Yang saya takutkan adalah mengulang siklus yang sama yaitu migrasi dari OpenGL 2 ke OpenGL 3 yang bagi saya, sebagai pengguna salah satu pengguna mesin lama, sangat traumatis.

Di Unity3d, masalah ini terjadi jika Anda menggerakkan kamera melalui Vector.Lerp. Kamera tidak memiliki cukup waktu untuk mengatur posisi jika objek bergerak. Membantu menggunakan Vector.Smoothdamp.

Juga beberapa tahun yang lalu saya mendapat masalah ini di BlitzBasic3d dan BlitzMax di winXP, win7. Saya membantu penggunaan waktu delta bersama di vsync. Fungsi move_and_collide menggunakan waktu delta?
Baris ini dengan waktu delta bekerja dengan sempurna pada win10 saya: motion = move_and_slide (motion * delta, Vector2 (0, -1))

Perubahan @ Shin-NiL semoga kali ini sangat minimal dibandingkan dengan migrasi 2.0 -> 3.0. Sebagian besar akan tetap seperti itu dan sebagian besar merupakan perubahan rendering internal daripada penulisan ulang mesin penuh.

@reduz Oke ... Sekarang aku merasa tidak enak. Saya baru saja menguji proyek utama saya dalam versi 3.1 beta 2, dan saya melihat sedikit peningkatan dalam gagap. Ini kurang terlihat sekarang, tapi masih ada.

Namun, saya sangat senang bahwa gangguan intermiten dalam penghalusan Camera2D telah diperbaiki! Ini bekerja dengan sempurna sekarang. Saya dapat melaporkan masalah # 17823 sebagai terselesaikan.

@ behelit2 Anda pasti salah paham. Yang saya maksud adalah bahwa apa pun yang menyebabkan masalah (JIKA ada masalah) tidak lagi dalam kode platform-independen di 3.1 (ini telah diperbaiki), tetapi harus sesuatu yang terkait dengan kode wgl khusus platform (windows GL manajemen konteks). Memeriksa implementasi wgl, saya tidak dapat melihat sesuatu yang aneh atau tidak pada tempatnya.

Melihat di internet, saya menemukan orang-orang dengan masalah serupa menggunakan OpenGL tetapi tidak ada yang serius yang tampak seperti perbaikan yang baik (saran berkisar dari menonaktifkan vsync untuk memaksa flush sebelum menukar buffer, semua diusulkan sebelumnya).

Mungkin game yang Anda coba menggunakan ini, tetapi menurut saya gagap itu tidak seburuk untuk membenarkan hal seperti itu (saya melihat gagap kecil sekali per menit, bahkan pada komputer jelek), perbaikan ini berlebihan.

@ behelit2 btw, saya memiliki PC Windows 10 dengan spesifikasi yang sama dengan milik Anda (i5-25xx) kecuali nvidia 1050, bukan 970. Menjalankan demo @diiiiiiiii pada layar penuh tidak ada gagap yang terlihat berjalan untuk sementara waktu, dan jendela saya lakukan melihat gagap tetapi hanya 3/4 detik pertama .. kemudian hilang dan hanya muncul kembali setiap waktu yang sangat lama. Apakah ini yang Anda lihat juga?

@reduz Sayangnya ... Tidak. Saat layar penuh, saya melihat gagap secara acak. Terkadang saat saya menjalankannya, tidak ada gagap yang terlihat. Di lain waktu, ini akan gagap beberapa kali dalam 10 detik. Benar-benar TAMPAKNYA seperti proses yang mengganggu, seperti yang Anda katakan. Tapi saya tidak yakin bagaimana itu mungkin ketika waktu CPU pada contoh diiiiiiiii melayang di 2% atau kurang dan tidak ada yang menggunakan CPU. Mungkinkah karena saya menjalankan pada resolusi desktop 1440p? ha ha

Dengan jendela, gagapnya sangat parah, setiap beberapa detik atau lebih. Pastinya jauh lebih buruk dari layar penuh.

Aneh ... Karena ketika saya pergi untuk menguji proyek utama saya, itu berjalan sangat lancar dalam mode Windowed. Hanya sesekali, gagap acak seperti layar penuh. Kegilaan! (O___0)

Sunting: Anda membuat saya ingin membeli 1050 untuk pengujian.

Sebagai seseorang yang telah berjuang dengan masalah serupa (Di Win10), saya telah mencapai hasil paling mulus dengan mematikan vsync di Godot dan tidak memaksakan framerate (tetap di 0). Untuk Godot lebih baik mengaktifkan opsi vsync pada GPU Anda, dan biarkan Godot dimatikan. Anehnya, saya memiliki lebih banyak masalah dalam membuat game 2d saya berjalan dengan lancar daripada yang saya lakukan untuk game 3d saya, meskipun saya tidak tahu mengapa!

Saya curiga bahwa driver OpenGL memiliki banyak kaitan dengan masalah berulang ini, karena sebagian besar game Windows menggunakan DX dan berjalan dengan baik untuk saya di semua mesin saya. Semoga perpindahan ke Vulkan pada akhirnya akan menyelesaikan masalah umum yang dialami orang-orang ... yaitu jeda kompilasi shader, gagap / jitter terputus-putus dan kinerja yang lebih baik pada perangkat keras yang lebih rendah (terutama gpus terintegrasi intel).

@reduz

Ini umumnya bukan masalah, mengingat bahwa kecepatan refresh yang lebih tinggi dari 60 Hz hampir tidak terlihat oleh mata manusia, dan dimulai dengan Godot 3.1, pengatur waktu bingkai diperkenalkan yang mencoba menyinkronkan dengan penyegaran sebaik mungkin.

apa pun di atas monitor 75Hz terlihat. terutama di 100+. Ini mungkin alasan mengapa Godot mengalami masalah gagap ini, pengembang utama membutuhkan monitor dengan kecepatan refresh yang tinggi untuk pengujian! itu akan sangat membantu. masalahnya adalah bea cukai di negaranya membuatnya sangat sulit untuk mengimpor elektronik, dan itu juga cukup mahal (+ pajak impor yang besar)

edit: masalah lain yang saya lihat sepanjang waktu (sejak 2014), tidak ada yang memposting kecepatan refresh monitor mereka dalam masalah ini, itu harus terdaftar, ini penting! setiap orang memiliki masalah gagap, tetapi PC pengembang utama (atau siapa pun yang menjawab) berada pada kecepatan 60 hz .. jadi mereka mengatakan tidak gagap, lalu penerbit mengatakan ya, ada gagap! dan sebaliknya.

Apakah semua pengujian dilakukan dengan editor dibuka atau mengekspor proyek rilis? debugger (kebanyakan pohon jarak jauh) suka mengganggu permainan yang sedang berjalan.

@DDru move_and_slide menggunakan langkah delta secara internal, tetapi masalah dengan KB dan pembaruan seharusnya diperbaiki pada 3.1

Keluhan tidak melakukan apa-apa selain memperlambat proses perbaikan bug dengan membuat utas ini sama sekali tidak dapat dibaca, jika Anda tidak membawa informasi ke topik, maka tahan.

Saya pikir saat ini kita perlu lebih terorganisir.

Pertama kita semua harus menyetujui persyaratannya, dan @reduz sudah menulis postingan yang bagus tentang ini.

Kami juga membutuhkan informasi sebanyak mungkin saat membuat laporan jadi saya membuat template dasar (Perbaikan dipersilahkan):

• Versi Godot:
• Platform + versi:
• CPU:
• GPU + driver:
• GLES2 atau GLES3:
• Layar Penuh / Jendela:
• Debug atau Ekspor:
• V-Sync On / V-Sync Off + batas framerate:
• Pantau kecepatan refresh:
• Resolusi asli:
• Aplikasi yang sedang berjalan:

Saya melihat 2 hal yang secara signifikan dapat menurunkan kinerja (dalam debug), jangan laporkan apa pun sampai itu dinonaktifkan:

• Panggilan cetak spam (tidak diuji dengan proyek yang diekspor)
• Remote Tree juga akan menurunkan performa

Saya melakukan pembersihan pada proyek uji @diiiiiiiii , idenya adalah membuat proyek sesederhana mungkin sebagai dasar untuk pengujian kami di masa mendatang dengan hampir semuanya diatur ke default untuk memiliki kesempatan tertinggi untuk mengidentifikasi masalah. Perbaikan dipersilakan!

• Setel ulang semua pengaturan proyek ke nilai aslinya
• Ubah nama adegan dan skrip
• Kode yang tidak digunakan dihapus
• Kode komentar dihapus
• Beralih ke sprite (dari sprite animasi)
• Zoom kamera dihapus, smoothing dan drag margin

_test_jitter_stutter.zip

Tes saya dan apa yang saya temukan:

• Versi Godot: 2d57ec2
• Platform + versi: Windows 10 - 1809
• CPU: i5 2500K
• GPU + driver: GTX 1060 (417.22)
• GLES2 atau GLES3: Campuran
• Layar Penuh / Jendela: Campuran (lihat di bawah)
• Debug atau Ekspor: Debug
• V-Sync On / V-Sync Off + batas framerate: V-Sync On
• Monitor kecepatan refresh: 60hz
• Resolusi asli: 1080p
• Aplikasi yang sedang berjalan: editor godot (bahkan anti-virus yang dinonaktifkan)

Saya menggunakan adegan no_physics_character

Yang saya perhatikan, tidak banyak jitter, jika ada, tetapi layar terus-menerus terlihat gagap / macet, tidak peduli apakah:

• Jendela / Layar Penuh
• GLES2 atau GLES3
• aplikasi berjalan atau tidak
• pemain pindah atau tidak (tidak ada input)

Contoh fullscreen-gles2:

Contoh windowed-gles3-noinput:

Sunting: Perhatikan lonjakan dalam bagan waktu proses, yang selalu terjadi setelah beberapa detik (variabel) dan mengakibatkan gagap / macet, saya tidak menguji lebih lanjut untuk melihat apakah itu rekursif.

@ Ploppy3 Nah, itulah yang saya bicarakan!

Versi Godot: 3.1 Beta 2
Platform + versi: Windows 10 - 1803
CPU: i5-2550K
GPU + driver: GTX 970 (411.70)
GLES2 atau GLES3: Keduanya digunakan, lihat di bawah.
Fullscreen / Windowed: Keduanya digunakan, lihat di bawah.
Debug atau Ekspor: Debug
V-Sync On / V-Sync Off + batas framerate: Vsync Diaktifkan.
Monitor kecepatan refresh: 60hz
Resolusi asli: 1440p
Aplikasi yang sedang berjalan: Editor Godot, Notepad (untuk menuliskan hal ini).

* INFO: Untuk tes ini, saya akan menggunakan proyek modifikasi yang disediakan oleh Ploppy3. Saya tidak menemukan grafik FPS / Proses yang berarti, mereka selalu mirip atau identik dengan contoh Ploppy3, jadi saya tidak akan menyediakannya. Dalam semua kasus, interval waktu antara gagap tampak acak, tanpa pola yang terlihat. Hanya tingkat kasar yang bisa diamati.

HASIL UNTUK: no_physics_character

GLES3 / Windowed : Significant stuttering every 1~2 seconds.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Significant stuttering every 1~2 seconds.
GLES2 / Fullscreen: At least one major stutter every 15~20 seconds.

HASIL UNTUK: kinetic_character

GLES3 / Windowed : Significant stuttering every 1~2 seconds.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Significant stuttering every 1~2 seconds.
GLES2 / Fullscreen: At least one major stutter every 10~20 seconds.

HASIL UNTUK: rigid_body_character

* CATATAN: Gerakan sama sekali berbeda dari dua lainnya.

GLES3 / Windowed : Heavy stuttering every 1~2 seconds, then seemed to settle down to one major stutter every 10~20 seconds after a while.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Heavy stuttering every 1-2 seconds, never settled down.
GLES2 / Fullscreen: At least one major stutter every 10~20 seconds.

@reduz @ Ploppy3 Apakah kalian punya ide tentang bagaimana kami dapat membuat pengukuran frekuensi / frekuensi yang lebih akurat pada gagap? Saya tidak menemukan apa pun di bagian monitor yang dapat melakukan ini dengan andal.

Coba lakukan beberapa tes pada rilis juga, ini dapat meningkatkan atau mengurangi kepentingan dan mengubah fokus masalah (untuk melihat apakah debugger adalah sumbernya dan / atau OS mengunci debugger sehingga memperburuk keadaan).

@ eon-s Saya akan melakukan serangkaian pengujian lengkap pada rilis yang diekspor ... Tapi saya ingin cara yang lebih akurat untuk mendeteksi gagap. Memandanginya terasa seperti metode yang sangat tidak ilmiah untuk melakukan ini. Selain itu, jika mencetak ke konsol menghasilkan gagap, saya tidak yakin bagaimana cara melakukannya. Saya perlu melakukan lebih banyak penelitian tentang ini. Kasus terburuk, saya dapat melihatnya dan menggunakan aplikasi cap waktu di ponsel saya. Jika ada yang memiliki metode untuk merekam gagap secara akurat dalam pengukuran waktu diskrit (yang tidak menghasilkan gagap itu sendiri), harap bagikan!

@ behelit2 dapatkah Anda melakukan hal berikut?

• Buka folder proyek menggunakan baris perintah
• jalankan dengan menulis c: \ path \ to \ godot.exe

lihat apakah ada lebih banyak atau lebih sedikit gagap daripada saat dijalankan dari editor.

The Elusive Frame Timing - Alen Ladavac - Medium
Ditemukan di utas tweet .
Pikir itu mungkin membantu.

@diiiiiiiii terima kasih! Saya telah melihatnya sekali dan tidak dapat menemukannya lagi.

Jika saya melakukannya dengan benar, cara untuk menambal ini _ sementara kita menunggu beberapa dekade untuk API_ grafis yang layak mungkin untuk mendapatkan rata-rata waktu bingkai dari sampel kecil dan menggunakannya daripada frekuensi gambar nyata?

Saya tidak ingin mengulangi tes yang kami lakukan di utas ini: https://github.com/godotengine/godot/issues/19783 tetapi ada beberapa hal yang perlu dilakukan hingga mengonfirmasi bahwa game tersendat:

1. Seperti yang dikatakan pengguna lain sebelumnya ... nonaktifkan semua cetakan ke konsol karena pencetakan sangat lambat dan tersendat.
2. Minimalkan editor Godot: Render editor Godot membuat game yang dieksekusi menjadi gagap.
3. Jalankan proyek semi-kompleks untuk diuji. Proyek yang sangat sederhana (setidaknya di jendela) selalu gagap. Saya rasa ini karena windows multi-tasking atau windows compositor prioritas.
4. Periksa apakah pohon pemandangan jarak jauh dinonaktifkan . Pohon pemandangan jarak jauh menghentikan utas utama secara berkala.

Setelah ini selesai, ada beberapa gagap yang saya temukan di 3 konfigurasi saya (3 komputer berbeda):

1. Gagap Awal. Godot gagap beberapa detik saat start berlari. Kemudian menjadi stabil.
2. Penguatan fokus- fokus hilang. gagap yang sama dengan "gagap awal" tetapi dalam peningkatan fokus. Menurut saya ini adalah gagap yang paling buruk, karena memberi kesan buruk pada permainan.
3. Gagap dalam sistem multi-layar ketika pembuat jendela memiliki layar utama dibalik dengan layar lain dan permainan tidak dijalankan di layar utama yang baru. Saya pikir ini adalah hal OpenGL karena itu juga terjadi dengan Chrome (tetapi tidak dengan game unity)
4. Gagap saat aplikasi OpenGL lain sedang dirender: Contoh: Godot tidak gagap saat Chrome memutar video youtube, tetapi video youtube terhenti hingga ....

Gagap ini tidak berasal dari Godot (reproduksi mempertahankan stabil 60 fps dan tidak memiliki lonjakan) tetapi terkait dengan cara Godot melakukan sesuatu (tidak terjadi di proyek Unity-SDL-XNA atau Game Maker di konfigurasi).

Resume investigasi dengan game lain dari utas ini (https://github.com/godotengine/godot/issues/19783):

· Mayoritas besar game uap adalah 32 bit. (Terbaru juga)
· Godot mengeksekusi 2 jenis panggilan rendering (OpenGL dan Windows GDI). Semua game yang diuji hanya menjalankan satu jenis (lihat utas dan aplikasi yang digunakan untuk melihat proses), tidak masalah rendering OpenGL atau DirectX. Ini bisa jadi karena hamparan uap, saya tidak tahu, tetapi tidak semua game menggunakan itu.
· Banyak permainan uap tidak memungkinkan untuk mengubah ukuran layar, atau layar bergerak. Apakah bisa dikaitkan dengan hal di atas?
· Banyak permainan uap menghentikan reproduksi fokus hilang.
· Mayoritas besar game uap adalah DirectX.
· Kebanyakan permainan uap hampir tidak gagap, mungkin satu atau dua gagap pada jam reproduksi tetapi tidak setiap X detik dan beberapa permainan tidak pernah gagap (Ej N ++, permainan sederhana secara visual yang tidak pernah gagap, tidak ada waktu bermain ibu), jadi mungkin untuk dilakukan lingkungan yang "bebas gagap".

Pendapat saya adalah bahwa _kita perlu menghentikan pengujian gagap dengan "Proyek sederhana" _ (menguji jika sprite bergerak di layar gagap) karena gagap ini hilang saat proyek menjadi lebih mahal untuk CPU dan GPU, dan kita perlu fokus pada gagap yang terjadi pada awal eksekusi, setiap x detik dalam eksekusi, fokus gain- fokus hilang gagap, dan gagap yang terkait dengan kamera, fisika, dll .... karena pada akhirnya jenis ini gagap akan menjadi masalah yang akan dicoba oleh pengguna akhir ...

Semua ini berasal dari pengalaman dan bukan opini yang memenuhi syarat: bukan insinyur di sini.

@Ranoller Saya pikir beberapa bagian yang Anda tangani tumpang tindih dengan apa yang telah dikatakan

karena gagap ini hilang ketika proyek menjadi lebih mahal untuk CPU dan GPU, dan kita perlu fokus pada gagap yang terjadi pada awal eksekusi, setiap x detik dalam eksekusi, fokus gain- fokus hilang gagap, dan gagap yang terkait dengan kamera, fisika, dll

Saya setuju tentang pentingnya memperbaiki gagap awal, tetapi saya merasa sulit untuk menyetujui "gagap secara alami menghilang pada proyek yang kompleks" karena saat proyek menjadi lebih kompleks, masalahnya hanya akan semakin buruk dalam kasus saya. Dan seperti yang sudah saya sebutkan sebelumnya, masalah terjadi bahkan tanpa node kamera atau fungsi fisik.

(reproduksi mempertahankan stabil 60 fps dan tidak memiliki lonjakan)

Dan juga kami mendapatkan laporan tentang lonjakan proses delta dan fps dari beberapa orang termasuk saya.

@diiiiiiiii Saya tahu artikel itu, dan juga akrab dengan masalah itu, tetapi tidak ada yang bisa dilakukan di OpenGL (dan platform seperti iOS dan Android). Inilah mengapa saya meminta kalian untuk menguji hal yang sama di Unity (di GL vs DX) dan mengapa saya menyebutkan bahwa port ke Vulkan pasti bisa membantu, karena Anda memiliki kontrol lebih besar atas swapchain.

Namun, prioritas proses memang memiliki pengaruh pada gagap, itulah sebabnya pada layar penuh Windows Anda akan lebih jarang melihatnya.

@reduz Ya. Prioritas proses berfungsi untuk saya, tidak seperti mode layar penuh.
Saya akan mencoba mengujinya di mesin lain. Namun karena saya tidak berpengalaman dalam Unity (karena dapat menyebabkan hasil tes yang tidak akurat), saya lebih suka orang lain melakukan tes atau membuat proyek tes di Unity.

@reduz Maaf, saya belum punya waktu untuk menguji dan tidak akan bisa mendapatkan kotak Windows sampai besok. Tapi saya membaca artikel yang diiiiiiiii yang dibagikan dan sekarang saya tertarik. Mungkinkah ada miskomunikasi antara CPU dan GPU, yang menyebabkan perilaku yang ditunjukkan dalam artikel? Ini tampaknya tidak hanya mungkin, tetapi sangat mungkin. Sebenarnya, itu penjelasan yang paling mungkin saya lihat. Mungkinkah ... Game (OpenGL / Multi-platform) tanpa gagap itu "curang" sedikit? Saya mengutip dari artikel:

"Apa yang terjadi di sini adalah bahwa game mengukur apa yang dipikirkannya sebagai awal dari setiap frame, dan waktu frame tersebut terkadang berosilasi karena berbagai faktor, terutama pada sistem multitasking yang sibuk seperti PC. Jadi di beberapa titik, game menganggapnya tidak benar. t membuat 60 fps, sehingga menghasilkan bingkai animasi yang dijadwalkan untuk laju bingkai yang lebih lambat di beberapa titik waktu. Tetapi karena sifat asinkron operasi GPU, GPU sebenarnya membuatnya tepat waktu untuk 60 fps pada setiap bingkai tunggal dalam urutan ini. "

Apakah ada cara untuk mengujinya? Putuskan hubungan "timing shenanigans" dan anggap saja itu selalu berjalan pada 60fps apa pun yang terjadi? Karena, mari menjadi nyata di sini. Dengan kecepatan komputer, banyak inti, proyek uji yang hanya menggunakan 2% waktu CPU, dan 97,9% CPU lainnya gratis? TIDAK ADA CARA hal itu mengganggu proses. Saya belum pernah melihat game dengan prioritas proses default di atas normal.

@ behelit2 Masalahnya adalah bahwa waktu yang telah berlalu antara frame di sisi logika bukanlah waktu yang diperlukan antara frame yang disajikan (layar hz). Solusi yang tepat pasti mendapatkan pengaturan waktu ini dari driver GPU, atau memiliki kontrol lebih besar atas swapchain untuk mendapatkan pengaturan waktu yang lebih tepat (apa yang Anda lakukan di DX12 dan Vulkan). Kemudian lagi, tidak mungkin di OpenGL.

@Ranoll

Pendapat saya adalah kita perlu menghentikan tes gagap dengan "Proyek sederhana" (menguji apakah sprite bergerak di layar gagap) karena gagap ini hilang ketika proyek menjadi lebih mahal untuk CPU dan GPU, dan kita perlu fokus pada gagap yang terjadi pada awal eksekusi, setiap x detik dalam eksekusi, fokus gain- fokus hilang gagap, dan gagap yang terkait dengan kamera, fisika, dll .... karena pada akhirnya gagap semacam ini akan menjadi masalah yang akan dicoba oleh pengguna akhir ...

Saya pikir pernyataan ini bertentangan. Untuk merepro sebagian besar jenis gagap / jitter satu per satu, saya pikir ada baiknya menemukan proyek minimal yang dengan jelas memisahkan satu kasus dari yang lain (misalnya untuk proyek utas lain itu saya memiliki solusi yang stabil, sedangkan untuk yang ini itu _doesn ' t_ work) - atau ide yang jelas tentang pengaturan OS / hardware yang diperlukan untuk melakukan repro.
Beberapa kasus tidak mungkin diselesaikan (atau tidak mungkin diselesaikan secara universal), seperti dalam artikel Prinsip Talos (BTW, Prinsip Talos memiliki masalah pembekuan gerakan kamera untuk saya dalam mode Vulkan beta - bukan artikel satu, tetapi satu shader), tetapi tidak semua dari mereka.
Karena itu, izinkan pengembang yang terhormat untuk membuat rilis 3.1.0 terlebih dahulu ...

@reduz Meskipun saya tidak mengalami masalah jitter sama sekali saat dalam layar penuh, saya mengalami masalah gagap yang saya jelaskan cukup detail di sini ; Anda mungkin melewatkannya. Saya ingin mendapatkan pendapat Anda. Saya dapat memberi Anda lebih banyak informasi dan dapat melakukan lebih banyak tes jika Anda mau.

Win 7 tanpa aero tidak gagap di layar penuh. Dengan aero bisa gagap. (tampaknya aero tidak memungkinkan layar penuh yang nyata)

Menangkan 8+ untuk memenangkan 10 dapat menggagap layar penuh atau tidak.

Kegagapan ini harus diatasi dengan melakukan proyek intensif kecuali interferensi multitasking, lebih dari satu eksekusi aplikasi opengl, rendering editor godot dengan game, eksekusi contoh godot lainnya, dll .... beberapa kali instance godot lain dapat meningkatkan persyaratan prosesor / gpu dan secara ajaib gagap itu hilang. Sekarang ada banyak masalah yang menguji hal ini. (Dirujuk di sana-sini)

Inilah yang diberikan profiler kepada saya saat lonjakan:

https://i.imgur.com/yCIkwfq.png

Paku:

Diikuti oleh nilai yang sangat rendah (mungkin untuk melawan lonjakan):

Selain itu, grafiknya konstan pada 16ms

NB: Saya baru saja memulai dari awal di Windows sehingga PC saya tidak bisa lebih bersih.

@ Ploppy3 yang lonjakan biasanya debugger itu sendiri, saat memperbarui inspektur jarak jauh dan hal-hal lain, Anda mungkin bisa mendapatkan beberapa data dalam permainan debug yang diekspor dengan kelas Kinerja untuk mengecualikan gangguan editor dan memasukkan file log untuk memeriksa apakah lonjakan apakah ada juga (masih dapat menghasilkan gagap sendiri jika tidak dalam mode rilis).

@ eon-s Seperti yang saya jelaskan di komentar asli saya , gagap juga ada saat diekspor, jadi sama sekali tidak terkait dengan editor itu sendiri.

Gagap yang disebabkan oleh bingkai besar yang berlebihan harus dapat diperbaiki di dalam Godot atau di dalam kode Anda sendiri ...

@Ranoller Apa yang Anda gambarkan terdengar seperti masalah kompositor. Kompositor Windows juga menggunakan sinkronisasi-v, dan memerlukan beberapa solusi (seperti https://github.com/godotengine/godot/issues/19783#issuecomment-456965634) untuk menunda bingkai game. Jika tidak, menurut pemahaman saya, kompositor terkadang mengambil frame game sebelumnya, dan terkadang - frame baru.
Aero adalah kompositor, dan di Win 8 dan di atasnya, itu tidak dapat dimatikan. Tapi itu bukan pilihan untuk mematikannya, karena bagi saya di nvidia itu berhenti menggunakan v-sync, dan semua jendela robek secara vertikal (tidak hanya satu game).
"Proyek intensif" yang Anda bicarakan, saya kira, secara alami terjadi untuk menunda bingkai setelah sinkronisasi-v.
Sayangnya, untuk MacOS tidak apa-apa untuk menyertakan beberapa peretasan untuk sinkronisasi-v secara langsung, dan di Windows kami berdebat tentang "berjalan hanya dengan cara yang benar", tetapi suatu saat kami akan sampai di sana dengan harapan. :)

Saya menguji proyek ini pada intel 4570 (3193 Mhz) dan kartu IntelHD 4600 terintegrasi, Windows 10, RC3.
Gagap. Lebih sedikit di layar Penuh. Saya sedang mengerjakan game serupa, masalahnya bahkan lebih buruk dan itu terjadi di Android juga .. Mungkin karena frame besar (layar 2x)? Saya berharap masalahnya akan berkurang saat game menjadi lebih kompleks ..

Saya menemukan opsi video di emulator RetroArch sangat menarik, berikut tangkapan layarnya:

Mereka memiliki grafik bergelombang di latar belakang menu dan saya belum pernah melihatnya bergetar atau tersendat sekali, baik dalam mode layar penuh atau berjendela. Saya pikir orang-orang itu benar. Perhatikan semua opsi Refresh Rate, Frame Rate dan VSync. Mungkinkah layak untuk dilihat / mengobrol dengan mereka?

Kecepatan refresh Monitor saya terkadang berada di 59,3Hz-59,9Hz

Standar pengaturan waktu video (CVT) AFAIK VESA mendefinisikan "kecepatan refresh vertikal nominal" (30Hz, 60Hz, dll.) Dan "kecepatan refresh vertikal yang dioptimalkan untuk video" dengan tambahan pengganda 1000/1001 , yang memberikan 59,94Hz (agar sesuai dengan NTSC 59,939Hz menilai).

Tidak bisa menghilangkan gagap / Jitter di platformer paling sederhana (((

• Versi Godot yang sebenarnya
• Gunakan Camera2d
• Latar belakang paralaks dasar
• FTP selalu 60
• GLES3
• Menguji pada iphone 6 / XR dan masalahnya sama.

https://youtu.be/44-eq7n6hkE

Tolong tolong bantu!

Saya pikir ini bisa menjadi alasan:
https://dmtopolog.com/cadisplaylink-and-its-applications/

Maaf, saya tidak dapat benar-benar berkontribusi pada solusinya, tetapi saya merasa perlu untuk menunjukkan bahwa gagap ini sangat mengganggu saya sejak saya mulai menggunakan Godot. Saya belum menerbitkan apa pun, jadi saya mengharapkan solusi pada saat saya melakukannya. Saya mulai menggunakan 3.0.6, tetapi masalahnya ada di 3.1 dan 3.2 beta1 bagi saya sama saja.
Saya pikir ini adalah masalah yang agak besar, karena bahkan hanya menggunakan proyek kosong dan kode gerakan yang diusulkan dalam tutorial dokumentasi KinematicPlayer2D , gagap tidak mungkin terlewatkan. Ini menjadi lebih jelas jika Anda meningkatkan variabel kecepatan sedikit (250 -> 600):

extends KinematicBody2D

var speed = 600
var velocity = Vector2()

func get_input():
    # Detect up/down/left/right keystate and only move when pressed.
    velocity = Vector2()
    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
    velocity = velocity.normalized() * speed

func _physics_process(delta):
    get_input()
    move_and_collide(velocity * delta)

Artikel tentang memperbaiki gagap itu salah. Bahkan dalam pengaturan minimal ini gagap muncul setiap beberapa detik di Windows, baik saat diputar dari editor (berjendela DAN layar penuh), saat diekspor (lagi berjendela DAN layar penuh).

Dalam proyek saya, saya menggunakan velocity = move_and_slide (velocity) dan berbagai kode Input yang berbeda, tetapi gagapnya sama seperti dalam proyek kosong dengan kode tutorial di atas.
Saya benar-benar berharap saya tidak perlu menunggu untuk menerbitkan hingga 4.0. Siapa yang tahu bug baru 4.0 apa yang akan diperkenalkan pada proyek saya? Berapa banyak pekerjaan yang harus dilakukan untuk mentransfer proyek saya ke 4.0?
Saya berharap gagap ini mendapat prioritas yang lebih tinggi.

3.2 beta1 minimal (termasuk win export): godot32beta1_stutter.zip

@golddotasksquestions Lihat diskusi di # 19783. Seperti yang Anda lihat, ini bukanlah masalah yang mudah untuk diperbaiki. Ada permintaan tarik terbuka di https://github.com/godotengine/godot/pull/33414 , tetapi perlu pengujian lebih lanjut. Saya akan mencoba mengunggah binari Windows yang dikompilasi untuk pengujian (dengan dan tanpa komitmen PR disertakan).

Saya akan menutup ini karena # 33414 sekarang telah digabungkan. Kami dapat mengaktifkan pengaturan itu secara default setelah mendapat lebih banyak pengujian.

@diiiiiiiii Dapatkah Anda mengonfirmasi bahwa fitur baru dari Humas di atas membantu mengatasi masalah Anda, atau apakah ini kasus yang tidak terkait?

@ starry-abyss Maaf, saya belum punya waktu untuk membaca utas atau menguji versi baru untuk sementara waktu, tetapi saya akan mencoba melakukannya ketika saya punya waktu.

Jangan khawatir, saya tidak ingin masalah ini ditutup kecuali jika benar-benar diselesaikan - atas nama kemajuan jitter!