Lummox JR wrote:

I have said several times now that this will get attention, and I'm sure we can work something out considering how many people want full-screen support. I'm not sure how much clearer I can get than that, since at the moment I'm not in any position to make any promises on exactly what path we'll take with this. The only important proviso as far as I'm concerned is that users who want to opt out of forced full-screen should have that choice.

Lummox JR

This bug should not be "fixed" until BYOND has true fullscreen support. No game in existence requires players to disable "taskbar on top" in order to play in fullscreen mode. Requiring BYOND users to do so is just absurd.

Lummox JR wrote:

Keeping the buggy behavior is not an option because it messes up taskbar redrawing.

Doesn't seem like a big enough issue to completely remove a "feature" over. Not to mention; I've fiddled with "full-screen" games before, and never had a problem with it.

If we are to have full-screen support it should be done properly or not at all. I don't think this would be difficult to add...

So then implement it before you go removing the current method?

I would be in favor of some kind of simple opt-out choice that let full-screen work unless the user decides otherwise.

If you're going to give them some client sided option to disable full-screen, it should be detectable through DM. So we can kick people out of full-screen only games when they have it disabled.

The point is there should be some form of choice available to the end user.

No, not really. If they don't want to play the game in full-screen mode, and the developer hasn't added an option otherwise, then they can just not play the game.

I totally support the idea to add fullscreen into games and people who dont agree can just not play the game there´s no need to not put it in games, almost every game is fullscreen so why should byond games have that option not?

I SAY DO ADD FULLSCREEN!!!!\

Chaokai

I'm replying to several posts in one shot here in the interest not letting this discussion get any more fractured.

I think some clarification might be in order too, because I have the feeling some people are thinking games won't be able to expand to the edge of the screen (excluding the taskbar) and will be stuck in windowed mode as a result of the bug fix. That isn't the case. The bug fix only prevents games without titlebars from covering the taskbar; it does not prevent games from filling the rest of the screen.

Fugsnarf wrote:

You're wrong actually, Lummox. It doesn't have to mess with the taskbar redrawing. What I was able to do is first minimize the screen, then unmaximize, sleep(1), then unminimize the screen. If that's done, everything on your screen comes out fine. If that's not done, yes it does mess it up. There are simple ways around it though which I found.

That doesn't make the bug any less of a bug--it just means you found a workaround to a secondary bug that it touched off. That's quite commendable, but considering the bug report that started all this it seems not everyone has that kind of ingenuity. We have a lot of amateur developers for whom if a feature exists, it should be simple and straightforward. The bug was actually a violation of those principles, and while some users did manage to milk something useful out of it, it was still something that needed to be fixed.

Vic Rattlehead wrote:

Why does the player need an option for fullscreen or not? Is it something FORCED on every game? No. Just one game. That'd be like if I yelled at Nexon for taking over three years to put in windowed mode. It's how the game is.

Simply put, full-screen is easy to screw up. A lot of commercial games use it but, they also use fairly common standard interfaces for leaving the game or switching in and out of windowed mode. Authors who don't apply any level of polish can easily confuse users with games that cover up the taskbar since it might not be obvious how to get out.

As for commercial games, remember that most of those games are designed with engines that expect full-screen, and windowed mode is actually harder for them to do. To work in windowed mode they need to be able to handle resize events, perhaps even changes of screen resolution and color depth, and adjust their resolution on the fly instead of just once, which can be hard to do if they've designed the game without any of that in mind. BYOND takes the exact opposite route, offering ways of flexibly responding to resolution changes at runtime through the use of anchors.

Falacy wrote:

Doesn't seem like a big enough issue to completely remove a "feature" over. Not to mention; I've fiddled with "full-screen" games before, and never had a problem with it.

Exploiting a bug does not equate to a feature. Relying on buggy behavior is a sure way to get burned.

If you're going to give them some client sided option to disable full-screen, it should be detectable through DM. So we can kick people out of full-screen only games when they have it disabled. ... If they don't want to play the game in full-screen mode, and the developer hasn't added an option otherwise, then they can just not play the game.

Since the rest of the screen can be covered to give the game a windowless look, there's no reason the game should have to know or care whether the taskbar is still showing or not. Considering monitors come in all sizes you still have to make your game adapt to different resolutions if you're going to leave it maximized and take off the borders. We're talking about a difference of maybe 28 pixels and a little bit of immersion that users can give up voluntarily for the sake of keeping control of their screen. Users deserve to have that choice, and they should not be penalized for it. But for users who are okay with having their taskbar covered I have no objection to games doing so, and I think it's quite safe to make that a default setting.

Lummox JR

Falacy wrote:

Lummox JR wrote:

Since the rest of the screen can be covered to give the game a windowless look, there's no reason the game should have to know or care whether the taskbar is still showing or not. Considering monitors come in all sizes you still have to make your game adapt to different resolutions if you're going to leave it maximized and take off the borders.

