-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
Screen Capturing #771
Screen Capturing #771
Conversation
…dbox to demonstrate it
Loading of assets doesn't seem to work yet
… the asset loaded event
Also allows for capturing multiple images at once, and scaling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I've left some comments. I think the main one is about passing the renderer to the framecontext.
I think the solution you have here is probably as good a job as you can do without a deeper (and trickier!) integration with the renderer.
The alternative I'm thinking of wouldn't need you to retain the previous data because you'd render to two canvas's at once (if some flag was set), dropping the layers you wanted to skip. Don't know if it would work of course, because I haven't tried it!
indigo/indigo/src/main/scala/indigo/platform/renderer/ScreenCaptureConfig.scala
Outdated
Show resolved
Hide resolved
indigo/indigo/src/main/scala/indigo/shared/platform/SceneProcessor.scala
Show resolved
Hide resolved
@@ -1,16 +1,26 @@ | |||
package indigo.platform.renderer.webgl1 | |||
|
|||
import indigo.AssetName | |||
import indigo.AssetPath | |||
import indigo.platform.assets.AtlasId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to drop this from the WebGL1 implementation. WebGL1 is very limited - really only good enough to display a message saying "don't use this" - and I'd hope no-one is trying to build anything screen capture worthy in it. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all the time we have a WebGL1 implementation we should support it.. It doesn't add much work in this case, so I think we should keep it
) | ||
) | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. So if I'm reading correctly, the process is:
- Take the previous scene (so that you can filter out the layers people don't want to capture).
- Set up a new canvas.
- Re-render which effectively overwrites the usual canvas context.
- Grab it, and stuff it into the new canvas.
- Save it.
Have I got that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's pretty much the process 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks @hobnob. 🔥
Allows for capturing a screen using the context, fulfilling #735
Usage:
Breaking Change:
Also adds an additional property to
AssetEvent.AssetBatchLoaded
detailing the assets that were loaded in the lastAssetEvent.LoadAssetBatch
event