Adaptive Tile Refresh ของ Commander Keen

 (fabiensanglard.net)
2 คะแนน โดย GN⁺ 2023-07-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Adaptive Tile Refresh (ATR) คือเทคนิคการเลื่อนหน้าจอที่ Commander Keen 1–3 ใช้เพื่อหลีกเลี่ยงการรีเฟรชทั้งหน้าจอที่ช้าของ EGA โดยทำให้วาดซ้ำเฉพาะ ไทล์ที่เปลี่ยนไป แทนที่จะวาดทั้งหน้าจอ
  • EGA mode Dh เก็บหน้าจอ 320x200 16 สี แยกเป็น 4 เพลน (C0~C3) และถ้าเขียนข้อมูลทั้งหน้าจอ 32KiB ผ่านบัส ISA ทุกเฟรม จะทำได้เพียงประมาณ 5fps ทำให้รีเฟรชที่ 60Hz ได้ยาก
  • ATR ใช้รีจิสเตอร์ CRTC_START, OFFSET, PEL เพื่อจัดการการเลื่อนแนวตั้งและแนวนอนภายในหน้าจอเสมือน และเมื่อถึงขอบ จะใช้ jolt เพื่อย้ายจุดอ้างอิงของหน้าจอกลับ จากนั้นเขียนทับเฉพาะไทล์ที่จำเป็นลงใน VRAM
  • ต้นทุนของ jolt ขึ้นอยู่กับจำนวนไทล์ที่ต้องวาดใหม่ ในตัวอย่างของ Commander Keen 1 มีไทล์ที่เปลี่ยนเพียง 40 ไทล์ จาก 250 ไทล์ จึงวาดใหม่แค่ 16% ของทั้งหน้าจอ และการออกแบบแผนที่ที่มีไทล์ซ้ำจำนวนมากเป็นปัจจัยสำคัญต่อประสิทธิภาพ
  • Commander Keen 4–6 เปลี่ยนจาก ATR ไปใช้ wraparound ของ aperture VRAM ขนาด 64KiB เพื่อแพนหน้าจอไปเรื่อย ๆ และวาดเฉพาะ แถบขอบที่เพิ่งปรากฏขึ้น แทน ซึ่งทำให้เกิดปัญหาความเข้ากันได้กับการ์ด Super VGA บางรุ่นเมื่อเข้าสู่หน่วยความจำที่ยังไม่ได้เริ่มต้นค่า

ข้อจำกัดแบนด์วิดท์ที่เจอบน EGA

  • Commander Keen ทำงานได้ดีที่สุดบนพีซีที่ติดตั้ง EGA (Enhanced Graphic Adapter) และการเขียนโปรแกรมกราฟิกทำผ่านรีจิสเตอร์สำหรับตั้งค่าและ หน้าต่างหน่วยความจำ 64KiB ที่แมปกับ VRAM
  • EGA เก็บข้อมูลภายในไว้ใน 4 เพลน ได้แก่ C0, C1, C2, C3
    • C0 เก็บบิตต่ำสุด (LSB) ของค่าพิกเซล 4 บิตแต่ละค่า
    • C3 เก็บบิตสูงสุด (MSB)
    • แต่ละเพลนประกอบด้วย 200 แถว แถวละ 40 ไบต์
  • โครงสร้าง 4 แบงก์ถูกออกแบบมาเพื่อให้มีแบนด์วิดท์เพียงพอตามการแสดงผลของจอ CRT และ CRTC จะอ่านข้อมูล 4 ไบต์แบบขนาน
  • EGA mode Dh ที่ Commander Keen ใช้ให้ ความละเอียด 320x200 และ 16 สี
    • ไม่ได้ใช้วิธีประกอบค่าสีหมึกใหม่จากค่าสี 64 ค่าเหมือน mode 10h
    • แม้ใน mode Dh ก็สามารถเปลี่ยนสีในพาเลตภายในชุด 16 สีพื้นฐานได้ จึงถูกใช้กับเอฟเฟกต์ fade in/out แบบเรียบง่ายของ Commander Keen

การหลีกเลี่ยงการวาดทั้งหน้าจอใหม่ด้วย Adaptive Tile Refresh

  • คอขวดหลักที่ ATR แก้คือ แบนด์วิดท์
  • การเขียนค่าพิกเซล 4 บิตของภาพ 320x200 หรือประมาณ 32KiB ทุกเฟรม เป็นภาระที่หนักเกินไปสำหรับบัส ISA
  • ลูปแบบง่ายที่อัปเดตทั้งหน้าจอทุกครั้งทำได้เพียงประมาณ 5 เฟรมต่อวินาที
  • EGA มีวิธีเขียนลง 4 แบงก์พร้อมกันด้วย ซึ่งช่วยในการล้างหน้าจอหรือการทำซ้ำคอลัมน์ของ Wolfenstein 3D ได้ แต่ไม่เหมาะกับปัญหาการเลื่อนหน้าจอของ Commander Keen

การเลื่อนหน้าจออย่างลื่นไหลด้วยรีจิสเตอร์

  • ATR เริ่มจากสร้าง หน้าจอเสมือน ที่ใหญ่กว่าหน้าจอจริงไว้ใน VRAM แล้วเปลี่ยนค่า CRTC_START ซึ่งกำหนดว่า CRTC จะเริ่มอ่านจากจุดใด เพื่อเลื่อนพื้นที่แสดงผล
  • การเลื่อนแนวตั้งค่อนข้างตรงไปตรงมา
    • ถ้าเพิ่ม 16 แถวไว้ทั้งด้านบนและด้านล่างของหน้าจอที่แสดง จะใช้ 40 x 232 = 9,280 ไบต์ต่อเพลน
    • เมื่อต้องเลื่อนหน้าจอขึ้นหนึ่งแถว ให้เพิ่ม CRTC_START ขึ้น 40 ไบต์
    • เมื่อต้องเลื่อนหน้าจอลงหนึ่งแถว ให้ลด CRTC_START ลง 40 ไบต์
  • การเลื่อนแนวนอนใช้รีจิสเตอร์ OFFSET ร่วมกับรีจิสเตอร์ PEL
    • เมื่อตั้ง OFFSET เป็น 2 จะเพิ่ม padding 16 ไบต์ระหว่างแถว ทำให้หน้าจอเสมือนมีระยะเผื่อด้านซ้ายและขวาฝั่งละ 16 พิกเซล
    • หากเพิ่ม CRTC_START ขึ้น 1 หน้าจอจะขยับทีละ 8 พิกเซล เพราะโครงสร้างแบบเพลน จึงหยาบเกินไป
    • Horizontal Pel Panning หรือรีจิสเตอร์ PEL ทำให้ข้ามได้สูงสุด 7 บิตหลัง CRTC_START จึงทำให้ เลื่อนแนวนอนระดับพิกเซล ได้
  • การขยับซ้ายขวาจริงทำโดยปรับ CRTC_START ด้วยค่าพิกัดหาร 8 และตั้ง PEL ด้วยเศษของพิกัด (% 8)

jolt และการอัปเดตบางส่วนระดับไทล์

  • เมื่อถึงขอบของหน้าจอเสมือน ATR จะทำ jolt เพื่อจัดหน้าจอเสมือนกลับมากึ่งกลางอีกครั้ง
  • ถ้าวาดทั้งหน้าจอใหม่จะใช้เวลาประมาณ 200ms และตกลงเหลือ 5fps ดังนั้น jolt จึงทำงานด้วยการเขียนทับเฉพาะไทล์ที่เปลี่ยน แทนการวาดทั้งหน้าจอใหม่
  • เลเวลของ Commander Keen สร้างจาก ไทล์ 16x16
    • เมื่อศิลปินวาดไทล์ ระบบ build จะกำหนด ID เฉพาะให้แต่ละไทล์
    • นักออกแบบเลเวลวาง ID ของไทล์ในตัวแก้ไขแบบ 2D เพื่อสร้างแผนที่
    • เอนจินติดตามว่าในหน้าจอเสมือนมี ID ไทล์ใดอยู่บ้าง
  • ณ ช่วงที่เกิด jolt จะเปรียบเทียบ ID ไทล์ ระหว่างสถานะปัจจุบันของหน้าจอเสมือนกับสถานะเป้าหมายหลังจัดกลับมากึ่งกลาง
    • ไทล์ที่เหมือนกันจะถูกข้าม
    • เขียนทับลง VRAM เฉพาะไทล์ที่ต่างกัน
  • ประสิทธิภาพของ jolt แปรผกผันกับจำนวนไทล์ที่ต้องวาดใหม่ ดังนั้นนักออกแบบเกมจึงต้องจัด tilemap ให้มี ไทล์ซ้ำ จำนวนมาก
  • ในตัวอย่างของ Commander Keen 1 เมื่อเลื่อนไปทางขวาอย่างลื่นไหลจนสุดหน้าจอเสมือนและเกิด jolt ไปทางซ้าย 16 พิกเซล มีไทล์ที่เปลี่ยนเพียง 40 ไทล์ จาก 250 ไทล์
    • สัดส่วนที่วาดใหม่คือ 16% ของทั้งหน้าจอ
  • เหนือพื้นหลังจะมีการวาดเลเยอร์สไปรต์
    • เอนจินเก็บรายการพิกัดไทล์สกปรกที่ถูกสไปรต์เขียนทับ
    • ในแต่ละเฟรมใหม่ จะวนผ่านรายการสกปรกเพื่อกู้คืนไทล์พื้นหลัง แล้วจึงวาดสไปรต์ใหม่

