Godot: Masalah gagap yang berat dalam game 2D sederhana [Windows 10, Nvidia]

Hai, Saya telah memperbarui laporan saya karena saya mengujinya di komputer saya yang lain (rumah) dan masalahnya ada di sini saat saya mengubah animasinya. Jadi, ini bukan animasi yang menyebabkan masalah. Saya rasa saya percaya karena ketika saya melihatnya ada di laptop saya, layarnya kecil. Berikut video masalah (video pada 60 FPS):
GodotStutter.zip

Jika videonya adalah representasi akurat dari apa yang ada di layar secara real time, maka jauh lebih gagap daripada yang pernah saya lihat disebutkan dalam masalah terkait gagap di sini. Pasti ada sesuatu yang salah dengan pengaturan Windows 10 / GTX 1060 ini (Saya melihat beberapa artikel di Internet yang merinci masalah kinerja pada Windows 10 / Nvidia setelah pembaruan Windows utama, tetapi tidak tahu apakah itu terkait).

Berikut adalah video dari proyek pengujian di sistem saya, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX dengan driver berpemilik terbaru (390.59). Tidak ada gagap sama sekali (di Openbox - di KWin, kompositor mengacaukan semuanya dan ada gagap yang sangat ringan setiap 10 detik atau lebih).
StutterTest_LinuxNvidia_OK.zip

BTW ini adalah versi tetap dari proyek demo firstGame_fixed.zip , yang asli memiliki file yang dibagi menjadi tiga folder yang berbeda entah bagaimana ("firstgame", "firstGame" dan "FirstGame").

Permainan ini memberi saya jumlah gagap yang sama seperti di video.
Namun, mematikan vsync akan menghilangkan gagap sepenuhnya (tetapi game berjalan pada 4000 fps).
Windows 10 64 bit nVidia GTX 1060 juga ada di sini.

Saya juga menguji seperti yang disarankan @Zylann di sini dan mendapatkan hasil yang sama. Saya juga memiliki Win10 x64 dan nVidia GTX 1060.

Sunting: Saya menggunakan driver ini dari nVidia:
398.11-desktop-win10-64bit-international-whql

Menangkan 7 64 bit GLES2 dan GLES3 diuji, GeForce GTX 660 / PCIe / SSE2 ... tidak ada gagap. Mengaktifkan Aero, dengan editor 2d dari Godot di belakang permainan menghasilkan beberapa gagap kecil (render editor Godot mengganggu rendering permainan).

Namun, Godot gagap adalah musuh raksasa yang tak terlihat, kita semua tahu itu ada tetapi kita tidak ingin melihat lebih dekat karena kita tahu bahwa solusinya tidak sederhana.

Masalah Anda tampaknya seperti fps tetap fisika yang berbeda dengan kecepatan refresh monitor, saya melihat gagap semacam ini di monitor yang tidak memiliki hz yang sama yang dikonfigurasikan editor fps fisika, tetapi bisa jadi hal lain.

Masalah Anda tampak seperti fps tetap fisika yang berbeda dengan kecepatan refresh monitor

Demo tidak menggunakan fisika, hanya _process .

Benar ... saya mengatakan bahwa saya hanya melihat gagap yang berat dalam kasus ini, tetapi memang benar bahwa tidak ada proses fisika yang terlibat. Saya menguji mengganti hz dari salah satu monitor dan tidak ada perbedaan, 0 gagap di gigi saya.

Sunting: Saya mendapat kemenangan 7, menang 8.1 dan menang 10 di komputer ini dan meluangkan waktu untuk menguji semua. Tidak ada gagap dalam kemenangan 8.1. Saya sedang menguji di win 10 sekarang dan sangat lancar ... tidak ada masalah windows. Godot marah dengan 1060 Anda?

Ini tes yang sama dengan laptop saya. Seperti yang Anda lihat, masalahnya juga ada di sini. Tapi sepertinya itu kurang terlihat tapi ada disini.

Spesifikasi Laptop: Windows 10 - Geforce 940M

Berikut video Laptop (ini adalah video 60 FPS):
GodotStutterLap.zip

Adakah yang bisa mencoba untuk menjalankan demo perubahan di Player.gd _process dengan _physics_process?

Saya akan menguji malam ini di PC rumah saya di sinilah saya mengalami masalah sepanjang waktu. Tapi saya punya hal yang aneh: Pagi ini, saya memberi Anda video dengan proyek tersebut di laptop saya dan seperti yang Anda lihat, Anda memiliki jenis gagap yang sama. Masalahnya adalah sekarang, jika saya menjalankannya lagi, saya tidak mengalami gagap ini lagi, seperti acak. Dan saya tidak mengubah apa pun di laptop saya, saya mengerjakannya sepanjang pagi di sesi TSE.

Peringatan: Saya berbicara hanya untuk laptop saya. Di PC rumah saya dengan GTX 1060 masalahnya selalu ada di sini. Tetapi di laptop saya, masalah tampaknya terjadi secara acak. Itulah mengapa saya berpikir bahwa untuk saat ini, saya akan membiarkan laptop saya di samping untuk tujuan pengujian dan saya akan menguji hanya pada PC rumah saya yang mengalami masalah sepanjang waktu, untuk dapat mengisolasi "bug".

@Ranoller Saya mengujinya dan mendapatkan hasil yang sama. Gagapnya masih ada dan terlihat hampir sama.

@Ranoller Melakukan pengujian dan hal yang sama à @RaXaR yang tidak mengubah apa pun. Punya masalah yang sama.

Ini tidak terlihat baik ....

Untuk menentukan bug secara tepat, saya akan melakukan tes ini:

1) Layar penuh on - off
2) Jika lebih dari 1 monitor:
Nonaktifkan- Aktifkan desktop bersama
3) Aero on-off

Kartu Anda berfungsi dengan baik di game lain? ...

Membaca posting pertama tentang animasi -> gagap / tidak ada animasi -> tidak gagap saya membaca kode dan saya melihat beberapa hal yang menurut saya tidak benar ... tepatnya: mengubah animasi setiap frame. Saya pikir kode itu harus memeriksa animasi saat ini. Mungkin itu tidak mengubah apa pun, tetapi jika seseorang ingin menguji untuk mengubah Player.gd dengan cara ini:

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)

Ini adalah ide terakhir ... mungkin omong kosong untuk masalah ini, tapi ... kartu grafis Anda sangat umum di pemain, jadi Godot harus mengeksekusi dengan baik di dalamnya.

@Ranoll

Untuk:

• Poin pertama: Sudah coba full screen atau belum, tidak ada perubahan apapun

• 2: Sudah mencoba menjalankan hanya dengan satu monitor (itu konfigurasi umum saya tetapi terkadang saya memiliki monitor kedua, jadi saya mencoba keduanya) dan tidak mengubah apa pun.

