Godot: مشكلة التلعثم الشديد في لعبة بسيطة ثنائية الأبعاد [Windows 10 ، Nvidia]

مرحبًا ، لقد قمت بتحديث تقريري لأنني اختبرته على جهاز الكمبيوتر الآخر (المنزل) والمشكلة هنا في نفس الوقت الذي أغير فيه الرسوم المتحركة. إذن ، هذه ليست الرسوم المتحركة التي تسبب المشكلة. أعتقد أنني صدقت ذلك لأنه عندما رأيت أنه كان على جهاز الكمبيوتر المحمول ، فإنه يحتوي على شاشة صغيرة. إليك مقطع فيديو للمشكلة (الفيديو 60 إطارًا في الثانية):
GodotStutter.zip

إذا كان الفيديو يمثل تمثيلًا دقيقًا لما هو معروض على الشاشة في الوقت الفعلي ، فهو إذن تلعثم أكثر بكثير مما رأيته في أي مشكلة متعلقة بالتلعثم هنا يجب أن يكون هناك خطأ خطير في إعداد Windows 10 / GTX 1060 (أرى عددًا قليلاً من المقالات حول الإنترنت توضح بالتفصيل مشكلة الأداء على Windows 10 / Nvidia بعد تحديثات Windows الرئيسية ، ولكن لا يمكنني معرفة ما إذا كانت مرتبطة).

إليك مقطع فيديو لمشروع الاختبار على نظامي ، Mageia 6 x86_64 (Linux) ، Nvidia GTX 670MX مع برامج تشغيل خاصة حديثة (390.59). لا تلعثم على الإطلاق (في Openbox - على KWin ، يقوم الملحن بعبث الأشياء وهناك تلعثم خفيف جدًا كل 10 ثوانٍ أو نحو ذلك).
StutterTest_LinuxNvidia_OK.zip

راجع للشغل هنا نسخة ثابتة من المشروع التجريبي firstGame_fixed.zip ،

اللعبة تعطيني نفس القدر من التأتأة كما في الفيديو.
ومع ذلك ، يؤدي إيقاف تشغيل vsync إلى التخلص من التأتأة تمامًا (لكن اللعبة تعمل بسرعة 4000 إطارًا في الثانية).
Windows 10 64 بت nVidia GTX 1060 هنا أيضًا.

لقد اختبرت أيضًا كما اقترح Zylann هنا وحصلت على نفس النتائج. لديّ أيضًا Win10 x64 و nVidia GTX 1060.

تحرير: أستخدم برامج التشغيل هذه من nVidia:
398.11-desktop-win10-64bit-international-whql

تم اختبار Win 7 64 بت GLES2 و GLES3 ، GeForce GTX 660 / PCIe / SSE2 ... بدون تقطع. عند تشغيل Aero ، مع وجود محرر 2d لـ godot خلف اللعبة ، ينتج عنه بعض التلعثم (يتداخل محرر Godot مع عرض اللعبة).

ومع ذلك ، فإن تلعثم جودو هو العدو العملاق غير المرئي ، نعلم جميعًا أنه موجود ولكننا لا نريد أن ننظر عن كثب لأننا نعلم أن الحل ليس بسيطًا.

تبدو مشكلتك وكأنها فيزياء مختلفة ثابتة في الثانية مع معدل تحديث الشاشة ، أرى هذا النوع من التلعثم في الشاشات التي ليس لها نفس هرتز الذي قام المحرر بتكوين إطار في الثانية له ، ولكن يمكن أن يكون شيئًا آخر.

تبدو مشكلتك وكأنها فيزياء مختلفة ثابتة إطارات في الثانية مع معدل تحديث الشاشة

لا يستخدم العرض التوضيحي الفيزياء ، فقط _process بسيط.

صحيح ... أقول إنني لا أرى سوى التلعثم الشديد في هذه الحالة ، لكن من الصحيح أنه لا توجد عملية فيزيائية. أختبر تغيير هرتز لأحد الشاشات ولا توجد اختلافات ، 0 تلعثم في معداتي.

تحرير: لقد حصلت على فوز 7 ، وفوز 8.1 ، وفزت 10 في هذا الكمبيوتر واستغرق الوقت لاختبار الكل. لا تتلعثم في الفوز 8.1. أنا أختبر في win 10 الآن وهو سلس للغاية ... لا توجد مشكلة في windows. جودو غاضب من 1060 الخاص بك؟

إليك نفس الاختبار مع جهاز الكمبيوتر المحمول الخاص بي. كما ترى المشكلة هنا أيضًا. لكن يبدو أن هذا أقل وضوحًا ولكنه موجود هنا.

مواصفات الكمبيوتر المحمول: Windows 10 - Geforce 940M

إليك فيديو الكمبيوتر المحمول (فيديو 60 إطارًا في الثانية):
GodotStutterLap.zip

هل يمكن لأي شخص يعاني من مشكلة التأتأة محاولة تنفيذ العرض التوضيحي المتغير في Player.gd _process with _physics_process؟

سأختبر هذا المساء على جهاز الكمبيوتر المنزلي الخاص بي ، وهذا هو المكان الذي أواجه فيه المشكلة طوال الوقت. لكن لدي شيء غريب: هذا الصباح ، أعطيتك مقطع فيديو مع المشروع على جهاز الكمبيوتر المحمول الخاص بي وكما ترون لديك نفس نوع التلعثم. المشكلة الآن ، إذا قمت بتشغيله مرة أخرى ، فلن أعاني من هذا التلعثم مرة أخرى ، كما لو كان عشوائيًا. ولم أغير أي شيء على الكمبيوتر المحمول الخاص بي ، لقد عملت عليه طوال الصباح في جلسة TSE.

تحذير: أنا أتحدث فقط من أجل جهاز الكمبيوتر المحمول الخاص بي. على جهاز الكمبيوتر المنزلي الخاص بي مع GTX 1060 ، المشكلة دائمًا هنا. ولكن يبدو أن المشكلة تحدث بشكل عشوائي على جهاز الكمبيوتر المحمول. لهذا السبب أعتقد أنه في الوقت الحالي ، سأترك الكمبيوتر المحمول الخاص بي على الجانب لغرض الاختبار وسأختبر فقط على جهاز الكمبيوتر المنزلي الذي يعاني من المشكلة طوال الوقت ، حتى أتمكن من عزل "الخطأ".

Ranoller اختبرت ذلك وحصلت على نفس النتيجة. لا يزال التلعثم موجودًا ويبدو إلى حد كبير كما هو.

Ranoller صنع الاختبار ونفس àRaXaR الذي لا يغير أي شيء. حصلت على نفس المشكلة.

هذا لا يبدو جيدا ....

لتحديد الخطأ بالضبط ، سأجري هذه الاختبارات:

1) ملء الشاشة على - إيقاف
2) إذا كان هناك أكثر من شاشة واحدة:
تعطيل- تمكين سطح المكتب المشترك
3) Aero on-off

بطاقاتك تعمل بشكل جيد مع ألعاب أخرى؟ ...

قراءة المنشور الأول حول الرسوم المتحركة -> تلعثم / عدم وجود رسوم متحركة -> لا تلعثم قرأت الكود وأرى بعض الأشياء التي لا أعتقد أنها صحيحة ... بالضبط: تغيير الرسوم المتحركة في كل إطار. أعتقد أن هذا الرمز يجب أن يتحقق من الرسوم المتحركة الحالية. ربما لم يغير شيئًا ، ولكن إذا أراد شخص ما اختبار لتغيير Player.gd بهذه الطريقة:

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)

هذه هي الفكرة الأخيرة ... ربما لا معنى للمشكلة ، لكن ... بطاقة الرسوم الخاصة بك شائعة جدًا في اللاعبين ، لذا يجب أن ينفذ جودو جيدًا فيها.

تضمين التغريدة

إلى عن على :

• النقطة الأولى: حاولت بالفعل ملء الشاشة أم لا ، فهي لا تغير أي شيء

• 2: حاولت بالفعل تشغيل جهاز عرض واحد فقط (هذا هو التكوين الشائع الخاص بي ولكن لدي شاشة ثانية أيضًا في بعض الأحيان ، لذلك حاولت كليهما) ولا يغير أي شيء.