ดับเบิลบัฟเฟอร์และ drifting ในไตรภาคที่สอง

  • เพื่อหลีกเลี่ยงอาร์ติแฟกต์ทางภาพ ระบบทั้งหมดถูกทำซ้ำเป็น เฟรมบัฟเฟอร์สองชุด
    • ขณะที่ CRTC อ่านจากชุดหนึ่ง อีกชุดหนึ่งสามารถถูกเขียนในตำแหน่งอื่นของ VRAM ได้
    • แต่ละบัฟเฟอร์ใช้ (320 + 32) * (200 + 32) * 4 / 8 = 40,832 ไบต์
    • ดับเบิลบัฟเฟอร์ทั้งหมดใช้ 40,832 * 2 = 81,664 ไบต์ ซึ่งเกิน 64KiB ของการ์ด EGA ดั้งเดิมจาก IBM
  • ตามข้อมูลของ VileR มีเพียงบอร์ด IBM EGA ดั้งเดิมเท่านั้นที่ติดตั้ง 64KiB และ EGA clone ส่วนใหญ่ที่ออกมาราวปี 1986–1987 ติดตั้ง 256K โดย ณ เวลาที่ Commander Keen วางจำหน่าย แทบไม่มีการ์ด EGA ที่มีหน่วยความจำน้อยกว่า 256K แล้ว
  • ใน Commander Keen 1–3 ลวดลายซ้ำที่ ATR ต้องการจะเห็นเด่นชัดบนหน้าจอ แต่ใน Commander Keen 4–6 ลักษณะดังกล่าวไม่ชัดเจนเท่าเดิม
  • ไตรภาค Keen ชุดที่สองใช้พฤติกรรม wraparound ที่เมื่อ CRTC_START แตะท้ายบล็อก 64KiB แล้วจะกลับไปยังต้นบล็อกอีกครั้ง
    • แพนหน้าจอต่อเนื่องและวาดเฉพาะ แถวไทล์ขอบที่เพิ่งปรากฏใหม่
    • เมื่อ jolt หายไป ความจำเป็นในการสร้างฟิลด์ซ้ำสีคล้ายกันก็ลดลง
  • วิธีนี้ใกล้เคียงกับการปรับปรุงเพื่อกำจัด jolt มากกว่าการเพิ่มฟีเจอร์ใหม่
    • องค์ประกอบของดับเบิลบัฟเฟอร์ทั้งสองชุด drift ผ่านพื้นที่ VRAM ด้วยความเร็วเดียวกัน จึงไม่ทับซ้อนกัน
    • โดยส่วนใหญ่ทำงานได้ดี
  • การ์ด Super VGA บางรุ่นเกิดปัญหา
    • ในการ์ดที่มีการติดตั้งต่างจากมาตรฐานและมีหน่วยความจำมากกว่า อาจไม่ wraparound จากท้ายกลับไปต้น แต่เข้าไปยังหน่วยความจำจริงที่มีอยู่และยังไม่ได้เริ่มต้นค่าแทน
    • Carmack เลือกวิธีแก้ที่ง่ายกว่า คือเมื่อถึงปลายหน้าจอให้ยอมเกิด hitch แล้วคัดลอกทั้งหน้าจอขึ้นด้านบน แทนที่จะรองรับการ์ดนอกมาตรฐานหลายรุ่นแยกกัน
  • เทคนิค drifting นี้อาจทำให้ไม่สามารถใช้วิธีเก็บไทล์และสไปรต์ไว้ใน VRAM เพื่อคัดลอก VRAM-to-VRAM อย่างรวดเร็วได้ แต่ปริมาณที่ต้องวาดในแต่ละเฟรมน้อยมาก จึงน่าจะไม่ใช่ปัญหาใหญ่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-29