• 3: Saya harus menguji (harus bisa melakukan ini, malam ini (Waktu Prancis).

• 4: Saya harus menguji kode Anda (harus bisa melakukan ini, malam ini (Waktu Prancis).

Baru saja menguji kode Anda dan tidak mengubah apa pun :(

Meskipun masalah ini mungkin tidak terkait langsung dengan Godot, Godot harus merevisi masalah gagap dengan baik ... tidak benar bahwa semua game gagap seperti yang dikatakan di utas lain. Hari ini saya bermain n ++, layar penuh, berjendela, mencoba melihat gagap dan tidak .... tidak ada gagap sama sekali. Sama dengan Ori dan hutan buta, banyak hal buruk yang harus dilakukan agar gagap dalam game ini (berjendela dengan program lain di latar belakang, dll .... dan hanya 2 atau 3 frame yang melompat dalam satu jam ...). Godot, saat memulai eksekusi, selalu gagap x jumlah detik, kemudian stabil, tetapi setiap X detik Anda akan mengalami lompatan bingkai (tentu saja jika Anda tidak memiliki masalah dengan gtx1060). Kami tidak seharusnya menganggap masalah ini sebagai masalah kecil.

Saya mencoba melakukan yang terbaik untuk mengisolasi masalah tetapi pada level saya ini agak sulit. Saya mencoba menguji pengaturan yang berbeda tetapi tanpa hasil. Saya juga menguji gambar latar belakang daripada menggunakan warna dengan layar jelas. Saya sudah melihat (jangan ingat penyihir) mesin dengan masalah ini karena rendering sprite 2D pada "layar kosong" menyebabkan masalah ini, tetapi tampaknya bukan itu masalahnya di sini. Jadi saya tidak punya ide untuk saat ini.

Karena penasaran, coba buat profil berapa lama SwapBuffers mengambil context_gl_win.cpp sekitar baris 68. Jika butuh waktu lebih lama dari 16 md, kemungkinan besar Anda membuang bingkai di sini.

Jika seseorang yang mengetahui sumber Godot dapat menguji bahwa saya menarik di hasilnya (maaf bahasa Inggris saya ...)

Saya bermain dengan masalah ini kemarin dan saya secara ajaib menyelesaikannya sendiri setelah jendela permainan berjalan selama sekitar 60 detik. Lalu lancar, ini memberi tahu saya bahwa itu bisa saja merupakan cache?

Karena penasaran, coba buat profil berapa lama SwapBuffers di context_gl_win.cpp di sekitar baris 68. Jika butuh waktu lebih dari 16 md, Anda kemungkinan besar akan menghilangkan bingkai di sini.

Mungkin bisa membantu untuk mengetahui jika masalah terjadi di GLES2, kami tidak mengujinya

Saya mencoba bermain dengan opsi di Godot tentang itu, tetapi itu tidak mengubah apa pun bagi saya, mungkin saya tidak tahu persis apa yang harus diubah?

Mencoba membiarkan permainan selama lebih dari 2 menit tetapi masalahnya selalu di sini tidak terpecahkan untuk saya setelah 60 detik.

Saya mengalami masalah serupa dengan 3.0.3. (Win10 64 bit, Nvidia 660) Saya tidak menyadarinya dengan 3.0.2.

Saya pikir itu ada hubungannya dengan AnimatedSprite Node karena saya melihat masalah kinerja dengan level yang memiliki node ini. Saya mendapatkan penutupan saat menjalankan dari IDE atau jika saya mengekspor ke Win 32bit, tetapi Jika saya mengekspor ke Win 64bit semuanya berjalan sebagaimana mestinya, tidak ada gagap.

.. yang menarik, saya tidak memiliki masalah dengan proyek contoh 'FirstGame.zip' ... tetapi masih dengan game saya, FPS turun menjadi 5 ketika dijalankan dari IDE dan versi 32bit, GPU duduk sekitar 2% .. .tapi, dengan ekspor 64bit GPU berada pada 30% dan semuanya baik-baik saja.

Halo, apakah ada berita tentang masalah ini? Saya baru saja menguji dengan demo pong (saya tidak melakukan itu sebelumnya, hanya dengan permainan tutorial) dan tampaknya masalahnya ada di sini dengan proyek sampel ini juga. Saya menggunakan versi terakhir Godot di Steam untuk mengujinya.

Memperbarui driver Nvidia tidak mengubah apa pun, jadi saya datang untuk mengambil berita tentang masalah ini. Saya belum menemukan cara mengendarainya.

Saya sekarang memiliki komputer dengan geforce gtx 1060 (3gb- murah) dan tidak memiliki masalah di windows 10 home. Ini bisa menjadi beberapa aplikasi latar belakang? Beberapa konfigurasi hardware khusus AMD-Nvidia Intel-Nvidia ....? Saya tidak memiliki aplikasi game apa pun di komputer ini (ada di studio rekaman musik saya) tetapi Godot berjalan dengan lancar bahkan dengan 3 layar yang terhubung ke komputer. Siapapun dengan masalah ini dapat memeriksa apakah ada perangkat lunak pemantau permainan yang berjalan di latar belakang, atau uap, atau sesuatu seperti ini ...? Dan jika berhasil mencoba untuk tidak setuju?

Sulit untuk mematikan Steam saat Anda menggunakannya untuk meluncurkan Godot ... Godot berjalan dengan baik, masalahnya adalah game yang Anda buat. Saya sudah mencoba menonaktifkan semua yang dapat saya nonaktifkan, yang tidak mengubah apa pun. Saya melakukan banyak tes tanpa hasil. Saya juga mencoba mengatur ulang driver nvidia misalnya, memperbaruinya dll ... tetapi tidak mengubah apa pun.

Di sisi lain, saya memiliki banyak mesin yang berjalan mulus, jadi mengapa tidak Godot? Itulah hal yang saya coba temukan. Tetapi untuk saat ini saya tidak menemukan sesuatu. Ada sesuatu di suatu tempat selain apa dan di mana, itulah pertanyaannya :-)

Masalah ini terlalu "spesifik-mesin" untuk menemukan solusi yang dapat diterima melalui penelusuran sendiri. saya dapat mencari berjam-jam untuk kode Godot dan saya tahu bahwa tidak akan pernah memiliki kemungkinan untuk menemukan sesuatu yang berhubungan dengan ini ... saya tahu bahwa pengembang mesin menyukai lebih banyak kode fungsi baru dan "perbaikan bug" lebih dipertimbangkan "junior-work " atau sesuatu seperti ini. Tetapi dengan masalah seperti ini tidak demikian. Kami memerlukan beberapa pengembang mesin untuk menetapkan masalah ini secara otomatis dan perbaikan bug "rumit-hantu-rendah-sulit untuk membeli" lainnya ...

Saya menyebutkan bahwa saya sudah mencoba versi dev (tanpa Steam) dan masalahnya sama.

Hai, saya memiliki masalah gagap yang sama persis (menggunakan Godot 3.1 dari sumber Git), gerakan apa pun yang tertinggal bagi saya, persis seperti di video Anda, baik itu move_and_slide atau hanya gerakan pemutar animasi. tetapi mengaktifkan V-Sync dalam pengaturan proyek sepenuhnya menyelesaikan masalah gagap dalam game 2D.

Saya agak bingung karena @Zylann mengatakan mematikan V-Sync menghilangkan gagap, tetapi bagi saya sebaliknya.

@Qws mematikannya DAN membuat game berjalan pada lebih dari 60fps (yang terjadi pada saat itu) membuat gagap hilang untuk saya tetapi itu membawa masalah lain (menggunakan semua daya yang tersedia dan membuat semua gagal yang tidak menggunakan delta yang tepat waktu). Jika Anda gagap dengan sinkronisasi-V tidak aktif maka itu baik karena waktu delta yang tidak tepat atau situasi di mana game harus menunggu / memproses lebih lama dari bingkai untuk memperbarui layar.

Tes pertama yang saya lakukan dengan gtx 1060 baru tidak ada masalah ... tetapi kemudian saya mengalami gagap itu. Satu-satunya hal yang saya ubah adalah dvi ke HDMI conexion (dan beberapa program diinstal) ... ini agak aneh. Satu-satunya hal yang saya yakin adalah bahwa masalahnya bukan di sisi windows 10.

Saya akan mengatakan sebanyak ini. Saya sedang mengerjakan tutorial game 2D "Hoppy Days" dari tutorial Gamedev.tv. SAYA menggunakan 3.0.2 untuk mengembangkannya, dan itu berfungsi dengan baik. Saya perhatikan bahwa tutorialnya menggunakan 3.0.4, jadi HARI INI saya memutuskan untuk meningkatkan ke 3.0.6. Sekarang ada jeda yang terlihat dalam game. _Lambatnya tidak ada sama sekali di 3.0.2_ . Itu ada di sana sekarang. Semua pengaturan lainnya sama.

My Laptop adalah laptop gaming Dell Inspiron 7000 series yang cukup baru (dibeli Maret 2017). Prosesornya adalah Intel Core i7-7700HQ Quad Core Generasi ke-7 (Cache 6MB, hingga 3,8 GHz). Kartu videonya adalah NVIDIA GeForce GTX 1050Ti dengan 4GB GDDR5. RAM 16GB, 2400MHz, DDR4. Hard drive adalah SSD Samsung. Windows 10.

Bagi saya, sepertinya ada sesuatu yang berubah baik di 3.0.4 atau 3.0.6 ..... Tidak ada lagi yang berubah sama sekali. Bahkan tidak dalam game (seperti dalam ... Saya belum mengubah / mengedit / memperbarui level sama sekali).

@ emo10001 Bisakah Anda menguji 3.0.3? Saat itulah kami mengubah sistem build yang digunakan untuk membuat binari 3.0.x (3.0 hingga 3.0.2 dibangun di AppVeyor CI dengan MSVC 2015, 3.0.3 hingga 3.0.6 telah dibangun dengan GCC 8 melalui MinGW).

Jika laptop Anda memiliki grafis Optimus / yang dapat dialihkan, bisa jadi sistem Anda memasukkan biner 3.0.2 ke dalam daftar putih untuk digunakan dengan Nvidia GPU, sementara 3.0.3+ akan menjadi default ke IGP. Atau bisa jadi 3.0.2 telah dimasukkan dalam daftar putih oleh antivirus Anda sementara 3.0.3+ terlihat berasal dari sumber yang berbeda (yang benar) dan belum dianggap aman, sehingga antivirus akan menjalankan pemeriksaan penuh dan memengaruhi kinerja.
Itu hanya tebakan, tapi selain itu saya tidak yakin apa perubahan Godot yang sebenarnya akan memengaruhi kinerja seperti itu, jadi saya hanya dapat memikirkan perubahan sistem build.

CC @hpvb

Saya mempunyai masalah yang sama! Proyek saya tersendat selama 20 hingga 30 detik, lalu berjalan mulus setelahnya. Saya mengunduh proyek di pos OP dan itu adalah hal yang persis sama.
Mematikan V-Sync menghilangkan masalah, dan ini berjalan pada 4000+ fps.

Saya menjalankan versi 3.0.6 di Linux Mint 19 (jadi saya rasa tag windows itu tidak akurat, eh?) Dan GTX 760 dengan driver berpemilik terbaru.

Saya menjalankan versi 3.0.6 di Linux Mint 19 (jadi saya rasa tag windows itu tidak akurat, eh?) Dan GTX 760 dengan driver berpemilik terbaru.

Tidak, tapi ini mungkin masalah yang berbeda. Gagap di Linux sering terjadi karena pengomposisian pengelola jendela (misalnya saya punya beberapa dengan KWin, tidak ada dengan Openbox).

Proyek saya tersendat selama 20 hingga 30 detik, lalu berjalan mulus setelahnya

Saya sering memperhatikan ini, jika saya menjalankan adegan yang saya edit, ada gagap dan beberapa robekan (dengan vsync aktif) sekitar 15-30 detik, tetapi jika saya memulai proyek dari menu utama dan membuka adegan dengan pemilih adegan ... yah, tidak ada gagap dalam adegan yang sama (akhirnya ada, tapi tidak pernah). Ada penjelasan tentang acara ini? Godot? Windows? Berapa banyak bingkai yang diperlukan untuk menstabilkan reproduksi? ... akan sangat menyenangkan mengetahui hal-hal itu karena diperlukan untuk desain permainan.

Tidak, tapi ini mungkin masalah yang berbeda.

Hmm, begitu. Yang saya maksud adalah, masalah khusus ini mungkin multi-platform karena banyak orang mengalami masalah yang sama.

Saya telah mengotak-atik dan memperhatikan bahwa dua benda kinematik tergagap tepat pada saat yang sama, untuk move_and_slide () dan move_and_collide ().

Mengaitkan kamera ke salah satu kamera saat keduanya berosilasi, semua yang ada di pemandangan akan terhenti kecuali untuk dua node kinematik. Kamera statis hanya menunjukkan dua node kinematik yang gagap.

Tidak peduli pengaturan grafis apa yang saya ubah, atau _process atau _physics_process. juga tidak menggunakan variabel delta yang berbeda.

Saya pikir proyek ini tidak mewakili penggunaan sebenarnya ... proyek yang lebih rumit berjalan agak lancar. Saya pikir windows tidak menangani dengan baik waktu idle godot besar yang berlebihan ... Saya menemukan masalah terkait lainnya, tidak hanya untuk Godot tetapi sangat menderita dengan itu: dalam multimonitor dengan permainan desktop yang diperluas lebih mulus di monitor 1 jika ini diberi tag seperti "monitor utama". Jika monitor utama lain yang 1 ada gagap di monitor sekunder (youtube menderita karena itu, tetapi tidak pada game komersial kesatuan seperti ori). Dengan layar penuh di monitor sekunder, aero di win 7, dan monitor bertukar (ej: monitor 2 seperti primer) skenario adalah yang terburuk dan ada gagap besar (tidak hanya Godot, tapi juga pembuat game atau game unity) ... Saya tahu bahwa multimonitor dengan desktop diperpanjang dalam 2 layar 1080p sulit untuk GPU murah tetapi game lain lebih halus (Godot jangan kehilangan fps, hanya gagap). Jika tes ini akan dilanjutkan, kita harus membuat contoh yang lebih kompleks.

@Ranoller setup saya adalah monitor ganda di gtx 760, monitor kedua ditandai sebagai 'primer', linux mint 19 dengan kayu manis. Saya mencoba memahami kondisi spesifik proyek yang gagap, tetapi tidak dapat mengetahuinya. Proyek kecil ini terkadang tersendat, terkadang tidak (hanya tersendat, tidak ada fps yang hilang). Juga, ketika gagap (berjalan di jendela, konfigurasi pengujian godot), saya biasanya memiliki satu atau lebih jendela chrome di monitor kedua (bukan yang utama), dan ketika saya meminimalkannya, gagap hilang ... setelah beberapa meminimalkan / memulihkan pada jendela krom, gagap benar-benar hilang.

Saya punya 2 komputer -> satu dengan i5 gtx660 2 layar 1080p dan lainnya dengan layar i7 gtx 1060 3 (2 1080p dan hdready lainnya) ... yah, saya memiliki masalah gagap terkait dengan monitor sekunder di gtx660, saya rasa secara eksklusif terkait dengan rendering, godot dan chrome gagap, pembuat game dan kesatuan tidak (game komersial, tepatnya HiperLightDrifter dan Ori, saya tidak menguji demo atau template). Windows aero lebih gagap dalam layar penuh (saya pikir tidak benar-benar layar penuh) tetapi memiliki fps yang sangat banyak, tanpa aero di win 7 yang saya dapatkan di proyek saya 130-140 fps tanpa vsync, dengan aero saya melewati 400 fps, tetapi. .. gagap (banyak) dalam kondisi tertentu (dengan dan tanpa vsync). Saya barelly tidak bisa membuat godot gagap di i7 gtx 1060 (dengan proyek nyata, demo di thread ini gagap dan saya menjelaskan jet pendapat saya tentang). Saya pikir ini adalah masalah optimasi / OpenGL, ej: Light2D barelly tidak dapat digunakan, mode campuran apa pun selain "campuran" dapat tersendat jika sistem tidak terlalu kuat, tetapi Godot harus menangani permormance pada level yang sama dengan pembuat game atau persatuan. Mungkin setelah 3.1 diluncurkan, pekerjaan untuk pengoptimalan dapat dimulai (jika masalah dapat diperbaiki dan itu bukan Direct3D / OpenGL - masalah Windows tentu saja ... saya tidak tahu bagaimana menemukan game GLES2 / 3 di windows untuk diuji dan disccard OpenGL langsung - masalah Aero / Win7-8-10) ... Saya mengerti bahwa permormance Godot tidak akan pernah sama dengan propietary -> satu mesin berbasis game (Misalnya: asal Rayman berjalan mulus di laptop lama yang saya miliki , Godot 2 don´t), tetapi itu harus membuat setidaknya pada level stabil yang sama dengan pembuat game (Unity mungkin akan lebih baik dioptimalkan Godot untuk waktu yang lama, Anda tahu, uang ...). Untuk saat ini saya merasa bahwa Godot berkinerja baik hanya di perangkat keras kelas atas atau di layar resolusi rendah (saya menguji di komputer grafis intel hd i5 win7 32bit 15 "dan berkinerja baik, tetapi saya tidak berpikir bahwa dengan layar hd komputer ini akan berjalan dengan lancar) ...

Tentu saja semua itu adalah pendapat / pengalaman saya, saya bisa saja salah (dan saya harap bisa .. jika ini akan menjadi perbaikan satu baris sederhana ini bisa menjadi hebat !!!)

Di sisi lain saya ingat untuk membaca reduz menulis sesuatu yang berhubungan dengan "prioritas proses" dari godot yang dapat dieksekusi, tetapi di windows tidak ada perbedaan jika Anda secara manual mengubah prioritas godot dalam eksekusi, godot tidak berkinerja buruk (whou, saya punya menemukan sebuah kata?), eksekusi program tidak memiliki paku, ini adalah rendering, sesuatu yang berhubungan dengan nvidia / godot dan desktop komputer (di windows, saya tidak mencoba di linux)

Halo, apakah ada berita tentang masalah ini? ^^ Saya akan menguji lagi dengan versi terbaru tetapi tampaknya masalahnya masih ada.

apakah ini keluar di platform android atau ios sekarang？ ada beberapa game di toko google yang dibuat oleh godot awal yang juga memiliki masalah rana. seperti: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Ini ada di semua platform yang diuji dalam keadaan tertentu, dengan beragam GPU dan sistem operasi yang beragam ... tidak didokumentasikan di konsol.

Saya mengujinya di linux dan windows dan itu berjalan lancar dengan sesekali gagap kecil, saya memiliki kartu grafis baytrail grafis intel hd terintegrasi yang terintegrasi.

Setelah berjam-jam mencoba mencari tahu penyebab gagap, setidaknya dalam kasus saya, saya secara kebetulan melacak gagap 1 yang konsisten hingga mengaktifkan 'Auto Switch To Remote Scene Tree' di 'Pengaturan Editor'. Menghapus centang ini menyelesaikan masalah gagap dan kinerja bagi saya. (mungkin masih ada sedikit gagap, tapi hampir tidak terlihat.)

Godot membangun 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit, NVIDIA GeForce GTX 660, driver v416.81

Saya juga memiliki masalah gagap dengan permainan saya. Satu-satunya hal yang tampaknya membuatnya lebih baik adalah mematikan dan menghidupkan layar penuh saat game berjalan ... Dan bahkan kemudian ada sedikit gagap yang merayap ke atas setelahnya. Sepertinya terjadi secara acak. Terkadang permainan akan berjalan mendekati sempurna, di lain waktu terjadi gagap.

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

Dalam menang 10 gagap terjadi lebih banyak di layar penuh, dan itu karena Aero (Dan dapat dinonaktifkan). Tampaknya Godot menggunakan lebih sedikit CPU dan lebih banyak GPU dengan windows Aero tetapi ini menimbulkan lebih banyak gagap. Di windows 7, menonaktifkan windows Aero, layar penuh memiliki lebih sedikit gagap yang berjendela dan menggunakan lebih banyak CPU. Saya pikir win 10 tidak memiliki layar penuh yang nyata ....

Saya sudah mulai membuat prototipe game pinball 2D dan saya sudah terlalu goyah dalam pergerakan bola, saya hanya seorang rigidbody yang jatuh karena gravitasi. Saya menggunakan Win10 / NVidia GTX 560 Ti 1Go (dengan driver terbaru) / 8 Go Ram, komputer saya bukan yang terbaik tetapi proyek saya hanya memiliki bola dan StaticBody2D untuk perbatasan dan saya dapat melihat dengan jelas gangguan yang sangat sering terjadi, saya Sudah mencoba dengan dan tanpa vsync, dengan opengl 3.0 dan 2.0, berjendela dan layar penuh, dengan fps fisik yang lebih banyak dan lebih sedikit, masalahnya masih di sini.
Versi Godot saya adalah 3,1 alpha.
Menurut saya ini adalah masalah besar, mungkin sulit untuk diperbaiki tetapi itu tidak boleh dilewati, penting untuk memiliki pergerakan 2D yang mulus untuk sebuah game 2D.

Anda benar, Godot sekarang memiliki kegunaan yang lebih baik dari semua mesin teratas (pendapat saya tentu saja). Sisi kegunaan mengalahkan semuanya. Tapi ...... sisi kinerja .... sisi ekspor .... sepertinya Godot mengalahkan dengan sistem operasi, bukan seperti kesatuan atau ekspor pembuat game yang lebih lancar (sampai konstruksi di chrome lebih lancar ), dan bukan karena kelambatan gdscript (terjadi dengan dan tanpa GDScript), ada "hal lain yang tidak dapat ditentukan", saya harap suatu hari seseorang dapat menemukan satu baris pemberontak dalam file cpp dan mengubah satu baris "!" masalah ini akan diperbaiki ... (harapan gratis seperti Godot!)

Saya memiliki beberapa proyek dalam pikiran dan saya ingin membuatnya dengan Godot, ini akan memakan banyak waktu saya (untuk tidak menyebutkan semua waktu luang saya), tetapi saya sedih untuk mengatakan bahwa jika mesin tidak dapat menjamin gerakan 2D yang mulus dalam animasi dengan pemandangan sederhana, mesin meskipun dengan semua kelebihan ini sama sekali tidak berguna. Dalam hal ini mungkin pilihan paling bijak bagi saya bukanlah mengambil risiko kehilangan waktu dengan cara ini.

Saya memahami bahwa masalah ini hanya muncul di beberapa konfigurasi (driver Windows 10 dan NVidia misalnya) tetapi saya ingin tahu:

• Apakah masalah ini (atau yang serupa) sudah direncanakan dalam tonggak sejarah atau tidak?
• Apakah masalah ini mungkin dikesampingkan menunggu penggantian OpenGL oleh Vulkan di milestone 3.2?

PS: Saya sudah mencoba dengan pc lain:

• Intel i7 4790K 4,00 Ghz
• Win10 64 bit 16 Go RAM
• NVidia GTX 1060 3Go (dengan driver terbaru)
• Godot 3.1 alpha resmi
  dan saya memiliki masalah yang sama dengan adegan sederhana.

Saya pikir konfigurasi PC semacam ini (kartu Win10 + Nvidia) sangat umum, dan saya berharap komunitas Godot (yang membuat pekerjaan hebat dengan cara) akan segera memperbaiki masalah ini dan game 2D yang bagus itu akan mulai dirilis untuk ditampilkan. yang bisa kita lakukan dengan Godot, tetapi bagi saya masalah semacam ini mustahil.

Mungkin itu semacam masalah fokus program? Ketika saya memulai permainan dalam layar penuh, saya melihat kegagapan pada dasarnya setiap saat. Tetapi jika (saat permainan berjalan) saya beralih ke mode berjendela dan kembali ke layar penuh, tampaknya berjalan sempurna setiap saat. Jika saya punya, saya dapat memprogram ini agar terjadi secara otomatis, tetapi tampaknya tersendat. Adakah orang lain yang dapat mengonfirmasi peralihan dari layar penuh, ke jendela, ke layar penuh lagi untuk memperbaiki gagap?

Sunting: Oh dan satu hal lagi ... Ketika saya menonaktifkan aplikasi Geforce Experience, segalanya tampak menjadi lebih baik.

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

Saya mencoba apa yang Anda usulkan, saya telah menonaktifkan Geforce Experience, mencoba beralih dari layar penuh, ke berjendela, ke layar penuh lagi, dengan vsync diaktifkan dan dinonaktifkan (lebih buruk dengan vsync dinonaktifkan) tetapi gagap selalu tampak tidak menguntungkan bagi saya.
Ini cukup acak tetapi saya tidak pernah melebihi sekitar 15-20 detik tanpa gagap.

Terima kasih telah mencoba! Aneh sekali, spesifikasi Anda lebih baik dari saya. Masalahnya dengan saya, ini sangat acak ... Sulit untuk mereproduksi dengan tepat. Terkadang akan berjalan dengan baik, di lain waktu akan gagap. Saya cukup yakin itu ada hubungannya dengan Godot sendiri. Saya tidak pernah mengalami gagap dalam game yang dibuat di Unity, atau mesin game lainnya dalam hal ini.

Baru saja menyadari gagap ini.

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

Seperti yang telah disebutkan orang lain, ini adalah masalah serius bagi Godot. Minggu ini saya memutuskan untuk membuat prototipe untuk permainan yang sangat sederhana. Saya mencari kerangka kerja atau mesin (menemukan cukup banyak) dan memutuskan untuk menggunakan Godot - karena gratis dan terbuka. Kemudian saya melihat gagap, menemukan masalah ini - dan terkejut karena sepertinya tidak ada kemajuan. Saya kira saya akan membuat prototipe ide saya di Godot. Tetapi jika saya ingin membuat game yang dapat dilepas, saya mungkin akan mencoba mesin lain. (Kedengarannya terlalu kasar ... Saya hanya berpikir, Godot mungkin kehilangan banyak pengadopsi potensial jika masalah tidak diperbaiki.)

Tidak ada kemajuan karena tidak ada yang mengerjakan ini, dan ya, ini masalah serius. Tetapi untuk saat ini, jika Anda perlu merilis game komersial, Anda dapat membuat prototipe di Godot dan port to unity (Anda dapat menggunakan C #). Anda perlu mengingat pendekatan komponen objek permainan-adegan dan Anda dapat mereplikasi di Godot dan jika karya pergi ke kesatuan untuk aliran cairan dan kinerja, atau jika 2D pergi ke pembuat permainan. Saya bekerja di plugin untuk mencoba mengonversi proyek Godot ke mesin lain dan mencoba mem-port gdscript ke modul, ke gml atau ke unity C #, tetapi merupakan tugas yang sangat besar (saya tidak tahu apakah upaya itu sepadan itu, terlalu banyak waktu tidak bekerja dalam permainan) dan selalu tidak sempurna (saya tidak bisa mendapatkan semua jenis, ej: objek dikembalikan oleh tabrakan). Saya memiliki parser kecil untuk skrip dan akan memulai parser ke tscn dan tres, tetapi mengonversi hasil parser dari gdscript ke unity c # atau pembuat game GML memerlukan banyak kode dan saya tidak tahu "legalitas" tentang ini (i perlu semua nama api ej. dalam file json dan tidak tahu tentang IP ini). Animasi adalah masalah lain, untuk saat ini saya tidak tahu bagaimana cara mendekatinya, tetapi menggunakan spine / dragonbones akan memudahkan port. Ide utama saya untuk melakukan itu adalah mulai di Godot dan berakhir di unity atau gm, tetapi bagi niw adalah sakit kepala ... Jika unity sama-sama portabel (saya butuh itu), kecil dan cepat berkembang seperti Godot (dan memiliki 32 bit editor) Saya melakukan port proyek utama saya beberapa bulan yang lalu, saya suka Godot tetapi untuk proyek ukuran menengah dalam tim kecil (atau pria lajang seperti saya) adalah risiko, tidak ada yang menjamin kepada Anda bahwa proyek yang sudah selesai tidak akan memberikan banyak masalah. Tetapi jika ada programmer C ++ yang baik di tim Anda adalah hal lain, Anda selalu dapat menyesuaikan Godot dengan permainan Anda (dalam kesatuan Anda tidak bisa, tetapi kurang buggy) ....
Saya benci masalah ini seperti saya benci kinerja editor yang rendah di proyek pertengahan dan game yang diekspor, tetapi saya benci lebih banyak kesatuan (mengapa saya perlu internet di semua komputer untuk membuka editor? Saya punya satu komputer tanpa itu!) Dan benci studio visual sangat dalam ... saya, saya yakin bahwa jika Godot menghentikan gagap dan bekerja pada kinerja dan ekspor, kita dapat mulai melihat game upcomming yang hebat.

Untuk memeriksa kembali masalah ini hari ini, saya melakukan hal berikut, masih di Windows 10 dengan nVidia GTX 1060:

Saya membuka The Binding of Isaac, mode berjendela. Berlari berputar-putar, tidak gagap (dengan ini dan seterusnya, maksud saya setidaknya selama 30 detik). Saya tidak tahu apakah gim ini memiliki sinkronisasi-V atau tidak, tidak ada pengaturan seperti itu.

Saya membuka Minecraft, mode berjendela. Memuat dunia datar dengan melihat ke tanah di mana kelambatan tidak akan ada, tidak ada gagap.

Saya membuka Factorio, mode masih berjendela, dengan pabrik akhir game yang cukup besar. Berlari dalam garis lurus, tidak gagap. Namun, sinkronisasi-V tidak aktif. Jika saya menyalakannya dan memulai kembali permainan ... masih tidak ada gagap.

Saya membuka game Java lama yang saya buat menggunakan Slick2D (OpenGL), tidak ada satupun gagap (saya belum melihat satu pun Oo). Memeriksa opsi, sinkronisasi-V diaktifkan. Jika saya mematikan sinkronisasi-V, saya akan tersendat setiap detik atau lebih. Jika saya menggandakan framerate cap, saya tidak gagap.

Sekarang, saya membuka proyek 3D dengan Godot 3.1 alpha3, dengan peta yang memiliki beberapa aset dan karakter yang bergerak: hampir tidak ada gagap, saya hanya dapat melihat satu mungkin setiap 20 detik, yang terlalu halus untuk mengganggu.

Saya juga mencoba proyek 2D Wallrider yang saya porting di Godot 3.0.6: sama, tidak cukup gagap (acak satu per 20 detik).

Semua proyek di atas memiliki kesamaan: mereka tidak hanya menggambar satu sprite di layar.

Jika saya mencoba proyek uji @crystalnoir dengan Godot 3.1 alpha3, saya langsung mendapatkan gagap yang sering tidak teratur, yang hanya hilang jika saya menunggu sekitar 30 detik setelah terakhir kali ditampilkan / dimaksimalkan. Saya mencoba beralih ke _physics_process , dan bahkan mencoba delta = 1.0 / 60.0 , semuanya sama saja. Jika saya mencetak delta , itu menunjukkan bahwa ada fluktuasi setiap detik, tetapi permainan menunjukkan gagap beberapa kali per detik bahwa delta tidak mencerminkan sama sekali. Itu juga terjadi jika saya memulai permainan tanpa editor.
Saya juga mencoba mem-portingnya ke Godot 2.1.5, dan masalah yang sama terjadi (proyek: Stuttering_issue19783.zip )

Dan sekarang, di sinilah menjadi menarik:
Jika saya membuka kedua game 3D saya DAN pengujian @crystalnoir kembali ke layar belakang, keduanya berjalan mulus, segera. Game 2D masih sedikit gagap, tapi tidak sebanyak itu. Jika saya menutup game 3D, sepertinya masih berfungsi dengan baik, tetapi jika saya mengurangi game 2D dan memaksimalkannya lagi, game akan kembali menjadi gagap yang mengerikan.

Ini belum berakhir!
Sekarang saya mencoba menambahkan kamera 3D di game 2D. Dan secara ajaib, kegagapan berkurang secara drastis, dan segera, hanya dengan melakukan itu.
Anda dapat mencobanya sendiri dengan PlayerWith3D scene: Stuttering_issue19783.zip
Lihat betapa mulusnya ini secara default. Sekarang tekan tombol magic , lihat bagaimana hasilnya jika tidak ada lingkungan 3D yang ditampilkan (meskipun tidak selalu kembali ke kotoran 100%, tetapi saya melihat PlayerWith3D.tscn selalu terlihat lebih baik daripada Player.tscn ).

Saya ingin melangkah lebih jauh dan melihat apa yang terjadi jika saya mengubah panel kontrol nVidia dari Optimal Power (default) menjadi Maximum performance , tapi ... erhm ...

Bagaimanapun, yang bisa saya tebak dari ini adalah (tapi ini tebakan jadi anggap saja dengan sebutir garam): ini bukan kesalahan Godot secara langsung. Ini driver grafis yang mencoba menjadi "pintar".

Demi dewa gagap !!! 😂😂😂

Buang saja ini di luar sana ... Pada November 2018, 14 kartu video teratas di Steam adalah Nvidia. Mari kita lihat kartu teratas di setiap kategori GPU:

NVIDIA GeForce GTX 1060: 14,60% pengguna Steam.
Grafik AMD Radeon R7: 1,06% pengguna Steam.
Intel HD Graphics 4000: 1,06% pengguna Steam.

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

Mengingat data di atas, sepertinya masalah ini harus menjadi prioritas utama. Sebagian besar gamer menggunakan kartu Nvidia, ini adalah konfigurasi yang paling umum sejauh ini. Perbandingan jumlah pengguna grafis Radeon dan Intel sangat kecil.

@Ranoller ... Anda membunuh saya. Memberi tahu orang-orang untuk membuat prototipe di Godot tetapi beralih ke Unity untuk judul komersial mereka (dalam utas masalah Godot) adalah hal paling konyol yang pernah saya dengar, jangan tersinggung.

@ Zylann Saya berhasil menyetel mode Manajemen daya ke "Perfer kinerja maksimum", tetapi tidak ada peningkatan dalam gagap.

@ behelit2 Jangan tersinggung

@Zylann Saya meletakkan kamera 3D yang membuat mesh di depan pemandangan yang membuat peta tilemap dengan tekstur animasi dan masalah godot gagap beberapa detik setelah mendapatkan fokus tidak diperbaiki. Tidak ada sttuter jenis lain sebelumnya (hanya "awal") di adegan itu jadi saya tidak tahu apakah trik ini memperbaiki sesuatu, tetapi menarik Anda temukan. Saya akan menguji dengan file Anda. Saya juga berpikir bahwa godot idle time membuat sesuatu di komputer menjadi "malas", tapi mungkin sistem operasinya, karena perbedaan win dengan dan tanpa aero di FPS, penggunaan CPU, dan stuttering sangat tinggi. Mungkin OS yang mencoba pintar dan bukan kartu grafis.

Saya suka ide Zylann untuk menganalisis apa yang dilakukan game lain. Saya tidak tahu apakah ini offtopic, tetapi saya melakukan beberapa tes.
Pertama-tama, tampaknya 95% dari game uap adalah 32bit (rilis terbaru juga). Tampaknya persentase yang sama dari game dirender oleh directx. Saya menangkap proses yang dijalankan game dan mencoba melihat apa yang terjadi dengan rendering. Beberapa info di belakang (Bukan untuk memiliki kesimpulan, hanya info):

Bit Game / Eksekusi / Mesin / Proses yang digunakan untuk membuat di windows 7 64 bit dan catatan.

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

• Ori dan hutan buta -> 32 bit / Unity / Windows GDI. Menjalankan proses yang disebut OPENGL32 seperti godot tetapi merupakan semacam pembungkus di Windows GDI. Bukan satu panggilan pun dari OpenGL32, semua panggilan berasal dari Windows GDI.
  

• Debu: Ekor Elysyian -> 32 bit / Microsoft XNA / Windows GDI. Memiliki gameoverlayrenderer.dll dan semua panggilan berasal dari ini (ClientToScreen). Tidak memiliki dll OpenGL.

• SuperMeatBoy -> 32 bit, eksekusi di dalam Steam Overlay, Windows GDI

• ΔV: Rings of Saturn (demo) -> 64 bit, godot / Executes OpenGL dan panggilan Windows GDI, lakukan satu panggilan ke OpenGl SwapBuffers - GetPixelformat dengan nilai 8. Lakukan banyak panggilan ke Windows GDI. Lakukan panggilan ganda? ke WindowsFromDC- SetRect (ukuran jendela), OffsetRect.
  

• Bastion -> 32 bit / SDL2 / Menjalankan panggilan OpenGL murni, tanpa Windows GDI, melakukan panggilan unik swapBuffers - GetPixelFormat sepanjang waktu dengan nilai 10.

• SouthPark tongkat kebenaran -> 32 bit / Mesin tidak tahu / Jalankan semua panggilan di Windows GDI, tampaknya direct3D v 9 (memiliki d3d9.dll tetapi melakukan sedikit panggilan dengan proses ini), sebagian besar panggilan berasal dari gameoverlayrenderer steam dan uxtheme.dll yang menjalankan OffsetRect dan IsRectEmpty dan fungsi jendela lainnya.
  

• Sine Mora -> 32 bit / Mesin tidak diketahui / Jalankan semua panggilan di Windows GDI dengan hamparan uap, dicect3d 9

• Apotheon -> 32 bit / Microsoft XNA / Semua panggilan di Windows GDI, satu panggilan dari overlay uap (Klien ke layar), satu panggilan Microsoft XNA (ScreenToClient), dan panggilan dari proses yang disebut uxtheme.dll (manajemen jendela di windows?) ke IsRectEmpty dan PtInrect (semua boolean).
• Telur kembali ke rumah -> 64 bit / Godot / Panggilan dari OpenGL dan dari jendela GDI, sama dengan Ring of Saturn.
• Guacamelee! Super turbo .... -> 32 bit / Unknow engine tapi untuk filenya bisa mirip sine mora. Game ini memungkinkan mengubah ukuran layar./ Semua panggilan dari Windows GDI.
• Bukan Hero -> 32 bit / SDL2 (wikipedia mengatakan ClickTeam Fusion) / Semua panggilan dari windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 bit (ya, ada satu) / Intro mengatakan Firebird, sampai sekarang tidak ada tentang proses / Semua panggilan dari windows GDI, tetapi, ada sangat sedikit panggilan, sedikit yang di game lain, beberapa panggilan per detik (ej, Anda barelly bisa mengikuti panggilan api godot, ada ton per detik). Tapi game ini membakar de GPU.

Saya perhatikan bahwa sebagian besar game dalam fokus hilang menghentikan proses dan jeda (mungkin latihan yang baik?) Dan sangat sedikit game yang memungkinkan Anda untuk mengubah ukuran layar secara manual (ej: bukan pahlawan). Sayangnya saya mengalami masalah gagap karena kehilangan fokus / perolehan fokus di ΔV: Rings of Saturn (demo).

Sunting: Tampaknya godot adalah satu-satunya mesin yang menggunakan proses OpenGL32 dan WindowsGDI pada saat yang bersamaan.
Aplikasi yang digunakan: API Monitor v2

(Sunting: Nama yang benar dari ΔV: Rings of Saturnus (demo))

Jika yang Anda maksud dengan Rings of Saturnus ΔV: Rings of Saturn (demo), itu dibuat dengan Godot 3.1, tetapi saya tidak yakin dengan revisi persis yang mereka gunakan?

Setelah berjam-jam mencoba mencari tahu penyebab gagap, setidaknya dalam kasus saya, saya secara kebetulan melacak gagap 1 yang konsisten hingga mengaktifkan 'Auto Switch To Remote Scene Tree' di 'Pengaturan Editor'. Menghapus centang ini menyelesaikan masalah gagap dan kinerja bagi saya. (mungkin masih ada sedikit gagap, tapi hampir tidak terlihat.)

Godot membangun 8849d3b
Win10 64bit, NVIDIA GeForce GTX 660, driver v416.81

Saya mengalami masalah gagap yang sama dan tidak mencentang Auto Switch to Remote Tree adalah penyebabnya.

Saya mengalami masalah yang sama di sini. Ada beberapa masalah tentang jitter ini tetapi kebanyakan dari mereka tampaknya tidak memiliki solusi yang tepat dan saya sangat membutuhkan bantuan.

Saya akan menandatangani kesepakatan dengan penerbit dengan permainan saya yang saya buat dengan Godot dan karena jitter saya mungkin harus memindahkan semua kode saya ke Unity. Waktu dan biaya untuk memindahkan semua kode dikesampingkan, saya enggan untuk beralih ke mesin yang berbeda karena saya sangat menyukai filosofi desain Godot dan Godot itu sendiri.

Saya juga memperhatikan bahwa dalam opsi 3.1 'Physics Jitter Fix' telah ditambahkan di menu pengaturan (https://twitter.com/reduzio/status/984783032459685890) tetapi itu juga tidak membantu.

Versi Godot:
Godot 3.0.6

OS / perangkat termasuk versi:
MacOS 10.14.1
MacBook (Retina, 12 inci, 2017)
1,2 GHz Intel Core m3
8 GB 1867 MHz LPDDR3
Grafis Intel HD 615 1536 MB
(Tetapi masalah ini terjadi pada banyak perangkat termasuk PC dan game yang diekspor di ponsel dan PC.)

Deskripsi masalah:
Objek apa pun yang bergerak tampaknya tersendat atau bergoyang secara berkala disertai layar membeku.

Langkah-langkah untuk mereproduksi:
Buat proyek baru dengan KinematicBody2D atau bahkan AnimatedSprite dan ubah posisi dengan move_and_slide () atau set_position () setelah menambahkan Camera2D sebagai simpul anak. (Tapi itu masih terjadi bahkan tanpa Camera2D.)

Dan tampaknya ini lebih sering terjadi pada perangkat dengan daya pemrosesan rendah.

Proyek reproduksi minimal:
Godot_Jitter.zip

KinematicBody2D, _proses_fisika (), pindah_dan_luncuran ()

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)

Menangkan 7 64 bit, GTX 660 (driver 391.35), Godot 3.0.6 dan 3.1-beta1

Hei, saya men-tweak proyek aslinya (animasi berhenti, memanfaatkan tubuh kaku alih-alih menyesuaikan posisi secara manual, menambahkan latar belakang yang sedikit animasi, dll)

Ini dia: FirstGame_2.zip

Diuji dengan jendela ukuran ~ 500x500 dan resolusi monitor 1920x1080

Sekarang pengamatan saya:

• Jitter bersifat omnidirectional (tidak hanya vertikal, seperti masalah vsync biasa)
• Semakin kecil ukuran jendela, semakin sering jitter
• Mematikan vsync menghilangkan jitter (poin berikutnya adalah dengan vsync aktif)
• Menjalankan game tanpa editor di layar pada saat yang sama (meminimalkannya, jadi ini hanya desktop - ikon, wallpaper, taskbar dan mungkin beberapa jendela statis seperti manajer file atau terminal) menghilangkan jitter
• Game yang diekspor atau dijalankan dari editor tidak masalah
• Jika saya menjalankan game dengan quakespasm-sdl2 di layar yang sama (dengan zombie menyerang pemain di bawah air), saya melihat sedikit jitter
• Jika saya menjalankan game dengan situs shadertoy (demo ini: https://www.shadertoy.com/view/ll3fz4), tanpa jeda, di layar yang sama, saya melihat banyak jitter
• Jika saya menjalankan game dengan situs shadertoy, tetapi berhenti, di layar yang sama, saya melihat sedikit gangguan
• Jika saya menjalankan game dengan editor di layar yang sama, dengan adegan yang ditampilkan di editor tidak memperbarui (Player.tscn), saya melihat sedikit gangguan
• Jika saya menjalankan game dengan editor di layar yang sama , dengan adegan yang ditampilkan di editor sering diperbarui (main.tscn, saya memiliki shader animasi di sana), saya melihat banyak jitter

Tidak mencoba dengan Aero mati, lupa cara cepat mematikannya?

@ starry-abyss untuk mematikan aero, pergi ke panel konfigurasi, pilih "penampilan dan personalisasi", di sana Anda harus dapat mengubah ke tema lama seperti "Windows Classic", yang tidak menampilkan efek visual (dan kemudian tidak ' t gunakan Aero), atau "Windows 7 Classic".

Oke, jadi dengan tema klasik, game ini, dengan shadertoy / editor di layar juga, bolak-balik dari status gagap menjadi mulus (setiap status dapat bertahan selama beberapa detik). Dan gagap disertai dengan robekan bingkai vertikal dalam mode ini. Konon, Firefox bahkan menggulirkan air mata dengan tema klasik: 'D

Saya mengalami masalah yang sama persis diiiiiiiii, kasus penggunaannya dengan move_and_slide sama dengan saya. Jika Anda perhatikan dengan cermat, bukan objek pemain yang bergetar, tetapi latar belakang paralaks di belakangnya.

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

Karena ini terjadi pada berbagai jenis perangkat, menurut saya ini tidak terkait erat dengan konfigurasi perangkat keras. Itu bahkan terjadi pada game yang diekspor yang berjalan di perangkat ios.

Jika Anda perhatikan dengan cermat, bukan objek pemain yang bergetar, tetapi latar belakang paralaks di belakangnya.

@ behelit2 Saya tidak yakin tentang itu. https://youtu.be/YVFtkbuyqEQ Dalam rekaman ini jika Anda melihat objek pemutar, bahkan akan bergoyang dengan sendirinya. Ini mungkin masalah yang terpisah tetapi menjadi jauh lebih buruk saat perataan kamera aktif atau objek dialihkan ke Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
Inilah yang terjadi saat penghalusan kamera aktif dan objek dialihkan ke 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)

Saya mungkin telah memperkuat jittering dengan menggunakan apply_impulse () seperti itu tetapi memodifikasi posisi objek secara langsung menggunakan set_position () tidak membuat banyak perbedaan.

@diiiiiiiii Saya pikir Anda harus membuka masalah terpisah saat itu. Jika tidak, utas akan penuh dengan pernyataan yang kontradiktif karena orang menguji berbagai hal.
Misalnya, saya mencoba proyek OP untuk saat ini, bukan milik Anda (maaf).

@ starry-abyss Mengerti;)
Meskipun sudah ada banyak masalah tentang jittering dan saya pikir mereka terkait erat dan mungkin memiliki akar penyebab yang sama.

Pembaruan tentang masalah OP. Saya menemukan beberapa opsi di Godot untuk menutup fps tanpa menggunakan v-sync. Jadi bagi saya itu 60 fps dengan v-sync off dan bukan ~ 4000 sekarang.
Dan fakta mematikan v-sync memperbaiki masalah untuk saya.

Saya ingin tahu apakah v-sync masuk akal dalam mode berjendela sama sekali. Windows tampaknya menggunakan v-sync dengan sendirinya, dan mungkin akan bertarung dengan game Godot yang akan menyiapkan bingkai lebih cepat setelah sinyal v-sync diterima. Juga IIRC game lain hanya robek dalam layar penuh dengan v-sync off, dan bukan dalam mode berjendela.

FYI, masalah diiiiiiiii berlanjut di sini sebagai gantinya: # 25162

Selain pendekatan v-sync off, saya menemukan cara khusus Windows yang menarik (dengan deskripsi komit, ini mungkin masalah ini), tidak yakin apakah Godot sudah menggunakan ini, tetapi mungkin seseorang punya waktu untuk mencoba:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Juga ini terkait: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

Namun, ada juga utas ini yang menjelaskan lebih detail dan dengan pendekatan berbeda:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
Dan ini saling melengkapi, lebih pendek dan lebih ke intinya, tetapi juga dengan beberapa emosi pada awalnya: https://www.vsynctester.com/firefoxisbroken.html

Mengubah kata gagap menjadi jitter dalam laporan saya di atas, karena itulah yang saya alami (lihat https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Ide saya adalah menonaktifkan v-sync hanya dalam mode berjendela (yaitu dapat dilakukan dari kode, bahkan mungkin meminta kecepatan refresh monitor untuk tutup fps), tetapi karena pengembang inti tidak mendukung pendekatan tersebut, tidak ada untuk mempertimbangkan kembali. :) Ada cara lain yang lebih spesifik untuk Windows, tetapi kami masih harus membuktikan bahwa cara tersebut berfungsi dengan baik dan tidak terlalu hacky.

Pembaruan tentang masalah OP. Saya menemukan beberapa opsi di Godot untuk menutup fps tanpa menggunakan v-sync. Jadi bagi saya itu 60 fps dengan v-sync off dan bukan ~ 4000 sekarang.
Dan fakta mematikan v-sync memperbaiki masalah untuk saya.

Saya ingin tahu apakah v-sync masuk akal dalam mode berjendela sama sekali. Windows tampaknya menggunakan v-sync dengan sendirinya, dan mungkin akan bertarung dengan game Godot yang akan menyiapkan bingkai lebih cepat setelah sinyal v-sync diterima. Juga IIRC game lain hanya robek dalam layar penuh dengan v-sync off, dan bukan dalam mode berjendela.

bagaimana Anda membatasi fps menjadi 60?

Menggunakan kolom "Paksa fps" di suatu tempat di kategori Debug pada setelan Project

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

Pembaruan tentang masalah OP. Saya menemukan beberapa opsi di Godot untuk menutup fps tanpa menggunakan v-sync. Jadi bagi saya itu 60 fps dengan v-sync off dan bukan ~ 4000 sekarang.
Dan fakta mematikan v-sync memperbaiki masalah untuk saya.
Saya ingin tahu apakah v-sync masuk akal dalam mode berjendela sama sekali. Windows tampaknya menggunakan v-sync dengan sendirinya, dan mungkin akan bertarung dengan game Godot yang akan menyiapkan bingkai lebih cepat setelah sinyal v-sync diterima. Juga IIRC game lain hanya robek dalam layar penuh dengan v-sync off, dan bukan dalam mode berjendela.
bagaimana Anda membatasi fps menjadi 60?
-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Saya belum pernah melihat orang memposting CPU mereka dengan sistem, kecuali dan I5-2500K yang memiliki GPU Intel terintegrasi.

Laptop saya memiliki GPU terintegrasi intel dan kartu Nvida khusus. Saya hanya ingin tahu apakah mungkin ada masalah antara dua gpu / driver dan Godot

Mungkin. Tapi sepertinya tidak tergantung pada gpu / cpu. Pada i7 2700 + 1080ti dapat menjadi gagap (berjendela) dan mentega halus pada ponsel i5 dengan intel 4000 (permukaan generasi pertama pro) - dalam layar penuh.

Lucu Anda harus mengatakan bahwa Jika saya menjalankan proyek demo di laptop 940m saya, saya melihat gagap. Namun ketika saya menjalankan aplikasi menggunakan Intel 530 khusus, saya tidak melihat gagap sama sekali.

Windows 10 rumah
i3-6100H CPU @ 2.70GHz,
GeForce 940M (26.21.14.3064)
Grafis Intel (R) HD 530 (26.20.100.6709)

Apakah gagap terlihat dalam proyek ini ? (Pindah dengan menekan tombol panah.)

Saya baru saja melakukan ekspor cepat dengan meninggalkan interpolasi dan mengatur physics ke 60:
940M ada sentakan sesekali tetapi tidak ada pemotongan
Intel 530 tidak ada sentakan tetapi terkadang geser vsync jelas,

Saya akan melakukan lebih banyak nanti, dan memberi tahu Anda.

Saya telah mencapai beberapa keberhasilan tampaknya dengan membatasi FPS saya pada 60. Tidak yakin apakah 60 adalah angka ajaib, layar saya dapat mendukung 144, saya mencoba mengatur tutup pada 144, tetapi gagap masih terlihat. Saya menurunkan FPS saya ke 120, gagap masih terlihat, tetapi tidak "buram", yang membuat saya berpikir itu hanya terjadi pada interval yang lebih rendah. Ditindaklanjuti dengan menurunkan FPS menjadi 80, dan hasil yang sama seperti sebelumnya, tetapi gagap sekarang tampak lebih lambat. Juga, saya harus mengatakan, saya menonaktifkan v-sync dan berjalan dalam mode berjendela, saya telah menguji dengan layar penuh, tetapi hasil yang sama. Apakah ada proses di mesin yang dibatasi pada 60 FPS?

Apakah ada proses di mesin yang dibatasi pada 60 FPS?

Secara default, fisika disimulasikan pada 60 FPS, yang berarti akan ada perbedaan yang terlihat saat rendering FPS lebih tinggi daripada FPS fisika (asalkan tampilan cukup cepat untuk menunjukkan perbedaannya). FPS fisika dapat diubah dalam Pengaturan Proyek ( Fisika> Umum> Fps Fisika ).

Ini dapat dikurangi dengan menginterpolasi benda-benda fisika, tetapi tidak ada dukungan resmi untuk ini. Di 3.2alpha, Anda dapat menggunakan add-on smoothing ini yang memudahkan interpolasi node.

Apakah ada proses di mesin yang dibatasi pada 60 FPS?

Secara default, fisika disimulasikan pada 60 FPS, yang berarti akan ada perbedaan yang terlihat saat rendering FPS lebih tinggi daripada FPS fisika (asalkan tampilan cukup cepat untuk menunjukkan perbedaannya). FPS fisika dapat diubah dalam Pengaturan Proyek ( Fisika> Umum> Fps Fisika ).

Ini dapat dikurangi dengan menginterpolasi benda-benda fisika, tetapi tidak ada dukungan resmi untuk ini. Di 3.2alpha, Anda dapat menggunakan add-on smoothing ini yang memudahkan interpolasi node.

Luar biasa, terima kasih, itu mungkin menjelaskan mengapa karakter gagap saat gerakan ditangani dalam panggilan proses fisika

Masih dapat mereproduksi dalam 3.1.1 BTW, cara termudah adalah dengan membuka Shadertoy di Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

Saya tersandung di sini berharap akan ada solusi tetapi setelah mencoba hampir setiap saran yang saya lihat di utas ini, tetap tidak ada dadu. Bagi saya, jittering hanya terjadi ketika saya menjalankan proyek di kartu NVIDIA. Jika saya menjalankannya menggunakan GPU Intel terintegrasi, ini berjalan sangat mulus. : /

Saya menggunakan versi alfa terbaru dari Godot 3.2 di Windows 10

Saya tersandung di sini berharap akan ada solusi tetapi setelah mencoba hampir setiap saran yang saya lihat di utas ini, tetap tidak ada dadu. Bagi saya, jittering hanya terjadi ketika saya menjalankan proyek di kartu NVIDIA. Jika saya menjalankannya menggunakan GPU Intel terintegrasi, ini berjalan sangat mulus. : /

Saya menggunakan versi alfa terbaru dari Godot 3.2 di Windows 10

Saya tidak berpikir Anda dapat memperbaikinya di windows, ini tidak terjadi di linux, ini mungkin diperbaiki di 4.0 dengan perender vulkan baru.

Saya tersandung di sini berharap akan ada solusi tetapi setelah mencoba hampir setiap saran yang saya lihat di utas ini, tetap tidak ada dadu. Bagi saya, jittering hanya terjadi ketika saya menjalankan proyek di kartu NVIDIA. Jika saya menjalankannya menggunakan GPU Intel terintegrasi, ini berjalan sangat mulus. : /
Saya menggunakan versi alfa terbaru dari Godot 3.2 di Windows 10

Saya tidak berpikir Anda dapat memperbaikinya di windows, ini tidak terjadi di linux, ini mungkin diperbaiki di 4.0 dengan perender vulkan baru.

Nah itu menyebalkan, bukankah Vulkan API hanya fokus pada perangkat kelas atas?

Saya secara khusus menargetkan OpenGL 2.0 sehingga saya dapat mendukung perangkat kelas bawah. Agak konyol menggunakan API grafis kelas atas hanya untuk game 2D dan menutup orang-orang dengan komputer / laptop kelas bawah. 😕

Kedengarannya seperti mitos. Mungkin gagap dari waktu ke waktu tidak bisa diperbaiki ATM, tapi gagap yang kita alami adalah fitur Godot saja.

Kedengarannya seperti mitos.

Apa yang Anda maksud dengan ini?

Ini adalah masalah yang menantang. Di satu sisi saya ingin secara pribadi memperbaiki ASAP ini. Tapi saya tidak bisa mereproduksi, jadi tidak ada yang bisa saya lakukan. (Saya menggunakan Windows 10 dengan kartu grafis NVidia)

Sayangnya, seseorang yang dapat mereproduksi masalah tersebut perlu mencoba memperbaikinya. :(

Meskipun ini adalah masalah yang tidak umum, tampaknya cukup umum untuk menarik banyak orang ke utas ini. Jadi semoga salah satu dari Anda dapat mengerjakan ini.

Ah, saya selalu lupa bahwa apa yang saya alami disebut jitter dalam istilah resmi dokumen Godot.

_Apakah ada yang tahu cara menangkap masalah dengan sempurna dalam 60 FPS tanpa membeli perangkat keras? _
Saya pikir beberapa orang meremehkan betapa menyebalkannya tampilannya, dan mungkin juga itu masalah yang tampak berbeda pada PC yang berbeda.

Apa yang Anda maksud dengan ini?

Mitos: "Ini selalu seperti itu di OpenGL (atau Windows, dll). Hanya Vulkan yang dapat menyelamatkan kita".

Oke, jadi:

1. ini adalah video dari OBS: https://www.youtube.com/watch?v=osbJlk1XD8c Dampak dari OBS adalah dengan menjalankan OBS saja membuat kegelisahan ini dalam proyek Godot (bahkan saat pengambilan tidak aktif).
2. Tanpa OBS itu mulus sampai saya unminize Firefox dengan shadertoy di dalamnya, kemudian mulai tersendat, tetapi tidak dapat menangkap dengan OBS, karena 1.

Memotong dalam rekaman saya sendiri, ini dilakukan dengan Bandicam dan sebagian besar adalah bagaimana kinerjanya dengan atau tanpa rekaman. Seperti yang Anda lihat, ini dimulai dengan lancar tetapi secara bertahap mulai mengalami masalah

@clayjohn Saya pikir itu akan diperbaiki dengan menerapkan interpolasi fisika, tetapi reduz menentang untuk memilikinya di inti karena beberapa alasan. Namun, sebuah metode telah ditambahkan di 3.2alpha untuk mengekspos rasio langkah fisika saat ini, yang memungkinkan untuk mengimplementasikan interpolasi fisika yang akurat secara manual.

@ starry-abyss Jika Anda dapat menggunakan 3.2alpha, cobalah add-on- smoothing- jelly: few_smiling_face:

Bayangkan saja, apakah ada sesuatu yang berguna di unreal engine atau sumber physX untuk dilihat?

Bersulang,
Victor Stan

Pada 22 Okt 2019, pukul 4:17, Hugo Locurcio [email protected] menulis:

</s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> orang </s>
@clayjohn Saya pikir itu akan diperbaiki dengan menerapkan interpolasi fisika, tetapi reduz menentang memilikinya di inti.

@ starry-abyss Jika Anda dapat menggunakan 3.2alpha, cobalah add-on-smoothing-jelly 🙂

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

@victorbstan Kita tidak boleh melihat kode sumber Unreal, karena tidak di bawah lisensi sumber terbuka. (Ia bahkan tidak mengizinkan redistribusi ke pengguna Unreal Engine yang tidak berlisensi.)

Jelas tidak mengangkat kode dari sumber tertutup, tetapi secara arsitektural Anda dapat melakukannya
tidak mendapatkan ide dari ini? [bukan pengacara]

Pada Sel, 22 Okt 2019 jam 11.07 Hugo Locurcio [email protected]
menulis:

@victorbstan https://github.com/victorbstan Kita seharusnya tidak melihat
Kode sumber Unreal, karena tidak di bawah lisensi open source. (Tidak
bahkan mengizinkan redistribusi ke pengguna Unreal Engine yang tidak berlisensi.)

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TULNUL52HS4DFVREXG43VMVBW6S4DFVREXG43VMVBW6S4DFVREXG43VMVBW4DF
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Saya tetap tidak akan merekomendasikan untuk melihat kode sumbernya. Jika Anda ingin mengambil inspirasi dari algoritme berpemilik, Anda harus melakukan rekayasa balik ruang bersih untuk mengurangi risiko hukum yang terkait.

Namun, kami tidak perlu melakukan semua ini di sini. Solusinya adalah dengan menggunakan interpolasi fisika, yang digunakan mesin game paling populer saat ini. Ini memiliki beberapa kelemahan (seperti membutuhkan pekerjaan dari pengguna untuk menghindari interpolasi saat teleportasi objek), tapi saya pikir kelebihannya jauh lebih besar daripada mereka.

Saya mengerti, sarannya adalah mendapatkan gambaran tentang kemungkinan jalan untuk menemukan solusi, tidak harus menjiplak. Saya tidak akan membayangkan ada paten untuk memecahkan masalah yang berkedip-kedip / gagap kecuali IANAL.

Bersulang,
Victor Stan

Pada 22 Okt 2019, pukul 14.07, Hugo Locurcio [email protected] menulis:

</s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> orang </s>
@victorbstan Kita tidak boleh melihat kode sumber Unreal, karena tidak di bawah lisensi sumber terbuka. (Ia bahkan tidak mengizinkan redistribusi ke pengguna Unreal Engine yang tidak berlisensi.)

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

Dalam skenario saya, profiler Godot menunjukkan 60 FPS yang sempurna, bahkan ketika saya melihat jitter / gagap. Apakah ini berarti masalah tidak terkait dengan interpolasi, atau saya melewatkan sesuatu?

Asumsi saya adalah bahwa pengaturan waktu Godot diimplementasikan dengan cara yang mengganggu pengaturan waktu kompositor Windows (dan mungkin SDL melakukannya lebih baik daripada GLFW Godot, karenanya mesin lain hanya berfungsi ketika Godot gagal).

(dan mungkin SDL melakukannya lebih baik daripada GLFW, oleh karena itu mesin lain hanya berfungsi saat Godot gagal).

Godot menggunakan kode manajemen jendelanya sendiri, ia tidak menggunakan SDL atau GLFW: few_smiling_face:

Saya memiliki Windows 10 dan nVidia GeForce GTX 1070 dan, dengan versi 3,2 alpha2 dengan vsync diaktifkan, mengalami kegugupan saat berada dalam mode berjendela. Mode layar penuh sepertinya baik-baik saja. Masalahnya sangat buruk jika editor tidak diminimalkan saat game berjalan. Game yang saya uji hanya menggunakan _process() untuk memperbarui posisi. Karena itu, saya menduga bahwa masalahnya ada pada delta sangat berisik atau bingkai yang jatuh (delta besar) tetapi bukan itu masalahnya. delta sebenarnya mantap selama jittering.

Berdasarkan penelitian orang lain di utas ini, saya meretas perubahan ke context_gl_windows.cpp untuk mengatur interval pertukaran ke 0 dan memanggil DwmFlush() dalam 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;
}

Ini didasarkan pada apa yang dilakukan proyek glfw dan Chromium .

Membuat perubahan ini tampaknya memperbaiki gangguan saat berada dalam mode berjendela. Dalam mode layar penuh, permainan telah robek sehingga DWM kemungkinan besar dinonaktifkan dan buffering ganda melalui nilai interval 1 tampaknya diperlukan. (Pada dasarnya, kode perlu melakukan apa yang dilakukannya saat ini.)

Jika ada orang lain yang mau dan bisa mencobanya maka saya akan tertarik untuk mengetahui bagaimana kelanjutannya.

Sepertinya wglSwapIntervalEXT(0); bagian sama dengan mematikan sinkronisasi-v dalam opsi.

Sepertinya wglSwapIntervalEXT (0); bagiannya sama dengan mematikan sinkronisasi-v dalam opsi.

Ini. 1 - aktifkan vsync, 0 - nonaktifkan, dan ada juga -1 untuk "adaptive vsync" (nonaktifkan sinkronisasi pada frekuensi gambar rendah, aktifkan pada frekuensi tinggi).

Saya menguji hal DwmFlush () dari atas dengan kasus sederhana saya, di cabang 3.1.x.

• Itu memperbaiki situasi dengan kasus uji shadertoy;
• V-sync on atau off - terlihat sama bagi saya (saya tidak menambal bagian wglSwapIntervalEXT ());
• Kasus OBS masih bergetar (terlihat sama menurut saya), tetapi Godot sekarang melaporkan FPS turun menjadi 40 (Saya ingin tahu apakah profiler di Godot sebenarnya terletak pada versi Godot asli);
• Saya juga mencoba memanggil DwmFlush () setelah SwapBuffers (hDC), dan semua 3 poin tetap sama.

Saya tidak yakin, tapi saya kira DwmFlush () setelah SwapBuffers (hDC) mungkin lebih benar karena Godot meletakkan bingkai di pembaruan kompositor terdekat, bukan di berikutnya, yaitu setelah terdekat.
Saya ingin tahu apakah Godot harus mendeteksi dengan lebih baik apakah kompositor sedang berjalan dan beralih kembali ke metode sinkronisasi v vanilla jika tidak.

Jadi selanjutnya untuk mencoba adalah fitur interpolasi baru yang disebutkan oleh Calinou.

PEMBARUAN: ya, dalam kasus OBS, Godot melaporkan waktu proses 0,03 detik (tetapi FPS dilaporkan sebagai 60), mungkin penghitung FPS Godot tidak memperhitungkan kehilangan v-blank setiap saat
PEMBARUAN 2: sayangnya, plugin interpolasi tampaknya tidak membantu di sini; Saya masih mengalami gangguan dalam kasus OBS dan gagap dan / atau campuran gangguan dalam kasus shadertoy

Sepertinya wglSwapIntervalEXT(0); bagian sama dengan mematikan sinkronisasi-v dalam opsi.

Benar, tetapi menambahkan DwmFlush() di swap_buffers() akan menyebabkan game menggunakan compositor (DWM) untuk sinkronisasi. Saat compositor diaktifkan, Anda secara efektif memiliki buffering ganda, baik Anda menginginkannya atau tidak. Anda akan memiliki tiga buffering jika Anda menyetel interval swap OpenGL ke 1. (Dua buffer Anda dan compositor.)

Saya juga bertanya-tanya mengapa proyek lain meminta DwmFlush() sebelum SwapBuffers() . Sepertinya mundur tapi saya hampir meyakinkan diri saya sendiri bahwa itu benar.

Dalam kasus proyek tersebut, mereka tidak menggunakan buffering ganda OpenGL (ketika kompositor diaktifkan) jadi melakukannya dengan cara ini sepertinya cara terbaik untuk menyelaraskan dengan periode kosong vertikal. Dengan interval swap OpenGL 0, panggilan ke SwapBuffers() tidak memblokir sehingga Anda mempresentasikan kompositor bingkai berikutnya segera setelah Anda tahu itu telah selesai dengan yang sekarang. Ini secara efektif memiliki efek yang sama seperti menggunakan interval swap OpenGL 1. (Ketika compositor tidak mengganggu - mode layar penuh, misalnya.)
>
>

Saya ingin tahu apakah Godot harus mendeteksi dengan lebih baik apakah kompositor sedang berjalan dan beralih kembali ke metode sinkronisasi v vanilla jika tidak.

Saya pikir Anda benar. Tampak jelas bahwa sinkronisasi-v OpenGL rusak saat kompositor diaktifkan. Jika Anda melihat kode glfw dan Chromium, mereka menyebutnya (menggunakan DwmFlush() ) sebagai HACK. Kemungkinan mereka berpikir OpenGL rusak dalam kasus ini dan harus melakukan sesuatu yang seharusnya dilakukan.

@ starry-abyss Setelah membaca ulang posting Anda tentang kasus OBS tidak berubah, saya ingin tahu apakah proyek itu telah mengaktifkan vsync. Karena Anda tidak mengubah panggilan ke wglSwapIntervalEXT() mengaktifkan vsync pada dasarnya akan menyebabkan game diblokir di DwmFlush() dan SwapBuffers() . Itu akan menjelaskan waktu proses 0,03 detik.

@TerminalJack Tidak, saya mencoba semua kombinasi. Waktu proses selalu meningkat menjadi 0,03 saat saya menjalankan OBS. Hanya saja Godot tampaknya berusaha keras untuk berada di 60 FPS, bahkan ketika itu tidak dapat mencapai beberapa bingkai ini secara berturut-turut.

Jadi saya akan membaginya dalam dua masalah:
1) Godot tidak berteman dengan pencipta lagu;
2) Godot terlalu bersemangat untuk memiliki FPS maksimal sementara itu hanya bisa memberikan 30 stabil jika di bawah beban.

Tetapi jika ada cara yang dapat diandalkan untuk (dis) membuktikan jika 0,03 adalah waktu komputasi murni dan tidak disinkronkan, saya dapat mencobanya.

@ starry-abyss Untuk tujuan pengujian, Anda dapat menggunakan Task Manager untuk meningkatkan proses 'prioritas ke' tinggi '. Ini akan menyebabkannya mendahului yang lain dan memberinya bagian terbesar dari waktu pemrosesan. Artinya, selama statusnya dapat dijalankan dan tidak diblokir di DwmFlush() dan / atau SwapBuffers() .

Saya belum memiliki banyak kesempatan untuk mengotak-atik hari ini tetapi saya mencoba menjalankan perubahan pada sistem Windows 10 yang memiliki GPU Intel UHD Graphics 620 terintegrasi. (GPU kelas bawah yang cukup.)

Saya pertama kali menjalankan game (dalam mode berjendela) dengan versi 3.2 alpha2 terbaru dan tidak ada gangguan yang terlihat. Saya kemudian menjalankan game dengan perubahan dan itu bekerja dengan baik juga.

Saya kebetulan telah mencatat delta kali selama dua kali berjalan dan saya menemukan bahwa mereka jauh lebih stabil dengan panggilan ke DwmFlush() daripada tanpa ...

3,2 alfa2

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

Uji Bangun

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)

(Delta tinggi di awal di sini disebabkan oleh fakta bahwa ini diambil tepat setelah adegan dimuat. Bangunan alfa menunjukkan perilaku yang sama.)

Perhatikan bagaimana build pengujian akhirnya diselesaikan dan mencapai kondisi mapan. Versi 3,2 alpha2 tidak pernah berhasil.

Jadi tampaknya GPU lain tidak hanya tidak akan terpengaruh oleh perubahan ini, tetapi benar-benar akan mendapat manfaat darinya. Dugaan saya adalah bahwa jitter menjadi lebih buruk karena GPU menjadi lebih kuat dan tidak tergantung pada pabrikan atau bahkan drivernya.

Saya telah membuat garpu yang memiliki satu komit yang seharusnya memperbaiki masalah ini.

Saya hanya mengujinya pada dua mesin Windows 10, jadi alangkah baiknya jika orang lain dapat membangunnya dan mengujinya pada versi Windows lainnya. Juga, saya membuatnya menggunakan VC ++ 2019, jadi jika seseorang yang menggunakan mingw dapat membangunnya maka itu akan bagus juga.

Jika Anda memiliki garpu (baru-baru ini) untuk proyek tersebut, maka Anda dapat menambal perubahan ini tanpa masalah.

Saya menggunakan Windows 10 dengan NVidia GTX 1050.

Saya tidak memiliki gagap dalam proyek contoh kecuali saya memiliki shadertoy yang terbuka dan berjalan (seperti yang dijelaskan beberapa komentar di atas).

Dengan komit @TerminalJack , gagap masih ada saat shadertoy dijalankan.

@clayjohn Terima kasih telah menguji ini. Saya ingin tahu apakah masalah dalam kasus Anda hanyalah masalah kekuatan pemrosesan.

Saya dapat menjalankan shadertoy 800 x 450 di latar belakang dan game Godot (dijalankan dari editor) di jendela di latar depan dan mendapatkan sedikit gangguan dengan perubahan yang saya buat. Sebaliknya, build alpha2 memiliki gangguan parah dalam situasi yang sama. Saya salah satu orang yang memiliki gangguan parah bahkan tanpa beban apa pun di sistem saya, jadi itu mungkin sesuatu yang perlu dipertimbangkan juga.

@Terminal Poin yang bagus. Saya menjalankan iq's rainforest shader :)

Saya pikir ada juga kemungkinan besar bahwa ada banyak masalah yang berperan di sini. Seperti yang @Calinou tunjukkan di atas, banyak pengguna yang masalah ini diperbaiki saat menggunakan fisika interpolasi juga.

Pada titik ini saya pikir Anda harus PR komit Anda, itu terlihat bagus dan membuat PR akan memberikan visibilitas lebih dan membuatnya lebih mudah bagi pengguna lain untuk membangun dan menguji.

@ clayjohn Ya, saya setuju bahwa mungkin ada masalah lain yang berperilaku serupa dengan ini.

Saya benar-benar mulai mencoba melacak masalah dengan gagap yang buruk yang terjadi setiap 60 hingga 90 detik sekali dan menemukan utas ini. (Sepertinya ada sesuatu yang memblokir proses selama 60ms hingga 100ms sesekali.) Saya menjalankan game saya dalam mode layar penuh dan tidak mengalami gangguan apa pun. Namun, setelah menemukan utas ini, saya mencoba menjalankannya di jendela dan, lihatlah: Saya salah satu yang beruntung yang dapat mereproduksi masalah khusus ini.

Saya kemungkinan akan menghapus pernyataan debugging dari perubahan saya dan mengirimkan PR dalam beberapa jam.

@TerminalJack Garpu tidak lagi tersedia (atau disetel ke pribadi), bisakah Anda membuatnya tersedia lagi?

@Calin Maaf. Saya mendongkrak repositori jadi saya menghapusnya. Saya akan bercabang lagi dan menjalankan kembali perubahan di sini segera.

@Calinou Komitmen baru ada di sini .

@TerminalJack Perbaikan Anda tampaknya hanya untuk Windows tetapi saya menghadapi masalah yang sama di Ubuntu.

@TerminalJack Perbaikan Anda tampaknya hanya untuk Windows tetapi saya menghadapi masalah yang sama di Ubuntu.

Ya, ini jelas merupakan perbaikan khusus Windows. Maaf.

Saya tidak tahu apakah perlu melakukan sesuatu yang serupa di Ubuntu atau tidak. Saya bahkan tidak yakin apakah itu menggunakan kompositor.

Saya tidak tahu apakah perlu melakukan sesuatu yang serupa di Ubuntu atau tidak. Saya bahkan tidak yakin apakah itu menggunakan kompositor.

Memang, pada kenyataannya, tidak ada cara untuk menonaktifkannya di beberapa pengelola jendela (termasuk default Ubuntu): sedikit_smiling_face:

@TerminalJack Mungkin juga memerlukan beberapa logika ketika Aero dinonaktifkan di misalnya Windows 7 (IIRC itu tidak v-sync, jadi Godot mungkin masih harus melakukan v-sync sendiri dalam kasus ini)

@ starry-abyss Saya berharap kasus itu akan tertangkap. Saya memiliki laptop lama yang memiliki Windows 7. Jika masih berfungsi, saya akan melakukan beberapa pengujian dengannya dan melihat apakah ada perubahan yang diperlukan.

Saya menyalakan laptop saya yang berusia 10 tahun yang memiliki Windows 7 dan menguji perubahan saya. Saya harus menggunakan proyek yang paling sederhana untuk pengujian. (GPU laptop sangat buruk saat itu.) Saya menggunakan proyek dari posting ini . Saya menambahkan yang berikut ini sehingga saya dapat beralih ke / keluar dari layar penuh.

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

Saya menjalankan proyek baik dengan perubahan saya maupun tanpa perubahan dan tidak ada perbedaan yang mencolok. Dengan perubahan saya, kompositor akan digunakan untuk sinkronisasi-v ketika diharapkan (mode berjendela, kompositor diaktifkan) dan buffering ganda OpenGL akan digunakan di semua kasus lainnya.

Kabar baiknya adalah tidak akan ada perubahan yang diperlukan pada _code_. Kode mendeteksi apakah kompositor diaktifkan atau tidak seperti yang seharusnya. Ia bahkan menangani kasus di mana Anda mengaktifkan atau menonaktifkan kompositor saat aplikasi berjalan. Namun, ini adalah kasus yang tidak saya duga, jadi saya tidak memasukkannya ke dalam komentar di swap_buffers() mengenai kasus-kasus di mana strategi v-sync berubah dengan cepat. Jadi itulah satu-satunya hal yang perlu saya ubah sejauh yang saya tahu.

Salah satu hal yang diangkat pada irc hari ini membahas hal ini (dan PR TerminalJack) adalah mengisolasi kesalahan dalam delta masukan yang diukur dari kesalahan di delta keluaran.

Calinou menunjukkan bahwa kita dapat menguji ini sampai batas tertentu dengan menjalankan saklar baris perintah --fixed-fps 60 . Ini akan memperlakukan input delta seolah-olah selalu 1/60 detik.

Akan sangat membantu jika mereka yang mengalami masalah (terutama di windows) dapat memberi tahu kami jika ini berdampak pada jitter.

@lawnjelly Saya mencoba dengan cepat dengan dan tanpa opsi baris perintah, tapi sayangnya saya tidak bisa melaporkan masalah hari ini%) Kecuali kasus OBS, yang masih sama.
Apakah nilai opsi yang disimpan di antara editor berjalan secara kebetulan?

Apakah nilai opsi yang disimpan di antara editor berjalan secara kebetulan?

Tidak, ini hanya argumen baris perintah (yang tidak memiliki kewarganegaraan).

BAIK. Juga, BTW, apakah opsi tersebut tersedia di Godot 3.1.1 (versi yang paling banyak saya uji di sini)?

BAIK. Juga, BTW, apakah opsi tersebut tersedia di Godot 3.1.1 (versi yang paling banyak saya uji di sini)?

Jika Anda menggunakan 3.1.1 untuk menguji ini, Anda perlu memindahkan objek dengan jarak yang sebanding dengan delta selama _process, karena tidak ada interpolasi langkah waktu yang tetap.

@ starry-abyss Argumen baris perintah itu ditambahkan di 3.1, jadi harus tersedia di 3.1.1 juga.

Jadi, --fixed-fps 60 tidak membantu saya untuk masalah ini. Dan menjalankan game dari baris perintah secara langsung juga tidak membantu (saya masih memiliki contoh editor terpisah di layar meskipun untuk mereproduksi lebih cepat).

Dan juga mencoba keduanya sekaligus, jika permintaan --fixed-fps 60 menyiratkan ini, masih gelisah.

Kesulitan untuk mereproduksi kemarin adalah karena saya menonaktifkan v-sync dalam opsi dari tes sebelumnya. : /