A lot of full screen games, WoW for example, have HUD's that line the bottom of the screen. Based on how your systems for such a thing were set up in previous versions, it could lead to the bottom half of that HUD being entirely cut off behind the task bar.

I can see how doing this with a HUD would run into such problems, since you're doing full-screen by using a very large world.view and letting the map fill the whole window using a fixed icon-size parameter.

After rereading your post and reviewing the others, I've come to the realization that there's been some misunderstanding in this thread. All along I've been wondering what the hubbub is about because I thought it should be easy to grab the window size, but you're using a method of grabbing the window size that was built around the bug and your concern is that there would be no way to get the info you need in this situation. Now I think I understand your position, so I can hopefully put your fears to rest.

I see now that you're making adjustments and positioning your HUD by trying to figure out the dimensions of the oversized window, but since using winget() to grab a window's size parameter only tells you the "normal" size of the window instead of its current size when maximized, you don't have that info to go on directly. Instead you're trying to do calculations on the size of a titlebar-maximized window to try to get full screen resolution so that the "bug form" can have icons placed accurately. Your concern is that the taskbar fix will negate those calculations.

I can see good reasons for grabbing the window's actual current interior size instead of its un-maximized size. I question whether that behavior is safe to change at this point, or whether that should be done with a new parameter, but this probably should be worked into any full-screen implementation for authors' convenience. I have made a note of that.

But I have a better solution that will work cleanly for you in any current or past versions, and any of the versions coming up. One other way to get the size info you need is to look at map control's size instead of the window's size. Since it's filling the whole window it will give you accurate results every time. By using that method, your game should be impervious to the presence or absence of the taskbar. The reason I misunderstood your objections was that I had already assumed you were using a method somewhat like this.

So in the end, the calculations you're doing to try to shoehorn the bug into working order will break; that's unavoidable. (In practice I think they were brittle anyway because the taskbar is flexible and can be hidden, enlarged, or put on a side instead of the top or bottom. Combine that with a myriad of standard monitor resolutions and I'm not sure it was ever possible to get a truly accurate screen res by rounding up.) But I think that it's worth implementing a way of grabbing the current window size regardless of maximization, and in the meantime there is another method you can use that works in any version that will solve your dilemma. Hopefully that resolves any concerns going forward.

Lummox JR

Lummox JR wrote:

We could, I suppose, set up some kind of config setting that asks if the user is okay with games going full-screen regardless of that, and maybe even default that on for most BYOND users.

Sounds like a good simple way to do it. At the same time, though, I wonder if there's any wisdom in treating a window (chromeless or not) as a full screen application. As you've said, the only real reason to cover the taskbar is to aid in immersion. If a window with full chrome is maximized, there's no reason it should cover the taskbar. Despite all the complaining about "n00bs" who don't know about the taskbar setting, I don't think there are many power users out there, myself and other posters included, who like to have regular windows cover the taskbar.

I guess what I'm saying is this: A full-screen setting would be good, and keep regular windows obeying the taskbar settings. All that would be needed then would be a pager setting allowing all or only listed games to go full-screen.

Kind of a pain, but if full-screen is going to be allowed (right now it only exists as the result of a bug) then we need to give users the ability to opt out of it.

Agreed. I certainly don't want random games going full-screen without asking, and then having no clear way to close them without Alt+F4 spamming.

Just for the record, I don't have a problem with allowing full-screen games. I do find it non-standard for windowing application, as (AFAIK) games and applications that are full-screen are entirely owner drawn and often control resolution. I wouldn't expect a full-screen game to have a menu or titlebar, and in fact I think the best approach would be to have it be an independent setting on the game (and perhaps even one that can set the resolution). It should also have a consistent, hard-coded method to exit this mode (probably ESC).

Tom wrote:

It should also have a consistent, hard-coded method to exit this mode (probably ESC).

That's the same "feature" that Adobe Flash Player uses. Regardless of what the flash program is, whenever it goes full screen a message appears saying "Press ESC to exit Full Screen"

Android Data wrote:

The map element should be changed. Right now it only stretches to fit to keep within aspect ratio. I really like to see a way for developers to cancel out the client.view limit. Perhaps setting client.view=-1 through the code makes it "stretch to fit": the map automatically shows as much tiles as the users' screen can handle, centered on client.eye.

WUTCHU TALKIN BOUT WILLIS!?
Sounds more like you want a change for the "stretch to fit" icon-size.
You can manually set up any map size you want with currently available features, as long as it doesn't exceed 30-something.

Dragonn wrote:

Well that bug (removing the title bar) worked 100% fine for my game. It was full screen with no negative consequences.

If there is no way to mimic this action in 455 or later byonds my game is ruined and I will be leaving byond. That's in no way a threat, but it's a fact.

I honestly don't see how having a taskbar or not, but being able to cover the rest of the screen, could "ruin" a game. But as I've said I have no problem with adding a feature to support full-screen properly, as long as end users have the option of suppressing that so they can still keep their taskbar if they want to.

Lummox JR