คำถามติดแท็ก opengl


3
ทำไมกราฟิกเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์ไม่ได้ถูกถอดออก?
ฉันกำลังทำงานกับแอพที่เกี่ยวข้องกับการจัดการเวกเตอร์พา ธ แบบเรียลไทม์ที่ 60fps และฉันประหลาดใจมากที่มีข้อมูลเพียงเล็กน้อยในเรื่องนี้ ตอนแรกผมพยายามที่จะใช้ความคิดของฉันโดยใช้ CoreGraphics แต่มันก็ไม่ได้ดำเนินการอย่างเพียงพอเพื่อฉัน จากนั้นผมก็ค้นพบว่ามีความเป็นมาตรฐาน Khronos สำหรับฮาร์ดแวร์เร่งกราฟิกแบบเวกเตอร์ที่เรียกว่าOpenVGและขอบคุณจิตวิญญาณชนิดได้เขียน OpenGL ES กึ่งการดำเนินงานที่เรียกว่าMonkVG แต่ข้อเท็จจริงที่ว่า OpenVG นั้นเป็น API ที่มีประโยชน์มาก แต่ดูเหมือนว่า Khronos จะถูกทอดทิ้งมากขึ้นหรือน้อยลง ตามวิกิพีเดียตั้งแต่ปี 2011 คณะทำงาน "ตัดสินใจที่จะ ... ไม่ต้องประชุมปกติ [sic] เพื่อให้ได้มาตรฐานมากขึ้น" เอกสารที่ดีที่สุดที่ฉันหาได้ประกอบด้วยบัตรอ้างอิงเพียงใบเดียว และยิ่งไปกว่านั้นยังมีตัวอย่างของ OpenVG แทบทุกที่บนอินเทอร์เน็ต ฉันสามารถค้นหาบทเรียนของ OpenGL หลายร้อยรายการได้ในพริบตา แต่ OpenVG ดูเหมือนจะหายไปอย่างชัดเจน คุณคิดว่าเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์จะมีความสำคัญมากกว่าในโลกปัจจุบันที่มีความละเอียดเพิ่มขึ้นอย่างรวดเร็วและดูเหมือนว่าหลาย บริษัท กำลังใช้วิธีการของตนเองในการทำสิ่งนี้ ตัวอย่างเช่น Qt และ Flash มีโครงร่างสำหรับเวกเตอร์ที่เร่งด้วยฮาร์ดแวร์และเครื่องมือของ Adobe หลายตัวมีการเร่งด้วยฮาร์ดแวร์เป็นตัวเลือก …

14
เหตุใด DirectX จึงใช้ระบบพิกัดซ้าย?
ฉันถือว่าการโพสต์ใน Stack Overflow แต่คำถามก็ทำให้ฉันรู้สึกว่าเป็นเรื่องส่วนตัวเกินไปเพราะฉันไม่สามารถคิดถึงคำอธิบายทางเทคนิคที่สมเหตุสมผลสำหรับทางเลือกของ Microsoft ในเรื่องนี้ แต่คำถามนี้บั๊กฉันมานานและปัญหายังคงเกิดขึ้นในโครงการของฉันและฉันไม่เคยเห็นความพยายามที่จะอธิบายสิ่งนี้: OpenGLใช้ระบบพิกัดขวามือโดยที่ส่วน + Z ของระบบพิกัดโลกขยายไปยังผู้ชม DirectXใช้ระบบซ้ายมือที่ส่วน + Z ของพิกัดโลกขยายไปถึงหน้าจอห่างจากผู้ชม ฉันไม่เคยใช้Glide APIดังนั้นฉันจึงไม่รู้ว่ามันทำงานอย่างไร แต่จากสิ่งที่ฉันสามารถรวบรวมได้ก็ใช้ระบบมือซ้ายเช่นกัน มีเหตุผลทางเทคนิคสำหรับสิ่งนี้หรือไม่? และถ้าไม่เป็นเช่นนั้นมีความได้เปรียบทางความคิดบางอย่างเกี่ยวกับความถนัดเฉพาะของระบบพิกัดหรือไม่? ทำไมหนึ่งจะเลือกหนึ่งมากกว่าอีก?
52 math  directx  opengl 