tidak ada interpolasi langkah waktu yang tetap.

Tentu saja, saya menguji metode satu per satu, tidak sekaligus (tidak seperti plugin interpolasi + dwmflush + ide baru).
Juga tolong lain kali sertakan langkah-langkah spesifik untuk mencoba ide baru, jadi saya tidak perlu menebak versi Godot, untuk menjalankan editor atau game secara langsung, dll. Saya tidak memiliki keinginan untuk mencoba semua kemungkinan kombinasi dari semuanya (dengan setiap ide menggandakan jumlah kombinasi). : P

Tentu saja, saya menguji metode satu per satu, tidak sekaligus (tidak seperti plugin interpolasi + dwmflush + ide baru).
Juga tolong lain kali sertakan langkah-langkah spesifik untuk mencoba ide baru, jadi saya tidak perlu menebak versi Godot, untuk menjalankan editor atau game secara langsung, dll. Saya tidak memiliki keinginan untuk mencoba semua kemungkinan kombinasi dari semuanya (dengan setiap ide menggandakan jumlah kombinasi). : P

Saya mengerti karena tidak disebutkan dalam dokumen, dan tidak ada interpolasi langkah waktu tetap dalam inti. Mungkin saya harus mencoba dan menulis sesuatu tentang ini untuk dokumen, saya belum menambahkan dokumentasi sebelumnya.

