What is the current behaviour?
Currently, all of our samples just invoke main(), and we do not attempt to use OS specific methods for starting the applications.
What is the expected behaviour/change?
We can implement an "Application" abstraction class within NovelRT's Core, with per-OS definitions (based on differences) to get native calls for launching the applications.
What is the motivation / use case for changing the behavior?
Windows is always getting consoles appearing on Release unless WinMain() is used as the entry-point.
ALSO, this allows us to better plan for usage around Mobile (think entry-points via JNI/Native for Android and similar for iOS), as well as allows users to customise what occurs at application start up (in the future, this could be used to invoke loading/splash screens ahead of time before the Core actually starts).
Describe alternatives you've considered:
Letting end-users handle it
Doesn't seem nice to do for newer/inexperienced users
Not providing this
Annoying but can be ignored - some retail games do this, especially when played in Fullscreen/ Borderless Windowed
Are there any potential roadblocks or challenges facing this change?
Ensuring that this works via Interop as well.
Need a way to provide Console output when desired
This can be built into the Core as an integrated Console, or as a flag that would switch between a console-less entry point and one that invokes a console.
Are there any downsides to implementing this change?
Cannot think of any - users would be able to modify the entry-points w/o affecting Core source, and if they needed anything new they can use source builds to adjust each OS as necessary or desired.
Additional context
You can change the entry point for one of the samples from main() to WinMain() (with the proper parameters) on Windows and see the difference - mainly notice that no console launches, but instead the application just directly starts via a GLFW window.
What is the current behaviour? Currently, all of our samples just invoke
main(), and we do not attempt to use OS specific methods for starting the applications.What is the expected behaviour/change? We can implement an "Application" abstraction class within NovelRT's Core, with per-OS definitions (based on differences) to get native calls for launching the applications.
What is the motivation / use case for changing the behavior? Windows is always getting consoles appearing on Release unless
WinMain()is used as the entry-point. ALSO, this allows us to better plan for usage around Mobile (think entry-points via JNI/Native for Android and similar for iOS), as well as allows users to customise what occurs at application start up (in the future, this could be used to invoke loading/splash screens ahead of time before the Core actually starts).Describe alternatives you've considered:
Are there any potential roadblocks or challenges facing this change?
Are there any downsides to implementing this change? Cannot think of any - users would be able to modify the entry-points w/o affecting Core source, and if they needed anything new they can use source builds to adjust each OS as necessary or desired.
Additional context You can change the entry point for one of the samples from
main()toWinMain()(with the proper parameters) on Windows and see the difference - mainly notice that no console launches, but instead the application just directly starts via a GLFW window.