ประโยชน์ของการกำหนดเฟรมต่อวินาทีคืออะไร (ถ้ามี)

ฉันกำลังทำงานกับเกมง่ายๆใน OpenGL โดยใช้ SDL สำหรับการเริ่มต้นการแสดงผลและการป้อนข้อมูลและปรากฏในแง่ของเวลาที่ฉันมีสองตัวเลือกให้ฉัน หมายเลขหนึ่งที่กำลังนอนหลับสำหรับ optimTimePerFrame - theTimeTakenToRender, เมื่อ optimTimePerFrame ในวินาที = 1 / theFramerateCap (ฉันไม่แน่ใจว่าสิ่งนี้จำเป็นหรือไม่เพราะมันเทียบเท่ากับการใช้ vsync ซึ่งอาจแม่นยำกว่านี้ถ้าการสันนิษฐานของฉันถูกต้องกรุณาบอกฉันทีว่า SDL + OpenGL มี vsync เป็นค่าเริ่มต้นหรือไม่อย่างไร เพื่อเปิดใช้งาน) ส่วนอีกอันคือการวัดเวลาตั้งแต่เฟรมสุดท้ายแสดงผลและปรับการเคลื่อนไหวตามนั้น (เวลาที่สั้นลงในการเรนเดอร์เฟรมจะทำให้เอนทิตีน้อยเคลื่อนไปในเฟรมนั้น) ในแง่ของประสิทธิภาพและการลดการสั่นไหว ฯลฯ ข้อดีและข้อเสียของสองวิธีนี้คืออะไร

หากกรอบเวลาของคุณเป็นที่คาดเดาไม่ได้ (หรือไม่นี้เป็นความผิดของคุณ OS อาจจะใช้ทรัพยากรบางครั้ง ฯลฯ ) สูงสุดที่กำหนดให้เป็นอัตราเฟรมที่คาดการณ์ที่ค่อนข้างต่ำกว่าอัตราเฟรมทำได้คุณจะทำมากสำหรับการคาดการณ์แฝงซึ่งสามารถ ทำให้เกมรู้สึกดีขึ้นมาก

การเปลี่ยนระยะเวลาเมื่อคุณประมวลผลอินพุตและแสดงการเปลี่ยนแปลงที่เกี่ยวข้องกับอินพุตนั้นจะรู้สึกไม่ดี - แม้ว่าโดยเฉลี่ยแล้วคุณจะมีเวลาแฝงน้อยลงระหว่างสองสิ่งนี้ "กระวนกระวายใจ" สามารถสังเกตเห็นได้โดยมนุษย์

ดูการนำเสนอของ Microsoft GameFest สิ่งที่อยู่ในเฟรม: การฉีกขาดความหน่วงและอัตราเฟรมสำหรับข้อมูลเชิงลึกที่นี่ Carmack ยังมีชุดของโพสต์บล็อกที่มีประโยชน์ในการนี้

นอกจากนี้โปรดทราบว่าคณิตศาสตร์บางตัวสามารถแยกย่อยเมื่อคุณเรียกใช้เฟรมโดยใช้deltaTค่าต่ำ- หรือแม้กระทั่งเมื่อคุณใช้ตัวแปรdeltaTเลย (สิ่งต่าง ๆ อาจกลายเป็นยากขึ้นหรือยากที่จะทำในลักษณะ "เสถียร" และคาดการณ์ได้ซึ่งสำคัญสำหรับสิ่งต่าง ๆ เช่นไกลและการซิงโครไนซ์เครือข่ายบางรูปแบบ) ดูFix Timestep ของคุณสำหรับข้อมูลเชิงลึกที่นี่

คุณจะจบลงด้วยการใช้ซีพียูน้อยลง (ผู้ทำงานหลายคนจะขอบคุณ) และผู้คนบนอุปกรณ์มือถือก็จะชอบสิ่งนี้เช่นกัน

คุณไม่ควรใช้ Sleep เพื่อควบคุมอัตราเฟรมเสมอไป