• 3: لا بد لي من الاختبار (يجب أن أكون قادرًا على القيام بذلك ، هذا المساء (بتوقيت فرنسا).

• 4: لا بد لي من اختبار الكود الخاص بك (يجب أن أكون قادرًا على القيام بذلك ، هذا المساء (بتوقيت فرنسا).

فقط اختبرت الكود الخاص بك ولم يغير شيئًا :(

على الرغم من أن هذه المشكلة قد لا تكون مرتبطة مباشرة بـ godot ، إلا أن godot يجب أن يراجع مشكلات التأتأة جيدًا ... ليس صحيحًا أن جميع الألعاب تتعثر كما قيل في موضوع آخر. اليوم كنت ألعب n ++ ، ملء الشاشة ، في إطارات ، أحاول رؤية أي تلعثم ولا .... لا تتلعثم على الإطلاق. كما هو الحال مع أوري والغابة العمياء ، بالنسبة للعديد من الأشياء السيئة التي يجب القيام بها للحصول على أي تلعثم في هذه اللعبة (إطارات مع برامج أخرى في الخلفية ، وما إلى ذلك .... وتخطي 2 × 3 إطارات فقط في ساعة ...) Godot ، عند بدء التنفيذ ، يتلعثم دائمًا بعدد x من الثواني ، ثم يستقر بعد ذلك ، ولكن كل X ثانية ستواجه تخطي الإطارات (إذا لم تكن لديك مشكلة gtx1060 بالطبع). لا ينبغي أن نتعامل مع هذه المسألة على أنها مشكلة صغيرة.

أحاول أن أبذل قصارى جهدي لعزل المشكلة ولكن على مستواي الأمر صعب بعض الشيء. حاولت اختبار إعدادات مختلفة ولكن بدون نتيجة. لقد اختبرت أيضًا صورة خلفية بدلاً من استخدام لون مع شاشة واضحة. لقد رأيت بالفعل (لا تتذكر الساحرة) محركًا بهذه المشكلة بسبب عرض كائن ثنائي الأبعاد على "شاشة فارغة" يسبب هذه المشكلة ، ولكن يبدو أن هذا ليس هو الحال هنا. لذلك ليس لدي أي فكرة في الوقت الحالي.

بدافع الفضول ، حاول تحديد المدة التي يستغرقها SwapBuffers في context_gl_win.cpp حول السطر 68. إذا استغرق الأمر وقتًا أطول من 16 مللي ثانية ، فمن المحتمل أن تسقط إطارًا هنا.

إذا كان هناك شخص يعرف مصادر Godot يمكنه اختبار أنني مثير للاهتمام في النتيجة (آسف لغتي الإنجليزية ...)

كنت ألعب بهذه المشكلة بالأمس وقمت بحل نفسها بطريقة سحرية بعد أن كانت نوافذ اللعبة تعمل لمدة 60 ثانية. ثم كان الأمر سلسًا ، وهذا يخبرني أنه يمكن أن يكون شيئًا للتخزين المؤقت؟

بدافع الفضول ، حاول تحديد المدة التي تستغرقها SwapBuffers في Context_gl_win.cpp حول السطر 68. إذا استغرق الأمر وقتًا أطول من 16 مللي ثانية ، فمن المحتمل أن تسقط إطارًا هنا.

قد يكون من المفيد معرفة ما إذا كانت المشكلة قد حدثت في GLES2 ، فنحن لا نختبر ذلك

حاولت أن ألعب بالخيارات في Godot حول هذا الموضوع ، لكنها لا تغير شيئًا بالنسبة لي ، فربما لا أعرف بالضبط ما الذي يجب تغييره؟

حاولت ترك اللعبة لأكثر من دقيقتين ولكن المشكلة دائمًا لم تحل بالنسبة لي بعد 60 ثانية.

لدي مشكلة مماثلة مع 3.0.3. (Win10 64 bit، Nvidia 660) لم ألاحظه مع 3.0.2.

أعتقد أن الأمر يتعلق بعقد AnimatedSprite لأنني أرى مشكلات الأداء مع المستويات التي تحتوي على هذه العقدة. أحصل على الإغلاق عند التشغيل من IDE أو إذا قمت بالتصدير إلى Win 32bit ، ولكن إذا قمت بالتصدير إلى Win 64bit ، فسيتم تشغيل كل شيء كما ينبغي ، فلا تأتأة.

.. من المثير للاهتمام ، ليس لدي مشكلة مع مثال المشروع "FirstGame.zip" ... ولكن ما زلت أفعل ذلك مع لعبتي ، تنخفض FPS إلى 5 عند تشغيلها من إصدار IDE و 32 بت ، ويوجد GPU حوالي 2٪ .. . ولكن ، مع 64 بت للتصدير GPU 30٪ وكل شيء على ما يرام.

مرحبًا ، هل هناك أي أخبار عن هذه المشكلة؟ لقد اختبرت للتو مع pong demo (لم أفعل ذلك من قبل ، فقط مع اللعبة التعليمية) ويبدو أن المشكلة هنا في نموذج المشروع هذا أيضًا. أستخدم الإصدار الأخير من Godot على Steam لاختباره.

لم يغير تحديث برامج تشغيل Nvidia أي شيء ، لذلك جئت لأخذ بعض الأخبار حول هذه المشكلة. لم أجد كيفية التخلص منه بعد.

لدي الآن جهاز كمبيوتر به بطاقة geforce gtx 1060 (3 جيجابايت رخيصة) ولا توجد مشكلة في نظام التشغيل windows 10 home. يمكن أن يكون بعض التطبيقات الخلفية؟ بعض التكوين الخاص بالأجهزة AMD-Nvidia Intel-Nvidia ....؟ ليس لدي أي تطبيق للعبة على هذا الكمبيوتر (موجود في أستوديو تسجيل الموسيقى الخاص بي) ولكن برنامج Godot يعمل بسلاسة حتى مع وجود 3 شاشات متصلة بالكمبيوتر. يمكن لأي شخص لديه مشكلة التحقق مما إذا كان لديه أي برنامج لمراقبة الألعاب يعمل في الخلفية ، أو بخار ، أو شيء من هذا القبيل ...؟ وإذا حصلت عليه حاول أن تشوه؟

من الصعب إيقاف تشغيل Steam عند استخدامه لإطلاق Godot ... يعمل Godot بشكل رائع المشكلة هي اللعبة التي تصنعها. لقد حاولت بالفعل تعطيل كل ما يمكنني تعطيله ، ولا يغير شيئًا. لقد أجريت الكثير من الاختبارات دون نجاح. حاولت أيضًا إعادة تعيين برامج تشغيل nvidia على سبيل المثال ، وتحديثها وما إلى ذلك ... لكنها لا تغير شيئًا.

على الجانب الآخر ، لدي مجموعة من المحركات تعمل بسلاسة ، فلماذا لا يوجد جودو؟ هذا هو الشيء الذي حاولت أن أجده. لكن في الوقت الحالي لا أجد شيئًا. يوجد شيء في مكان ما ولكن ماذا وأين ، هذا هو السؤال :-)

هذه المشكلة "خاصة بالمحرك" بدرجة لا يمكن معها العثور على حل مقبول من خلال البحث الخاص. يمكنني البحث لساعات عن كود godot وأنا أعلم أنه لن يكون هناك أي إمكانية للعثور على شيء متعلق بهذا ... أعلم أن مطوري المحرك مثل المزيد من الوظائف الجديدة للشفرة و "إصلاح الأخطاء" يعتبر أكثر "عمل مبتدئ "أو شيء من هذا القبيل. ولكن مع هذا النوع من القضايا ليس هو الحال. نحتاج إلى بعض مطوري المحركات لتعيين هذه المشكلة تلقائيًا وغيرها من إصلاحات الأخطاء "المعقدة - الأشباح - المنخفضة المستوى - التي يصعب تحملها" ...

أذكر أنني جربت بالفعل إصدار dev (بدون Steam) والمشكلة هي نفسها.

مرحبًا ، كان لدي نفس مشكلة التلعثم (باستخدام Godot 3.1 من مصدر Git) ، أي حركة تأخرت بالنسبة لي ، تمامًا كما هو الحال في الفيديو الخاص بك ، سواء كان ذلك تحريكًا أو انزلاقًا أو مجرد حركة لاعب متحرك لكن تشغيل V-Sync في إعداد المشروع أدى إلى حل مشكلة التلعثم في اللعبة ثنائية الأبعاد تمامًا.

أنا في حيرة من أمري لأن

قامQws بإيقاف تشغيله وتشغيل اللعبة بأكثر من 60 إطارًا في الثانية (وهو ما حدث في ذلك الوقت) مما أدى إلى اختفاء التلعثم بالنسبة لي ولكنه يجلب مشكلات أخرى (باستخدام كل الطاقة المتاحة وجعل كل شيء لا يستخدم دلتا مناسبة زمن). إذا كان لديك تلعثم مع إيقاف تشغيل V-sync ، فهذا إما بسبب وقت دلتا غير مناسب أو موقف حيث يتعين على اللعبة الانتظار / المعالجة لفترة أطول من الإطار لتحديث الشاشة.

الاختبار الأول الذي قمت به مع gtx 1060 الجديد لا يعطي أي مشكلة ... لكن لاحقًا واجهت هذا التلعثم. الشيء الوحيد الذي قمت بتغييره هو dvi إلى اقتران hdmi (وبعض البرامج مثبتة) ... هذا غريب بعض الشيء. الشيء الوحيد الذي أقنعته هو أن المشكلة ليست في جانب windows 10.

سأقول هذا كثيرا. أنا أعمل على برنامج تعليمي للعبة ثنائية الأبعاد "Hoppy Days" من دروس Gamedev.tv التعليمية. كنت أستخدم 3.0.2 لتطويره ، وكان يعمل بشكل جيد. لقد لاحظت أن البرنامج التعليمي كان يستخدم 3.0.4 ، لذلك قررت اليوم حرفياً الترقية إلى 3.0.6. يوجد الآن تأخر ملحوظ في اللعبة. _ لم يكن التأخير موجودًا على الإطلاق في 3.0.2_ . إنه هناك الآن. جميع الإعدادات الأخرى هي نفسها.

جهاز الكمبيوتر المحمول هو جهاز كمبيوتر محمول جديد إلى حد ما (تم شراؤه في مارس 2017) من سلسلة Dell Inspiron 7000. المعالج هو الجيل السابع Intel Core i7-7700HQ رباعي النواة (ذاكرة تخزين مؤقت سعة 6 ميجابايت ، تصل إلى 3.8 جيجاهرتز). بطاقة الفيديو هي NVIDIA GeForce GTX 1050Ti مع 4GB GDDR5. ذاكرة الوصول العشوائي 16 جيجابايت ، 2400 ميجاهرتز ، DDR4. القرص الصلب هو Samsung SSD. نظام التشغيل Windows 10.

بالنسبة لي ، يبدو أن شيئًا ما تغير إما في 3.0.4 أو 3.0.6 ..... لم يتغير شيء آخر على الإطلاق. ولا حتى اللعبة (كما في ... لم أقم بتغيير / تحرير / تحديث المستوى على الإطلاق).

@ emo10001 هل يمكنك اختبار 3.0.3؟ هذا عندما قمنا بتغيير نظام البناء المستخدم لإنشاء ثنائيات 3.0.x (3.0 حتى 3.0.2 تم بناؤها على AppVeyor CI مع MSVC 2015 ، 3.0.3 حتى 3.0.6 تم بناؤها مع GCC 8 عبر MinGW).

إذا كان الكمبيوتر المحمول الخاص بك يحتوي على Optimus / رسومات قابلة للتحويل ، فقد يكون نظامك قد وضع في القائمة البيضاء الملف الثنائي 3.0.2 ليتم استخدامه مع Nvidia GPU ، بينما 3.0.3+ سيكون افتراضيًا على IGP. أو يمكن أن يكون 3.0.2 مدرجًا في القائمة البيضاء بواسطة برنامج مكافحة الفيروسات الخاص بك بينما يُنظر إلى الإصدار 3.0.3+ على أنه قادم من مصدر مختلف (وهذا صحيح) ولم يتم اعتباره آمنًا بعد ، لذلك سيقوم برنامج مكافحة الفيروسات بإجراء فحوصات كاملة ويؤثر على الأداء.
هذه مجرد تخمينات ، لكن على خلاف ذلك ، لست متأكدًا من تأثير تغيير Godot الفعلي على أداء مثل هذا ، لذلك لا يمكنني التفكير إلا في تغييرات بناء النظام.

سيسي hpvb

انا لدى نفس المشكله! يتعطل مشروعي لمدة 20 إلى 30 ثانية ، ثم يعمل بسلاسة بعد ذلك. لقد قمت بتنزيل المشروع في منشور OP وهو نفس الشيء بالضبط.
يؤدي إيقاف تشغيل V-Sync إلى إزالة المشكلة ، ويتم تشغيله بسرعة 4000+ إطارًا في الثانية.

أنا أقوم بتشغيل الإصدار 3.0.6 على Linux Mint 19 (لذا أعتقد أن علامة windows غير دقيقة ، أليس كذلك؟) و GTX 760 مع أحدث برامج التشغيل الخاصة.

أنا أقوم بتشغيل الإصدار 3.0.6 على Linux Mint 19 (لذا أعتقد أن علامة windows غير دقيقة ، أليس كذلك؟) و GTX 760 مع أحدث برامج التشغيل الخاصة.

لا ، ولكن من المحتمل أن تكون هذه مشكلة مختلفة. غالبًا ما يحدث التأتأة على نظام Linux بسبب تكوين مدير النوافذ (على سبيل المثال ، لدي البعض مع KWin ، ولا شيء مع Openbox).

يتعطل مشروعي لمدة 20 إلى 30 ثانية ، ثم يعمل بسلاسة بعد ذلك

لقد لاحظت هذا كثيرًا ، إذا قمت بتنفيذ المشهد الذي أقوم بتحريره ، فهناك تقطع وبعض التمزق (مع تشغيل vsync) حوالي 15-30 ثانية ، ولكن إذا بدأت المشروع من القائمة الرئيسية وفتحت المشهد باستخدام محدد المشاهد ... حسنًا ، لا يوجد تلعثم في نفس المشهد (يوجد في النهاية ، ولكن ليس أبدًا). هناك بعض الشرح حول هذا الحدث؟ جودو؟ شبابيك؟ كم عدد الإطارات اللازمة لتحقيق الاستقرار في التكاثر؟ ... سيكون من الرائع معرفة هذه الأشياء لأن هناك ضرورة لتصميم اللعبة.

لا ، ولكن من المحتمل أن تكون هذه مشكلة مختلفة.

هم أرى. ما قصدته هو أن هذه المشكلة المحددة ربما تكون متعددة الأنظمة الأساسية لأن العديد من الأشخاص يواجهون نفس المشكلات.

لقد كنت العبث ولاحظت أن جسمين حركيين يتلعثمان تمامًا في نفس الوقت ، لكل من move_and_slide () و move_and_collide ().

ربط الكاميرا بأحدهما أثناء تأرجحهما ، كل شيء في المشهد يتلعثم باستثناء العقدتين الحركيتين. تظهر الكاميرا الثابتة فقط تلعثم العقدتين الحركية.

لا يبدو أنه يهم ما هي إعدادات الرسوم التي أغيرها ، ولا العملية أو العملية الفيزيائية. ولا استخدام متغير دلتا مختلف.

أعتقد أن هذا المشروع لا يمثل الاستخدام الحقيقي ... المشاريع الأكثر تعقيدًا تعمل بسلاسة بعض الشيء. أعتقد أن النوافذ لا تتعامل بشكل جيد مع وقت خمول كبير للغاية من godot ... لقد وجدت مشكلة أخرى ذات صلة ، ليس فقط من أجل godot ولكنها تعاني كثيرًا من ذلك: في الشاشات المتعددة مع لعبة سطح المكتب الممتدة يكون أكثر سلاسة في الشاشة 1 إذا كان هذا مرتب مثل "جهاز العرض الأساسي". إذا كان جهاز العرض الأساسي غير ذلك 1 ، فهناك تلعثم في الشاشة الثانوية (يعاني YouTube من ذلك ، ولكن ليس الألعاب التجارية الموحدة مثل ori). مع الشاشة الكاملة في الشاشة الثانوية ، و aero في win 7 ، والشاشات التي تم تبديلها (ej: monitor 2 مثل الأساسي) ، يكون المشهد هو الأسوأ وهناك تلعثم كبير (ليس فقط godot ، ولكن ليس صانع الألعاب أو ألعاب الوحدة) ... .أعلم أن الشاشات المتعددة مع سطح المكتب الممتد بشاشتي 1080 بكسل أمر صعب بالنسبة لوحدات معالجة الرسومات الرخيصة ولكن الألعاب الأخرى أكثر سلاسة (لا تفقد godot fps ، بل تلعثم فقط). إذا استمر هذا الاختبار ، فيجب أن نقدم مثالًا أكثر تعقيدًا.

Ranoller إعدادي هو شاشة مزدوجة في gtx 760 ، جهاز العرض الثاني الموسوم بـ "أساسي" ، linux mint 19 مع القرفة. كنت أحاول فهم الحالة المحددة التي تعثر فيها المشروع ، لكنني لم أستطع معرفة ذلك. تتلعثم هذه المشاريع الصغيرة أحيانًا ، وأحيانًا لا تتلعثم (تتلعثم فقط ، ولا توجد خسارة في الثانية) أيضًا ، عندما تتلعثم (تعمل في تكوينات اختبار godot ذات النوافذ) ، عادةً ما يكون لدي واحد أو أكثر من نوافذ الكروم في الشاشة الثانية (وليس الأساسي) ، وعندما أقوم بتصغيرها ، تختفي التلعثم ... بعد بعض التصغير / استعادة على نوافذ الكروم ، والتلعثم ذهب تماما.

لقد حصلت على جهازي كمبيوتر -> أحدهما مزود بشاشة i5 gtx660 وشاشتين 1080 بكسل والآخر مزود بشاشات i7 gtx 1060 3 (2 1080 بكسل وغيرها من الأجهزة عالية الدقة) ... حسنًا ، لدي مشكلة التلعثم المتعلقة بالشاشات الثانوية في gtx660 ، أعتقد ذلك مرتبط بشكل حصري بالتصيير والتلعثم والكروم وصانع الألعاب والوحدة لا (الألعاب التجارية ، HiperLightDrifter و Ori بالضبط ، لم أختبر العروض التوضيحية أو القوالب). يتأرجح Windows aero بشكل أكبر في وضع ملء الشاشة (أعتقد أنه ليس ملء الشاشة حقًا) ولكن لديه الكثير من الإطارات في الثانية ، بدون aero في الفوز 7 ، لقد حصلت في مشروعي على 130-140 إطارًا في الثانية بدون vsync ، مع aero i تمرير 400 إطارًا في الثانية ، لكن. .. التعتعة (كثيرا) في ظروف معينة (مع وبدون vsync). لا أستطيع أن أتسبب في تلعثم جودو في i7 gtx 1060 (مع مشروع حقيقي ، يتلعثم العرض التوضيحي في هذا الخيط وأشرح له رأيي بشأنه). أعتقد أنها مشكلة في التحسين / OpenGL ، ej: Light2D غير قابل للاستخدام ، أي وضع مزيج آخر غير "mix" يمكن أن يتلعثم إذا لم يكن النظام قويًا للغاية ، ولكن يجب أن يتعامل godot مع الثبات بنفس المستوى الذي يفعله صانع اللعبة أو الوحدة. ربما بمجرد إطلاق الإصدار 3.1 ، يمكن أن يبدأ العمل على التحسين (إذا كانت المشكلة قابلة للإصلاح ولم تكن مشكلة Direct3D / OpenGL - بالطبع مشكلة Windows ... لا أعرف كيفية العثور على ألعاب GLES2 / 3 في Windows للاختبار والتجاهل مشكلة OpenGL - Aero / Win7-8-10 مباشرة) ... أفهم أن ثبات godot لن يكون أبدًا كما هو الحال في propietary -> محركات تعتمد على لعبة واحدة (Ej: أصول Rayman تعمل بسلاسة في كمبيوتر محمول قديم لدي ، godot 2 don´t) ، ولكن يجب أن تقدم على الأقل نفس المستوى المستقر الذي قدمه صانع الألعاب (من المحتمل أن تكون الوحدة أفضل من ذلك godot لفترة طويلة ، كما تعلمون ، المال ...). في الوقت الحالي ، أشعر أن أداء godot جيد فقط في الأجهزة المتطورة أو في الشاشات منخفضة الدقة (أختبر في كمبيوتر رسومات Intel i5 win7 32bit 15 بوصة وأداء جيد ، لكنني لا أعتقد أنه مع شاشة عالية الدقة فإن هذا الكمبيوتر سيفعل تشغيل godot بسلاسة) ...

بالطبع كل هذا هو آرائي / خبراتي ، يمكن أن أكون مخطئًا (وآمل أن أكون .. إذا كان هذا إصلاحًا بسيطًا من سطر واحد ، فقد يكون هذا رائعًا !!!)

من ناحية أخرى ، أتذكر قراءة كتابة reduz لشيء متعلق بـ "أولوية العملية" في ملف godot القابل للتنفيذ ، ولكن في النوافذ لا يوجد فرق إذا قمت بتغيير أولوية godot يدويًا في التنفيذ ، فإن godot لا يكون أقل من أداء اخترع كلمة؟) ، تنفيذ البرنامج لا يحتوي على مسامير ، إنه العرض ، شيء مرتبط بـ nvidia / godot وسطح مكتب الكمبيوتر (في windows ، لا أحاول في Linux)

مرحبًا ، هل هناك أي أخبار عن هذه المشكلة؟ ^^ سأختبر مرة أخرى باستخدام أحدث إصدار ولكن يبدو أن المشكلة لا تزال قائمة.

هل هذا الخروج في نظام android أو ios الأساسي الآن？ هناك بعض الألعاب في متجر Google تم إنشاؤها بواسطة godot المبكر والتي بها أيضًا مشكلة في الغالق. مثل: https://play.google.com/store/apps/details؟ .DunkUp

يوجد هذا في جميع الأنظمة الأساسية التي تم اختبارها في ظروف معينة ، مع وحدات معالجة رسومات متنوعة وأنظمة تشغيل متنوعة ... لم يتم توثيقها في وحدات التحكم.

لقد اختبرت ذلك على كل من لينكس وويندوز وعمل بسلاسة مع التأتأة الصغيرة في المناسبات ، لدي بطاقة رسومات baytrail عالية الدقة متكاملة من Intel

بعد عدة ساعات من محاولة اكتشاف سبب التأتأة ، في حالتي على الأقل ، تتبعتُ بالصدفة التلعثم المتسق للثانية حتى يتم تمكين "التبديل التلقائي إلى شجرة المشهد البعيد" في "إعدادات المحرر". يؤدي إلغاء تحديد هذا إلى حل مشكلات التلعثم والأداء بالنسبة لي. (ربما لا يزال هناك تلعثم طفيف جدًا ، لكنه بالكاد ملحوظ).

بناء Godot 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit ، NVIDIA GeForce GTX 660 ، برنامج التشغيل v416.81

لدي أيضًا مشكلة التأتأة في لعبتي. الشيء الوحيد الذي يبدو أنه يجعل الأمر أفضل هو إيقاف تشغيل الشاشة الكاملة وتشغيلها أثناء تشغيل اللعبة ... وحتى مع ذلك ، هناك تلعثم طفيف يزحف بعد ذلك. يبدو أنه يحدث بشكل عشوائي. في بعض الأحيان ، تقترب اللعبة من الكمال ، وفي أحيان أخرى يحدث التأتأة.

مشروع ثنائي الأبعاد مع شخصيات حركية.
وحدة المعالجة المركزية Intel i5-2550K
16 جيجا رام
Geforce GTX 970
Win10 64 بت
جودو 3.0،6

في فوز 10 تتلعثم يحدث أكثر في وضع ملء الشاشة ، وذلك بسبب Aero (ويمكن تعطيله). يبدو أن Godot يستخدم وحدة معالجة مركزية أقل والمزيد من GPU مع windows Aero ولكن هذا يؤدي إلى مزيد من التأتأة. في Windows 7 ، تعطيل windows Aero ، يكون ملء الشاشة أقل تلعثمًا في الإطارات ويستخدم المزيد من وحدة المعالجة المركزية. أعتقد أن الفوز 10 لا يحتوي على شاشة كاملة حقيقية ....

لقد بدأت في صنع نموذج أولي للعبة pinball 2D ولديّ توتّر شديد في حركة الكرة ، لديّ جسم صلب يسقط مع الجاذبية. أنا على Win10 / NVidia GTX 560 Ti 1Go (مع أحدث برامج التشغيل) / 8 Go Ram ، جهاز الكمبيوتر الخاص بي ليس الأفضل ولكن مشروعي يحتوي فقط على كرة و StaticBody2D للحدود ويمكنني أن أرى الارتعاش الواضح يحدث كثيرًا ، أنا لقد جربت مع vsync وبدونه ، مع opengl 3.0 و 2.0 ، بإطارات وملء الشاشة ، مع عدد إطارات في الثانية أكثر فأكثر ، لا تزال المشكلة قائمة.
إصدار My Godot هو 3.1 alpha.
أعتقد أنها مشكلة كبيرة ، ربما يصعب حلها ولكن يجب عدم تخطيها ، من المهم أن يكون لديك حركة سلسة ثنائية الأبعاد للعبة ثنائية الأبعاد.

أنت على حق ، لدى Godot الآن إمكانية استخدام أفضل لجميع المحركات العليا (رأيي بالطبع). جانب سهولة الاستخدام يتفوق عليهم جميعًا. لكن ...... جانب الأداء .... جانب التصدير .... مثل Godot كان يتفوق على نظام التشغيل ، وليس مثل صادرات الوحدة أو صانع الألعاب التي تكون أكثر مرونة (حتى يصبح البناء في الكروم أكثر مرونة ) ، وليس بسبب بطء gdscript (يحدث مع GDScript وبدونه) ، هناك "شيء آخر غير محدد" ، آمل يومًا ما أن يجد شخص ما سطرًا متمردًا واحدًا في ملف cpp وتغيير واحد بسيط "!" سيتم إصلاح هذه المشكلة ... (الأمل مجاني مثل جودو!)

لدي العديد من المشاريع في ذهني وأحب أن أقوم بها مع Godot ، سيستغرق الأمر الكثير من وقتي (كي لا أقول كل وقت فراغي) ، لكن يحزنني أن أقول إنه إذا كان المحرك لا يستطيع أن يضمن حركة سلسة ثنائية الأبعاد في الرسوم المتحركة مع مشهد بسيط ، المحرك على الرغم من كل هذه المحترفين هو ببساطة عديم الفائدة. في هذه الحالة ربما يكون الخيار الأكثر حكمة بالنسبة لي هو عدم المخاطرة بضياع الوقت بهذه الطريقة.

أتفهم أن هذه المشكلة تظهر فقط في بعض التكوينات (برامج تشغيل Windows 10 و NVidia على سبيل المثال) ولكن أود أن أعرف:

• هل هذه المشكلة (أو مشكلة مماثلة) مخطط لها بالفعل في مرحلة رئيسية أم لا؟
• هل يمكن وضع هذه المشكلة جانبًا في انتظار استبدال OpenGL بـ Vulkan في المرحلة 3.2؟

ملاحظة: لقد حاولت مع جهاز كمبيوتر آخر:

• Intel i7 4790K 4.00 جيجاهرتز
• Win10 64 بت 16 Go RAM
• NVidia GTX 1060 3Go (مع أحدث برامج التشغيل)
• مسؤول جودو 3.1 ألفا
  ولدي نفس المشكلة مع المشاهد البسيطة.

أعتقد أن هذا النوع من تكوينات الكمبيوتر الشخصي (بطاقات Win10 + Nvidia) مشتركة للغاية ، وآمل أن يقوم مجتمع Godot (الذي يقوم بعمل رائع بالمناسبة) بإصلاح هذه المشكلة قريبًا جدًا وستبدأ الألعاب ثنائية الأبعاد في الظهور. يمكننا القيام به مع Godot ولكن مع هذا النوع من المشكلات بالنسبة لي ، الأمر ببساطة مستحيل.

ربما هو نوع من مشكلة تركيز البرنامج؟ عندما أبدأ لعبة في وضع ملء الشاشة ، أرى التأتأة بشكل أساسي في كل مرة. ولكن إذا قمت (أثناء تشغيل اللعبة) بالتبديل إلى وضع الإطارات والعودة إلى وضع ملء الشاشة ، يبدو أنه يعمل بشكل مثالي في كل مرة. إذا كان لدي أيضًا ، يمكنني برمجة هذا ليحدث تلقائيًا ، لكن يبدو أنه غير مرغوب فيه. هل يمكن لأي شخص آخر تأكيد التبديل من وضع ملء الشاشة ، إلى النافذة ، إلى ملء الشاشة مرة أخرى لإصلاح التأتأة؟

تحرير: أوه وشيء آخر ... عندما قمت بتعطيل تطبيق Geforce Experience ، بدا أن الأمور تتحسن.

مشروع ثنائي الأبعاد مع شخصيات حركية
جودو 3.0.6
Win10 64 بت
وحدة المعالجة المركزية Intel i5-2550K
16 جيجا رام
Geforce GTX 970

لقد جربت ما اقترحته ، لقد عطلت Geforce Experience ، وحاولت التبديل من وضع ملء الشاشة ، إلى نافذة ، إلى ملء الشاشة مرة أخرى ، مع تمكين وتعطيل vsync (الأمر أسوأ مع تعطيل vsync) ولكن التأتأة تبدو دائمًا مزعجة بالنسبة لي.
إنه عشوائي جدًا ولكني لم أتجاوز 15 إلى 20 ثانية دون تلعثم.

شكرا للمحاولة! هذا غريب جدًا ، مواصفاتك أفضل من مواصفاتي. المشكلة معي هي أنها عشوائية جدًا ... من الصعب التكاثر بدقة. في بعض الأحيان ستعمل بشكل رائع ، وفي أحيان أخرى ستتلعثم. أنا متأكد إلى حد ما من أن الأمر يتعلق بجودو نفسه. لا أعاني أبدًا من التأتأة في الألعاب المصنوعة في Unity أو أي محرك ألعاب آخر في هذا الشأن.

فقط لاحظت هذا التأتأة.

(Godot 3.0.6 و Windows 10 و 64 بت و i7-8550U و 16 جيجابايت من ذاكرة الوصول العشوائي و NVIDIA GeForce MX150)

كما ذكر آخرون ، هذه مشكلة خطيرة بالنسبة لجودو. قررت هذا الأسبوع إنشاء نموذج أولي للعبة بسيطة للغاية. لقد بحثت عن إطار عمل أو محرك (وجدت الكثير منها) وقررت أن أستخدم جودو - لأنه مجاني ومفتوح. ثم لاحظت التأتأة ، ووجدت هذه المشكلة - وفوجئت أنه لا يبدو أن هناك تقدمًا. أعتقد أنني سأضع نموذجًا أوليًا لفكرتي في Godot على أي حال. ولكن إذا كنت أرغب في إنشاء لعبة قابلة للإصدار ، فربما أجرب محركًا آخر. (هذا يبدو قاسيًا جدًا ... أعتقد فقط ، قد يفقد Godot الكثير من المتبنين المحتملين إذا لم يتم حل المشكلة.)

لا يوجد تقدم لأنه لا يوجد أحد يعمل على هذا ، ونعم ، إنها قضية خطيرة. ولكن في الوقت الحالي ، إذا كنت بحاجة إلى إصدار لعبة تجارية ، فيمكنك وضع نموذج أولي في godot ومنفذ إلى الوحدة (يمكنك استخدام C #). يجب أن تضع في اعتبارك نهج عنصر لعبة الكائن ، ويمكنك التكرار في godot وإذا انتقلت الأعمال إلى الوحدة لتدفق السوائل والأداء ، أو إذا كانت ثنائية الأبعاد ، فانتقل إلى صانع الألعاب. أنا أعمل في مكون إضافي لمحاولة تحويل مشروع godot إلى محركات أخرى ومحاولة نقل gdscript إلى وحدة نمطية أو إلى gml أو وحدة C # ، ولكنها مهمة ضخمة جدًا (لا أعرف ما إذا كان الجهد يستحق هذا ، الكثير من الوقت لا يعمل في اللعبة) وسيكون دائمًا غير كامل (لا يمكنني الحصول على جميع الأنواع ، ej: الكائن الذي تم إرجاعه عن طريق الاصطدام). لدي محلل صغير للنصوص وسأبدأ المحلل اللغوي إلى tscn و tres ، لكن تحويل نتيجة المحلل اللغوي لـ gdscript إلى وحدة c # أو يتطلب GML لصانع الألعاب الكثير من التعليمات البرمجية ولا أعرف "الشرعية" حول هذا ( بحاجة إلى جميع أسماء api. في ملفات json ولا تعرف عنوان IP الخاص بهذا). الرسوم المتحركة هي مشكلة أخرى ، لا أعرف في الوقت الحالي كيفية التعامل مع ذلك ، ولكن استخدام العمود الفقري / عظام التنين سيسهل نقله. كانت فكرتي الرئيسية عن القيام بذلك هي البداية في godot وتنتهي بالوحدة أو gm ، ولكن بالنسبة إلى niw هو صداع ... إذا كانت الوحدة محمولة بنفس القدر (أحتاج ذلك) ، فهي صغيرة وسريعة التطور مثل godot (ولديها 32 بت محرر) لقد قمت بنقل مشروعي الرئيسي منذ أشهر ، فأنا أحب Godot ولكن بالنسبة لمشروع متوسط ​​الحجم في فريق صغير (أو رجل واحد مثلي) يمثل مخاطرة ، فلا أحد يضمن لك أن المشروع المكتمل لن يعطي الكثير من مشاكل. ولكن إذا كان هناك مبرمج C ++ جيد في فريقك هو شيء آخر ، فيمكنك دائمًا تكييف godot مع لعبتك (في الوحدة لا يمكنك ذلك ، ولكن أقل تعقيدًا) ....
أكره هذه المشكلة كأنني أكره الأداء المنخفض للمحرر في مشروع متوسط ​​واللعبة المصدرة ، لكني أكره المزيد من الوحدة (لماذا أحتاج إلى الإنترنت في جميع أجهزة الكمبيوتر لفتح المحرر؟ لدي كمبيوتر واحد بدون ذلك!) وأكره أستوديو بصري عميق جدًا ... أنا متأكد من أنه إذا توقف godot عن التأتأة وعمل على الأداء والتصدير ، فيمكننا البدء في رؤية ألعاب رائعة.

لإعادة التحقق من هذه المشكلة اليوم ، قمت بما يلي ، ما زلت على Windows 10 مع nVidia GTX 1060:

فتحت The Binding of Isaac ، وضع النافذة. ركضت في دوائر بدون تلعثم (أعني بذلك 30 ثانية على الأقل). لا أعرف ما إذا كانت اللعبة تحتوي على V-sync أم لا ، ليس لديها مثل هذا الإعداد.

فتحت Minecraft ، وضع النوافذ. تم تحميل عالم مسطح ينظر إلى الأرض حيث يكون التأخر غير موجود ، ولا تلعثم.

فتحت Factorio ، لا يزال وضع النوافذ ، بمصنع ألعاب نهائي كبير جدًا. ركضت في خط مستقيم ، بلا تلعثم. ومع ذلك ، تم إيقاف V-sync. إذا قمت بتشغيلها وأعدت تشغيل اللعبة ... فلا يزال هناك تلعثم.

لقد فتحت لعبة Java قديمة قمت بإنشائها باستخدام Slick2D (OpenGL) ، وليس تلعثم واحد (لا يزال يتعين علي رؤية Oo واحدة). التحقق من الخيارات ، تم تمكين V-sync. إذا قمت بإيقاف تشغيل V-sync ، فإنني أتلعثم بشكل منتظم كل ثانية أو نحو ذلك. إذا قمت بمضاعفة غطاء معدل الإطارات ، فلن أتلعثم.

الآن ، فتحت مشروعًا ثلاثي الأبعاد باستخدام Godot 3.1 alpha3 ، بخريطة بها بعض الأصول وشخصية متحركة: لا تلعثم تقريبًا ، يمكنني رؤية واحدة فقط كل 20 ثانية ربما ، وهو أمر خفي للغاية بحيث لا يزعجني.

لقد جربت أيضًا مشروعي ثنائي الأبعاد Wallrider الذي قمت بتنفيذه في Godot 3.0.6: نفس الشيء ، لا يوجد تلعثم كافٍ للإزعاج (واحد عشوائي كل 20 ثانية).

تشترك كل هذه المشاريع أعلاه في هذا الأمر: فهي لا ترسم كائنًا واحدًا على الشاشة.

إذا جربت مشروع اختبار أتلقى تلعثمًا متكررًا وفوريًا وغير منتظم ، والذي يختفي فقط إذا انتظرت حوالي 30 ثانية بعد آخر عرض / تكبير. حاولت التبديل إلى _physics_process ، وحتى حاولت delta = 1.0 / 60.0 ، كل شيء متشابه. إذا قمت بطباعة delta ، فهذا يظهر أن هناك تقلبًا في كل ثانية ، لكن اللعبة تظهر تتعثر عدة مرات في الثانية أن delta لا ينعكس على الإطلاق. يحدث ذلك أيضًا إذا بدأت اللعبة بدون المحرر.
حاولت أيضًا نقله إلى Godot 2.1.5 ، وتحدثت نفس المشكلة (المشروع: Stuttering_issue19783.zip )

والآن ، هذا هو المكان الذي يصبح فيه الأمر ممتعًا:
إذا فتحت كل من لعبتي ثلاثية الأبعاد فسيتم تشغيلهما بسلاسة على الفور. لا تزال اللعبة ثنائية الأبعاد تتعثر قليلاً ، لكن ليس كثيرًا. إذا أغلقت اللعبة ثلاثية الأبعاد ، فلا يزال يبدو أنها تعمل بشكل جيد ، ولكن إذا قمت بتقليص اللعبة ثنائية الأبعاد وتعظيمها مرة أخرى ، فستعود إلى التعتعة الرهيبة.

إنها ليست النهاية بعد!
حاولت الآن إضافة كاميرا ثلاثية الأبعاد في اللعبة ثنائية الأبعاد. وبطريقة سحرية ، يتم تقليل التلعثم بشكل كبير وفوري بمجرد القيام بذلك.
يمكنك تجربة هذا بنفسك مع مشهد PlayerWith3D : Stuttering_issue19783.zip
انظر كم هو سلس بشكل افتراضي. اضغط الآن على الزر magic ، شاهد كيف يتحول الأمر إلى حالة سيئة إذا لم يتم عرض بيئة ثلاثية الأبعاد (لا يعود دائمًا إلى الهراء بنسبة 100 ٪ ، لكني أرى PlayerWith3D.tscn دائمًا يبدو أفضل من Player.tscn ).

أود أن أذهب أبعد من ذلك وأرى ما سيحدث إذا قمت بتغيير لوحة تحكم nVidia من Optimal Power (الافتراضي) إلى Maximum performance ، لكن ... erhm ...

على أي حال ، كل ما يمكنني تخمينه من هذا هو (لكنه تخمين ، لذا خذها بحذر): إنه ليس خطأ جودو مباشرة. إنها برامج تشغيل الرسومات تحاول أن تكون "أذكياء".

من أجل إله التعتعة !!! 😂😂😂

مجرد رمي هذا هناك ... اعتبارًا من نوفمبر 2018 ، فإن أفضل 14 بطاقة فيديو على Steam هي Nvidia. دعونا نلقي نظرة على أفضل البطاقات في كل فئة GPU:

NVIDIA GeForce GTX 1060: 14.60٪ من مستخدمي Steam.
AMD Radeon R7 Graphics: 1.06٪ من مستخدمي Steam.
Intel HD Graphics 4000: 1.06٪ من مستخدمي Steam.

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

بالنظر إلى البيانات المذكورة أعلاه ، يبدو أن هذه المشكلة يجب أن تأخذ الأولوية القصوى. تستخدم الغالبية العظمى من اللاعبين بطاقات Nvidia ، وهي التكوين الأكثر شيوعًا حتى الآن. إن عدد مستخدمي رسومات Radeon و Intel ضئيل بالمقارنة.

Ranoller ... أنت تقتلني. إن إخبار الناس بنموذج أولي في Godot ولكن نقلهم إلى Unity للحصول على لقبهم التجاري (في موضوع موضوع Godot) هو أكثر الأشياء سخافة التي سمعتها على الإطلاق ، بلا إهانة.

Zylann حاولت ضبط وضع إدارة الطاقة على "Perfer أقصى أداء" بنجاح ، لكن لم أجد أي تحسن في التأتأة.

@ behelit2 لا إهانة

Zylann لقد وضعت كاميرا ثلاثية الأبعاد تعرض شبكة أمام مشهد تعرض خريطة tilemap بأنسجة متحركة ومشكلة تلعثم godot بعد ثوانٍ من زيادة التركيز لم يتم إصلاحها. لا يوجد نوع آخر من sttuter سابقًا (فقط "الأولي") في هذا المشهد ، لذلك لا أعرف ما إذا كانت هذه الحيلة تصلح شيئًا ما ، لكنك تكتشفها مثيرة للاهتمام. سأختبر الملفات معك. أعتقد أيضًا أن وقت الخمول في godot يجعل شيئًا ما في الكمبيوتر "كسولًا" ، ولكن من المحتمل أن يكون نظام التشغيل ، لأن الفروق في الفوز مع وبدون aero في FPS واستخدام وحدة المعالجة المركزية والتلعثم عالية جدًا. ربما هو نظام التشغيل الذي يحاول أن يكون ذكيًا وليس بطاقة الرسوميات.

أحب فكرة Zylann لتحليل ما تفعله الألعاب الأخرى. لا أعرف ما إذا كان هذا خارج الموضوع ، لكنني أجريت بعض الاختبارات.
بادئ ذي بدء ، يبدو أن 95٪ من ألعاب البخار هي 32 بت (الإصدارات الأخيرة أيضًا). يبدو أن النسبة المئوية نفسها من الألعاب يتم عرضها بواسطة Directx. ألتقط العمليات التي تنفذها الألعاب وأحاول رؤية ما يحدث مع العرض. بعض المعلومات وراء (ليس من أجل الحصول على أي استنتاجات ، مجرد معلومات):

اللعبة / وحدات البت القابلة للتنفيذ / المحرك / العملية التي تستخدم للعرض في windows 7 64 بت والملاحظات.

• HyperLightDrifter -> 32 بت / Game Maker / Windows GDI
• الخطاف -> 32 بت / الوحدة / Windows GDI
• Nidhogg -> 32 بت /؟ / Windows GDI

• أوري والغابة العمياء -> 32 بت / Unity / Windows GDI. ينفذ عملية تسمى OPENGL32 مثل godot ولكن بجانب نوع من الغلاف في Windows GDI. ليست مكالمة واحدة من OpenGL32 ، كل المكالمات من Windows GDI.
  

• الغبار: ذيل Elysyian -> 32 بت / Microsoft XNA / Windows GDI. يحتوي gameoverlayrenderer.dll وجميع المكالمات من هذا (ClientToScreen). لا يحتوي OpenGL dll.

• SuperMeatBoy -> 32 بت ، التنفيذ داخل Steam Overlay ، Windows GDI

• ΔV: حلقات Saturn (عرض توضيحي) -> 64 بت ، مكالمات godot / Executes OpenGL و Windows GDI ، قم بإجراء مكالمة واحدة إلى OpenGl SwapBuffers - GetPixelformat بقيمة 8. قم بإجراء الكثير من المكالمات إلى Windows GDI. هل المكالمات مكررة؟ إلى WindowsFromDC- SetRect (حجم النافذة) ، OffsetRect.
  

• Bastion -> 32 بت / SDL2 / ينفذ مكالمات OpenGL نقية ، بدون Windows GDI ، قم بإجراء مكالمة فريدة من swapBuffers - GetPixelFormat طوال الوقت بقيمة 10.

• SouthPark عصا الحقيقة -> محرك 32 بت / Unknow / ينفذ جميع المكالمات في Windows GDI ، ويبدو أنه direct3D v 9 (يحتوي على d3d9.dll ولكن لا يتم إجراء مكالمات قليلة من خلال هذه العملية) ، ومعظم المكالمات من gameoverlayrenderer of steam و uxtheme.dll ينفذ OffsetRect و IsRectEmpty وغيرها من وظائف النافذة.
  

• Sine Mora -> محرك 32 بت / غير معروف / ينفذ جميع المكالمات في Windows GDI بواسطة Steam Overlay ، dicect3d 9

• Apotheon -> 32 بت / Microsoft XNA / جميع المكالمات في Windows GDI ، ومكالمة واحدة من Steam Overlay (Client to screen) ، ومكالمة واحدة من Microsoft XNA (ScreenToClient) ، والمكالمات من عملية تسمى uxtheme.dll (إدارة النوافذ في windows؟) إلى IsRectEmpty و PtInrect (كافة القيم المنطقية).
• يعود البيض إلى المنزل -> 64 بت / Godot / مكالمات من OpenGL ومن windows GDI ، مثل Ring of Saturn.
• Guacamelee! Super turbo .... -> محرك 32 بت / غير معروف ولكن بالنسبة للملفات يمكن أن يكون مشابهًا لـ sine mora. تسمح هذه اللعبة بتغيير حجم الشاشة. / جميع المكالمات من Windows GDI.
• ليس بطلاً -> 32 بت / SDL2 (تقول ويكيبيديا ClickTeam Fusion) / جميع المكالمات من Windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 بت (نعم ، هناك واحد) / مقدمة تقول Firebird ، لا شيء الآن حول العمليات / جميع المكالمات من windows GDI ، ولكن هناك عدد قليل جدًا من المكالمات ، القليل منها في الألعاب الأخرى ، بعض المكالمات في الثانية (ej ، يمكنك متابعة مكالمات godot api ، هناك أطنان في الثانية). لكن هذه اللعبة تحترق من GPU.

ألاحظ أن معظم الألعاب التي تم التركيز عليها فقدت إيقاف العملية وإيقافها مؤقتًا (ربما ممارسة جيدة؟) وأن عددًا قليلاً جدًا من الألعاب يسمح لك بتغيير حجم الشاشة يدويًا (ej: not a hero). للأسف لدي مشكلة التأتأة المتمثلة في فقد التركيز / كسب التركيز في ΔV: حلقات زحل (عرض توضيحي).

تحرير: يبدو أن godot هو المحرك الوحيد الذي يستخدم عملية OpenGL32 و WindowsGDI في نفس الوقت.
التطبيق المستخدم: API Monitor v2

(تحرير: الاسم الصحيح لـ ΔV: حلقات زحل (عرض توضيحي))

إذا كنت تقصد بحلقات زحل ΔV: حلقات زحل (عرض توضيحي) ، فقد تم بناؤها باستخدام Godot 3.1 ، لكنني لست متأكدًا من المراجعة الدقيقة التي استخدموها؟

بعد عدة ساعات من محاولة اكتشاف سبب التأتأة ، في حالتي على الأقل ، تتبعتُ بالصدفة التلعثم المتسق للثانية حتى يتم تمكين "التبديل التلقائي إلى شجرة المشهد البعيد" في "إعدادات المحرر". يؤدي إلغاء تحديد هذا إلى حل مشكلات التلعثم والأداء بالنسبة لي. (ربما لا يزال هناك تلعثم طفيف جدًا ، لكنه بالكاد ملحوظ).

بناء Godot 8849d3b
Win10 64bit ، NVIDIA GeForce GTX 660 ، برنامج التشغيل v416.81

واجهت نفس مشكلة التأتأة وكان إلغاء تحديد التبديل التلقائي إلى الشجرة البعيدة هو الجاني.

أواجه نفس المشكلة هنا. هناك العديد من المشكلات حول هذا التوتر ولكن يبدو أن معظمها ليس لديه أي حلول مناسبة وأحتاج حقًا إلى بعض المساعدة.

أنا على وشك توقيع صفقة مع ناشر مع لعبتي التي قمت بها مع Godot وبسبب التوتر الذي قد يضطرني إلى نقل جميع أكوادي إلى Unity. إذا وضعنا الوقت والتكلفة اللازمين لنقل جميع الرموز جانباً ، فأنا متردد في التبديل إلى محرك مختلف لأنني أحب حقًا فلسفة التصميم الخاصة بـ Godot و Godot نفسها.

لقد لاحظت أيضًا أنه في 3.1 تمت إضافة خيار Physics Jitter Fix في قائمة الإعدادات (https://twitter.com/reduzio/status/984783032459685890) ولكن هذا لا يساعد أيضًا.

إصدار Godot:
جودو 3.0.6

نظام التشغيل / الجهاز بما في ذلك الإصدار:
نظام التشغيل MacOS 10.14.1
MacBook (Retina ، 12 بوصة ، 2017)
1.2 جيجاهرتز Intel Core m3
8 جيجا بايت 1867 ميجا هرتز LPDDR3
بطاقة رسومات Intel HD Graphics 615 1536 ميجابايت
(ولكن تحدث هذه المشكلة على أجهزة متعددة بما في ذلك الكمبيوتر الشخصي واللعبة المصدرة على الهاتف المحمول والكمبيوتر الشخصي.)

وصف المشكلة:
يبدو أن أي جسم يتحرك يتلعثم أو يرتعش بشكل دوري مصحوبًا بتجميد الشاشة.

خطوات التكاثر:
أنشئ مشروعًا جديدًا باستخدام KinematicBody2D أو حتى AnimatedSprite وقم بتعديل الموضع باستخدام move_and_slide () أو set_position () بعد إضافة Camera2D كعقدة فرعية. (لكنه لا يزال يحدث حتى بدون Camera2D.)

ويبدو أنه يحدث بشكل متكرر على الأجهزة ذات قدرات المعالجة المنخفضة.

مشروع التكاثر الأدنى:
Godot_Jitter.zip

KinematicBody2D، _physics_process ()، move_and_slide ()

https://youtu.be/78S95yugRDk

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

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

AnimatedSprite ، _physics_process () ، set_global_position ()

https://youtu.be/gdc6NOoWG4E

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

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

KinematicBody2D، _process ()، set_global_position ()

https://youtu.be/YVFtkbuyqEQ

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

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

Win 7 64 بت و GTX 660 (برامج تشغيل 391.35) و Godot 3.0.6 و 3.1-beta1

مرحبًا ، لقد قمت بتعديل المشروع الأصلي (الرسوم المتحركة المتوقفة ، واستخدمت الجسم الصلب بدلاً من ضبط المواضع يدويًا ، وإضافة خلفية متحركة قليلاً ، إلخ)

ها هو: FirstGame_2.zip

تم الاختبار مع نافذة بحجم 500 × 500 ودقة شاشة 1920 × 1080

الآن ملاحظاتي:

• الارتعاش متعدد الاتجاهات (ليس فقط عموديًا ، مثل مشكلات التزامن المتزامن المعتادة)
• كلما قل حجم النافذة ، زاد تذبذب الاهتزازات
• يؤدي إيقاف تشغيل VSync إلى إزالة التوتر (النقاط التالية مع تشغيل VSync)
• تشغيل اللعبة بدون المحرر على الشاشة في نفس الوقت (تصغيرها ، لذا فهي مجرد سطح مكتب - رموز وخلفية وشريط مهام وربما بعض النوافذ الثابتة مثل مدير الملفات أو المحطة الطرفية) يزيل الاهتزاز
• اللعبة المصدرة أو تشغيلها من المحرر لا يهم
• إذا قمت بتشغيل اللعبة باستخدام quakespasm-sdl2 على نفس الشاشة (مع هجوم زومبي على اللاعب تحت الماء) ، أرى القليل من التوتر
• إذا قمت بتشغيل اللعبة باستخدام موقع shadertoy (هذا العرض التوضيحي: https://www.shadertoy.com/view/ll3fz4) ، بدون إيقاف مؤقت ، في نفس الشاشة ، أرى الكثير من التوتر
• إذا قمت بتشغيل اللعبة باستخدام موقع shadertoy ، ولكني توقفت مؤقتًا ، في نفس الشاشة ، أرى القليل من التوتر
• إذا قمت بتشغيل اللعبة مع المحرر على نفس الشاشة ، مع عدم تحديث مشهد في المحرر (Player.tscn) ، أرى القليل من التوتر
• إذا قمت بتشغيل اللعبة مع المحرر في نفس الشاشة ، مع تحديث مشهد يظهر في المحرر بشكل متكرر (main.tscn ، لدي تظليل متحرك هناك) ، أرى الكثير من التوتر

لم تحاول مع إيقاف تشغيل Aero ، هل نسيت كيفية تبديله ذهابًا وإيابًا بسرعة؟

@ starry-abyss لإيقاف تشغيل aero ، والانتقال إلى لوحة التكوين ، واختيار "المظهر والتخصيص" ، حيث يجب أن تكون قادرًا على التغيير إلى مظهر قديم مثل "Windows Classic" ، والذي لا يتميز بتأثيرات مرئية (ثم لا ر استخدام Aero) ، أو "Windows 7 Classic".

حسنًا ، مع المظهر الكلاسيكي ، تنتقل اللعبة ، مع وجود shadertoy / محرر على الشاشة أيضًا ، ذهابًا وإيابًا من حالة التلعثم إلى السلس (يمكن أن تبقى كل حالة لعدة ثوان). ويترافق التلعثم مع تمزق الإطار العمودي في هذا الوضع. ومع ذلك ، حتى Firefox يمزق الدموع بالموضوع الكلاسيكي: 'D

أواجه نفس المشكلة بالضبط التي يواجهها diiiiiiiii ، حالة استخدامه مع move_and_slide هي نفسها حالتي. إنك تراقب عن كثب ، فهي ليست ارتعاش جسم اللاعب ، ولكن خلفية المنظر خلفها.

مشروع ثنائي الأبعاد مع شخصيات حركية
جودو 3.0.6
Win10 64 بت
وحدة المعالجة المركزية Intel i5-2550K
16 جيجا رام
Geforce GTX 970

نظرًا لأن هذا يحدث على العديد من أنواع الأجهزة المختلفة ، لا أعتقد أن هذا مرتبط بشكل صارم بتكوينات الأجهزة. يحدث ذلك حتى في الألعاب المصدرة التي تعمل على أجهزة iOS.

إنك تراقب عن كثب ، فهي ليست ارتعاش جسم اللاعب ، ولكن خلفية المنظر خلفها.

@ behelit2 لست متأكدًا من ذلك رغم ذلك. https://youtu.be/YVFtkbuyqEQ في هذه اللقطات ، إذا نظرت إلى كائن المشغل ، فإنه يهتز من تلقاء نفسه. قد تكون مشكلة منفصلة ولكنها تزداد سوءًا عند تشغيل تنعيم الكاميرا أو تحويل الكائن إلى Rigidbody2D.

https://youtu.be/MGMlhl0tPTA
هذا ما يحدث عند تشغيل تنعيم الكاميرا وتحويل الكائن إلى 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)

ربما قمت بتضخيم الارتعاش باستخدام application_impulse () من هذا القبيل ولكن تعديل موضع الكائن مباشرةً باستخدام set_position () لم يحدث فرقًا كبيرًا.

diiiiiiiii أعتقد أنه يجب فتح قضية منفصلة بعد ذلك. خلاف ذلك ، سيكون الموضوع مليئا ببيانات متناقضة لأن الناس يختبرون أشياء مختلفة.
على سبيل المثال ، أحاول مشروع OP في الوقت الحالي ، وليس مشروعك (آسف).

@ starry-abyss فهمت ذلك ؛)
على الرغم من وجود العديد من المشكلات حول الارتعاش بالفعل وأعتقد أنها مرتبطة ارتباطًا وثيقًا وقد يكون لها نفس السبب الجذري.

تحديث بشأن قضية OP. لقد وجدت بعض الخيارات في Godot للحد من الإطارات في الثانية دون استخدام v-sync. بالنسبة لي ، يبلغ 60 إطارًا في الثانية مع إيقاف مزامنة v وليس ~ 4000 الآن.
وحقيقة إيقاف تشغيل v-sync تعمل على إصلاح المشكلة بالنسبة لي.

أتساءل عما إذا كان v-sync منطقيًا في وضع الإطارات على الإطلاق. يبدو أن Windows يستخدم v-sync بنفسه ، وربما يحارب مع لعبة Godot التي ستجهز الإطار بشكل أسرع بعد تلقي إشارة v-sync. أيضًا ألعاب IIRC الأخرى يتمزق فقط في وضع ملء الشاشة مع إيقاف مزامنة v ، وليس في وضع الإطارات.

لمعلوماتك ، تستمر مشكلة diiiiiiiii هنا بدلاً من ذلك: # 25162

إلى جانب نهج v-sync off ، وجدت طريقة مثيرة للاهتمام خاصة بـ Windows (من خلال وصف الالتزام ، قد تكون هذه المشكلة) ، ولست متأكدًا مما إذا كان Godot يستخدم هذا بالفعل ، ولكن ربما يكون لدى شخص ما الوقت للمحاولة:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
هذا أيضًا مرتبط بـ: https://bugzilla.mozilla.org/show_bug.cgi؟id=1127151

ومع ذلك ، هناك أيضًا هذا الخيط الذي يتعمق في مزيد من التفاصيل وبنهج مختلفة:
https://bugs.chromium.org/p/chromium/issues/detail؟id=467617
وهذا مكمل ، وأقصر وأكثر في جوهره ، ولكن أيضًا مع بعض المشاعر في البداية: https://www.vsynctester.com/firefoxisbroken.html

تم تغيير كلمة التلعثم إلى اهتزاز في تقريري أعلاه ، لأن هذا هو ما اختبرته (انظر https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

ByTheQuietLake كانت فكرتي هي إيقاف تشغيل v-sync فقط في وضع الإطارات (على يستعلم عن معدل تحديث الشاشة لغطاء fps) ، ولكن نظرًا لأن المطورين الأساسيين لا يدعمون هذا النهج ، فلا يوجد شيء لإعادة النظر بعد. :) هناك طرق أخرى خاصة بـ Windows ، ولكن لا يزال يتعين علينا إثبات أنها تعمل بشكل جيد وليست مخترقة للغاية.

تحديث بشأن قضية OP. لقد وجدت بعض الخيارات في Godot للحد من الإطارات في الثانية دون استخدام v-sync. بالنسبة لي ، يبلغ 60 إطارًا في الثانية مع إيقاف مزامنة v وليس ~ 4000 الآن.
وحقيقة إيقاف تشغيل v-sync تعمل على إصلاح المشكلة بالنسبة لي.

أتساءل عما إذا كان v-sync منطقيًا في وضع الإطارات على الإطلاق. يبدو أن Windows يستخدم v-sync بنفسه ، وربما يحارب مع لعبة Godot التي ستجهز الإطار بشكل أسرع بعد تلقي إشارة v-sync. أيضًا ألعاب IIRC الأخرى يتمزق فقط في وضع ملء الشاشة مع إيقاف مزامنة v ، وليس في وضع الإطارات.

كيف حددت fps الخاص بك إلى 60؟

استخدام حقل "Force fps" في مكان ما في فئة Debug من إعدادات المشروع

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

تحديث بشأن قضية OP. لقد وجدت بعض الخيارات في Godot للحد من الإطارات في الثانية دون استخدام v-sync. بالنسبة لي ، يبلغ 60 إطارًا في الثانية مع إيقاف مزامنة v وليس ~ 4000 الآن.
وحقيقة إيقاف تشغيل v-sync تعمل على إصلاح المشكلة بالنسبة لي.
أتساءل عما إذا كان v-sync منطقيًا في وضع الإطارات على الإطلاق. يبدو أن Windows يستخدم v-sync بنفسه ، وربما يحارب مع لعبة Godot التي ستجهز الإطار بشكل أسرع بعد تلقي إشارة v-sync. أيضًا ألعاب IIRC الأخرى يتمزق فقط في وضع ملء الشاشة مع إيقاف مزامنة v ، وليس في وضع الإطارات.
كيف حددت fps الخاص بك إلى 60؟
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

لم أر أشخاصًا ينشرون وحدات المعالجة المركزية الخاصة بهم مع الأنظمة ، باستثناء I5-2500K الذي يحتوي على وحدة معالجة رسومات Intel مدمجة.

يحتوي جهاز الكمبيوتر المحمول الخاص بي على وحدة معالجة رسومات Intel مدمجة وبطاقة Nvida مخصصة. أنا فقط أتساءل عما إذا كان يمكن أن تكون هناك مشكلة بين اثنين من GPU / السائقين و godot

يمكن. لكنها لا تبدو وكأنها تعتمد على وحدة المعالجة المركزية / وحدة المعالجة المركزية. على i7 2700 + 1080ti يمكن أن تكون قطعية (نوافذ) وزبدة سلسة على الهاتف المحمول i5 مع إنتل 4000 (أول سطح برو) - في ملء الشاشة

من المضحك أن تقول إنني إذا قمت بتشغيل المشروع التجريبي على أجهزة الكمبيوتر المحمولة الخاصة بي 940 م أرى التأتأة. ومع ذلك ، عندما أقوم بتشغيل التطبيق باستخدام Intel 530 المخصص ، لا أرى أي تلعثم على الإطلاق.

ويندوز 10 هوم
وحدة المعالجة المركزية i3-6100H @ 2.70 جيجا هرتز ،
GeForce 940M (26.21.14.3064)
Intel (R) HD Graphics 530 (26.20.100.6709)

هل التأتأة ظاهرة في هذا المشروع ؟ (تحرك بالضغط على مفاتيح الأسهم.)

لقد قمت للتو بتصدير سريع مع ترك الاستيفاء قيد التشغيل وضبط الفيزياء على 60:
940M كان هناك هزات عرضية ولكن ليس القص
Intel 530 لم يكن هناك هزات ولكن في بعض الأحيان قص واضح في التزامن ،

أفعل المزيد لاحقًا ، وأعلمك بذلك.

لقد حققت بعض النجاح على ما يبدو مع وضع حد أقصى لإطار في الثانية عند 60. لست متأكدًا مما إذا كان الرقم 60 هو رقم سحري ، يمكن لشاشتي أن تدعم 144 ، لقد حاولت ضبط الغطاء عند 144 ، لكن التأتأة كانت لا تزال مرئية. لقد خفضت معدل إطاراتي في الثانية إلى 120 ، وكان التلعثم لا يزال مرئيًا ، ولكن ليس "ضبابيًا" ، مما يجعلني أعتقد أنه يحدث فقط في فترة زمنية أقل. تمت المتابعة مع خفض FPS إلى 80 ، والنتيجة نفسها كما في السابق ، ولكن التلعثم أصبح الآن أبطأ بشكل واضح. أيضًا ، يجب أن أقول ، لقد قمت بتعطيل v-sync والتشغيل في وضع windowed ، لقد اختبرت مع ملء الشاشة ، ولكن نفس النتيجة. هل توجد أي عمليات في المحرك متوقفة عند 60 إطارًا في الثانية؟

هل توجد أي عمليات في المحرك متوقفة عند 60 إطارًا في الثانية؟

افتراضيًا ، تتم محاكاة الفيزياء بمعدل 60 إطارًا في الثانية ، مما يعني أنه سيكون هناك تناقض مرئي عندما يكون عرض الإطارات في الثانية أعلى من إطار في الثانية للفيزياء (بشرط أن تكون الشاشة سريعة بما يكفي لإظهار الفرق). يمكن تغيير FPS الفيزيائية في إعدادات المشروع ( فيزياء> عام> إطار فيزياء ).

يمكن التخفيف من حدته عن طريق إقحام أجسام الفيزياء ، لكن لا يوجد دعم رسمي لذلك. في 3.2alpha ، يمكنك استخدام هذه الوظيفة الإضافية للتنعيم والتي تجعل من السهل إقحام العقد.

هل توجد أي عمليات في المحرك متوقفة عند 60 إطارًا في الثانية؟

افتراضيًا ، تتم محاكاة الفيزياء بمعدل 60 إطارًا في الثانية ، مما يعني أنه سيكون هناك تناقض مرئي عندما يكون عرض الإطارات في الثانية أعلى من إطار في الثانية للفيزياء (بشرط أن تكون الشاشة سريعة بما يكفي لإظهار الفرق). يمكن تغيير FPS الفيزيائية في إعدادات المشروع ( فيزياء> عام> إطار فيزياء ).

يمكن التخفيف من حدته عن طريق إقحام أجسام الفيزياء ، لكن لا يوجد دعم رسمي لذلك. في 3.2alpha ، يمكنك استخدام هذه الوظيفة الإضافية للتنعيم والتي تجعل من السهل إقحام العقد.

رائع ، شكرًا ، قد يفسر ذلك سبب تأتأة الشخصيات أثناء التعامل مع الحركة في استدعاء عملية الفيزياء

لا يزال بإمكانك التكاثر في 3.1.1 BTW ، أسهل طريقة هي فتح Shadertoy في Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

لقد تعثرت هنا على أمل أن يكون هناك حل ولكن بعد تجربة كل نصيحة تقريبًا رأيتها في هذا الموضوع ، لا يزال هناك نرد. بالنسبة لي ، يحدث الارتعاش فقط عندما أقوم بتشغيل المشروع في بطاقة NVIDIA. إذا قمت بتشغيله باستخدام Intel GPU المدمج ، فإنه يعمل بسلاسة. : /

أنا أستخدم أحدث إصدار من الإصدار ألفا من Godot 3.2 على نظام التشغيل Windows 10

لقد تعثرت هنا على أمل أن يكون هناك حل ولكن بعد تجربة كل نصيحة تقريبًا رأيتها في هذا الموضوع ، لا يزال هناك نرد. بالنسبة لي ، يحدث الارتعاش فقط عندما أقوم بتشغيل المشروع في بطاقة NVIDIA. إذا قمت بتشغيله باستخدام Intel GPU المدمج ، فإنه يعمل بسلاسة. : /

أنا أستخدم أحدث إصدار من الإصدار ألفا من Godot 3.2 على نظام التشغيل Windows 10

لا أعتقد أنه يمكنك إصلاحه على الويندوز ، هذا لا يحدث على نظام لينكس ، قد يتم إصلاح هذا في 4.0 مع عارض فولكان الجديد.

لقد تعثرت هنا على أمل أن يكون هناك حل ولكن بعد تجربة كل نصيحة تقريبًا رأيتها في هذا الموضوع ، لا يزال هناك نرد. بالنسبة لي ، يحدث الارتعاش فقط عندما أقوم بتشغيل المشروع في بطاقة NVIDIA. إذا قمت بتشغيله باستخدام Intel GPU المدمج ، فإنه يعمل بسلاسة. : /
أنا أستخدم أحدث إصدار من الإصدار ألفا من Godot 3.2 على نظام التشغيل Windows 10

لا أعتقد أنه يمكنك إصلاحه على الويندوز ، هذا لا يحدث على نظام لينكس ، قد يتم إصلاح هذا في 4.0 مع عارض فولكان الجديد.

حسنًا ، هذا سيء ، ألا تركز Vulkan API على الأجهزة المتطورة فقط؟

أستهدف برنامج OpenGL 2.0 على وجه التحديد حتى أتمكن من دعم الأجهزة المنخفضة الجودة. من السخف نوعًا ما استخدام واجهة برمجة تطبيقات رسومات عالية الجودة لمجرد لعبة ثنائية الأبعاد وإغلاق الأشخاص الذين لديهم أجهزة كمبيوتر / أجهزة كمبيوتر محمولة منخفضة الجودة. 😕

يبدو وكأنه أسطورة. ربما لا يمكن إصلاح التلعثم من وقت لآخر في أجهزة الصراف الآلي ، ولكن مشكلة التلعثم التي نواجهها هي ميزة خاصة بـ Godot فقط.

يبدو وكأنه أسطورة.

ما الذي كنت تشير إليه بهذا؟

هذه قضية صعبة. من ناحية واحدة أود أن أصلح هذا شخصيًا في أسرع وقت ممكن. لكن لا يمكنني التكاثر ، لذلك لا يمكنني فعل شيء. (أستخدم Windows 10 مع بطاقة رسومات NVidia)

يحتاج الشخص الذي يمكنه إعادة إظهار المشكلة إلى اتخاذ طعنة في إصلاحها لسوء الحظ. :(

في حين أنها مشكلة غير شائعة ، يبدو أنها شائعة بما يكفي لجذب الكثير من الأشخاص إلى هذا الموضوع. لذا نأمل أن يعمل أحدكم على هذا.

آه ، إنني دائمًا أنسى أن ما أختبره يسمى jitter في مصطلحات Godot doc الرسمية.

_هل يعرف أي شخص كيفية التقاط المشكلة تمامًا بسرعة 60 إطارًا في الثانية دون شراء بعض الأجهزة؟ _
أعتقد أن بعض الناس يستخفون بمظهرها الغامض ، وربما تكون أيضًا مشكلة مختلفة المظهر على أجهزة كمبيوتر مختلفة.

ما الذي كنت تشير إليه بهذا؟

الأسطورة: "هذا دائمًا ما يكون على OpenGL (أو Windows ، إلخ). فقط Vulkan يمكنه إنقاذنا".

حسنا اذا:

1. هذا مقطع فيديو من OBS: https://www.youtube.com/watch؟v=osbJlk1XD8c تأثير OBS هو أن مجرد تشغيل OBS يجعل هذا التوتر في مشروع Godot (حتى عند إيقاف الالتقاط).
2. بدون OBS يكون الأمر سلسًا حتى أقوم بإلغاء تصغير Firefox باستخدام shadertoy فيه ، ثم يبدأ في التأتأة ، لكن لا يمكن التقاطه باستخدام OBS ، لأن 1.

التقطيع في تسجيلي الخاص ، يتم ذلك باستخدام Bandicam وفي الغالب يكون هذا هو كيفية أدائه مع التسجيل أو بدونه. كما ترى ، يبدأ الأمر بسلاسة ولكنه يبدأ بالتدريج في مواجهة المشكلات

clayjohn أعتقد أنه سيتم إصلاحه من خلال تطبيق الاستيفاء الفيزيائي ، لكن reduz يعارض وجوده في الجوهر لعدة أسباب. ومع ذلك ، تمت إضافة طريقة في 3.2alpha لفضح نسبة خطوة الفيزياء الحالية ، مما يجعل من الممكن تنفيذ الاستيفاء الفيزيائي الدقيق يدويًا.

@ starry-abyss إذا كان بإمكانك استخدام 3.2alpha ، فجرّب الملحق الملائم لـ lawnjelly:

مجرد فكرة ، هل هناك أي شيء مفيد في محرك غير حقيقي أو مصدر فيزكس للنظر فيه؟

في صحتك،
فيكتور ستان

في 22 أكتوبر 2019 ، الساعة 4:17 صباحًا ، كتب Hugo Locurcio [email protected] :

clayjohn أعتقد أنه سيتم إصلاحه من خلال تطبيق الاستيفاء الفيزيائي ، لكن reduz يعارض وجوده في جوهره.

@ starry-abyss إذا كان بإمكانك استخدام 3.2alpha ، فجرّب الملحق الملائم لـ lawnjelly 🙂

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بإلغاء الاشتراك.

victorbstan يجب ألا ننظر إلى كود مصدر Unreal ، لأنه ليس تحت ترخيص مفتوح المصدر. (لا يسمح حتى بإعادة التوزيع لمستخدمي Unreal Engine غير المرخصين.)

بالتأكيد لا ترفع الشفرة من المصدر المغلق ، ولكن يمكنك ذلك من الناحية المعمارية
لا تجمع الأفكار من هذا؟ [ليس محامياً]

يوم الثلاثاء 22 أكتوبر 2019 الساعة 11:07 صباحًا Hugo Locurcio [email protected]
كتب:

victorbstan https://github.com/victorbstan يجب ألا ننظر
كود مصدر Unreal ، لأنه ليس تحت ترخيص مفتوح المصدر. (لا
حتى تسمح بإعادة التوزيع لمستخدمي Unreal Engine غير المرخصين.)

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/19783؟email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HS4DFVREXG43VM84
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

Razzlegames ما زلت لا أوصي بالنظر إلى كود المصدر الخاص به. إذا كنت ترغب في أي وقت مضى في الحصول على الإلهام من خوارزمية خاصة ، فيجب عليك إجراء هندسة عكسية للغرفة النظيفة لتقليل المخاطر القانونية المرتبطة بذلك.

ومع ذلك ، لا نحتاج إلى القيام بأي من هذا هنا. الحل هو استخدام الاستيفاء الفيزيائي ، والذي تستخدمه محركات الألعاب الأكثر شيوعًا في الوقت الحاضر. لها بعض الجوانب السلبية (مثل طلب العمل من المستخدم لتجنب الاستيفاء عند النقل الآني للكائنات) ، لكنني أعتقد أن المكاسب تفوقها كثيرًا.

أفهم أن الاقتراح هو الحصول على فكرة عن السبل الممكنة لإيجاد حل ، وليس بالضرورة الانتحال. لا أتخيل أن هناك براءة اختراع لحل مشكلات الاهتزاز / التلعثم ولكن IANAL.

في صحتك،
فيكتور ستان

في 22 تشرين الأول (أكتوبر) 2019 ، الساعة 2:07 ظهرًا ، كتب Hugo Locurcio [email protected] :

victorbstan يجب ألا ننظر إلى كود مصدر Unreal ، لأنه ليس تحت ترخيص مفتوح المصدر. (لا يسمح حتى بإعادة التوزيع لمستخدمي Unreal Engine غير المرخصين.)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بإلغاء الاشتراك.

في السيناريوهات الخاصة بي ، يُظهر ملف تعريف Godot 60 إطارًا في الثانية مثاليًا ، حتى عندما أرى اهتزاز / تلعثم. هل هذا يعني أن المشكلة لا تتعلق بالاستيفاء ، أم أنني أفتقد شيئًا ما؟

كان افتراضي أن توقيتات Godot قد تم تنفيذها بطريقة تتداخل مع توقيتات مؤلف Windows (وربما تقوم SDL بعملها بشكل أفضل من

(وربما يقوم SDL بعمل أفضل من GLFW ، ومن ثم تعمل المحركات الأخرى حيث يفشل Godot).

يستخدم Godot كود إدارة النوافذ الخاص به ، ولا يستخدم SDL ولا GLFW:

لديّ نظام التشغيل Windows 10 و nVidia GeForce GTX 1070 ، ومع الإصدار 3.2 alpha2 مع تمكين vsync ، أشعر بالقلق عندما تكون في وضع الإطارات. يبدو وضع ملء الشاشة جيدًا. تكون المشكلة سيئة بشكل خاص إذا لم يتم تصغير المحرر عند تشغيل اللعبة. تستخدم اللعبة التي أختبرها فقط _process() لتحديث المراكز. لهذا السبب ، كنت أظن أن المشكلة تتعلق بـ delta أو الإطارات المسقطة (دلتا كبيرة) ولكن هذا ليس هو الحال. delta هو في الواقع ثابت للغاية أثناء الارتعاش.

استنادًا إلى أبحاث الآخرين في هذا الموضوع ، قمت باختراق تغيير إلى context_gl_windows.cpp لتعيين الفاصل الزمني للمبادلة على 0 واستدعاء DwmFlush() في 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;
}

يعتمد هذا على ما يفعله مشروعا Chromium .

يبدو أن إجراء هذا التغيير يؤدي إلى إصلاح الاهتزاز في وضع الإطارات. في وضع ملء الشاشة ، تمزق اللعبة لذا من المحتمل أن يتم تعطيل DWM ويبدو أن التخزين المؤقت المزدوج عبر قيمة الفاصل الزمني 1 ضروري. (بشكل أساسي ، يحتاج الكود إلى القيام بما يفعله حاليًا.)

إذا كان أي شخص آخر مستعدًا وقادرًا على تجربة ذلك ، فسأكون مهتمًا بمعرفة كيف ستسير الأمور.

يبدو أن الجزء wglSwapIntervalEXT(0); هو نفسه إيقاف تشغيل v-sync في الخيارات.

يبدو مثل wglSwapIntervalEXT (0) ، الجزء هو نفس إيقاف تشغيل v-sync في الخيارات.

أنه. 1 - تمكين vsync ، 0 - تعطيل ، وهناك أيضًا -1 لـ "Adaptive vsync" (قم بتعطيل المزامنة عند معدلات الإطارات المنخفضة ، قم بتمكينها على المستوى العالي).

لقد اختبرت الشيء DwmFlush () من الأعلى مع حالاتي البسيطة ، على فرع 3.1.x.

• يقوم بإصلاح الموقف مع حالة اختبار shadertoy ؛
• مزامنة V أو إيقاف تشغيلها - تبدو متشابهة بالنسبة لي (لم أقم بإصلاح جزء wglSwapIntervalEXT ()) ؛
• لا تزال حالة OBS تتأرجح (تبدو كما هي على ما أعتقد) ، لكن Godot أبلغت الآن عن انخفاض FPS إلى 40 (أتساءل عما إذا كان ملف التعريف في Godot يكمن بالفعل في إصدار Godot الأصلي) ؛
• حاولت أيضًا الاتصال بـ DwmFlush () بعد SwapBuffers (hDC) ، وتبقى جميع النقاط الثلاث كما هي.

لست متأكدًا ، لكني أعتقد أن DwmFlush () بعد SwapBuffers (hDC) قد يكون أكثر صحة نظرًا لأن Godot يضع الإطار في أقرب تحديث للمُعد ، وليس في التحديث التالي ، وهو بعد الأقرب.
أتساءل عما إذا كان يجب على Godot أن يكتشف بشكل أفضل ما إذا كان المكون قيد التشغيل والعودة إلى طريقة Vanilla v-sync إذا لم تكن كذلك.

لذا بعد المحاولة ستكون ميزة الاستيفاء الجديدة التي ذكرها كالينو.

تحديث: نعم ، في حالة OBS ، يبلغ Godot وقت معالجة 0.03 ثانية (ولكن تم الإبلاغ عن FPS على أنه 60) ، ربما لا يأخذ عداد Godot FPS في الاعتبار فقدان v-blank في كل مرة
تحديث 2: للأسف ، لا يبدو أن المكوِّن الإضافي للاستيفاء يساعد هنا ؛ ما زلت أعاني من عدم الاستقرار في حالة OBS والتلعثم و / أو مزيج الاهتزاز في حالة shadertoy

يبدو أن الجزء wglSwapIntervalEXT(0); هو نفسه إيقاف تشغيل v-sync في الخيارات.

هذا صحيح ، ولكن إضافة DwmFlush() في swap_buffers() سيجعل اللعبة تستخدم أداة التركيب (DWM) للمزامنة. عندما يتم تمكين المكون ، يكون لديك تخزين مؤقت مزدوج بشكل فعال سواء كنت ترغب في ذلك أم لا. سيكون لديك تخزين مؤقت ثلاثي في ​​الحالة التي قمت فيها بتعيين الفاصل الزمني لمبادلة OpenGL على 1. (المخازن المؤقتة الخاصة بك والمخزن.)

أتساءل أيضًا لماذا وضعت المشاريع الأخرى الدعوة إلى DwmFlush() قبل SwapBuffers() . يبدو الأمر متخلفًا لكنني أقنعت نفسي تقريبًا أنه صحيح.

في حالة هذه المشاريع ، لا يستخدمون التخزين المؤقت المزدوج لـ OpenGL (عندما يتم تمكين المكون) ، لذا فإن القيام بذلك بهذه الطريقة يبدو أفضل طريقة للتزامن مع الفترة الفارغة الرأسية. باستخدام فاصل زمني للتبديل بين OpenGL بقيمة 0 ، لا يتم حظر الاتصال بـ SwapBuffers() لذا فأنت تقدم الإطار التالي للمُنشئ بمجرد أن تعلم أنه انتهى مع الإطار الحالي. هذا له نفس تأثير استخدام فاصل مبادلة OpenGL من 1. (عندما لا يتداخل المكون - وضع ملء الشاشة ، على سبيل المثال.)
>
>

أتساءل عما إذا كان يجب على Godot أن يكتشف بشكل أفضل ما إذا كان المكون قيد التشغيل والعودة إلى طريقة Vanilla v-sync إذا لم تكن كذلك.

أعتقد أنك على حق. يبدو واضحًا أن مزامنة OpenGL الخاصة بـ OpenGL تتعطل عند تمكين المكون. إذا نظرت إلى كود glfw's و Chromium ، فإنهم يسمون هذا (باستخدام DwmFlush() ) HACK. من المحتمل أنهم يعتقدون أن OpenGL معطل في هذه الحالة ويتعين عليهم القيام بشيء ينبغي القيام به.

@ starry-abyss بعد إعادة قراءة منشورك حول حالة OBS التي لا تتغير ، أتساءل عما إذا كان هذا المشروع قد تم تمكين vsync. نظرًا لأنك لم تقم بتغيير المكالمة إلى wglSwapIntervalEXT() تفعيل vsync سيؤدي بشكل أساسي إلى حظر اللعبة في كل من DwmFlush() و SwapBuffers() . هذا من شأنه أن يفسر وقت العملية 0.03 ثانية.

TerminalJack لا ، لقد جربت كل المجموعات. يزيد وقت العملية دائمًا إلى 0.03 عند تشغيل OBS. يبدو أن Godot يحاول جاهدًا أن يكون بسرعة 60 إطارًا في الثانية ، حتى عندما لا يتمكن من تحقيق هذه الإطارات المتعددة على التوالي.

لذلك سأقسمها إلى قضيتين:
1) جودو ليس صديقًا للملحن ؛
2) إن Godot حريص جدًا على الحصول على أقصى عدد من الإطارات في الثانية في حين أنه يمكن أن يقدم 30 ثابتًا فقط إذا كان تحت الحمل.

ولكن إذا كانت هناك طريقة موثوقة لإثبات ما إذا كان 0.03 هو وقت حساب خالص وليس مزامنة ، فيمكنني تجربتها.

@ starry-abyss لأغراض الاختبار ، يمكنك استخدام مدير المهام لتعزيز "أولوية العملية" إلى "عالية". سيؤدي ذلك إلى استباق الآخرين ومنحها نصيب الأسد من وقت المعالجة. أي ، طالما أنه في حالة قابلة للتشغيل ولم يتم حظره في DwmFlush() و / أو SwapBuffers() .

لم تتح لي فرصة كبيرة للتغلب على هذا اليوم ، لكنني حاولت تشغيل التغيير على نظام Windows 10 الذي يحتوي على وحدة معالجة رسومات Intel UHD Graphics 620. (وحدة معالجة رسومات منخفضة الجودة إلى حد ما.)

قمت أولاً بتشغيل اللعبة (في وضع الإطارات) بأحدث إصدار 3.2 alpha2 ولم يكن بها أي تشويش ملحوظ. ثم قمت بتشغيل اللعبة مع التغييرات وعملت بشكل جيد أيضًا.

صادف أنني قمت بتسجيل مرات delta خلال المرحلتين ووجدت أنها كانت أكثر استقرارًا مع الاتصال بـ DwmFlush() من دونها ...

3.2 ألفا 2

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

اختبار البناء

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)

