You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
to this:
So it definitely seems possible, at least on the JVM with the Java2D tilesets.
The text was updated successfully, but these errors were encountered:
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: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
Cons
Additional context
If I apply the following diff:
The rendered image goes from this:
to this:
So it definitely seems possible, at least on the JVM with the Java2D tilesets.
The text was updated successfully, but these errors were encountered: