API đồ họa cấp thấp đa nền tảng

Khi tạo một sự trừu tượng hóa hệ thống sẽ tốt hơn khi các nền tảng API khác nhau bị ẩn bởi một giao diện chung ở mức thấp nhất có ý nghĩa.

Có tính đến các API đồ họa gốc hiện đại (không có chức năng cố định) khác nhau: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM

Nếu một người tạo ra một API đồ họa cấp thấp không trạng thái để đặt lên trên tất cả, thì cách tốt nhất để làm cho nó mỏng và nhanh nhất có thể là gì?

Mức thấp nhất có ý nghĩa theo quan điểm của tôi là một cái gì đó nói về các tài nguyên liên quan đến kết xuất - vb / ib, kết xuất bề mặt, kết cấu, đổ bóng, khối trạng thái, v.v.

Vấn đề ở đây là một số trong số này cần phải ở các định dạng khác nhau, tùy thuộc vào API - đó là nơi nó có một chút khó khăn. Cách dễ nhất là xử lý trước các tài nguyên tĩnh cho API tương ứng. Đối với những người năng động, chỉ sử dụng các trình tạo bóng để tạo ra chúng - điều đó khiến cho việc giữ nguyên các định dạng gốc khá đơn giản.

Tất cả những gì bạn làm ở cấp độ cao hơn là thiết lập các đường ống với các tài nguyên được đính kèm và đưa chúng cho GPU. Bạn sẽ thấy rằng không phải mọi thứ đều có thể được trừu tượng hóa theo cách đó, đặc biệt nếu bạn tận dụng các thủ thuật dành riêng cho phần cứng. Nhưng đó là một khởi đầu tốt.

(Sidenote: nếu bạn coi các thủ thuật dành riêng cho nền tảng là một loại tài nguyên đặc biệt, bạn có thể đẩy toàn bộ khái niệm này đi khá xa.)

Vì vậy, theo một cách nào đó, bạn sẽ tạo ra hai điều: Trình quản lý tài nguyên phần cứng, cộng với bộ công cụ để thiết lập DAG của các tài nguyên này.

Do phạm vi API rộng mà bạn muốn đề cập, cách tiếp cận gói điển hình có thể không hiệu quả và dễ gặp khó khăn trong việc ánh xạ các khái niệm API qua một số API khác có thể hoặc không hỗ trợ các chức năng cụ thể ở các mức độ khác nhau.

Kết quả là, cách tiếp cận hợp lý nhất sẽ là tạo ra một API tập trung vào tính năng . Mặc dù cách tiếp cận này ngăn người dùng API sử dụng tất cả các chức năng có sẵn, nhưng nó đơn giản hóa đáng kể việc triển khai từng phụ trợ và cho phép tối ưu hóa cụ thể phụ trợ mà không thể thực hiện được.

Nó cũng đơn giản hóa rất nhiều việc quản lý chức năng không được hỗ trợ cho người dùng API; họ không còn phải kiểm tra xem hàm X có tồn tại hay không và xác định các tính năng nào bị ảnh hưởng, mà thay vào đó chỉ cần truy vấn chính tính năng đó để xem nó có được hỗ trợ với cấu hình hiện tại không. Ngay cả khi bạn hỗ trợ các chế độ một phần hoặc giới hạn cho các tính năng, bối cảnh được cung cấp sẽ giúp quản lý dễ dàng hơn nhiều.

Về mặt tạo trình kết xuất không trạng thái (còn được gọi là trình kết xuất dựa trên trình), thông thường, khóa 64 bit được sử dụng để đóng gói và gửi lệnh để kết xuất. Từ thời điểm đó, có rất nhiều sự linh hoạt về cách thực hiện các lệnh và thông tin nào cần gửi tùy thuộc vào các tính năng và khả năng bạn muốn hỗ trợ.

Để bắt đầu, mỗi API thực hiện mọi thứ khác nhau, do đó, không cần phải nói rằng việc gói tất cả các API ở trên sẽ khó khăn. Điều đó nói rằng, đôi khi cần phải làm như vậy: tại một số điểm, một trò chơi chỉ cần chạy trên nhiều nền tảng bất kể nó khó đến mức nào.

Tôi nghĩ rằng cách tốt nhất để thực hiện điều này là đưa ra các chức năng có thể được triển khai trên tất cả các API cơ bản và trừu tượng đó và chỉ có thế. Nếu bạn đang phát triển một trò chơi đa nền tảng, bạn sẽ không triển khai mọi chức năng tối nghĩa mà mỗi API hỗ trợ, bạn sẽ chỉ thực hiện những gì bạn cần. Điều này cũng giúp giữ cho API nhỏ và nhanh.

Để tránh sự lộn xộn của mỗi triển khai API khác nhau được đóng gói vào đầu ra, việc biên dịch phải được thực hiện với các tệp tiêu đề trung lập nền tảng và các tệp mã cụ thể của nền tảng. Sau đó, tệp mã cụ thể cho nền tảng đích sẽ là tệp duy nhất được biên dịch giữ API nhỏ.

Có một bài viết về GPU Pro về điều này, bởi Emil Persson (Humus)

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

Một giao diện đa nền tảng để kết xuất. Những lợi thế của việc có một và cách chúng tôi nhồi nhét DX10 vào một giao diện chung với bảng điều khiển DX9 và duy trì hiệu suất tốt.

Bạn có thể muốn kiểm tra thư viện SDL hoặc Allegro . Cả hai đều là thư viện trò chơi cấp độ thấp, có tính di động cao, có cách cắm chúng vào ngữ cảnh OpenGL để bạn có thể kết xuất đồ họa của mình ở đó. SDL nổi tiếng khi được Loki Games sử dụng để chuyển một số trò chơi phổ biến từ những năm 2000 sang Linux, và Allegro có nhiều thời gian hoạt động và có một cộng đồng lớn các nhà phát triển trò chơi nghiệp dư.