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

Support zoom/scale #375

Open
nanodeath opened this issue Mar 19, 2021 · 0 comments
Open

Support zoom/scale #375

nanodeath opened this issue Mar 19, 2021 · 0 comments
Assignees
Labels
blocked Tasks which are blocked help wanted More complex issues for which we'd like to get community help

Comments

@nanodeath
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Sometimes I have a 16px or 20px tileset, but it'd hard to see due to the small size and I'd rather it render as a 32px or 40px tileset, and I don't have or for legitimate reasons don't want to use a larger tileset.

Describe the solution you'd like

A way to configure, at runtime, whether the tileset should be "zoomed"/embiggened or not. Scaling should use a nearest-neighbor-type algorithm to ensure pixel art remains pixely and not blurry. This should ultimately be implemented near the draw surface level by drawing an image onto the surface with a width and size larger than the source image.

Further thought needs to be given to how to selectively zoom components rendered to the screen. For example, the GUI likely should not be scaled, only the main play area.

Ideas for things that should perhaps accept a zoom argument:

  • Components
  • Tilesets
  • Layers

Describe alternatives you've considered

Asset Pipeline

What if I simply used ImageMagick or equivalent during my build process to automatically generate tilesets at the sizes I want?

Pros

  • Works today! Anyone can do this right now to get this functionality.
  • Not reliant on scaling at runtime, which could be more performant and less contingent on platform capabilities.

Cons

  • Requires every developer to write code in order to resize images (unless we build a standardized version)
  • Game will need to ship with each size of each asset, increasing the game's installed size
    • Counterpoint: game is likely to be tiny to begin with.
  • Images at 2x zoom will be 4x as large in memory. Images at 3x zoom will be 9x larger.
    • Counterpoint: these images were small to begin with, and there are unlikely to be very many of them.
  • If the developer makes the zoom customizable at runtime via Settings, swapping tilesets means swapping resources and may:
    • Require loading new assets from disk, causing a short delay.
    • Restarting the game (though unlikely).

Additional context

If I apply the following diff:

index c77514e3b..0e66176ff 100644
--- a/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DCP437Tileset.kt
+++ b/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DCP437Tileset.kt
@@ -56,9 +56,13 @@ class Java2DCP437Tileset(

     override fun drawTile(tile: Tile, surface: Graphics2D, position: Position) {
         val texture = fetchTextureForTile(tile, position)
-        val x = position.x * width
-        val y = position.y * height
-        surface.drawImage(texture.texture, x, y, null)
+        val scale = 2
+        val x = position.x * width * scale
+        val y = position.y * height * scale
+        surface.drawImage(texture.texture, x, y,
+            width * scale,
+            height * scale,
+            null)
     }

     private fun fetchTextureForTile(tile: Tile, position: Position): TileTexture<BufferedImage> {
diff --git a/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DGraphicTileset.kt b/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DGraphicTileset.kt
index 2ccf3f0fc..79b46a862 100644
--- a/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DGraphicTileset.kt
+++ b/zircon.jvm.swing/src/main/kotlin/org/hexworks/zircon/internal/tileset/Java2DGraphicTileset.kt
@@ -72,9 +72,13 @@ class Java2DGraphicTileset(private val resource: TilesetResource)

     override fun drawTile(tile: Tile, surface: Graphics2D, position: Position) {
         val texture = fetchTextureForTile(tile)
-        val x = position.x * width
-        val y = position.y * height
-        surface.drawImage(texture.texture, x, y, null)
+        val scale = 2
+        val x = position.x * width * scale
+        val y = position.y * height * scale
+        surface.drawImage(texture.texture, x, y,
+            width * scale,
+            height * scale,
+            null)
     }

The rendered image goes from this:
image

to this:
image

So it definitely seems possible, at least on the JVM with the Java2D tilesets.

@adam-arold adam-arold added the help wanted More complex issues for which we'd like to get community help label Mar 19, 2021
@adam-arold adam-arold added the blocked Tasks which are blocked label Aug 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Tasks which are blocked help wanted More complex issues for which we'd like to get community help
Projects
None yet
Development

No branches or pull requests

2 participants