Resizing

Page: 1 2
ID:2348033
 
Feb 22 2018, 7:50 pm
(See the best response by Ter13.)
Code:
mob/verb/resize()
    set hidden = 1
    var/size = winget(src,"map.Main","size") //"default" is the name of the default window.
    var/x = findtext(size,"x") //Returns a numeric value, where 'x' is located in the string
    var/WIDTH = text2num(copytext(size,1,x)) //Copy the text from the first placement to before the 'x'
    var/HEIGHT = text2num(copytext(size,x+1)) //Copy the text after the 'x'
    WIDTH = round(WIDTH/32) //Receive a whole number. This ratio works 1:1, 1 pixel for each pixel on screen. Modify that by changing '32'
    HEIGHT = round(HEIGHT/32) //Same as above
    client.view = "[WIDTH]x[HEIGHT+1]"


Problem description:Would like to know if there was a better option. For resizing window keeping Screen Objs in same place and all.

Feb 22 2018, 9:26 pm (Edited on Feb 22 2018, 9:55 pm)
Best response
winget() is unnecessary. The on-resize command will replace "[[*]]" with the new size if included as an argument of the property. See the skin reference for details.

Check out the LEFT,TOP,BOTTOM,RIGHT screen locations in the new BYOND beta. They are currently bugged, but they should make resizable UIs much easier.

http://www.byond.com/forum/?post=2189366

Also this bit:

    var/x = findtext(size,"x") //Returns a numeric value, where 'x' is located in the string
    var/WIDTH = text2num(copytext(size,1,x)) //Copy the text from the first placement to before the 'x'
    var/HEIGHT = text2num(copytext(size,x+1)) //Copy the text after the 'x'


500 features make this an inferior way of handling complex strings.

var/list/split = splittext(size,"x")
var/w = text2num(split[1]), h = text2num(split[2])



Set mainwnd.on-resize to:
resize "[[*]]"



#define ceil(x) (-round(-(x)))
#define floor(x) round(x)

#define TILE_WIDTH 32
#define TILE_HEIGHT 32

client/verb/resize(size as text)
    set hidden = 1, instant = 1 //you forgot instant. You should basically always set verbs instant when you don't want them to block the input queue.
    var/list/split = splittext(size,"x")
    //you were also rounding down. You want to round up.
    var/w = ceil(text2num(split[1])/TILE_WIDTH), h = ceil(text2num(split[2])/TILE_HEIGHT)
    //also, you want to ensure that the viewport has odd dimensions so it centers properly.
    w += !(w%2)
    h += !(h%2)
    view = "[w]x[h]"


Also, I would very strongly recommend using a system that will set a maximum number of tiles in the viewport at any given time. Otherwise, players with very large viewports are going to have truly awful performance.

That modification would look something like this:

#define ceil(x) (-round(-(x)))
#define floor(x) round(x)

#define TILE_WIDTH 32
#define TILE_HEIGHT 32

#define MAX_VIEW_TILES 800

client/verb/resize(size as text)
    set hidden = 1, instant = 1
    var/list/split = splittext(size,"x")
    var/w = text2num(split[1]), h = text2num(split[2])
    var/vw, vh, z = 0

    do
        ++z
        vw = ceil(w/z/TILE_WIDTH)
        vh = ceil(h/z/TILE_HEIGHT)
        vw += !(vw%2)
        vh += !(vh%2)
    while(vw*vh>MAX_VIEW_TILES)

    view = "[vw]x[vh]"
    winset(src,"mainwnd","zoom=[z]")
Feb 22 2018, 10:27 pm (Edited on Feb 22 2018, 10:33 pm)
Loving the energy around here lately you guys been a wonderful help I appreciate it.

EDIT: In the argument why is size as text?
Feb 22 2018, 11:12 pm
Because the argument is passed as text, and that's how verb arguments work?

When on-resize is called on a skin element with a verb, if you include "[[*]]", it will pass the new size of the skin element as a size string: "256x240", for instance.

This is why I was saying the winget() wasn't necessary, because BYOND already knows the new size of the object and can be coaxed into passing it at the time that the verb is initiated by the client.

Calling winget() after the verb has been called already means that the client is telling the server to call the verb, then the server is asking the client what size an element is, and then the client tells the server what it asked for.

By using the "[[*]]" argument, the client tells the server to call the verb, and tells it what size the element that changed was at the time the message was sent to call that verb. It involves a much smaller network delay, and makes your code way less ugly.
Feb 22 2018, 11:18 pm
In response to Ter13
when I do size as text it asks me to input text when the verb is called.
Feb 22 2018, 11:23 pm
In response to Ganite
Ganite wrote:
when I do size as text it asks me to input text when the verb is called.

That's because you didn't include "[[*]]" in the on-resize command field in the skin editor like I mentioned three or four times. And also because you didn't actually look up what that is in the skin reference like I mentioned in the first sentence of my first reply.
Feb 22 2018, 11:44 pm
You say I didn't but in reality I did and it still does the same thing.

EDIT: My fault it did work, I was using a child for my game window so I put it on the interface where the map actually was instead of the main window like u said that was the problem.
Feb 22 2018, 11:47 pm
Show me. Computers don't do things all willy-nilly on their own. This issue is only caused by the resize verb being called with a null argument being passed.

Which means you either have not correctly included the argument, or you have included multiple on-resize commands and at least one of them doesn't have the argument included.

These are the only possibilities. Not an attack, just the only possible explanations for what you are seeing.
Feb 22 2018, 11:51 pm
In response to Ter13
https://imgur.com/a/h6D9A
EDIT: Just don't want you to think I'm asking for help and not reading what you are saying because I am. I'm actually trying to learn more then I was before.
Feb 23 2018, 12:02 am
Feb 23 2018, 12:16 am
AHHH I feel so stupid lmaooo.

And sorry for the long responses my internet keeps going in and out.
Feb 23 2018, 12:20 am
In response to Ganite
Ganite wrote:
AHHH I feel so stupid lmaooo.

And sorry for the long responses my internet keeps going in and out.

It happens.

Wait until you are arrogant enough to think it will be faster to debug your own code than to explain it to anyone else.

Spent 12 hours the other day on an issue that I thought had to be a BYOND bug. It was a single-character typo.
Feb 23 2018, 12:20 am
one more question would I put it on my Game Window or the Window that has the Map on it?
Feb 23 2018, 12:21 am
In response to Ter13
Well shit atleast you dont take 3 days on the simplest things lol
Feb 23 2018, 12:56 am
Ideally? The map control itself. You really shouldn't need to know how big the window is, just the map control if you are only adjusting the view based on the size of the map control.
Mar 6 2018, 9:18 am (Edited on Mar 6 2018, 10:37 am)
In response to Ter13
Hey Ter. Thanks for the snippet. One thing tho: this zoom feature ignores the KEEP_APART appearence_flag and planes, thus zooming in on hud objects too. Do you know of any roundabout ways of doing this?

Edit: It seems to be faulty. If you resize the window to be bigger than the max-view, the view actually decreases. Here is some prints:

At max view (correct): http://prntscr.com/inpa49
Increasing the window (incorrect): http://prntscr.com/inpam8

this is ofcourse with the zoom function disabled. But the view should stick to it's max, not decrease
Mar 6 2018, 5:59 pm
It seems to be faulty. If you resize the window to be bigger than the max-view, the view actually decreases. Here is some prints:

That's exactly how it's supposed to work. I explained above that if the number of tiles in the viewport exceeds some maximum number, you need to scale up the tile size by an integer value. Obviously this will decrease the view size at certain thresholds because math. It's a non-problem because math.

As for your screenshots, you've got something else going on. Probably a failure to implement it properly. It looks like you have gone wrong somewhere, and I couldn't begin to guess where you've gone wrong.

You probably forgot to change the line that changes the zoom level of the map element. Obviously if you named your interface elements something other than what I did, using that element isn't going to work.

Also, you should have gotten an error message in the log saying that the interface element doesn't exist, which should have been your first clue to what was wrong and why.

One thing tho: this zoom feature ignores the KEEP_APART appearence_flag and planes, thus zooming in on hud objects too. Do you know of any roundabout ways of doing this?

This zoom feature has nothing to do with either of those. It doesn't need to account for either, because they are not even remotely related.
Mar 6 2018, 7:55 pm (Edited on Mar 6 2018, 8:45 pm)
In response to Ter13
Ter13 wrote:
It seems to be faulty. If you resize the window to be bigger than the max-view, the view actually decreases. Here is some prints:

That's exactly how it's supposed to work. I explained above that if the number of tiles in the viewport exceeds some maximum number, you need to scale up the tile size by an integer value. Obviously this will decrease the view size at certain thresholds because math. It's a non-problem because math.

Just because it's correct in math doesn't mean it is the wanted result. Even so, I now see that setting the view to be bigger wouldn't make sense, with the zoom feature, since it keeps the view the size of the screen.

Here is a picture using your map zoom: http://prntscr.com/inw5ec
Here it's manually setting it to 1.5: http://prntscr.com/inw5l0

So I miss a lot of view that I have with half zoom value. Do you think it's worth it for the quality?

As for your screenshots, you've got something else going on. Probably a failure to implement it properly. It looks like you have gone wrong somewhere, and I couldn't begin to guess where you've gone wrong.

You probably forgot to change the line that changes the zoom level of the map element. Obviously if you named your interface elements something other than what I did, using that element isn't going to work.

Also, you should have gotten an error message in the log saying that the interface element doesn't exist, which should have been your first clue to what was wrong and why.

No, I implemented it properly and renamed the map element properly too.
And I didn't have any error messages

What is happenning is you skiped something that I wrote:
this is ofcourse with the zoom function disabled. But the view should stick to it's max, not decrease

I'm not complaining that it isn't zooming in. I was talking about the fact that the view got much smaller. And to see the size of the view, I disabled the zoom. Now I know that it is what it is, but I wish there was another way to keep quality while zooming less.

One thing tho: this zoom feature ignores the KEEP_APART appearence_flag and planes, thus zooming in on hud objects too. Do you know of any roundabout ways of doing this?

This zoom feature has nothing to do with either of those. It doesn't need to account for either, because they are not even remotely related.

I'm not saying it has anything to do with it. I'm saying that's what happenning and asking if there is a way around it. Jeez, having a bad day?


Edit: Added and changed stuff
Mar 7 2018, 5:44 am (Edited on Mar 7 2018, 3:27 pm)
What you are asking doesn't make sense.

By modifying my code in the way you did, it shows you didn't understand some really important concepts. I can't really dig deeper into your question than that, because the reason my code was structured the way it was comes down to really basic logic that doesn't really need to be explained.

If you can't see that non-integer scaling of the screen looks like shit, I can't help you.
Mar 7 2018, 6:24 am
In response to Ter13
Ok dude, whatever floats your boat
Page: 1 2