ID:132671
 
It would definitely be nifty to set the pos parameter of a control at run-time based on a percentage of the width/height of the user's resolution.( This would also be a good addition to the size parameter too )

Alternatively, you could add a way to get the height/width of a user's resolution so developers wishing to create full-screen apps can stop using hacky workarounds.

For example:
winset( src, "chat_label_window", "pos=0,100%" ) ( Would place a control( in this case a completely transparent window bearing a transparent label for chat output ) at the bottom left of the screen )
It may have been screwed up in 455+, but this works in 454:
mob/var/ResWidth
mob/var/ResHeight

mob/proc/GetResolution()
winset(src,"SizeWindow","is-maximized=true")
var/Size=winget(src,"SizeWindow.SizeLabel","size")
src.ResWidth=text2num(copytext(Size,1,findtext(Size,"x")))
src.ResHeight=text2num(copytext(Size,findtext(Size,"x")+1))

mob/verb/View_Resolution()
src.GetResolution()
src<<"[src.ResWidth]x[src.ResHeight]"

SizeWindow isn't visible, and has the Title & Status bars disabled. SizeLabel covers that entire window with top left/bottom right anchors.
You can then easily set your %s based on those values - taking into account size of the positioned windows.
mob/proc/PositionWindow(var/WindowName,var/PercentWidth,var/PercentHeight)
if(!src.ResWidth || !src.ResHeight) src.GetResolution()
var/Size=winget(src,WindowName,"size")
var/WinWidth=text2num(copytext(Size,1,findtext(Size,"x")))
var/WinHeight=text2num(copytext(Size,findtext(Size,"x")+1))
WinWidth=(src.ResWidth*PercentWidth/100)-(WinWidth*PercentWidth/100)
WinHeight=(src.ResHeight*PercentHeight/100)-(WinHeight*PercentHeight/100)
winset(src,WindowName,"pos=[WinWidth],[WinHeight]")

mob/verb/Position_Window(var/PerWidth as num,var/PerHeight as num)
src.PositionWindow("PosWindow",PerWidth,PerHeight)
In response to Falacy
But what on earth could the point of going back 8 builds just to use this feature be when the cons greatly outweigh the pros?
I knew well enough myself that I could make a hacky work around for this in previous versions, but it is a thing of the past now, hence why I made this post in the first place: I don't want to work against progression, I want to aid it.
In response to Metamorphman
Metamorphman wrote:
But what on earth could the point of going back 8 builds just to use this feature be when the cons greatly outweigh the pros?

As I said, I wasn't sure if this would work in the newer versions. I refuse to update to their newest fail until they fix massive bugs, and/or at least add something competent worth updating for. Taking a look at this step backwards you can see why.
*bump*
In response to Falacy
Falacy wrote:
As I said, I wasn't sure if this would work in the newer versions. I refuse to update to their newest fail until they fix massive bugs, and/or at least add something competent worth updating for. Taking a look at this step backwards you can see why.

