Open capnkenny opened 1 year ago
If it helps, I was working on a demo application that may better illustrate/demonstrate this type of API - I can link it here if/when it's completed
I think I would need to see a working example of this before I have any questions on it.
What is the current behaviour? Currently (and for the foreseeable future) we expose an API that allows users fine-tuned control over the NovelRT Core for all things rendering, windowing, input, etc.
What is the expected change? We would implement a higher-level API that hides some of the controls that a user would gain from using the NovelRT Core directly, in exchange for a simpler interface that still offers plenty of customisation.
What is the motivation / use case for changing the behavior? For newer/inexperienced users of NovelRT (or C++ in general), we can provide an interface that is more traditionally seen in OOP vs. DOD. We would ultimately still provide both, but by being able to target OOP users unfamiliar with ECS, DOD, etc. we can entice a larger user base to "try out" NovelRT and as progression with NovelRT occurs, said users can then choose to either a) stick with the high-level API, or b) pivot to the lower-level Core API that introduces them to the more detailed nuances of ECS/DOD design as well as the potential for higher performance gains and more control over the Core.
Describe alternatives you've considered:
Are there any potential roadblocks or challenges facing this change?
Are there any downsides to implementing this change?
Additional context