_ Hasilnya adalah ini: _
Terlepas dari masalah lain (delta, OS), jika Anda menggunakan fisika atau memindahkan objek dalam _physics_process, saat ini Godot akan memberikan jitter sebagai akibat dari aliasing antara kutu fisika dan frame sebenarnya. Hal ini akan terjadi sampai batas tertentu dalam semua kombinasi tingkat centang / tingkat penyegaran monitor fisika, beberapa akan lebih buruk daripada yang lain.

Metode 'jitter fix' adalah upaya untuk menutupi aliasing ini dengan membuatnya terjadi dengan cara yang tidak terlalu jelas (masih akan terjadi). Pikirkan aliasing tangga.

Untuk mencegah jitter 'tingkat dasar' ini, Anda saat ini perlu melakukannya
1) (Tersedia di semua versi Godot) Pindahkan objek dalam _process dan pindahkan dengan jarak yang proporsional dengan delta. Ini tidak ideal untuk game karena Anda tidak dapat menggunakan fisika, dan perilakunya bergantung pada frekuensi gambar, namun tidak masalah untuk pengujian jitter.

2) (Tersedia di Godot 3.2 dan seterusnya) Digunakan interpolasi langkah waktu tetap. Ini hanya benar-benar mungkin di 3.2 dengan fungsi Engine-> get_physics_interpolation_fraction (). Lihat https://github.com/lawnjelly/smoothing-addon untuk contoh bagaimana menggunakan ini.

