Interface Resizing

ID:2112743
 
Jul 7 2016, 9:54 pm
Code:
#define ceil(x) (-round(-x))



#define TILE_WIDTH 32
#define TILE_HEIGHT 32
#define MAX_VIEW_TILES 800

world
    icon_size = 32

client
    var
        view_width
        view_height
        buffer_x
        buffer_y
        map_zoom
    verb
        onResize()
            set hidden = 1
            set waitfor = 0
            var/sz = winget(src,"map1","size")
            var/map_width = text2num(sz)
            var/map_height = text2num(copytext(sz,findtext(sz,"x")+1,0))
            map_zoom = 1
            view_width = ceil(map_width/TILE_WIDTH)
            if(!(view_width%2)) ++view_width
            view_height = ceil(map_height/TILE_HEIGHT)
            if(!(view_height%2)) ++view_height

            while(view_width*view_height>MAX_VIEW_TILES)
                view_width = ceil(map_width/TILE_WIDTH/++map_zoom)
                if(!(view_width%2)) ++view_width
                view_height = ceil(map_height/TILE_HEIGHT/map_zoom)
                if(!(view_height%2)) ++view_height

            buffer_x = round((view_width*TILE_WIDTH - map_width/map_zoom)/2)
            buffer_y = round((view_height*TILE_HEIGHT - map_height/map_zoom)/2)

            src.view = "[view_width]x[view_height]"
            for(var/hudobj/h in screen) h.updatePos()
            winset(src,"map1","zoom=[map_zoom];")


Problem description:

Let me start off by apologizing for that semi-wall, and by linking you to the snippet/tutorial page I was using this from: http://www.byond.com/forum/?post=1816091

I replaced the floor define with round procs, because floor was returning some error, but anywho, this works absolutely fine for me. It shows up perfectly, resizes like so:



It works perfectly with my monitor size, resizing and getting exactly the look I was hoping for, but I found a problem when others with varying monitor sizes tested it, especially for those with bigger resolution settings. Examples of this:




As you can see, when the screen is resized along with the map, it causes a sort of zoom that I wasn't hoping for, I can only assume because it's not properly changing the view of the client to fit the resized window, or something to that effect. I looked more into the code, and noticed the map_zoom vars. The map_zoom was set to one, but if I disabled the zoom, it ended up doing something like this:



What I'm trying to do is make it so that when it resizes, it doesn't create a zoom or anything like that, but instead just increases the players view to fit the bigger size. Does anyone have any helpful advice?


Jul 7 2016, 10:51 pm
Don't use round add floor back 
#define floor(v) round(v)


Also did you setup the map so it isn't stretch and just normal icon size 32.
Jul 8 2016, 5:56 am
Your description hints that it may have to do with the MAX_VIEW_TILES variable. Have you tried increasing the value?
Jul 8 2016, 7:26 am
Is 32 really the size of your tiles?
Jul 8 2016, 5:46 pm
Yeah, the tile size is 32x32, and increasing it made it zoom out a little bit, and had no effect on my side. The tutorial I got this from said it didn't recommend going over 1200 tho.
Jul 9 2016, 12:52 pm
The increase of view size is completely intentional. 2D graphics require a clean aspect ratio in order for your game to not look like shit.

The reason I don't recommend over 1200 tiles in the viewport at any one time is that BYOND is a server-directed environment. The client has almost no information about what is going on around the user. The bigger the view size, the more information has to be sent. The more information has to be decoded, sorted, and then rendered into visual data.

You will not achieve reasonable performance with greater than 1200 tiles in the viewport with BYOND with a reasonable framerate. Feel free to go above it, but be forewarned, most of your users are going to start complaining about lag.

Also remember that you have to account for the viewport bounds overlap for your screen objects because my approach forgoes ugly black letterbox in favor of the developer understanding that parts of the screen are cropped and it must be accounted for.
Jul 9 2016, 5:18 pm
Hm, I see. Useful information, ofc!

So there's not really a way to reduce the zoom when someone with a higher resolution is playing? I mean, it works fabulously for me, but I don't want other players to suffer with stretched, zoomed graphics because I couldn't figure this out ;c

When you say the increase of view size is intentional, do you mean the zooming, or the increase of the actual view var? I'd like for people with higher screen resolution to not have that zoom, but instead, they'd just be able to see more turfs in their map than say, someone with my resolution. It'd update their view size based on their resolution.

I'm pretty novice with interfaces and the like, but is what I'm trying to do impossible?
Jul 9 2016, 5:30 pm (Edited on Jul 9 2016, 5:35 pm)
I'm pretty novice with interfaces and the like, but is what I'm trying to do impossible?

I feel like I answered all of these questions in my last post.

When you say the increase of view size is intentional, do you mean the zooming, or the increase of the actual view var?

Both.

I'd like for people with higher screen resolution to not have that zoom, but instead, they'd just be able to see more turfs in their map than say, someone with my resolution.

Again, I explained that the larger the number of tiles in range of a number of clients, the worse that performance for the client and server will be. I absolutely irrevocably warn against doing this, but:

In the tutorial you followed, there's a preprocessor definition called MAX_VIEW_TILES. BYOND supports up to 5000 tiles in the view at any one point. Going above that simply CAN NOT BE DONE. It is a well documented engine limitation. Change MAX_VIEW_TILES to 5000 from 800 tiles (my default sweet spot). That will acheive the effect. However, you should be warned that attempting to fullscreen on a 4K monitor will result in the following equation:

3840/32 = 120 -> 121
2160/32 = 67.5 -> 69

121*69 = 8349 tiles @ 1x zoom (121x69 viewport) !!THIS IS MORE THAN 5,000 TILES!!

Therefore: Double zoom:

3840/64 = 60 -> 61
2160/64 = 34 -> 35

61*35 = 2135 tiles @ 2x zoom (61x35 viewport)



Please don't take this as me being a dick.

The reason my viewport resizing tutorial works the way it does is very methodically thought through. You do not want to do what you are asking the system to do because it will make your project completely unplayable in multiplayer. It's just a bad idea. Don't do it. That said, I can't stop you from shooting yourself in the foot. The instructions are above.

Also, if you have ever used a monitor with a 1080p or 4K resolution, you would understand why it's a bad idea to present a pixel art game at 1x zoom on those resolutions. Not only are you making your game unplayable by doing this, but you are destroying the game's presentability by making your pixel art unreadable, destroying the game's flow by giving players viewports too large to control, making your artists' lives hell by taking away their ability to present scale and impose on the player through size, and making your job as a developer a hundred times harder as detecting the internal walls of the player's viewport more difficult to predict making a myriad of problems you could easily avoid by standardizing a few particular view sizes that you know will work on hardware you are specifically targeting.

Basically, I could write a lecture on why this is a bad idea. Here's 3/4th of one instead.
Jul 9 2016, 6:25 pm
You're good, I don't take it as you being a dick. If anything, I'm thankful for your advice. You obviously know far more than I, so I'll take your word for it that attempting to do what I'm trying is a bad idea.

For now, I'm just gonna leave the zoom feature in it, and see how people react to it. Honestly, if they're playing on a larger resolution and dislike the zoom, they could always just minimize the window to it's standard settings.