ความคิดเห็นจาก Hacker News

  • ความลื่นไหลของการเลื่อนฉากใน Commander Keen 4~6 เป็นสิ่งที่ไม่มีเกมไหนบน PC ตามทันได้อยู่หลายปี แม้หลังจากเกมต่าง ๆ ย้ายไปใช้กราฟิก 256 สีแล้วก็ตาม
    ด้วยงานเทคนิคอันน่าทึ่งของ John Carmack และงานศิลป์พาเลต 16 สีของ Adrian Carmack ทำให้ id กลายเป็นผู้สร้างเกมแพลตฟอร์มบน PC ที่ดูดีที่สุดช่วงหนึ่งในทศวรรษ 1990
    Adrian Carmack ไม่ได้เป็นญาติกับ Carmack ที่โด่งดังกว่า แต่ผมมองว่าเขาเป็นยอดฝีมือที่ซ่อนอยู่ของพาเลต 16 สี

    • รู้สึกค่อนข้างแปลกที่เกม Commander Keen คลาสสิกทั้งหมดถูกพัฒนาและวางจำหน่ายระหว่างเดือนธันวาคม 1990 ถึงธันวาคม 1991
      ความเร็วในการพัฒนาด้านกราฟิกและเกมเพลย์นั้นมหาศาลจริง ๆ
      การเปลี่ยนแปลงจากเกมแรก: https://en.wikipedia.org/wiki/Commander_Keen_in_Invasion_of_...
      การเปลี่ยนแปลงจนถึงเกมสุดท้าย: https://en.wikipedia.org/wiki/Commander_Keen_in_Goodbye,_Gal...
      ตอนนั้นผมเล่นเองตอนยังเป็นเด็ก และลืมไปแล้วว่าเรื่องทั้งหมดเกิดขึ้นรวดเร็วขนาดนั้น
    • ถ้าพูดถึงเกมแพลตฟอร์มบน PC ที่ดูดีที่สุดช่วงหนึ่งในทศวรรษ 1990 ผมจะเลือก Prince Of Persia
      ไม่ได้จะดูแคลน Commander Keen แต่ผมรู้สึกว่างานภาพและกลไกเกมของ PoP นั้นโดดเด่นไม่เหมือนใครตามมาตรฐานยุคนั้น
      ตอนเล่นครั้งแรกตอนอายุราว 7 ขวบ มันให้ความรู้สึกเหมือนเวทมนตร์ และถึงตอนนี้ก็ยังเป็นเกมแพลตฟอร์มที่ผมชอบที่สุด เลยยอมรับว่ามีอคติอยู่บ้าง
      แน่นอนว่า PoP ไม่มีการเลื่อนฉากเลย และตรงนั้นคือมนตร์ดำของ Commander Keen
    • อาจเป็นมุมมองเมื่อมองย้อนกลับไปตอนนี้ แต่ การพัฒนาเชิงนวัตกรรม หลายอย่างแบบนี้ เมื่อเทียบกับการพัฒนาในปัจจุบันแล้วดูค่อนข้างเรียบง่าย
      แนวคิดว่า “หน่วยความจำช้า งั้นวาดใหม่เฉพาะส่วนที่เปลี่ยนก็พอ” ตอนนี้แทบจะเป็นเรื่องสามัญสำนึกแล้ว
      ถึงอย่างนั้น การปรับแต่งในภาค 4~6 ก็น่าสนุกดี อีกจุดที่น่าสนใจคือในภาค 1~3 พวกเขาทำงานทั้งหมดบนสมมติฐานว่าบัฟเฟอร์ไม่ wrap แต่ในความเป็นจริงมัน wrap ทำให้งานนั้นกลายเป็นสิ่งไร้ประโยชน์
    • แล้ว Jazz Jackrabbit ล่ะ? เกมนั้นก็เลื่อนฉาก VGA ได้ลื่นมากจริง ๆ

  • ผมเคยสร้าง เกมแบบไทล์ ด้วย DirectX 5 บน Windows 98 และตอนแรกก็ implement วิธีที่คล้ายกับที่บทความนี้อธิบาย
    สถานการณ์ง่ายกว่านิดหน่อยเพราะหน้าจอไม่ได้เลื่อน แต่ก็อาจต้องวาดไทล์จำนวนมากใหม่
    สุดท้ายผมรื้อโค้ดส่วนนั้นออกทั้งหมด เพราะพอทำ profiling ค่าใช้จ่ายในการวาดทั้งหน้าจอบนการ์ด RIVA TnT แล้ว เวลาที่ใช้เล็กมากจนแทบวัดไม่ได้
    ดีใจที่พลาดยุค EGA ในการพัฒนา PC ไป ถ้าเป็นสมัยนั้นคงทำอะไรไม่สำเร็จเลย

    • ผมกลับชอบ การเขียนโปรแกรมระดับต่ำ แบบนั้น
      ปรับแต่งด้วย bit shift แทนการคูณ เขียนโค้ดแกนหลักด้วย Assembly และเมื่อโปรเซสเซอร์พัฒนาขึ้นก็เขียนทีละ 16 บิตหรือ 32 บิต
      มีแหล่งข้อมูลน้อย เลยเรียนรู้ต่อเนื่องจากหนังสือในห้องสมุดท้องถิ่นกับฟลอปปีดิสก์ที่มีไฟล์ txt
      ตอนนั้นยังเด็กเกินไปและประสบการณ์ก็น้อย เลยไม่ได้ทำอะไรเสร็จจริง ๆ แต่ผมทำการเลื่อนแนวตั้งให้ลื่นได้ ทำการเลื่อนแนวนอนได้เกือบทำงานแล้ว และยัง implement double buffering สำหรับลูกบาศก์ 3D ที่หมุนได้ด้วย รวมถึง depth buffering, คณิตศาสตร์ และการวาดโพลีกอนทีละเส้น
      แล้ว DirectX ก็ออกมา จุดสัมผัสกับเครื่องหายไป และลูกบาศก์ 3D ที่หมุนได้ก็ง่ายเกินไปจนไม่สนุกแล้ว
    • ตอนนั้นช่องว่างระหว่างการ์ดกราฟิกที่ช้าที่สุดกับเร็วที่สุดก็เริ่มกว้างมากแล้ว
      บัสขยายจาก 8 บิตเป็น 16/32 บิต การ์ดกราฟิกรองรับ posted writes ทำให้ CPU ต้องรอน้อยลง และ CPU ก็เร็วขึ้น จนระบบที่เร็วสามารถเขียนหน้าจอ 640x480x256 ได้มากกว่า 300 เฟรมต่อวินาที
      ในกรณีนี้อาจเป็นบัฟเฟอร์ในหน่วยความจำระบบที่ถูก cache แล้วคัดลอกด้วย DMA หรือไม่ก็ blitter เป็นตัวจัดการการวาด แต่แม้ในยุค Windows 98 ก็ยังมีการ์ด 3D ราคาถูกบางรุ่นที่ CPU เข้าถึงได้ช้ามาก จนแทบจะดีกว่าการ์ดบัส ISA รุ่นเก่าแค่นิดเดียว
      ตอนนี้มีบางส่วนที่กลับทิศอีกเล็กน้อย เพราะความละเอียดหน้าจอสูงขึ้นมาก ต่อให้วาดทั้งหน้าจอ 4K ใหม่ได้ที่ 60 เฟรมต่อวินาที ก็ยังเรียกได้ยากว่ามีประสิทธิภาพ
      เกมโดยทั่วไปยังมักวาดใหม่ทั้งหมดอยู่ แต่ desktop compositor ก็ทำการปรับแต่งค่อนข้างมาก เช่น จัดสรรเลเยอร์ให้กับ hardware plane แบบไดนามิกเพื่อลดพื้นที่ที่ต้องวาดใหม่

  • ผมทำงานที่บริษัทเกมอีกแห่งในช่วงเวลาเดียวกัน และคิดค้น เทคนิคการเลื่อนฉาก แบบเดียวกับแนวทางที่สองด้วยตัวเอง
    ผมไม่คิดว่ามันเป็นเรื่องน่าทึ่งขนาดนั้น ถ้าตอนนั้นกำลังแก้ปัญหาเดียวกันอยู่ ก็คงได้ข้อสรุปคล้าย ๆ กัน
    ผมยังทำไดรเวอร์เสียง PWM เองเพื่อเล่นเสียง sample ผ่าน PC speaker ด้วย และดูเหมือนคนอื่น ๆ ก็ทำแบบนั้นกันหมด
    ก่อนที่พวกเราทั้งหมดจะย้ายไปคอนโซล PC ไม่ได้รับความรักมากพอ ดูเดโมอย่าง 8088 MPH ของ Hornet ทีไรก็ยังตื่นเต้นอยู่

    • ถ้าเป็นเกมที่วางจำหน่ายแล้ว ช่วยบอก ชื่อเกม ให้หน่อยได้ไหม จะได้เอามาเทียบกัน? ผมเห็นด้วยว่าคนส่วนใหญ่น่าจะคิดวิธีแก้คล้าย ๆ กันได้ แต่อยากรู้ว่าผลลัพธ์ตอนเล่นให้ความรู้สึกเหมือนกันหรือเปล่า
    • ถ้ามันไม่ได้ยิ่งใหญ่อะไรขนาดนั้น ทำไมแม้แต่ เกมแพลตฟอร์มแบบเลื่อนฉากระดับบน ในยุคนั้นหลายเกมถึงยังกระตุกมาก?
      มันไม่ใช่เงื่อนไขจำเป็นของเกมที่สนุก แต่โดยเฉพาะบนฮาร์ดแวร์สเปกต่ำอย่างต่ำกว่า 10MHz ความลื่นไหลที่ Keen แสดงให้เห็นนั้นเป็นระดับที่ทำให้ตาสว่างในยุคนั้น
    • ชื่อเสียงมักไม่ได้มาจากการประดิษฐ์เอง แต่มาจาก ความสามารถในการทำให้เป็นสินค้าและการตลาด
      น่าจะมีสิ่งประดิษฐ์ยอดเยี่ยมที่ไม่มีใครรู้จักนับไม่ถ้วนตลอดหลายพันปี
      ผมเองก็เคย “ประดิษฐ์” สิ่งที่คล้ายกันเมื่อ 10 ปีก่อน LinkedIn จะออกมา แต่ทำให้เป็นสินค้าได้ไม่สำเร็จ ผมคิดว่าสิ่งประดิษฐ์ส่วนใหญ่คงไม่เคยเป็นที่รู้จักอย่างแพร่หลาย
      นั่นจึงเป็นเหตุผลที่สตาร์ทอัพจำนวนมากเริ่มจากคนสองคน: ผู้เชี่ยวชาญหนึ่งคนกับนักธุรกิจหนึ่งคน
      ดังนั้นพูดแบบนั้นก็ไม่ได้ผิด สิ่งประดิษฐ์นี้อาจไม่ได้พิเศษอะไร แต่เมื่อ ความใหม่·ประโยชน์ใช้สอย·การทำให้เป็นสินค้าได้สำเร็จ มารวมกัน มันก็กลายเป็นสิ่งพิเศษ

  • หนังสือยอดเยี่ยม Masters of Doom อธิบายว่า Keen เป็นเกมแบบ Mario คือเกมเลื่อนหน้าจอแนวนอน
    id เสนอเทคโนโลยีนี้ให้ Nintendo ในฐานะตัวเลือกสำหรับพอร์ต Mario มาลง PC แต่ Nintendo ปฏิเสธ จึงเกิด Keen ขึ้นมา
    นี่เป็นก้าวกระโดดครั้งใหญ่ของเกม PC และเปิดยุคใหม่ของเกม PC
    แต่สิ่งที่ยังไม่ค่อยเข้าใจคือ เทคโนโลยีของ NES กับ PC แตกต่างกันอย่างไร Nintendo ถึงทำการเลื่อนหน้าจอแนวนอนได้ก่อน PC หลายปี

    • EGA โดยพื้นฐานแล้วให้เฟรมบัฟเฟอร์ขนาดใหญ่
      ในโหมดกราฟิก EGA สามารถวาดอะไรก็ได้ตามต้องการ เช่น เส้น วงกลม หรือพิกเซลเดี่ยว ๆ และถูกออกแบบมาให้ใช้แบบนั้น
      แต่การเลื่อนหน้าจอไม่ได้มาฟรี ๆ ต้องคัดลอกหน่วยความจำเอง และอย่างที่บทความที่ลิงก์ไว้แสดงให้เห็น ถ้าดันทุรังทำแบบตรง ๆ ก็จะได้แค่ราว 5 เฟรมต่อวินาทีเพราะข้อจำกัดแบนด์วิดท์ของบัส ISA
      NES และเครื่องเกม 8/16 บิตอื่น ๆ ไม่ได้ถูกสร้างมาให้วาดอะไรก็ได้ตามใจ แต่ถูกสร้างมาเพื่อเรนเดอร์ไทล์
      แค่กำหนดกริดไทล์พื้นหลังและระบุออฟเซ็ตการเลื่อนก็พอ สไปรต์ก็ทำงานคล้ายกันแต่เคลื่อนที่ได้อย่างอิสระ ทั้งหมดนี้ได้มาฟรี ๆ ที่ 60 เฟรมต่อวินาที
      ข้อเสียคือเรนเดอร์สิ่งใด ๆ ตามใจได้ไม่ง่าย เช่น ถ้าจะลงสีพิกเซลเดี่ยว ๆ ตรงไหนสักที่ ต้องอ้อมทางค่อนข้างมาก
      ไม่ใช่ว่า Nintendo “ค้นพบ” ปัญหานี้ก่อน IBM แต่ IBM สร้างระบบกราฟิกอเนกประสงค์ที่เหมาะกับคอมพิวเตอร์ทั่วไปและกราฟิกแบบคงที่ พร้อมให้การควบคุมละเอียดระดับทุกพิกเซล ถ้าดูการ์ด EGA จะเห็นว่าเป็นอุปกรณ์ค่อนข้างใหญ่ที่มีซิลิคอนอยู่มาก
      ในทางกลับกัน Nintendo สร้าง ระบบกราฟิกเฉพาะทาง ที่ง่ายกว่ามากสำหรับการเลื่อนไทล์ไปมา
    • ความจริงคือพวกเขาทำพอร์ต SMB3 แล้วนำไปให้ Nintendo ดู
      เมื่อ Nintendo ไม่รับ ก็สร้างแอสเซ็ตใหม่และกลายเป็น Keen ในภายหลัง
      วิดีโอพอร์ตอยู่ที่นี่: https://youtu.be/1YWD6Y9FUuw
    • ไม่แน่ใจนัก แต่เท่าที่รู้ NES มี ชิปกราฟิกเฉพาะสำหรับจัดการสไปรต์ ส่วนบน PC ต้องทำทั้งหมดนี้ด้วยซอฟต์แวร์
    • วิธีในบทความคือการใช้เฟรมบัฟเฟอร์แบบพิกเซลอิสระเพื่อจำลองไทล์ที่ฮาร์ดแวร์จัดการด้วยซอฟต์แวร์
      ฝั่ง NES ดูเหมือนว่า https://www.nesdev.org/wiki/PPU จะเป็นจุดเริ่มต้นที่ดี
      โจทย์หลักไม่ใช่ “หาวิธีเลื่อนหน้าจอแนวนอน” เอง แต่คือการปรับเอนจินเกมเลื่อนหน้าจอแนวนอนให้ทำงานได้ดูดีภายใต้พื้นที่หน่วยความจำและข้อจำกัดแบนด์วิดท์ของระบบที่แตกต่างกันโดยสิ้นเชิง
    • NES กับ GB น่าจะเป็นแบบ อิงไทล์
      เพราะสร้างเกมแบบอิงสไปรต์ที่มีเลเยอร์ วิธี “เร่งความเร็ว” 2D แบบนั้นจึงค่อนข้างสมเหตุสมผล

  • ใน บทสัมภาษณ์ John Carmack ของ Lex Fridman มีการไล่พูดถึงนวัตกรรมหลักของแต่ละเกมทั้งหมด
    เป็นตอนที่น่าสนใจจริง ๆ ถ้ามีเวลาขอแนะนำอย่างยิ่ง ยาวประมาณ 5 ชั่วโมง

  • ยังจำช่วงที่เคยเชื่อว่าตัวเองรู้ องค์ประกอบลับ แทบทั้งหมดใน Commander Keen Goodbye Galaxy ได้อยู่เลย
    เพื่อนที่โรงเรียนมักจะมาถามให้บอกความลับของด่านที่พวกเขาเล่นบนคอมพิวเตอร์ของโรงเรียนหลังเลิกเรียน

    • น่าอิจฉา ที่โรงเรียนที่ผมเรียน ผมเป็น เด็กเนิร์ด คนเดียวเท่าที่เคยคุยด้วยที่รู้จัก Commander Keen

  • เห็น fabiensanglard.net ทีไร ก็ต้องกดแนะนำทันที

    • เขาเป็นคนที่ล้ำค่าจริง ๆ หนังสือ CPS1 ก็ยอดเยี่ยม
      ถ้ามีใครรู้จักบล็อกเกมคลาสสิกอื่น ๆ ที่ลงลึกเชิงเทคนิค ก็อยากให้ช่วยแชร์
      https://nicole.express/ และ https://sudden-desu.net/ ก็เป็นเว็บที่ผมชอบ

  • ผมเข้าใจแล้วว่าถ้าปรับจุดเริ่มต้นของเฟรมบัฟเฟอร์เป็นระดับสแกนไลน์ การเลื่อนแนวตั้ง จะเป็นอย่างไร แต่ตอนแรกยังไม่ชัดเจนว่าการเลื่อนแนวนอนทำได้อย่างไรโดยไม่บิดเฟรมบัฟเฟอร์อย่างหนัก
    พอคิดต่ออีกหน่อยก็รู้ว่ามันคล้ายกับการวาดภาพบนด้านข้างของทรงกระบอก ไม่ว่าจะวาดขอบซ้ายของภาพไว้ตรงไหน ก็มีวิธีหมุนทรงกระบอกแล้วตั้งค่ารีจิสเตอร์ CRTC_START และ PEL เพื่อให้เห็นภาพทั้งหมดได้อย่างคมชัดเสมอ
    ส่วนที่ว่า “เมื่อถึงขอบจอ ก็ใช้ทางออกง่าย ๆ โดยยอมให้กระตุกแล้วคัดลอกทั้งหน้าจอขึ้นไป” ก็น่าสนใจ
    ผมจำได้ว่าตอนเริ่ม Keen มักจะมีข้อความทำนอง “VGA compatibility mode enabled” ขึ้นมา และสงสัยมาตลอดว่ามันหมายความว่าอะไร

  • Commander Keen เป็นเกมเล็ก ๆ ที่น่ารักจริง ๆ
    คงต้องลองหาวิธีเอามารันอีกครั้ง
    แต่ควรจะรันมันยังไงดี? ตั้งแต่กลายเป็น “ผู้ใหญ่” ก็ไม่ได้ใช้ Windows มาราว 20 ปีแล้ว จะเล่นบน Debian ได้ยังไงบ้าง?

    • เล่นได้ทันที: https://archive.org/details/msdos_Commander_Keen_1_-_Maroone...
    • ไม่เห็นด้วย เกมนี้เป็นเกมสำหรับเด็กที่ไม่ว่าจะด้วยเหตุผลอะไร ก็มีคอมพิวเตอร์ใช้ แต่ไม่มี Nintendo
      สมัยนั้นคอมพิวเตอร์แพงกว่าคอนโซลราว 10 เท่า ดังนั้นโดยทั่วไปจึงเป็นเพราะผู้ใหญ่มีความคิดแรงกล้าว่าเด็กควรทำอะไร
      เมื่อเทียบกับเกม NES และ Genesis แล้วมัน ขาดจิตวิญญาณ ตอนนั้นผมชอบนะ แต่พอลองกลับไปเล่นใน DosBox เมื่อไม่นานมานี้ ก็รู้สึกชัดเจนว่าเทียบกันไม่ได้เลย
    • DosBox รันเกม VGA เก่า ๆ ได้ดีมาก และทำงานได้แทบทุกแพลตฟอร์ม รวมถึงในเบราว์เซอร์ด้วย: https://archive.org/details/msdos_Commander_Keen_1_-_Maroone...
    • น่าจะเป็น DosBox
    • Commander Keen กับ Jill of the Jungle เป็นเกมที่ทำให้ผมได้สัมผัส PC ครั้งแรกในอดีต เป็นความทรงจำที่ดีจริง ๆ

  • เมื่อหลายปีก่อนผมเคยทำวิธีที่สองไว้ แต่แค่วาดเฉพาะ ขอบด้านหน้า ก็ยังช้ามาก
    เพียงแต่เขียนด้วย C และไม่เคยเรียนการเขียนโปรแกรมแอสเซมบลีอย่างจริงจัง
    https://github.com/geon/kate/blob/master/src/platform/dos/eg...