7
เขียนใน C เพื่อประสิทธิภาพ? [ปิด]
ฉันรู้ว่าฉันเคยได้ยินบ่อยๆว่า C มักจะมีข้อได้เปรียบด้านประสิทธิภาพมากกว่า C ++ ฉันไม่ได้คิดอย่างอื่นจนกว่าฉันจะรู้ว่า MSVC ดูเหมือนจะไม่สนับสนุนมาตรฐานใหม่ล่าสุดของ C แต่รุ่นล่าสุดรองรับ C99 (เท่าที่ฉันรู้) ฉันวางแผนที่จะเขียนไลบรารีด้วยโค้ดบางอย่างเพื่อให้แสดงผลใน OpenGL เพื่อให้ฉันสามารถนำมาใช้ซ้ำได้ ฉันวางแผนที่จะเขียนไลบรารีใน C เนื่องจากการเพิ่มประสิทธิภาพใด ๆ ก็ยินดีต้อนรับเมื่อมันมาถึงกราฟิก แต่มันจะคุ้มหรือไม่ รหัสที่ใช้ไลบรารีน่าจะเขียนใน C ++ และฉันต้องการรหัสใน C ++ โดยทั่วไป อย่างไรก็ตามถ้ามันสร้างความแตกต่างเล็กน้อยในการแสดงฉันก็น่าจะไปกับ C อาจสังเกตได้ว่าห้องสมุดนี้จะเป็นสิ่งที่ฉันจะใช้ในการทำงานกับ Windows / OS X / Linux และฉันอาจรวบรวมทุกอย่างโดยพื้นฐาน (MSVC สำหรับ Windows, Clang หรือ GCC สำหรับ OS X และ GCC สำหรับ …

5
เหตุใดห้องสมุดสมัยใหม่จึงไม่ใช้ OOP
ฉันเป็นโปรแกรมเมอร์ C ++ ระดับต้น แต่ฉันเข้าใจแนวคิดของภาษาค่อนข้างดี เมื่อฉันเริ่มเรียนรู้ไลบรารี C ++ ภายนอกเช่น SDL, OpenGL (อาจเป็นอย่างอื่น) ด้วยความประหลาดใจที่ยิ่งใหญ่ของฉันฉันพบว่าพวกเขาไม่ได้ใช้แนวคิด C ++ เลย ตัวอย่างเช่นทั้ง SDL และ OpenGL ไม่ใช้คลาสหรือข้อยกเว้นเลือกฟังก์ชั่นและรหัสข้อผิดพลาด ใน OpenGL ฉันเคยเห็นฟังก์ชั่นเช่น glVertex2f ซึ่งใช้ตัวแปรลอย 2 ตัวเป็นอินพุตและน่าจะดีกว่าเทมเพลต นอกจากนี้บางครั้งห้องสมุดเหล่านี้ใช้มาร์กอสในขณะที่ดูเหมือนว่าเป็นข้อตกลงทั่วไปที่ใช้มาโครไม่ดี โดยรวมแล้วพวกเขาดูเหมือนจะเขียนในสไตล์ C มากกว่าในสไตล์ C ++ แต่พวกเขาเป็นภาษาที่แตกต่างกันโดยสิ้นเชิงใช่มั้ย คำถามคือเหตุใดห้องสมุดสมัยใหม่จึงไม่ใช้ข้อดีของภาษาที่เขียน

4
ความสัมพันธ์ระหว่าง OpenGL, GLX, DRI และ Mesa3D คืออะไร
ฉันเริ่มทำการเขียนโปรแกรม 3D ระดับต่ำใน Linux ฉันมีประสบการณ์มากมายโดยใช้กราฟิก API ระดับสูงกว่า OpenInventor ฉันรู้ว่ามันไม่จำเป็นอย่างยิ่งที่จะต้องตระหนักว่าสิ่งเหล่านี้เข้ากันได้อย่างไร แต่ฉันแค่อยากรู้อยากเห็น ฉันรู้ว่า OpenGL เป็นเพียงมาตรฐานสำหรับแอปพลิเคชันกราฟิก Mesa3D น่าจะเป็นการใช้งานโอเพ่นซอร์สของมาตรฐานนี้ ดังนั้น GLX และ DRI จะพอดีกับที่ใด เมื่อขุดลงบนวิกิพีเดียและเว็บไซต์ทั้งหมดเหล่านี้ฉันยังไม่พบคำอธิบายว่ามันเข้ากันได้อย่างไร การเร่งความเร็วฮาร์ดแวร์เกิดขึ้นที่ไหน ไดรเวอร์ที่เป็นกรรมสิทธิ์ต้องทำอะไรกับสิ่งนี้

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

2
คำแนะนำสำหรับไลบรารี GUI ใน Haskell [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ในฐานะที่เป็นHaskell Wiki ระบุว่า : มีไลบรารี GUI จำนวนมากสำหรับ Haskell น่าเสียดายที่ไม่มีมาตรฐานใด ๆ เลยและทั้งหมดนั้นไม่สมบูรณ์ไม่มากก็น้อย โดยทั่วไปแล้วแผ่นไม้อัดระดับต่ำจะทำได้ดี แต่ก็มีระดับต่ำ abstractions ระดับสูงเป็นการทดลองที่ค่อนข้างดี ไม่จำเป็นต้องมีไลบรารี GUI ระดับกลางที่รองรับ อาจารย์ที่วิทยาลัยของฉันขอให้ฉันและวิชาเอกวิทยาการคอมพิวเตอร์อีกสามคนพิจารณาที่จะทำงานในห้องสมุด GUI สำหรับ Haskell ความคิดเริ่มต้นของเขาสำหรับโครงการคือการเขียนเลเยอร์บน OpenGL ที่เลียนแบบมอร์ฟิคไลบรารีที่พบใน Smalltalk ; อย่างไรก็ตามนี่เป็นเพียงข้อเสนอแนะและระบบอื่น ๆ ก็เป็นสิ่งที่ควรค่าแก่การพิจารณา นี่นำเราไปสู่คำถามที่เกิดขึ้นจริงและมีหลายส่วน ห้องสมุดของเรามุ่งมั่นในระดับใด Haskell Wiki ดูเหมือนจะบ่งบอกอย่างชัดเจนว่าต้องการ GUI ไลบรารีระดับกลาง อย่างไรก็ตามยินดีต้อนรับสู่ห้องสมุดระดับสูง ห้องสมุดของเราควรสร้างอะไร …

3
Android, OpenGL และขยาย GLSurfaceView หรือไม่
คำถามนี้เป็นส่วนหนึ่งทางเทคนิคส่วนหนึ่งเมตาส่วนร่วมและเฉพาะเจาะจงมาก: ฉันเป็นนักพัฒนาเกมอินดี้ที่ทำงานกับ Android และในช่วง 6 เดือนที่ผ่านมาฉันพยายามและในที่สุดก็ประสบความสำเร็จในการสร้างแอพเกม 3D ของฉันเองสำหรับ Android ดังนั้นฉันคิดว่าฉันจะกระโดดเพื่อให้และช่วยเหลือผู้อื่นที่กำลังต่อสู้กับ Android และ openGL-ES GLSurfaceViewแต่ส่วนใหญ่ของคำถามที่เกี่ยวข้องกับการขยาย ฉันสร้างแอปทั้งหมดของฉันโดยไม่ขยายGLSurfaceView(และมันก็ทำงานได้ดี) ฉันไม่เห็นเหตุผลใด ๆ เลยGLSurfaceViewสำหรับคำถามส่วนใหญ่ที่ฉันเจอ เลวร้ายยิ่งไปกว่านั้นเอกสาร Android นั้นบอกเป็นนัยว่าคุณควรจะทำ แต่ไม่ได้อธิบายอย่างละเอียดว่าทำไมหรือข้อดีข้อเสียคืออะไรที่ไม่ขยายและทำทุกอย่างผ่านการใช้งานของคุณเองGLSurfaceView.Rendererเหมือนที่ฉันทำ ถึงกระนั้นปริมาณคำถามที่เลี่ยงไม่ได้ที่จะขยายGLSurfaceViewคือทำให้ฉันสงสัยว่าจริง ๆ แล้วมีบางเหตุผลที่ดีจริง ๆ ที่ทำแบบนั้นกับวิธีที่ฉันทำ (และแนะนำคำตอบของฉันให้คนอื่น ๆ ) ทำ). ดังนั้นมีบางสิ่งที่ฉันขาดหายไปหรือไม่ ฉันควรหยุดตอบคำถามในเวลาเดียวกันหรือไม่? เอกสารประกอบ openGL ของ Android
12 android  opengl 
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.