การอัพเดทเรนเดอร์อิสระในเกมลูปคืออะไร?

มีบทความหนังสือและการอภิปรายมากมายในลูปเกม อย่างไรก็ตามฉันมักเจอสิ่งนี้:

while(running)
{
    processInput();
    while(isTimeForUpdate)
    {
        update();
    }
    render();
}

สิ่งที่ทำให้ฉันรำคาญใจเกี่ยวกับวิธีการนี้คือการแสดงผลแบบ "ปรับปรุงอิสระ" เช่นสร้างเฟรมเมื่อไม่มีการเปลี่ยนแปลงเลย ดังนั้นคำถามของฉันคือทำไมวิธีการนี้มักถูกสอน

มีประวัติศาสตร์อันยาวนานของวิธีที่เรามาถึงการประชุมสามัญนี้ด้วยความท้าทายที่น่าสนใจมากมายระหว่างทางดังนั้นฉันจะพยายามกระตุ้นมันในแต่ละขั้นตอน:

1. ปัญหา: อุปกรณ์ทำงานด้วยความเร็วที่แตกต่างกัน

เคยลองเล่นเกม DOS เก่าบนพีซีที่ทันสมัยและมันเล่นได้เร็วอย่างไม่น่าเชื่อ - แค่พร่ามัวหรือเปล่า?

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

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

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

โซลูชัน surefire ที่นี่คือเพื่อล็อคอัตราที่เราทำการอัพเดทเกมเพลย์ ด้วยวิธีนี้เราสามารถรับประกันผลลัพธ์ที่ได้จะเหมือนเดิมเสมอ

2. ดังนั้นทำไมไม่เพียงล็อค framerate (เช่นใช้ VSync) และยังคงเรียกใช้การอัปเดตและการแสดงผลสถานะการเล่นเกมใน lockstep?

สิ่งนี้สามารถใช้งานได้ แต่ผู้ชมอาจไม่พอใจเสมอไป มีเวลานานเมื่อทำงานที่ 30 fps ที่แข็งถือเป็นมาตรฐานทองคำสำหรับเกม ตอนนี้ผู้เล่นคาดหวัง 60 เฟรมต่อวินาทีเป็นแถบขั้นต่ำโดยเฉพาะอย่างยิ่งในเกมแอ็คชั่นแบบผู้เล่นหลายคนและตอนนี้ผู้เล่นเก่า ๆ บางคนก็ดูเหมือนจะเปลี่ยนแปลงเร็วตามที่คาดการณ์ไว้ นอกจากนี้ยังมีกลุ่มแกนนำของผู้เล่น PC โดยเฉพาะอย่างยิ่งที่คัดค้านการล็อกเฟรมทั้งหมด พวกเขาจ่ายเงินจำนวนมากสำหรับฮาร์ดแวร์ที่มีเลือดออกและพวกเขาต้องการที่จะใช้กล้ามเนื้อการคำนวณนั้นเพื่อการเรนเดอร์ที่ราบรื่นและมีความเที่ยงตรงสูงสุดที่มันสามารถทำได้

ใน VR โดยเฉพาะ framerate คือราชาและมาตรฐานยังคงคืบคลาน ในช่วงแรกของการฟื้นตัวของ VR เกมมักจะวิ่งประมาณ 60 เฟรมต่อวินาที ตอนนี้ 90 เป็นมาตรฐานมากขึ้นและแฮร์แวร์เช่น PSVR เริ่มสนับสนุน 120 สิ่งนี้อาจเพิ่มขึ้นอย่างต่อเนื่อง ดังนั้นหากเกม VR จำกัด ขอบเขตของสิ่งที่สามารถทำได้และยอมรับได้ในวันนี้ก็มีแนวโน้มที่จะถูกทิ้งไว้ข้างหลังในขณะที่ฮาร์ดแวร์และความคาดหวังพัฒนาต่อไป

(ตามกฎแล้วระวังเมื่อมีการบอกว่า "ผู้เล่นไม่สามารถรับรู้อะไรเร็วกว่า XXX" เพราะโดยปกติแล้วจะขึ้นอยู่กับ "การรับรู้" บางประเภทเช่นการจดจำเฟรมตามลำดับการรับรู้ความต่อเนื่องของการเคลื่อนไหว ละเอียดอ่อน)

ปัญหาสุดท้ายที่นี่คือเกมที่ใช้ framerate ที่ล็อคไว้จะต้องระมัดระวังเช่นกันหากคุณเคยเล่นเกมที่คุณกำลังอัปเดตและแสดงวัตถุจำนวนมากผิดปกติคุณไม่ต้องการพลาดเฟรมของคุณ กำหนดเวลาและทำให้เกิดการพูดติดอ่างหรือผูกปม ดังนั้นคุณต้องกำหนดงบประมาณเนื้อหาของคุณให้ต่ำพอที่จะออกจากห้องว่างหรือลงทุนในคุณสมบัติการปรับคุณภาพแบบไดนามิกที่ซับซ้อนยิ่งขึ้นเพื่อหลีกเลี่ยงการ pegging ประสบการณ์การเล่นทั้งหมดกับประสิทธิภาพที่แย่ที่สุดในฮาร์ดแวร์ min-spec

นี่อาจเป็นปัญหาโดยเฉพาะอย่างยิ่งหากปัญหาด้านประสิทธิภาพปรากฏขึ้นช้าในการพัฒนาเมื่อระบบที่มีอยู่ทั้งหมดของคุณได้รับการสร้างและปรับแต่งโดยสมมติว่าการเรนเดอร์เฟรมล็อคเฟรมเป็นสิ่งที่คุณไม่สามารถทำได้ การแยกการอัปเดตและอัตราการเรนเดอร์มีความยืดหยุ่นมากขึ้นสำหรับการจัดการกับความแปรปรวนของประสิทธิภาพ

3. การอัปเดตตามเวลาที่กำหนดไม่ได้มีปัญหาเหมือนกับ (2) ใช่หรือไม่

ฉันคิดว่านี่เป็นเนื้อของคำถามเดิม: ถ้าเราแยกการอัปเดตของเราออกและบางครั้งทำให้เฟรมสองเฟรมโดยที่ไม่มีการอัพเดตสถานะของเกมในระหว่างนั้นมันไม่เหมือนกับการเรนเดอร์ lockstep ที่อัตราเฟรมต่ำกว่า หน้าจอ?

จริงๆแล้วมีหลายวิธีที่เกมใช้ในการแยกการปรับปรุงเหล่านี้ออกมาให้ได้ผลดี:

a) อัตราการอัปเดตอาจเร็วกว่าอัตราเฟรมที่แสดงผล

ในฐานะที่เป็น tyjkenn บันทึกในคำตอบอื่นฟิสิกส์โดยเฉพาะอย่างยิ่งมักจะก้าวที่ความถี่สูงกว่าการแสดงผลซึ่งจะช่วยลดข้อผิดพลาดการรวมและให้การชนที่แม่นยำยิ่งขึ้น ดังนั้นแทนที่จะมีการอัพเดต 0 หรือ 1 ระหว่างเฟรมที่แสดงผลคุณอาจมี 5 หรือ 10 หรือ 50

ตอนนี้ผู้เล่นเรนเดอร์ที่ 120 fps สามารถรับการอัพเดตได้ 2 เฟรมต่อเฟรมในขณะที่ผู้เล่นที่ใช้ฮาร์ดแวร์ที่ต่ำกว่าที่ 30 เฟรมต่อวินาทีได้รับ 8 อัปเดตต่อเฟรมและเกมของพวกเขาทั้งสองทำงาน ฮาร์ดแวร์ที่ดีกว่าทำให้ดูราบรื่นขึ้น แต่ไม่ได้เปลี่ยนแปลงการเล่นเกมอย่างสิ้นเชิง

มีความเสี่ยงที่นี่หากอัตราการอัปเดตไม่ตรงกับอัตราเฟรมคุณสามารถรับ "ความถี่ความถี่" ระหว่างสองค่านี้ได้ เช่น. เฟรมส่วนใหญ่เรามีเวลาเพียงพอสำหรับการอัปเดตสถานะของเกม 4 รายการและเหลืออีกเล็กน้อยดังนั้นทุกครั้งที่เรามีการบันทึกมากพอที่จะอัปเดต 5 ครั้งในเฟรมทำให้กระโดดหรือพูดติดอ่างเล็กน้อยในการเคลื่อนไหว สามารถแก้ไขได้โดย ...

b) การสอดแทรก (หรือการคาดการณ์) สถานะของเกมระหว่างการอัพเดท

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

เมื่อทำถูกต้องสิ่งนี้ทำให้การเคลื่อนไหวรู้สึกเหมือนเนยลื่นและยังช่วยปกปิดความผันผวนบางอย่างในอัตราเฟรมตราบใดที่เราไม่ลดลงต่ำเกินไป

c) การเพิ่มความราบรื่นให้กับการเปลี่ยนแปลงที่ไม่ใช่เกมเพลย์

แม้ว่าจะไม่มีการแก้ไขปัญหาการเล่นเกมเราก็ยังสามารถได้รับชัยชนะอย่างราบรื่น

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

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

4. ทำไมไม่ใช้สไตล์ (c) สำหรับทุกอย่าง? ถ้ามันใช้งานได้กับอนิเมชั่นและ UI เราไม่สามารถปรับขนาดการอัปเดตสถานะการเล่นเกมของเราให้ตรงกับอัตราเฟรมปัจจุบันได้หรือไม่

ใช่ * เป็นไปได้ แต่ไม่ง่าย

คำตอบนี้มีมานานแล้วดังนั้นฉันจะไม่เข้าไปดูรายละเอียดเต็มไปหมดเพียงแค่บทสรุปอย่างย่อ:

• การคูณด้วยdeltaTimeงานเพื่อปรับให้เข้ากับการอัปเดตความยาวผันแปรสำหรับ การเปลี่ยนแปลงเชิงเส้น (เช่นการเคลื่อนไหวด้วยความเร็วคงที่, การนับถอยหลังของตัวจับเวลาหรือความคืบหน้าตามเส้นเวลาภาพเคลื่อนไหว)

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

• โดยเฉพาะอย่างยิ่งผลลัพธ์ของการตรวจจับการชนกันโดยไม่ตั้งใจและความละเอียดขึ้นอยู่กับอัตราการอัปเดตซึ่งนำไปสู่ข้อผิดพลาดในการทันเนลและการสั่นสะเทือนหากเฟรมยาวเกินไป ดังนั้นตัวแปรที่เป็นตัวแปรบังคับให้เราใช้วิธีการตรวจสอบการชนกันอย่างต่อเนื่องที่ซับซ้อนและมีราคาแพงมากขึ้นกับเนื้อหาของเรามากขึ้นหรือยอมรับความแปรปรวนในฟิสิกส์ของเรา แม้กระทั่งการตรวจจับการชนอย่างต่อเนื่องจะพบกับความท้าทายเมื่อวัตถุเคลื่อนที่เข้าโค้งต้องใช้เวลาประทับสั้นลง ...

ดังนั้นในกรณีทั่วไปสำหรับเกมที่มีความซับซ้อนปานกลางการรักษาพฤติกรรมและความเป็นธรรมที่สอดคล้องกันอย่างสมบูรณ์ผ่านการdeltaTimeปรับสเกลนั้นอยู่ระหว่างความยากลำบากมากและการบำรุงรักษาอย่างเข้มข้นจนถึงความเป็นไปไม่ได้ทันที

การกำหนดอัตราการอัปเดตมาตรฐานให้เรารับประกันพฤติกรรมที่สอดคล้องกันมากขึ้นในทุกช่วงของเงื่อนไขมักใช้รหัสที่ง่ายกว่า

การรักษาอัตราการปรับปรุงที่หลุดพ้นจากการแสดงผลจะช่วยให้เรามีความยืดหยุ่นในการควบคุมความเรียบเนียนและประสิทธิภาพการทำงานของประสบการณ์โดยไม่ต้องเปลี่ยนตรรกะเพลย์

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

คำตอบอื่น ๆ นั้นดีและพูดคุยเกี่ยวกับสาเหตุของการวนซ้ำของเกมที่มีอยู่และควรแยกจากลูปการเรนเดอร์ อย่างไรก็ตามสำหรับตัวอย่างเฉพาะของ "เหตุใดจึงสร้างเฟรมเมื่อไม่มีการเปลี่ยนแปลง" มันเพิ่งมาลงกับฮาร์ดแวร์และความซับซ้อน

การ์ดแสดงผลเป็นเครื่องจักรของรัฐและพวกเขาทำได้ดีมากในการทำสิ่งเดียวกันซ้ำแล้วซ้ำอีก หากคุณแสดงเฉพาะสิ่งที่มีการเปลี่ยนแปลงจริง ๆ แล้วมันมีราคาแพงกว่าไม่น้อยกว่า ในสถานการณ์ส่วนใหญ่ไม่มีอะไรที่คงที่ถ้าคุณเลื่อนไปทางซ้ายเล็กน้อยในเกม FPS คุณเปลี่ยนข้อมูลพิกเซลเป็น 98% ของสิ่งต่าง ๆ บนหน้าจอคุณอาจแสดงผลทั้งเฟรม

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

การออกแบบฮาร์ดแวร์และอื่น ๆ นั้นได้รับการปรับให้เหมาะสมที่สุดสำหรับการประชุมปัจจุบันและเครื่องของรัฐก็เป็นแบบอย่างที่ดีสำหรับการเริ่มต้น

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

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

การสร้างอย่างหนึ่งในคำถามของคุณสามารถทำให้รู้สึกว่าระบบย่อยการแสดงผลที่มีความคิดบางส่วนของ"เวลาผ่านไปนับตั้งแต่ที่ผ่านมาทำให้"

ตัวอย่างเช่นพิจารณาวิธีการที่ตำแหน่งของวัตถุในโลกของเกมถูกแสดงผ่าน(x,y,z)พิกัดคงที่ด้วยวิธีการที่เก็บเวกเตอร์การเคลื่อนไหวปัจจุบัน(dx,dy,dz)เพิ่มเติม ตอนนี้คุณสามารถเขียนห่วงเกมของคุณเพื่อให้การเปลี่ยนแปลงของตำแหน่งที่มีการเกิดขึ้นในupdateวิธี แต่คุณยังสามารถออกแบบเพื่อให้การเปลี่ยนแปลงของการเคลื่อนไหวupdateที่มีการเกิดขึ้นในช่วง ด้วยวิธีการหลังแม้ว่ารัฐเกมของคุณจริงจะไม่เปลี่ยนจนกว่าจะมีการต่อไปupdateเป็นrenderฟังก์ชั่นที่เรียกว่าที่ความถี่สูงกว่าสามารถวาดวัตถุที่ตำแหน่งที่อัปเดตแล้วเล็กน้อย ในขณะที่เทคนิคนี้นำไปสู่ความแตกต่างระหว่างสิ่งที่คุณเห็นและสิ่งที่เป็นตัวแทนภายในความแตกต่างมีขนาดเล็กพอที่จะไม่สำคัญสำหรับแง่มุมในทางปฏิบัติส่วนใหญ่

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

นอกจากคำตอบอื่น ๆ ...

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

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