ebiten: `RunGameWithOptions` to specify a graphics library explicitly

[hajimehoshi]

ebiten.SetGraphicsLibrary might be another option, but setting a graphics library afterRunGame doesn't make sense.

Requested by @erexo

[hajimehoshi]

These are other examples that don't make sense to be called after RunGame

• SetInitFocused
• SetScreenTransparent

[hajimehoshi]

For specifying a graphics library, we need more discussion.

• The use case is that a game works well with OpenGL than DirectX, but in this case, isn't there an issue in Ebitengine?
• Letting a player choose a graphics library might be a good idea, maybe?

[hajimehoshi]

The use case is that a game works well with OpenGL than DirectX, but in this case, isn't there an issue in Ebitengine?

@erexo reported the example was #2232. Then I'll focus on #2232 first...

[tinne26]

My two cents:

• Maybe SetScreenTransparent should be possible to use after RunGame. I have used multiple virtual keyboards, and more than one had the option to change styles including opaque and transparent backgrounds. It might be a niche use-case, but it wouldn't be crazy for someone to want SetScreenTransparent to remain available even after RunGame.

On the topic of OpenGL vs DirectX, while I agree that 2232 is quite critical, there may be more to it (from https://github.com/hajimehoshi/ebiten/issues/2333):

DirectX has a GPU usage of around 40%, way lower than OpenGL (94%), which suggests underusage of the GPU.

Maybe @erexo wants to look into that performance metric for his game and let us know? My examples didn't use SubImage() at all, and maybe some parts of his game (maybe in the map with minimap and other UI disabled) don't use that either.

[hajimehoshi]

Maybe SetScreenTransparent should be possible to use after RunGame.

There are some technical reasons we cannot change this after RunGame. A transparent window is hard to achieve with DirectX for example. We cannot change the graphic library after RunGame.

[erexo]

what about

type RunGameOptions struct {
    InitFocused       bool
    ScreenTransparent bool
    GraphicsLibrary   GraphicsLibrary
}

func RunGameWithOptions(game Game, options *RunGameOptions) error {
    ...
}

[hajimehoshi]

Yeah but we need discussions about whether we really need the option of graphics library

[hajimehoshi]

I still hesitate to introduce an API for a graphics library, since specifying a graphics library means that there is an issue in the default graphics library. So, the first priority is to fix the issue.

[erexo]

That's true, it's good to have DirectX working better than OpenGL on windows. But even if you manage to do that there are scenarios where you would want to specify OpenGL explicitly. One of such scenarios is just debugging, how do I know if my particular game runs better on DirectX? As a developer I would like to test it out on both engines. Second argument is mentality of PvP oriented mmorpg game players. I can hear stories about how certain group lost a match just because one of their players had 139 fps. Currently my players have an library choice and there are people who are willingly using OpenGL over DirectX just because they think that it is better for them. Regardless of the actual effectiveness of such action if I take that option from them, they would not take it kindly. And lastly it's not like you are adding new functionality to the API, there is already an option to force graphics library in Ebitengine, but in a very cumbersome way. If you are claiming that it should not be needed to change the library, why did you implement such option in the first place?

tl;dr I'm aware that 97% of game devs are not in need to explicitly change the graphics lib, but I truly am and I do have empiric proofs for that, so since there is already an option to determine the library, why shouldn't it be easier?

[hajimehoshi]

If you are claiming that it should not be needed to change the library, why did you implement such option in the first place?

This is needed for special cases like testing Ebitengine itself.

why shouldn't it be easier?

An easier API would make users tend to use it easily, though I don't want them to use it if possible. That's why.

[hajimehoshi]

Second argument is mentality of PvP oriented mmorpg game players. I can hear stories about how certain group lost a match just because one of their players had 139 fps. Currently my players have an library choice and there are people who are willingly using OpenGL over DirectX just because they think that it is better for them. Regardless of the actual effectiveness of such action if I take that option from them, they would not take it kindly.

Have you already run an MMO with Ebitengine? This is a good case that I need to improve the DirectX driver.

[SolarLune]

I think it could be useful to add as an option on game start-up, sure. I think it could be a good option for people who want to debug their game's rendering process under a specific backend. This would afford them various graphics backend options to use when attaching their rendering debugger (i.e. RenderDoc, as an example) to their game.

An easier API would make users tend to use it easily, though I don't want them to use it if possible. That's why.

You could add documentation that says to leave it up to Ebitengine unless you need a specific graphics back-end for a specific reason. I think most people either wouldn't mess with it, would set it to a non-problematic setting (like OpenGL on Linux), or set it to a setting that would immediately force a crash, leaving them to choose something else (like DirectX on Linux).

[AmanitaVerna]

Right now, whether the backend is set via environment variable or via a RunGameWithOptions function, we could have our programs watch for a --opengl or --directx command line flag or the like, if we want the user to be able to specify which to use (as many games do).

The doc comment on RunGame says "Don't call RunGame twice or more in one process," which I assume means it's not possible to shut down Ebitengine (returning a particular error, and watching for it) and restart it to switch backends?

[hajimehoshi]

The doc comment on RunGame says "Don't call RunGame twice or more in one process," which I assume means it's not possible to shut down Ebitengine (returning a particular error, and watching for it) and restart it to switch backends?

Yes, that's correct

[SolarLune]

I suppose this means that you would need to spawn another process to run the game again with the specified graphics library flag.

[hajimehoshi]

As #2232 is already fixed, I think this is a little deprioritized. @erexo What do you think?

[erexo]

As #2232 is already fixed, I think this is a little deprioritized. @erexo What do you think?

I'm allowing my players to change their graphics library so I have to have code responsible for switching the library, and due to reasons already mentioned in this issue this won't change no matter how good DirectX is 😅 It is doable right now with env variables so it's not urgent, but having the ability to do it much, much more easily would be a huge plus.

[hajimehoshi]

I'm allowing my players to change their graphics library so I have to have code responsible for switching the library, and due to reasons already mentioned in this issue this won't change no matter how good DirectX is 😅

But ideally users would not have to care what graphics library is used, right...? And I have actually resolve one significant issue about DirectX.

[erexo]

true, but as I mentioned, I'm not developing a single player game for casual people to relax themselves after work, but a mmorpg heavily focused on PvP where players may lose by an inch. That's why I need to do absolutely everything that is in my power to ensure smooth gameplay so players won't accuse me or my game for their faults. There were situations in the past where players left the game because they claimed that in the decisive moment the game had a lag for 0.3s and that was the reason why they lost. That being said, I know for sure that unavailability of OpenGL option would be a cause of problems, especially that the current game client written in C++ has that option, so it would be considered a regression. And there are players who willingly prefer OpenGL for whatever reason, but the Customer is King right. And the third reason is that the OpenGL is actually better right now, I know it shouldn't be, but it is. And if you didn't add an option to switch the engine in the first place, we probably wouldn't know that this is true. I know that it may be hard to understand but believe me, it is important. And I'm not really forcing the RunGameWithOptions thing, as I said it's not truly necessary because there is an option to switch the engine, but I would like you to acknowledge that this option is actually used, also in production, for various important reasons. Thanks