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

Created a High-Res screenshot option to gui. #85

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Igrium
Copy link

@Igrium Igrium commented Jul 22, 2022

I was finding myself needing to easily take screen captures of my world at large scales, and due to my monitor's resolution, Snipping Tool wasn't cutting it. I decided to go ahead and code a simple function that takes a screenshot of the current viewport where one block = one pixel.

The feature can be accessed with File > Screenshot. It simply takes a screenshot there and then, and then brings up a file chooser so you can save it.

@piegamesde
Copy link
Owner

That's pretty cool, many thanks for doing this. I guess that it renders the world at the resolution of the screen/display, correct? Also, which parts of the overlay (grid, pins, etc.) get rendered)?

I think this is pretty similar to the request in #82, although for that the export should include the entire view and at full resolution. Maybe we can do both?

@Igrium
Copy link
Author

Igrium commented Jul 22, 2022

This actually renders the world at a resolution where one block is equal to one pixel. So if you're viewing your world at 1:1, yes, that would be your display resolution. However, if you zoomed out and are viewing, say a 4K x 5K block area, your image would be 4000 pixels by 5000 pixels.

None of the UI elements get rendered because we're directly rendering the RenderedMap to a custom canvas and then saving it with Canvas#snapshot. The UI elements would need to be drawn to that canvas as well.

@piegamesde
Copy link
Owner

Code looks good to me except for one thing: If I zoom out a lot and then hit screenshot, the resulting image will be huge yet mostly contain transparent pixels. The rendered frustum should be clamped down to the bounds of the world to avoid this.

There is also the issue that – similarly to --create-big-image – this will easily require huge amounts of RAM. I'm willing to accept that, but maybe we should warn the users abouti t.

On a technical note, please target the PR against the develop branch.

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

Successfully merging this pull request may close these issues.

3 participants