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
I didn't see this on the plans list so I thought to post it here. OHRRPGCE appears to have a hard coded limit of 20 x 20 pixels for world tiles, and other fixed sizes for enemy and hero graphics. I believe it would improve flexibility a lot if tile size could be specified as a global setting, while heroes and monsters could have custom resolutions (instead of "Small Enemy" / "Medium Enemy" / "Large Enemy").
For world tiles: This would be a global setting that the user should define before he starts mapping and drawing, based on the sprite resolution he plans to use. It would basically tell the engine what the size of a tile is. This would affect the pixel range that tiles are separated by (when importing a bmp set), and the scale of each tile and walkabout graphic you draw. Obviously, it would affect the virtual grid that the player walks on, adding more pixels per step (as it basically scales the world in pixel size). Since tile size would be one for the entire project, each item would snap accordingly no matter what the size is, and no functionality would change.
For battle graphics: Since heroes and monsters don't need to snap anywhere, I imagine each can be given an individual resolution. For example, I can have a monster at 80 x 80 pixels and another at 160 x 160, where I specify the resolution before I start drawing the characters. Same for heroes, where each can be given any sprite resolution when you define that hero, then you draw each frame based on that.
For compatibility, the default value should probably be 20 for world tiles, and whatever is appropriate for battle graphics. If the developer resizes the world or a hero / monster after he has drawn it, the engine could do one of two things: Either cut the image if shrinking it or give it a transparent border if expanding it (crop), or if the engine can handle such editing, resize the image and change its resolution (resample). Custom resolutions could also be allowed for text box portraits.
Apart from allowing higher quality / higher resolution RPG's, this would allow importing free tile sets of various resolutions without losing quality. For example, I found a nice tile package where each square is 32 x 32. If I'd find walkabout graphics for heroes and NPC's of the same size, I could make a nice HD game without having to size them down. This feature would probably go hand in hand with allowing a larger window resolution (already planned), but I believe it can be implemented before that. With the current window scale, larger sprites might make the world appear too close and zoomed in.
From: @MirceaKitsune
Operating system: Windows 7
Severity: feature request
The text was updated successfully, but these errors were encountered:
Resizable spritesets are finally implemented in fufluns. Tile sizes other than 20x20 are a completely different feature; only a small part of that has to do with tile graphics. I disagree with this suggestion for having a single tile size setting for a whole game, since it would make it impossible to change in an existing game. and it's pretty obsolete and distracting, so I'm closing this. I want each tileset to have its own tile size setting. If someone wants to start a discussion or have something to upvote, I suggest filing a new request.
[bz#938]
I didn't see this on the plans list so I thought to post it here. OHRRPGCE appears to have a hard coded limit of 20 x 20 pixels for world tiles, and other fixed sizes for enemy and hero graphics. I believe it would improve flexibility a lot if tile size could be specified as a global setting, while heroes and monsters could have custom resolutions (instead of "Small Enemy" / "Medium Enemy" / "Large Enemy").
For world tiles: This would be a global setting that the user should define before he starts mapping and drawing, based on the sprite resolution he plans to use. It would basically tell the engine what the size of a tile is. This would affect the pixel range that tiles are separated by (when importing a bmp set), and the scale of each tile and walkabout graphic you draw. Obviously, it would affect the virtual grid that the player walks on, adding more pixels per step (as it basically scales the world in pixel size). Since tile size would be one for the entire project, each item would snap accordingly no matter what the size is, and no functionality would change.
For battle graphics: Since heroes and monsters don't need to snap anywhere, I imagine each can be given an individual resolution. For example, I can have a monster at 80 x 80 pixels and another at 160 x 160, where I specify the resolution before I start drawing the characters. Same for heroes, where each can be given any sprite resolution when you define that hero, then you draw each frame based on that.
For compatibility, the default value should probably be 20 for world tiles, and whatever is appropriate for battle graphics. If the developer resizes the world or a hero / monster after he has drawn it, the engine could do one of two things: Either cut the image if shrinking it or give it a transparent border if expanding it (crop), or if the engine can handle such editing, resize the image and change its resolution (resample). Custom resolutions could also be allowed for text box portraits.
Apart from allowing higher quality / higher resolution RPG's, this would allow importing free tile sets of various resolutions without losing quality. For example, I found a nice tile package where each square is 32 x 32. If I'd find walkabout graphics for heroes and NPC's of the same size, I could make a nice HD game without having to size them down. This feature would probably go hand in hand with allowing a larger window resolution (already planned), but I believe it can be implemented before that. With the current window scale, larger sprites might make the world appear too close and zoomed in.
From: @MirceaKitsune
Operating system: Windows 7
Severity: feature request
The text was updated successfully, but these errors were encountered: