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

Encapsualting graphics state changes #273

Open
17cupsofcoffee opened this issue Jul 21, 2021 · 0 comments
Open

Encapsualting graphics state changes #273

17cupsofcoffee opened this issue Jul 21, 2021 · 0 comments
Labels
Area: Graphics Issues related to graphics/rendering. Type: Feature Request Improvements that could be made to the code/documentation.

Comments

@17cupsofcoffee
Copy link
Owner

17cupsofcoffee commented Jul 21, 2021

Summary

aka: why did my GUI library just yeet my transform matrix

One thing I've noticed as I've been writing some games/libraries with Tetra, is that it's quite hard to build rendering abstractions that don't leak into the global rendering state.

It would be good to add something to the API that would let you push/pop graphics state changes. There's a similar API in a lot of engines I've used (most notably Love2D), and it ends up being pretty convenient.

In the past I've said I wouldn't implement this because it's possible to do in user-space, but that doesn't take into account the fact that code you don't control (e.g. third party libraries) can't benefit from that.

Motivation/Examples

  • In one of my game projects, I have a piece of code that wants to draw to a canvas, and then switch back to whatever canvas was previously bound. At the moment, this means you have to pass the canvas in, which makes things a bit more unwieldy.
  • I'm working on an imgui renderer for Tetra, and this requires me to set the scissor rectangle and blend modes to ensure correct rendering. Again, if I want to be able to leave the state how I found it, I'd have to make the API consumer pass it in, which feels a bit gross.

Alternatives Considered

  • We could just leave things as is - it's not causing any earth-shattering issues, and people haven't complained so far.
  • We could try to make the API less stateful - though I'm not sure how to do this without adding a ton of parameters to a load of methods...
@17cupsofcoffee 17cupsofcoffee added Type: Feature Request Improvements that could be made to the code/documentation. Area: Graphics Issues related to graphics/rendering. labels Jul 21, 2021
@17cupsofcoffee 17cupsofcoffee changed the title Add some kind of graphics state stack Encapsualting graphics state changes Jul 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Graphics Issues related to graphics/rendering. Type: Feature Request Improvements that could be made to the code/documentation.
Projects
None yet
Development

No branches or pull requests

1 participant