Skip to content
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

ebiten: expose the default implementation of FinalScreenDrawer #3139

Closed
11 tasks
noppikinatta opened this issue Oct 21, 2024 · 6 comments
Closed
11 tasks

ebiten: expose the default implementation of FinalScreenDrawer #3139

noppikinatta opened this issue Oct 21, 2024 · 6 comments

Comments

@noppikinatta
Copy link

Operating System

  • Windows
  • macOS
  • Linux
  • FreeBSD
  • OpenBSD
  • Android
  • iOS
  • Nintendo Switch
  • PlayStation 5
  • Xbox
  • Web Browsers

What feature would you like to be added?

I may want to call the following code in DrawFinalScreen that I have implemented in my Game.

https://github.com/hajimehoshi/ebiten/blob/v2.8.1/gameforui.go#L139-L155

I would like this code to be a function and be able to call it like ebiten.DrawFinalScreenDefault(screen, offscreen, geoM).

Why is this needed?

Whether or not a filter is applied when drawing a game depends on the situation. For example, I may want to draw the Ebitengine splash screen unfiltered when the game starts up, and apply the CRT filter on the title screen and beyond.
Now Ebitengine does not allow me to call the default behavior if Game implements FinalScreenDrawer.

@hajimehoshi
Copy link
Owner

Makes sense.

@hajimehoshi hajimehoshi changed the title New API to call the default behavior of DrawFinalScreen ebiten: expose the default implementation of FinalScreenDrawer Oct 21, 2024
hajimehoshi added a commit that referenced this issue Oct 21, 2024
@noppikinatta
Copy link
Author

Thanks for adding the feature!
The function name is DefaultDrawFinal “s” Screen, is this a typo?

func DefaultDrawFinalsScreen(screen *Image, offscreen *Image, geoM GeoM) {

hajimehoshi added a commit that referenced this issue Oct 24, 2024
@hajimehoshi
Copy link
Owner

This was typo. Thanks!

@noppikinatta
Copy link
Author

The type of first argument of DefaultDrawFinalScreen screen is *Image, but wouldn't it be better to have the FinalScreen interface, same as FinalScreenDrawer.DrawFinalScreen?

I want to call DefaultDrawFinalScreen from my own FinalScreenDrawer.DrawFinalScreen, so I think it would save me the trouble of casting FinalScreen to *Image or preparing an *Image of the same size as FinalScreen.

@hajimehoshi
Copy link
Owner

Oh that's true... Let me fix this

@hajimehoshi
Copy link
Owner

Fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants