Vấn đề gì có thể xảy ra nếu bạn sử dụng cả API MonoGame và API đồ họa cơ bản?


10

Những loại vấn đề nào người ta có thể gặp phải nếu họ đang tạo một trò chơi với MonoGame và cũng bắt đầu thực hiện các cuộc gọi đến API đồ họa cơ bản?

Ví dụ: nếu tôi muốn làm một cái gì đó trong dự án MonoGame mà MonoGame không nhất thiết phải hỗ trợ hoặc tôi không thể tìm thấy tài liệu / ví dụ thích hợp cho nhưng tôi có thể tìm thấy một ví dụ về cách thực hiện trong OpenTK, tôi có tự đặt ra rắc rối nếu tôi triển khai trực tiếp bằng OpenTK trong khi sử dụng API MonoGame ở mọi nơi khác? Cụ thể tôi đang tìm hiểu xem có bất kỳ vấn đề lớn nào được biết có thể là kết quả của việc này và không phải là điều gì đó tối nghĩa sẽ xảy ra trong những trường hợp rất hiếm.

Tôi đã thử thực hiện một nghiên cứu nhỏ thông qua Google và trang web GD.SE và tôi không thể tìm thấy nhiều. Có thể MonoGame đã thực sự bao phủ hầu hết các cơ sở của nó, nhưng điều gì sẽ xảy ra nếu tôi muốn tự khắc phục một trong những vấn đề nổi bật hoặc một tính năng chưa được triển khai?

Nếu vậy loại vấn đề nào có thể phát sinh và có cách nào để giúp giảm thiểu những vấn đề này?

Câu trả lời:


12

Trong hầu hết các trường hợp, các vấn đề này sẽ thuộc loại "hành vi không xác định" (không phải theo nghĩa C ++, nhưng theo cách hiểu rộng hơn).

Những gì bạn đang làm về cơ bản là phá vỡ sự trừu tượng được cung cấp bởi MonoGame (ví dụ, điều này tất nhiên áp dụng cho bất kỳ API cấp cao hơn như vậy). Khi làm như vậy, bạn có thể khiến các bảo đảm bất biến của lớp bị vi phạm, điều này có nghĩa là các giả định mà các tác giả MonoGame có thể viết mã của họ theo có thể không còn đúng nữa và mã có thể hành xử bất ngờ. Mã của riêng bạn thực sự có thể không còn dựa vào các đảm bảo bất biến của trừu tượng nữa, vì bạn đã phá vỡ chúng.

Hành vi bất ngờ này sẽ bao gồm, có khả năng, toàn bộ gam của hành vi đó từ tạo tác đơn giản cho đến sự cố hoặc hỏng bộ nhớ.

  • Ví dụ: nếu bạn sử dụng một số trạng thái API kết xuất bằng cách chạy cuối cùng xung quanh MonoGame, thì có thể không thể phát hiện thay đổi trạng thái đó (vì có thể nó sẽ không thăm dò API cơ bản để thay đổi, đơn giản là nó hiệu quả hơn giả sử nó là người kiểm soát API và theo dõi những thay đổi đó). Do đó, nó có thể quyết định, trong lần kết xuất tiếp theo, nó không cần cập nhật thứ gì đó thực tế cần được cập nhật và cảnh của bạn có thể không được kết xuất chính xác.

  • Hoặc bạn có thể gây rối với API cơ bản và thay đổi số tham chiếu của một số đối tượng thiết bị (giả sử D3D), có nghĩa là nó có thể được phát hành sớm từ dưới MonoGame hoặc vô tình không được phát hành, dẫn đến sự cố có thể xảy ra hoặc rò rỉ tài nguyên.

  • Hoặc bạn có thể làm một cái gì đó hoạt động, nhưng vì bạn đang lẩm bẩm một cách không được hỗ trợ và với các tính năng không có giấy tờ hoặc các mẫu truy cập bất ngờ, bạn có thể thấy mã của mình bị hỏng khủng khiếp trong lần phát hành tiếp theo.

  • Hoặc bạn có thể làm một cái gì đó, nó hoạt động tốt trong một vài phiên bản, nhưng sau đó bạn gặp phải một số lỗi khác và gặp khó khăn trong việc theo dõi nó, vì vậy bạn yêu cầu mọi người giúp đỡ MonoGame, có thể gửi báo cáo lỗi vì bạn chắc chắn một vấn đề trong mã của họ. Tất nhiên, họ không thể tái tạo lỗi và cuối cùng phát hiện ra rằng bạn đang thực hiện vụ hack truy cập trực tiếp kỳ lạ này và tại thời điểm đó - bất kể tin tặc của bạn có phải là nguyên nhân gốc của lỗi hay không - họ Có thể bạn sẽ ngừng chi tiêu tài nguyên cho sửa chữa của mình chỉ vì bạn đang làm một việc không được hỗ trợ (hoặc ít nhất, họ có thể sẽ ưu tiên cho bạn).

Tất nhiên, trong một số trường hợp, bạn hoàn toàn có thể phải phá vỡ API, có lẽ phải khắc phục một lỗi trong phần mềm vận chuyển mà bản vá chính thức sẽ không được phát hành kịp thời. Nếu bạn hoàn toàn phải làm điều này, bạn nên thực hiện phương pháp mềm: cố gắng phạm vi quyền truy cập trực tiếp của bạn càng hẹp càng tốt và đảm bảo bạn cố gắng để trạng thái của API cơ bản không thay đổi nhất có thể khi bạn kết thúc với sự can thiệp của mình . Đó không phải là một sự đảm bảo thành công, nhưng nó có thể giúp đỡ.

Mặc dù vậy, lý tưởng nhất là bạn sẽ tránh được loại điều này.


3

Tôi hoàn toàn đồng ý với câu trả lời của Josh nhưng tôi muốn thêm một vài suy nghĩ.

Mục đích của MonoGame là đưa API XNA đến nhiều nền tảng. Nếu bạn đang sử dụng OpenTK trực tiếp, bạn sẽ tự giới hạn mình chỉ những nền tảng hỗ trợ nó. Do đó, bạn có thể mất một trong những lợi ích chính của việc sử dụng tính trừu tượng.

Nếu bạn thấy mình muốn làm điều gì đó mà MonoGame không hỗ trợ hoặc gặp khó khăn khi tìm tài liệu, trước tiên hãy hỏi câu hỏi cụ thể hơn về những gì bạn đang cố gắng làm. Bạn có thể thấy rằng đã có một cách để làm điều đó hoặc có lẽ đó là một tính năng được lên kế hoạch chưa được triển khai.

Sau khi thảo luận về vấn đề này, có thể bạn hoặc ai đó có thể triển khai các tính năng còn thiếu trong MonoGame vì lợi ích của mọi người.


3

Liên quan đến cách giảm thiểu các vấn đề phát sinh khi kết hợp hai ý tưởng đó:

MonoGame là mã nguồn mở, sửa đổi trực tiếp và bạn không cần phải lo lắng về vấn đề sử dụng cả hai.

Nếu bạn nghĩ rằng bạn cần những thứ bổ sung trong đó, thì bằng mọi cách: tạo một ngã ba. Sử dụng mã cơ sở đó và thêm mã của bạn lên trên nó. Biên dịch lại MonoGame và bạn đi. Điều này cũng sẽ cho phép bạn cập nhật ngã ba MonoGame khi được cập nhật (tất nhiên bạn sẽ phải khắc phục mọi xung đột có thể phát sinh trong quy trình).


Bất cứ ai đã bỏ phiếu xuống, xin vui lòng nói lý do của bạn, để tôi có thể tìm hiểu lần sau nếu bạn cảm thấy tôi đã viết sai.
Timotei

1
Làm thế nào để trả lời câu hỏi này?

1
Chà, người ta có thể giải quyết bất kỳ vấn đề nào phát sinh từ việc kết hợp cả hai (monogame + API gạch chân) bằng cách sửa đổi trực tiếp nguồn monogame (nghĩa là ở một nơi duy nhất). Xin lưu ý câu hỏi cuối cùng của anh ấy: "Nếu vậy thì loại vấn đề nào có thể phát sinh và có cách nào giúp giảm thiểu những vấn đề này không?"
Timotei

Điểm hay của Timotei, tôi đã thực hiện một chỉnh sửa nhỏ để làm cho nó rõ hơn một chút về câu trả lời của bạn.
MichaelHouse

Tôi thích điểm này. Tôi nghĩ rằng sẽ thực sự có ý nghĩa hơn khi cố gắng tìm một vị trí thích hợp trong chế độ một trò chơi để thực hiện một tính năng hơn là thực hiện cụ thể trong thư viện trò chơi của riêng bạn. Có những cạm bẫy rõ ràng của việc không hiểu đúng về monogame và vẫn thực hiện nó không chính xác nhưng đó là một vấn đề khác hoàn toàn.
SpartanDovy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.