Ini adalah prasyarat SEBELUM Anda mulai menyelidiki jitter. Mereka akan memberikan hubungan linier antara posisi suatu objek dan waktu, yang kita inginkan.

Metode alternatif (lebih ramah pemula) untuk mencapai hal ini adalah dengan langkah waktu semi-tetap, yang telah saya dapatkan sejak Juli # 30798.

Ini adalah dasar penyelidikan ilmiah dan pengujian hipotesis. Idenya adalah mengurangi efek perancu sebanyak mungkin dan memeriksa satu per satu.

Ada 3 faktor utama yang berperan di sini:

1) Hubungan linier antara posisi objek dan waktu dari permainan (lihat di atas)
2) Kesalahan dalam pengaturan waktu input
3) Kesalahan dalam pengaturan waktu keluaran

Hilangkan (1) seperti di atas. Hilangkan (2) dengan menggunakan argumen baris perintah, lalu Anda dapat memeriksa (3) secara terpisah.

Selain itu, untuk penyelidikan jitter apa pun, Anda harus memindahkan objek secara langsung, bukan melalui fisika, karena fisika berpotensi menambah jitter itu sendiri.

_Edit: _
Saya baru saja melihat proyek repro minimum di utas ini (menghindari creep) dan bergerak dengan kecepatan * delta di _process, yang seharusnya baik-baik saja. Itu bergantung pada is_action_pressed dan secara pribadi saya akan menghapusnya sebagai masalah yang mungkin, tetapi mungkin baik-baik saja. Jika menggunakan proyek lain untuk menguji jitter, berhati-hatilah dengan poin-poin di atas.

@lawnelly begitu. Saya mendapat kesan bahwa plugin interpolasi masih juga sesuatu yang hanya diuji oleh beberapa orang, dan mungkin buggy (dan bahkan menambah jitter). Jadi saya mengambil apa yang stabil (3.1.1), itulah cara "ilmiah" bekerja untuk saya.
Saya akan mencoba dengan pertimbangan baru lain kali.

Saya baru saja melihat proyek repro minimum di utas ini

Saya menggunakan versi saya sendiri dari proyek ini, karena yang asli menggunakan animasi (dapat menutupi jitter) dan memiliki sprite abu-abu di atas latar belakang abu-abu. Saya akan menyesuaikannya agar memenuhi kriteria Anda.

Jadi, --fixed-fps 60 tidak membantu saya untuk masalah ini.

Itu adalah info yang sangat berguna. Hal ini tampaknya menggerakkan jari telunjuk menyalahkan ke arah penundaan keluaran (dan kompositor), dan memberi bobot pada jenis pendekatan dalam PR. Ini mengasumsikannya menggunakan buffering ganda / tripel dan menjaga agar pipa tetap diumpankan, dan tidak menjatuhkan bingkai.

Apakah ini juga kasus @TerminalJack dengan argumen baris perintah?

Saya menggunakan proyek saya sendiri, karena yang asli menggunakan animasi (dapat menutupi jitter) dan memiliki sprite abu-abu di atas latar belakang abu-abu. Saya akan menyesuaikannya agar memenuhi kriteria Anda.