The fullscreen restriction was taken back out because frankly it was too hacky to make it work. Windows is apparently dead set on the idea that removing the titlebar or making a window non-resizable means it should be fullscreen when maximized. Although inasmuch as the label trick would always work to give you the correct resolution for adjusting your HUD and whatnot, I'm not sure what the fuss is about. As I recall the problem you had originally was that you weren't using such a technique, and instead you were trying to grab the size of the window through some other means that was not yielding the results you wanted. Even if fullscreen support (or more accurately, the attempt to work around Windows' heinous limitations) had not been put back in, the fact that you're now using a technique that always works would moot this.

Regarding "massive bugs", I know there were two issues in particular that had an impact on your games because of their highly dynamic nature, and both of those issues were fixed in 461. You only got a sour taste in your mouth from the 455+ series anyway because you got hold of an early closed beta where the release notes were not available to you and you didn't read the reference on how to use the new features, nor did you even apply common sense to issues like the fact that you'd need to create new icons to use isometric mode. How about ditching the bad attitude and if you find a real, genuine problem, post a bug report on it? Ranting about bugs that ceased to exist weeks ago whose demise you won't bother to verify firsthand is not productive.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Regarding "massive bugs", How about ditching the bad attitude and if you find a real, genuine problem, post a bug report on it? Ranting about bugs that ceased to exist weeks ago whose demise you won't bother to verify firsthand is not productive.

Still happening on a regular basis: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=602
Would hands down improve every hosted game in existence: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=122
overlays+flick() still don't work worth a crap: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=68
This and probably other performance hits were "implemented": http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=788
I keep hearing talk about this, but nothing has been done about it as far as I know: http://www.byond.com/developer/forum?id=713657
I haven't been paying close attention to all the new bugs created/found. Though I'm sure they are numerous, and that I would find even more myself.

The only things that interest me in the least are the new way that the icon editor spans to show more frames, and the pixel workings on the map editor (which I actually hear are rather buggy/un-functional). Neither of which are worth updating for in my opinion, considering the 10,000 (THAT'S OVER 9,000!) problems I'm sure it would cause me. Heck, even just the users updating changed all their computer_ids and screwed me over. Countless systems have been over complicated, like the new map view TOP_DOWN whatever, and nothing that would in any way help me improve my games has been added.
Iso mode was a complete waste of time, it has a negative effect on too many currently existing games, no positive effects, and I seriously doubt any games will ever even be made using it (unless somebody releases Zeta ISO).

EDITS: As we went over when the full screen removal crap was being discussed. Its not a big deal if you remove it, as long as you added something to replace it's basic functions, which you apparently didn't. Getting screen resolution is a pretty basic function that all games should have.

As I recall the problem you had originally was that you weren't using such a technique, and instead you were trying to grab the size of the window through some other means that was not yielding the results you wanted. Even if fullscreen support (or more accurately, the attempt to work around Windows' heinous limitations) had not been put back in, the fact that you're now using a technique that always works would moot this.

I'm not sure where you're getting any of that really... I posted the previously working method, which the OP said no longer does.
In response to Falacy
Falacy wrote:
Still happening on a regular basis: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=602

Still lack any solid followup info with which to investigate said problem.

Would hands down improve every hosted game in existence: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=122

Every investigation into this has proven futile. Having exhaustively ruled out any cause in BYOND's code, even at a very low networking level, the problem seems to be either an issue of network lag or the TCP/IP stack causing the client and server to get slightly out of sync. On my local network it seems to be intermittent.

overlays+flick() still don't work worth a crap: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=68

Yes, this is a known issue, and eventually can be fixed with a minor overhaul to the way we handle frames in flicks. It's not a trivial fix which is why it hasn't been addressed yet. That, and it doesn't impact very many games and can be worked around. But it is on the list.

This and probably other performance hits were "implemented": http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=788

The map editor thing is something we hope to improve down the road, possibly with DirectX support in the map editor, but some slowdown there was unavoidable due to the implementation of pixel offsets and isometric mode. This is something we plan to revisit.

I keep hearing talk about this, but nothing has been done about it as far as I know: http://www.byond.com/developer/forum?id=713657

This is the first I've heard of any issues; to my knowledge the new command queue is a huge improvement over the old method of having things broken in one way or broken in another, since it can compromise between implementing a "command spam" cutoff and catching up-key macros. I'm not aware of any specific problems people have had with the new system.

I haven't been paying close attention to all the new bugs created/found. Though I'm sure they are numerous, and that I would find even more myself.

Wild speculation doesn't add anything useful to the discussion. I can't fix bugs that exist only in someone's imagination. The issues you've actually listed are largely not new and tend to affect few games, with the major exception being a map editor slowdown.

The only things that interest me in the least are the new way that the icon editor spans to show more frames, and the pixel workings on the map editor (which I actually hear are rather buggy/un-functional).

I'm not aware of any buggy behavior in the map editor regarding pixel offsets. There haven't been any bug reports to that effect.

EDITS: As we went over when the full screen removal crap was being discussed. Its not a big deal if you remove it, as long as you added something to replace it's basic functions, which you apparently didn't. Getting screen resolution is a pretty basic function that all games should have.

It's something they can have, since you have yourself already implemented it. Pulling the size from an anchored full-window control should always give you the exact size the window has to work with. I do think there's room for improvement for these features though.

Lummox JR
In response to Lummox JR
Oddly enough, the method works on my brother's computer but it fails every time on my own. No idea why at all.

Also, kinda off-topic but how much further down the line do you think using higher client.view values with less lag is? I'm currently developing a fullscreen RTS(screenie) but I will have to ditch it cause of the amount of lag. It's quite the shame :(
In response to Metamorphman
Higher client.view means more map tiles are sent to the clients, ergo more network traffic.

Lummox JR
In response to Lummox JR
What I meant is general increase in speed of the whole rendering part of it, because it lags for the host let alone connected clients.