(ترجع الدلتا العالية في البداية هنا إلى حقيقة أن هذه تم التقاطها بعد تحميل المشهد مباشرة. ويعرض بناء ألفا نفس السلوك.)

لاحظ كيف استقر بناء الاختبار في النهاية ووصل إلى حالة مستقرة. الإصدار 3.2 alpha2 لم يسبق له مثيل.

لذلك يبدو أن ليس فقط وحدات معالجة الرسومات الأخرى لن تتأثر سلبا نتيجة هذا التغيير، ولكن سوف تستفيد فعلا من ذلك. أعتقد أن الارتعاش يزداد سوءًا مع ازدياد قوة وحدة معالجة الرسومات ولا يعتمد على الشركة المصنعة أو حتى السائقين.

لقد قمت بإنشاء مفترق يحتوي على التزام واحد يجب أن يحل هذه المشكلة.

لقد اختبرته فقط على جهازي Windows 10 ، ومع ذلك ، سيكون من الرائع أن يتمكن الآخرون من بنائه واختباره على إصدارات Windows الأخرى. أيضًا ، لقد قمت بإنشائه باستخدام VC ++ 2019 ، لذلك إذا كان بإمكان شخص يستخدم mingw إنشاءه ، فسيكون ذلك رائعًا أيضًا.