Ah bagus, terima kasih! : +1:

@lawnelly begitu. Saya mendapat kesan bahwa plugin interpolasi masih juga sesuatu yang hanya diuji oleh beberapa orang, dan mungkin buggy (dan bahkan menambah jitter).

Sedikit keluar dari topik, tetapi seharusnya baik-baik saja (saya belum menyentuhnya dalam beberapa minggu), seharusnya tidak menimbulkan gangguan. Jika Anda menemukan bug, beri tahu saya di pelacak masalah atau bahkan buat PR. : +1: Saya bermaksud untuk meletakkannya di addons resmi untuk 3.2 _ketika saya menggunakannya_: smile:.

@rumahguguk

Apakah ini juga kasus @TerminalJack dengan argumen baris perintah?

Maaf, saya belum sempat mencoba saran Anda. Saya agak bingung tentang masalah yang sedang saya tangani.

@lawnjelly Berdasarkan diskusi kita di utas PR, saya hanya berpikir bahwa saya akan menyebutkan bahwa Anda benar tentang opsi baris perintah --fixed-fps <fps> . Itu, pada kenyataannya, tetap mengaktifkan vsync. Jadi, seperti yang Anda katakan, menggunakannya adalah cara yang baik untuk memfaktorkan masalah apa pun dengan penghitungan delta. Saya pasti kacau ketika saya mencobanya sebelumnya dan saya menjadi gagap karena bukan itu masalahnya sekarang.

Saya telah menggunakan opsi itu bersama dengan perubahan saya untuk menetapkan bahwa menggunakan DwmFlush() memang membantu saat menjalankan di luar editor. Jika Anda menonaktifkan DwmFlush() maka Anda dapat menyebabkan gagap dalam game hanya dengan menyeret beberapa jendela lain atau mengarahkan mouse ke salah satu tugas yang sedang berjalan di bilah tugas. Jelas, karena game berjalan pada prioritas 'Di Atas Normal', ini seharusnya tidak terjadi. (Dan tidak jika DwmFlush() digunakan.)