-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI/UX - Device types and Engine version #1147
Comments
The main difference is one is for project settings. This affects the build and other users on the project. The launcher options just affect your launch tab. This allows you do things like test the app under WebGL 1 (for compatibility/you get get a bug report) without changing the project data itself. Having a single option between WebGL 1 / 2 / WebGPU makes sense. The launcher tickboxes were probably stacked for ease at the time while WebGPU support was still considered 'beta'. It made sense when we just had WebGL 1 and 2 😅 |
One option with highest GAPI is the way to go. Although there is a scenario where developer wants to support only WebGPU, and not WebGL, and would need a nice solution to provide UI to user in such case. Handling app launching without ending up with barrage of exceptions. |
Yes I agree the launcher force option should be clear that its an override of the existing project device settings. With regards to the setting WebGPU I mean the way createGraphicsDevice works itll fall back to WebGL if failing WebGPU even if not directly specified because otherwise theres nothing to render with. I guess I can just overlay with a splash screen saying |
We could add an |
Providing UI to the user that no GAPI is available should be down to the user with probably default behaviour (if not provided by user) with very minimal UI by the engine (not an alert please). |
Okay so ive added some UI examples for the proposed UI/UX. The one area that isnt covered yet is setting a device without wanting to fallback e.g. WebGPU. In that case I was thinking of adding a |
I would drop the |
The launcher override makes sense, but users should be able to explicitly set the the fallback where necessary. As @Maksims mentioned, they may only want to support WebGPU and we shouldn't force fallback to WebGL. |
Yea thats why having a disable fallback flag will be useful |
Maybe we need to go a similar way to what I've suggested for the examples. In the Editor settings, have two options:
That will dictate where in this chain we'll start using the devices: |
@mvaligursky So by default both are set with the ordering implied? |
I guess the default would be |
Okay sounds good ill add those and then for the launcher is the proposed submenu for device better? |
This issue is to be used for discussing a cleaner and more informative device type management and editor engine version.
Device types
Current solution
The current state is as follows with an ordered multi select for the project device types which is project scoped
The launcher has two flags which are non persistent that can be used to override the project settings for quick testing in the launcher
Proposed solution
The ordering for project device types seems unnecessary as you would never want to fallback from an older device to a new one (eg. WebGL1 to WebGL2 or WebGPU). We can define the order as
WebGPU -> WebGL2 -> WebGL1 -> Null
with each arrow denoting the next device to fallback to. The user can then choose which devices to enable with two togglesEnable WebGPU
andEnable WebGL2
. With both of these disabled the graphics device will fallback to WebGL1 on the old engine and NullDevice otherwise.For the launcher itself the two choices
Prefer WebGL1
andPrefer WebGPU
options will be replaced by aLaunch Device
option which branches off to a submenu of radio buttons one for each device. The default device selected will match the project setting on load but can be changed here to affect which device is used for the launcher.Engine Version
Given the devices shown now depend on the engine version this should be modified as such. The engine versions will now be displayed as follows:
These versions will force update the user to use those versions relative to the current stable release. This with the exception of previous stable which would cause the user to be doubly force updated to the latest stable engine. As such better UI is required to signifiy the current engine version you are on, when there was a force engine update and which version it was updated from (maybe do not need the last part).
The text was updated successfully, but these errors were encountered: