ถ้าไม่ใช่ dev คงไม่มีทางรู้นะผมว่า (ฮา) หรือเราจะหารอมมาแล้วต่อ debugger เถื่อนดี

ส่วนตัวผมว่า ก็อาจจะเป็น event-driven ได้ครับ คือเรามี game object แล้วแต่ละ object ก็ spawn event ออกมา แล้วก็มี Handler มารับไป ฯลฯ แต่ event ทั้งหมดจะถูก process ใน frame เดียวกัน ไม่ใช่ว่าทำแยกออกจาก rendering ครับ ไม่งั้นจะเกิดปัญหาการ synchronization คือมันไม่ใช่แบบ กดปุ่ม A แล้วไปกระโดดในอีก 3 เฟรมข้างหน้า แบบนี้ไม่ได้ input ของเฟรมไหนต้องทำงานในเฟรมนั้น

ปรกติแล้วโครงสร้างของเกมมันจะมีโค๊ดประมาณว่า

state_t state{};
while(true) {
  auto input = read_input();
  state = process(state, input);
  render(state);
}

(อันนี้โค๊ดผมนะ โค๊ดคนอื่นก็คงเขียนแตกต่างกันออกไป แล้วก็เขียนย่อสุด ๆ ด้วย อย่างเรื่อง frame time นี่ผมตัดไปก่อนละกัน คิดซะว่ามันเป็นโค๊ด Doom ที่รันบนเครื่องตรวจครรภ์ก็ได้ครับ 555)

ถ้าจะทำ Multi-thread เท่าที่เคยอ่าน (คือสมัยผมเขียนเอนจินเอง ผมเขียนแค่ single-thread น่ะครับ 555) เค้าจะใช้วิธีการแตก thread ในแต่ละขั้นตอนให้ทำงานย่อย ๆ พร้อมๆ กัน เช่นขั้นตอน process เองก็อาจจะทำการคำนวน state ใหม่ของหลาย ๆ Object ในฉากพร้อมๆ กัน ส่วนขั้นตอน render ก็จะอัพเดตพวก VBO, image, ฯลฯ (ตรงนี้ลืมหมดแล้ว api ใหม่ๆ ก็คงมีอะไรอย่างอื่นอีก) เหมือน ๆ กันหมด คือจะต้องรอให้ process เสร็จก่อนแล้วค่อย render ทีเดียว เพราะถ้า process ไป render ไป ก็มีโอกาสที่ภาพกับ state ไม่ตรงกันได้ อะไรงี้ครับ

ที่จริง จะเขียน process กับ rendering เป็น 2 thread แยกกันก็ได้ (แล้วให้แต่ละ thread ไปแตก task ย่อย ๆ เอง) แต่ว่าการ sync ข้อมูลก็จะ sync กันทีเดียวพร้อม ๆ กันทุก object ในฉาก ไม่ใช่ว่าเฮ้ยทำอันไหนเสร็จแล้วเอาไปก่อน แบบนี้เจ๊งครับ ส่วนตัวผมว่า มันก็เวิร์คถ้าเรา process กับ render ด้วยความถี่ที่แตกต่างกัน แต่ดูแล้วการ sync ข้อมูลกันมันดูน่าปวดหัวแปลกๆ และอาจจะเกิด deadlock/livelock ได้ด้วย ส่วนข้อดีคือไม่ว่า hw จะช้าหรือเร็ว การคำนวนจะเกิดด้วยความถี่เท่ากัน ดังนั้นไอ้เรื่องแบบใครใช้ hw แรงๆ เฟรมไทม์สั้น ๆ แล้วได้เปรียบ ก็จะไม่เกิดครับ

ทีนี้ เครื่องเกมสมัยนี้เป็น multi-core หมดแล้ว อย่าง Nintendo Switch ก็ใช้ Tegra X1 ที่มี Cortex-A57 4 คอร์ (จริง ๆ เคยมีอีกสี่คอร์ แต่ปิดไป) ผมเดาว่านอกจากมือใหม่มาก ๆ คงไม่เขียน single-thread แล้วล่ะครับ แต่การแตก thread ก็อย่างที่ว่า คือไม่ใช่มีหลาย ๆ เธรดทำงานหลายๆ อย่างพร้อมกันตลอดเวลา แต่จะเป็นการทำงานเป็นอย่างๆ ให้เสร็จทั้งหมดแล้ว terminate

ทั้งนี้มันก็อาจจะมี thread บาง thread ที่ทำงานตลอดเวลาบ้างเหมือนกันครับ เช่น audio mixer แต่ก็ขึ้นกับการออกแบบครับ จะเขียนเป็น synchronized ก็ได้เหมือนกัน (mixer thread นี่ ขอให้เติมดาต้าลงบัฟเฟอร์ได้ทันก่อนอันเดอร์รัน ก็เป็นอันใช้ได้)

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

ส่วนเรื่องทำไมเฟรมเรทต่ำ

ผมเดาว่า ... object ในฉากมันเยอะครับ ซีพียูทำงานไม่ทันมั้ง คือกราฟิคมันไม่ได้หนี arceus เท่าไหร่เลยน่ะครับ

ไม่รู้เอาออกทำไม หรือแยกการพัฒนาเป็นสองสายก็ไม่รู้