I'm currently working on a project and I was attempting to scale the map via winset(). Kaiochao's Zoom library also does this (though much more smoothly) and I was attempting to get it working with my project when I ran into a huge issue.
Scaling the maps icon size will also scale anything on the client screen! I am aware this is intentional, as the client screen is meant to be displayed this way, though I'm wondering with all the recent advances to BYOND if it may be possible to separate the two in terms of the size that the map display it as.
Essentially what I'm requesting is a variable of some sort either in the code itself or as part of the skin which allows a separate scaling of just the client screen as a whole, separate from everything else appearing on the map.
Now I'm not sure which method would be best or simplest or a combination of both, so I'm leaving that open to make sure it's not a hassle or non-feasible based on my description.
For example, perhaps there could be a way to apply a matrix transform to client.screen or client.eye? Or perhaps it could be done through how the map is displayed, I'm not exactly sure which would be best.
Thank you for taking the time to consider my request.
ID:1916254
 Aug 12 2015, 11:23 am
|
|||||||
| |||||||
|
Aug 12 2015, 11:24 am
|
|
Zasif
 |
+1!
|
Also +1!
This also happens in the webclient. When attempting to zoom in and out it will zoom the browser window as well. | |
Thinking on it, yeah, that sounds like it'd fit. My only concern is whether or not in your example that changing client.transform would also modify stuff in client.screen.
| |
In addition to the issues I mentioned in that client.transform topic, there's the issue that the new "crisp" map scaling would be fundamentally incompatible with this.
| |
You mean the non-anti-aliasing? Why is that? If that's the case though, why not have the option to have the old aliasing mode available as well?
| |
Bravo1 wrote:
You mean the non-anti-aliasing? Why is that? If that's the case though, why not have the option to have the old aliasing mode available as well? Here's what's happening under the hood: 1) DS does its normal sprite draw to a non-scaled surface, which uses simple pixel coordinates. This canvas is the "true" size. 2) The non-scaled surface is stretched onto the main surface, using a final size that's close to the final display size but rounded to a multiple of the true size. This stretch gives control over whether anti-aliasing is used. 3) Present() is called, which stretches the results of #2 but does not offer any control over anti-aliasing. There's simply no way to rectify that with your idea. You're treating the HUD as an overlay over everything else, but BYOND doesn't guarantee that to be the case; it allows HUD elements to layer in with map elements. (Isometric/side sorts are an exception. In those cases the HUD effectively uses TOPDOWN_LAYER.) | |
Ah, so does this end up as a non-feasible for both requests or just mine alone?
I'll just have to experiment with some stuff like multiple maps then. Do you think that would be doable? For example, a secondary window, which always sticks to the position and size of the map in the main window, and uses a transparent color. This new window also has a map which displays the players HUD, and is transparent the rest of the way through? That way the main map could be scaled and the overlayed window and it's own map with the HUD would remain the same? I'm just trying to think of some possible way to scale the map without also scaling client.screen objects. | |
IMO both requests are related. The real trick here--and it's significant--is that if the other request can be done, scaling via client.transform won't be subject to this new pretty crisp scaling.
| |
I believe in this case that many would prefer function over form. If it gets all blurry then that might not be a huge deal depending on the graphical fidelity of the pixel art in the first place.
Does the client.transform idea seem feasible though? If so, I think we can close out this request as it's pretty much a duplicate of the other. Also, would you have an idea of what kind of timeline it would take to implement it? I ask just so that people can know that it's being considered but that it's still a ways off. Something tells me you might've mentioned it before but I can't seem to find the post so I just want to cover my bases. | |
I can say that it does get pretty blurry. I would like to be able to turn AA off! Some don't mind jaggies.
| |
Neither is currently being considered. Too many unresolved questions at the moment. That might change in the future if the questions in the original request can be dealt with satisfactorily.
| |