สิ่งนี้เกิดขึ้นก่อนหน้าแล้วและฉันจะแนะนำคุณไปยังคำถามอื่นสำหรับการอภิปรายถึงเหตุผลว่าทำไม สิ่งหนึ่งที่ไม่ได้กล่าวถึงคืออัตราการรีเฟรชที่ทันสมัยโดยทั่วไปที่ 60Hz และด้วยความละเอียดระดับ 1 มิลลิวินาทีโดยทั่วไปของการโทรแบบสลีปจึงเป็นไปไม่ได้ที่จะนอนหลับตามระยะเวลาที่ถูกต้องระหว่างเฟรม

ฉันไม่ได้บอกว่าให้ CPU ถ้าคุณไม่ทำอะไรเป็นเรื่องเลวร้าย ไกลจากมัน. แต่มันไม่เหมือนกับการควบคุม framerate และ Sleep เป็นวิธีการแก้ปัญหาที่เหมาะสมสำหรับอดีต แต่ไม่ใช่อย่างหลัง

แทนที่จะตรวจสอบเวลาที่ผ่านไปและถ้าถึงเวลาที่จะเรียกใช้เฟรมให้ทำเช่นนั้นมิฉะนั้น - และหากคุณต้องการให้ CPU บางตัว - สลีปสำหรับเวลาขั้นต่ำเปล่า - 1 มิลลิวินาที นอกจากนี้ให้แน่ใจว่าตัวตั้งเวลาปิดเครื่องของคุณได้รับการตั้งค่าอย่างเหมาะสมสำหรับแพลตฟอร์มของคุณเพื่อให้ความละเอียดที่ดี นั่นคือเมื่อคุณออกคำว่า "Sleep (1)" โทรหาคุณจริง ๆ แล้วมีโอกาสนอนได้ 1 มิลลิวินาทีแทนที่จะเป็น 15, 20 หรือ 30 (ซึ่งจะเป็นอย่างอื่น) ฉันเชื่อว่า SDL จะทำสิ่งนี้ให้คุณโดยอัตโนมัติ

นอกจากนี้คุณยังสามารถสร้างความหย่อนลงได้เพื่อที่ว่าหากเวลาใกล้จะวิ่งเฟรมคุณจะหยุดการนอนและเริ่มวิ่งแบนจนเฟรมวิ่งซึ่งจะช่วยให้คุณตีกรอบช่วงเวลาที่คุณต้องการได้แม่นยำยิ่งขึ้น

สิ่งนี้จบลงด้วยการมองเป็นกลุ่มของ Sleep (1) การโทรสลับกับกรอบเป็นครั้งคราวและนั่นก็โอเค คุณยังคงยอมแพ้ซีพียูเมื่อคุณไม่ต้องการมัน แต่เฟรมของคุณจะยังสามารถทำงานได้ทันเวลา

อาจเป็นประโยชน์ที่สำคัญที่สุดของอัตราเฟรมสูงสุดที่กำหนดว่าสามารถช่วยป้องกันความเสียหายทางกายภาพที่แท้จริงของเครื่อง พวกเขาลืมที่จะทำเช่นนี้กับ Starcraft II ซึ่งกลายเป็นปัญหามาก (และมีราคาแพง) สำหรับผู้ใช้บางคนจนกระทั่งพวกเขาทำการปะแก้

ดังที่ได้กล่าวไว้ก่อนหน้านี้มันลดการใช้งาน CPU ที่ flipside และที่สำคัญยิ่งกว่านั้นก็จะทำให้แบตเตอรี่หมด เป็นตัวอย่างที่ดี FTL ทำงานที่ CPU เกือบ 100% ใน MBA ของฉัน ทำให้แบตเตอรี่หมดเร็วกว่า 2 ชั่วโมงและร้อนมาก (เนื่องจากผลลัพธ์โดยตรงมากขึ้นฉันถอนการติดตั้งและไม่เล่นอีกต่อไป ... ) กรอบหมวกจะป้องกันสิ่งนี้

ข้อได้เปรียบอีกอย่างหนึ่งคือถ้าเป็นเกมที่มีผู้เล่นหลายคนคุณจะได้เลเวลของสนามเด็กเล่นด้วยการมอบประสบการณ์ที่เหมือนกันให้กับทุกคน