إذا كان لديك تفرع خاص بك (حديث) من المشروع ، فيجب أن تكون قادرًا على تصحيح هذا التغيير فيه دون أي مشاكل.

أنا على نظام التشغيل Windows 10 مع NVidia GTX 1050.

ليس لدي تلعثم في مثال المشروع إلا إذا كان لدي لعبة shadertoy مفتوحة وجارية (كما هو موضح في التعليقات القليلة أعلاه).

مع التزامTerminalJack ،

clayjohn شكرا لاختبار هذا. أتساءل عما إذا كانت المشكلة في حالتك هي مجرد مسألة قوة معالجة.

يمكنني تشغيل لعبة shadertoy مقاس 800 × 450 في الخلفية ولعبة Godot (يتم تشغيلها من المحرر) في نافذة في المقدمة والحصول على قدر ضئيل جدًا من الارتعاش مع التغييرات التي أجريتها. من ناحية أخرى ، يعاني بناء alpha2 من اهتزاز شديد في ظل نفس الظروف. أنا واحد من الأشخاص الذين يعانون من اضطراب شديد حتى بدون أي عبء على نظامي ، لذلك ربما يكون هذا أمرًا يجب أخذه في الاعتبار أيضًا.

TerminalJack نقطة جيدة. كنت أقوم بتشغيل تظليل الغابات المطيرة في آي كيو :)

أعتقد أن هناك احتمالية كبيرة لوجود العديد من القضايا هنا. كما أشار Calinou أعلاه ، فإن العديد من المستخدمين لديهم مشكلة ثابتة عند استخدام الفيزياء

في هذه المرحلة ، أعتقد أنه يجب عليك العلاقات العامة الالتزام الخاص بك ، فهو يبدو جيدًا وسيؤدي إنشاء العلاقات العامة إلى منحها مزيدًا من الرؤية وتسهيل بناء واختبار المستخدمين الآخرين.

clayjohn نعم ، أوافق على أن هناك مشكلات أخرى من المحتمل أن تتصرف على نحو مشابه لهذا.

لقد بدأت بالفعل في محاولة تعقب مشكلة تلعثم سيئ يحدث مرة كل 60 إلى 90 ثانية ووجدت هذا الموضوع. (يبدو أن شيئًا ما يعيق العملية لمدة 60 مللي ثانية إلى 100 مللي ثانية بين الحين والآخر.) كنت أقوم بتشغيل لعبتي في وضع ملء الشاشة ولم تكن تعاني من أي توتر. بعد أن صادفت هذا الخيط ، حاولت تشغيله في نافذة ، وها هو: أنا من المحظوظين الذين يمكن أن يحدثوا لإعادة إنتاج هذه المشكلة بالذات.

من المحتمل أن أزيل بيانات التصحيح من تغييراتي وأرسل عبر PR في غضون ساعتين.

TerminalJack الشوكة لم تعد متوفرة (أو تم ضبطها لتكون خاصة) ، هل يمكنك إتاحتها مرة أخرى من فضلك؟

@ كالينو آسف. لقد رفعت المستودع لذا قمت بحذفه. سأفترقها مرة أخرى وأعيد تنفيذ التغييرات هنا قريبًا.

Calinou الالتزام الجديد هنا .

TerminalJack يبدو أن الإصلاح الخاص بك مخصص لنظام التشغيل Windows فقط ولكني أواجه نفس المشكلة على Ubuntu.

TerminalJack يبدو أن الإصلاح الخاص بك مخصص لنظام التشغيل Windows فقط ولكني أواجه نفس المشكلة على Ubuntu.

نعم ، هذا بالتأكيد إصلاح لنظام Windows فقط. آسف.

لا أعرف ما إذا كان من الضروري القيام بشيء مماثل على Ubuntu أم لا. لست متأكدًا حتى مما إذا كان يستخدم مكونًا.

لا أعرف ما إذا كان من الضروري القيام بشيء مماثل على Ubuntu أم لا. لست متأكدًا حتى مما إذا كان يستخدم مكونًا.

