ข้ามแพลตฟอร์ม API กราฟิกระดับต่ำ

11

เมื่อสร้างสิ่งที่เป็นนามธรรมระบบจะดีกว่าที่จะมีแพลตฟอร์ม API ที่แตกต่างกันที่ซ่อนอยู่โดยอินเตอร์เฟซทั่วไปในระดับต่ำสุดที่เหมาะสม

คำนึงถึงความทันสมัยที่แตกต่างกัน (โดยไม่มีฟังก์ชั่นคงที่) API กราฟิคดั้งเดิม: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM

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

— NocturnDragon
แหล่งที่มา

ข้อกำหนดสำหรับ API ที่จะไร้สัญชาตินั้นน่าสนใจ ยกตัวอย่างเช่น OpenGL นั้นเป็นของรัฐและฉันคิดว่า stateless API ที่ห่อหุ้มมันจะสมเหตุสมผลถ้ามันอยู่ในระดับที่สูงกว่ามากดังนั้นมันจึงไม่ใช่สำหรับตัวอย่างเช่นเมื่อต้องผลักดันและป๊อปอัปแบบเดียวกันสำหรับแต่ละคนและทุกคน พื้นผิวมันแสดงผล

— SpoonMeiser

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

— NocturnDragon

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

— SpoonMeiser

ใช่สำหรับทุกการเรียกที่คุณต้องการข้อมูลตาข่ายสถานะการผสมพื้นผิวที่จะผูกสถานะการสุ่มตัวอย่าง ฯลฯ การปรับให้เหมาะสมสามารถทำได้ในภายหลังโดยไม่ต้องเปลี่ยน API โท หรือบางทีผมอ่านความคิดเห็นของคุณไม่ถูกต้อง ..

— NocturnDragon

6

ระดับต่ำสุดที่เหมาะสมจากมุมมองของฉันคือสิ่งที่พูดถึงทรัพยากรที่เกี่ยวข้องในการแสดงผล - vb / ib, แสดงพื้นผิวพื้นผิว shaders บล็อกรัฐ ฯลฯ

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

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

(Sidenote: หากคุณใช้เทคนิคเฉพาะแพลตฟอร์มเป็นทรัพยากรชนิดพิเศษคุณสามารถผลักดันแนวคิดทั้งหมดนี้ไปได้ไกล)

ดังนั้นคุณจะสร้างสองสิ่ง: ผู้จัดการทรัพยากรฮาร์ดแวร์พร้อมชุดเครื่องมือเพื่อตั้งค่า DAG ของทรัพยากรเหล่านี้

— Rachel Blum
แหล่งที่มา

ฉันไม่เคยคิดเกี่ยวกับการรักษาสิ่งต่าง ๆ เฉพาะแพลตฟอร์มเป็นทรัพยากร ดูเหมือนความคิดที่ดีมาก! ขอบคุณ

— NocturnDragon

10

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

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

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

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

— Jason Kozak
แหล่งที่มา

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

— NocturnDragon

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

— Jason Kozak

1

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

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

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

— ฌอนเจมส์
แหล่งที่มา

0

มีบทความเกี่ยวกับ GPU Pro เกี่ยวกับสิ่งนี้โดย Emil Persson (Humus)

http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html

อินเตอร์เฟสข้ามแพลตฟอร์มสำหรับการเรนเดอร์ ข้อดีของการมีหนึ่งเดียวและวิธีที่เรายัดเยียด DX10 ให้เป็นอินเทอร์เฟซทั่วไปกับคอนโซล DX9 และรักษาประสิทธิภาพที่ดีไว้

— NocturnDragon
แหล่งที่มา

-4

คุณอาจต้องการที่จะตรวจสอบห้องสมุด SDLหรือAllegro ทั้งคู่เป็นไลบรารีเกมแบบพกพาในระดับต่ำซึ่งมีวิธีการเชื่อมต่อพวกเขาในบริบท OpenGL เพื่อให้คุณสามารถแสดงกราฟิกของคุณที่นั่น SDL มีชื่อเสียงในการใช้งานโดยเขาเลิก Loki Games ไปยังพอร์ตเกมยอดนิยมบางอย่างจากยุค 2000 ถึง Linux และ Allegro มีเวลาทำงานนานและมีชุมชนนักพัฒนาเกมมือสมัครเล่นที่ยอดเยี่ยม

— chiguire
แหล่งที่มา

4

สิ่งนี้ไม่ได้ตอบคำถามไม่ต้องพูดถึงว่ามันเป็นไปได้ที่จะห่อทั้ง OpenGL และ DirectX (ดู Ogre3D, Irrlicht, ฯลฯ )

— Jason Kozak

พิจารณาเกมที่คุณเล่น มีกี่ตัวเลือกในการใช้ DirectX หรือ OpenGL นั่นคือจำนวนการสร้าง wrappers สำหรับทั้งสองไลบรารีเพื่อให้สามารถรองรับได้ คุณมีจินตนาการที่ จำกัด :-P

— Ricket

ฉันรู้ว่ามีบางเกมที่ให้คุณเลือกว่าคุณต้องการแสดงผลกราฟิกด้วย OpenGL หรือ DirectX แต่คำถามนั้นเกี่ยวกับ API ข้ามแพลตฟอร์มดังนั้นฉันคิดว่าคำตอบนั้นเพียงพอฉันจะแก้ไขย่อหน้าแรก แม้

— chiguire

1

คำถามนั้นเกี่ยวกับ API ระดับต่ำที่ไม่มีสัญชาติข้ามแพลตฟอร์ม SDL และ Allegro ไม่มีส่วนเกี่ยวข้องกับเรื่องนี้

— NocturnDragon

@NotctDragon - ชื่อคำถามนั้นทำให้เข้าใจผิดเล็กน้อย เมื่อเห็นอย่างรวดเร็วครั้งแรกฉันคาดหวังว่าคำถามจะเกี่ยวกับตัวเลือกของ API ที่มีอยู่และฉันคิดว่าผู้ตอบคำถามนี้ก็ทำได้เช่นกัน

— a_m0d