في الواقع ، لا توجد طريقة لتعطيله في بعض مديري النوافذ (بما في ذلك Ubuntu الافتراضي):

TerminalJack قد يحتاج أيضًا إلى بعض المنطق عندما يتم تعطيل Aero في Windows 7 على سبيل المثال (IIRC لا يقوم بمزامنة v ، لذلك ربما يجب على Godot الاستمرار في مزامنة نفسه في هذه الحالة)

@ starry-abyss آمل أن يتم القبض على هذه القضية. لدي جهاز كمبيوتر محمول قديم يعمل بنظام Windows 7 عليه. إذا كان لا يزال يعمل ، فسأجري بعض الاختبارات معه ومعرفة ما إذا كانت هناك أية تغييرات ضرورية.

لقد قمت بتشغيل جهاز الكمبيوتر المحمول الخاص بي الذي يبلغ من العمر 10 سنوات والذي يحتوي على Windows 7 واختبرت التغييرات. اضطررت إلى استخدام أبسط المشاريع للاختبار. (كانت وحدات معالجة الرسومات الخاصة بالكمبيوتر المحمول سيئة للغاية في ذلك الوقت). لقد استخدمت المشروع من هذا المنشور. أضفت ما يلي حتى أتمكن من التبديل إلى / خارج ملء الشاشة.

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

لقد قمت بتشغيل المشروع من خلال التغييرات التي أجريتها وبدونها ولم تكن هناك أي اختلافات ملحوظة في كلتا الحالتين. من خلال التغييرات التي أجريتها ، سيتم استخدام المُنشئ للمزامنة الرأسية عندما يكون متوقعًا (وضع الإطارات ، وتم تمكين المكون) وسيتم استخدام التخزين المؤقت المزدوج لبرنامج OpenGL في جميع الحالات الأخرى.

الخبر السار هو أنه لن يكون هناك أي تغييرات ضرورية على _code_. يكتشف الرمز ما إذا كان المكون ممكّنًا أم لا كما ينبغي. حتى أنه يتعامل مع الحالة التي تقوم فيها بتمكين أو تعطيل المكون أثناء تشغيل التطبيق. هذه حالة لم أتوقعها ، ومع ذلك ، لم أقم بتضمينها في التعليقات في swap_buffers() فيما يتعلق بالحالات التي تتغير فيها إستراتيجية v-sync بشكل سريع. لذلك هذا هو الشيء الوحيد الذي أحتاج إلى تغييره بقدر ما أعرف.

أحد الأشياء التي أثيرت في irc اليوم والتي تناقش هذا (والعلاقات العامة في TerminalJack) هو عزل الخطأ في دلتا الإدخال المقاسة عن الخطأ في دلتا الإخراج.

وأشار كالينو إلى أنه يمكننا اختبار ذلك إلى حد ما عن طريق التشغيل باستخدام مفتاح سطر الأوامر --fixed-fps 60 . سيعامل هذا دلتا الإدخال كما لو كانت دائمًا 1/60 من الثانية.

سيكون من المفيد جدًا أن يخبرنا أولئك الذين يواجهون المشكلة (خاصة على النوافذ) إذا كان لهذا أي تأثير على عدم الاستقرار.

lawnjelly لقد حاولت بسرعة مع وبدون خيار سطر الأوامر ، لكن للأسف لا يمكنني إعادة معالجة المشكلة اليوم٪) باستثناء حالة OBS ، والتي لا تزال هي نفسها.
هل قيمة الخيار المخزن بين المحرر تعمل بالصدفة؟

هل قيمة الخيار المخزن بين المحرر تعمل بالصدفة؟

لا ، إنها مجرد وسيطة سطر أوامر (وهي عديمة الحالة).

حسنا. أيضًا ، راجع للشغل ، هل الخيار متاح في Godot 3.1.1 (الإصدار الذي أجري عليه معظم الاختبارات هنا)؟

حسنا. أيضًا ، راجع للشغل ، هل الخيار متاح في Godot 3.1.1 (الإصدار الذي أجري عليه معظم الاختبارات هنا)؟

إذا كنت تستخدم 3.1.1 لاختبار ذلك ، فستحتاج إلى نقل الكائنات مسافة تتناسب مع دلتا أثناء _ العملية ، حيث لا يوجد استيفاء زمني ثابت.

@ starry-abyss تمت إضافة وسيطة سطر الأوامر هذه في 3.1 ، لذا يجب أن تكون متوفرة في 3.1.1 أيضًا.

لذا ، لم يساعدني --fixed-fps 60 حل المشكلة بالنسبة لي. وتشغيل اللعبة من سطر الأوامر مباشرة لم يساعد أيضًا (لا يزال لدي مثيل منفصل للمحرر على الشاشة على الرغم من إعادة إنتاجه بشكل أسرع).

كما جربت كلاهما مرة واحدة ، في حالة ما إذا كان الطلب --fixed-fps 60 ينطوي على ذلك ، فلا يزال هناك توتر.

كانت صعوبة إعادة الإنتاج بالأمس لأنني أوقفت مزامنة v في خيارات من الاختبارات السابقة. : /

لا يوجد استيفاء زمني محدد.

بالطبع ، أقوم باختبار الطرق واحدة تلو الأخرى ، وليس كلها مرة واحدة (ليس مثل المكون الإضافي للاندماج + dwmflush + أي فكرة جديدة).
يرجى أيضًا في المرة القادمة تضمين الخطوات المحددة لتجربة الفكرة الجديدة ، لذلك لا يتعين علي تخمين إصدارات Godot ، لتشغيل محرر أو لعبة مباشرة ، وما إلى ذلك. ليس لدي الرغبة في تجربة جميع المجموعات الممكنة من كل شيء (باستخدام كل فكرة تضاعف كمية التوليفات). : ص

بالطبع ، أقوم باختبار الطرق واحدة تلو الأخرى ، وليس كلها مرة واحدة (ليس مثل المكون الإضافي للاندماج + dwmflush + أي فكرة جديدة).
يرجى أيضًا في المرة القادمة تضمين الخطوات المحددة لتجربة الفكرة الجديدة ، لذلك لا يتعين علي تخمين إصدارات Godot ، لتشغيل محرر أو لعبة مباشرة ، وما إلى ذلك. ليس لدي الرغبة في تجربة جميع المجموعات الممكنة من كل شيء (باستخدام كل فكرة تضاعف كمية التوليفات). : ص

أفهم أنه غير مذكور في المستندات ، ولا يوجد استيفاء زمني ثابت في جوهره. ربما يجب أن أحاول كتابة شيء ما عن هذا للمستندات ، لم أقم بإضافة الوثائق من قبل.

_النتيجة هي: _
بصرف النظر عن المشكلات الأخرى (دلتا ، نظام التشغيل) ، إذا كنت تستخدم الفيزياء أو تحرك الأشياء في _الفيزياء_العملية ، فإن Godot حاليًا سيعطي توترًا نتيجة التعرج بين علامات الفيزياء والإطارات الفعلية. سيحدث هذا إلى حد ما في جميع مجموعات معدل تحديث / معدل تحديث علامة التجزئة الفيزيائية ، وبعضها سيكون أسوأ من البعض الآخر.

كانت طريقة "إصلاح الارتعاش" محاولة للالتفاف حول هذا الاسم المستعار بجعله يحدث بطريقة أقل وضوحًا (سيظل يحدث). فكر في التعرّف على الدرج.

من أجل منع تذبذب "المستوى الأساسي" هذا ، فإنك تحتاج حاليًا إلى ذلك
1) (متوفر في جميع إصدارات Godot) انقل الكائنات في _العملية وحركها بمسافة تتناسب مع دلتا. هذا ليس مثاليًا للألعاب حيث لا يمكنك استخدام الفيزياء ، والسلوك يعتمد على معدل الإطارات ، ولكن لا بأس في اختبار الارتعاش.

2) (متوفر في Godot 3.2 وما بعده) يستخدم استيفاء زمني ثابت. هذا ممكن حقًا فقط في الإصدار 3.2 باستخدام وظيفة Engine-> get_physics_interpolation_fraction (). راجع https://github.com/lawnjelly/smoothing-addon للحصول على مثال عن كيفية استخدام هذا.

هذه هي المتطلبات الأساسية قبل أن تبدأ بفحص الارتعاش. سيعطون علاقة خطية بين موضع الشيء والوقت ، وهو ما نريده.

هناك طريقة بديلة (أكثر ودية للمبتدئين) لتحقيق ذلك وهي بخطوة زمنية شبه ثابتة ، والتي كانت لدي علاقات عامة منذ يوليو # 30798.

هذا هو أساس البحث العلمي واختبار الفرضيات. الفكرة هي تقليل أكبر عدد ممكن من التأثيرات المربكة وفحص واحد تلو الآخر.

هناك 3 عوامل رئيسية تلعب هنا:

1) العلاقة الخطية بين موضع الكائن والوقت من اللعبة (انظر أعلاه)
2) خطأ في توقيت الإدخال
3) خطأ في توقيت الإخراج

حذف (1) على النحو الوارد أعلاه. استبعد (2) باستخدام وسيطة سطر الأوامر ، ثم يمكنك فحص (3) بمعزل عن غيرها.

وأيضًا ، بالنسبة لأي استقصاء عن الاهتزازات ، يجب أن تقوم بتحريك الأشياء بشكل مباشر ، وليس عن طريق الفيزياء ، حيث من المحتمل أن تضيف الفيزياء توترًا بحد ذاته.

_تعديل:_
لقد ألقيت للتو نظرة على الحد الأدنى من مشروع repro في هذا الموضوع (تفادي الزحف) وهو يتحرك بسرعة * دلتا في _العملية ، والتي يجب أن تكون جيدة. إنها تعتمد على عملية الضغط ، وأنا شخصياً سأزيل ذلك كمشكلة محتملة ، ولكن ربما لا بأس بذلك. إذا كنت تستخدم مشروعًا آخر لاختبار التوتر ، فاحذر من النقاط أعلاه.

lawnjelly فهمت. كان لدي انطباع بأن المكوِّن الإضافي للاستيفاء لا يزال أيضًا شيئًا تم اختباره فقط من قبل عدد قليل من الرجال ، وقد يكون عربات التي تجرها الدواب (وحتى تضيف إلى التوتر). لذلك أخذت ما هو مستقر (3.1.1) ، هكذا يعمل "علمي" بالنسبة لي.
سأحاول مع الاعتبارات الجديدة في المرة القادمة.

لقد ألقيت للتو نظرة على الحد الأدنى من مشروع repro في هذا الموضوع

أنا أستخدم الإصدار الخاص بي من المشروع ، حيث أن الإصدار الأصلي يستخدم الرسوم المتحركة (يمكنه إخفاء الارتعاش) وله كائن رمادي على خلفية رمادية. سوف أقوم بتعديله بحيث يلبي المعايير الخاصة بك.

لذا ، لم يساعدني --fixed-fps 60 حل المشكلة بالنسبة لي.

هذه معلومات مفيدة للغاية. يبدو أن هذا يحرك إصبع اللوم تجاه تأخير الإخراج (والمؤلف) ، ويضفي وزناً على نوع النهج في العلاقات العامة. هذا بافتراض استخدام التخزين المؤقت المزدوج / الثلاثي والحفاظ على تغذية خط الأنابيب ، وليس إسقاط الإطارات.

هل هذا هو الحال أيضًا مع TerminalJack مع وسيطة سطر الأوامر؟

أنا أستخدم مشروعي الخاص ، حيث أن المشروع الأصلي يستخدم الرسوم المتحركة (يمكنه إخفاء الارتعاش) وله كائن رمادي على خلفية رمادية. سوف أقوم بتعديله بحيث يلبي المعايير الخاصة بك.

آه جيد ، شكرا لك! : +1:

lawnjelly فهمت. كان لدي انطباع بأن المكوِّن الإضافي للاستيفاء لا يزال أيضًا شيئًا تم اختباره فقط من قبل عدد قليل من الرجال ، وقد يكون عربات التي تجرها الدواب (وحتى تضيف إلى التوتر).

بعيدًا عن الموضوع قليلاً ، لكن يجب أن يكون جيدًا (لم أتطرق إليه في غضون أسابيع قليلة) ، لا ينبغي أن يتسبب في حدوث توتر. إذا وجدت أي أخطاء ، فأعلمني بمتعقب المشكلة أو حتى قم بإجراء العلاقات العامة. : +1: أنوي وضعه على الإضافات الرسمية لـ 3.2 _عندما أتحرك إليه _: ابتسم:.

تضمين التغريدة

هل هذا هو الحال أيضًا مع TerminalJack مع وسيطة سطر الأوامر؟

آسف ، لم تسنح لي الفرصة لتجربة اقتراحاتك. لقد ذهبت إلى جحر أرنب بشأن القضية التي أعمل عليها.

lawnjelly في مناقشتنا في موضوع العلاقات العامة ، أعتقد أنني سأذكر أنك كنت على صواب بشأن خيار سطر الأوامر --fixed-fps <fps> . في الواقع ، يحافظ على تمكين VSync. لذا ، كما قلت ، يعد استخدامه طريقة جيدة لاستبعاد أي مشكلات في حساب الدلتا. لابد أنني أفسدت الأمر عندما جربته في وقت سابق وكان لدي تأتأة لأن هذا ليس هو الحال الآن.

لقد تم استخدام هذا الخيار جنبا إلى جنب مع التغيرات جهدي لإثبات أن استخدام DwmFlush() لا يساعد عند تشغيل خارج المحرر. إذا قمت بتعطيل DwmFlush() فيمكنك التسبب في تلعثم في اللعبة ببساطة عن طريق سحب بعض النوافذ الأخرى أو تحريك الماوس فوق إحدى المهام قيد التشغيل في شريط المهام. من الواضح ، نظرًا لأن اللعبة تعمل بأولوية "فوق العادي" ، فلا ينبغي أن يحدث هذا. (وهذا لا يحدث إذا تم استخدام DwmFlush() .)