Just say no to FULLSCREEN

hodgestar on 2011/04/16 07:11

FULLSCREEN was useful when your typical machine had one 640x480 monitor connected. It is no longer useful.

(log in to comment)

Comments

richard on 2011/04/16 07:53:

Fullscreen is nice - as an option.

Falun on 2011/04/16 08:01:

Any game that involves a lot of action at the same time I prefer to be fullscreen to isolate it from the other stuff I have going on Also if the game involves using the mouse to move by hitting one of the screen edges I prefer fullscreen.

john on 2011/04/16 08:36:

I concur with Richard. Games like xmoto and wesnoth suck as windowed*; however, it is unlikely games like that'll be made in pyweek. :)

*And fullscreen doesn't work in my dual-screens set-up, neither does my tablet work very well. I hate you dual screen. >.>

gizmo_thunder on 2011/04/16 11:58:

most games use fullscreen i don't see why it should be a problem for pyweek. I still make my games windowed but i dont' mind games using fullscreen.   

Cosmologicon on 2011/04/16 15:36:

As someone with a slow computer, it's nice to have a fullscreen, low-resolution option for games whose speed is at all limited by graphics. For pygame/pyopengl games, this gives a speed boost. Testing with our pygame-based game:

1280x720 windowed: 22fps
1280x720 fullscreen: 25fps
680x384 windowed: 42fps
680x384 fullscreen: 48fps

I always wished that pyglet would let you set the resolution for fullscreen mode... a lot of pyglet games could go from unplayable to playable for me! 

hodgestar on 2011/04/16 18:57:

My objection is mostly to games messing with my screen settings without asking (and then failing to restore them afterwards).

stycchio on 2011/04/16 20:13:

I go for opengl + resizable windows, they are tiling (xmonad/awesomewm) friendly and if ya want fullscreen just maximize it. No performance loss in HW accelerated blitting even in high resolutions. Just don't use texture filtering and maintain aspect-ratio (and integer zoom multiples).

PhillipNguyen on 2011/04/16 23:11:

There is some support for changing the screen resolution in pyglet 1.2dev.

Cosmologicon on 2011/04/17 05:08:

@stycchio: I go for opengl + resizable windows, if ya want fullscreen just maximize it. No performance loss in HW accelerated blitting even in high resolutions.

What do you mean by no performance loss? Even when I'm just using GL calls on a hardware-accelerated pygame surface, the fullscreen resolution makes a huge difference to the framerate on my system. How is that not the same as a performance loss on higher resolutions?

Chard on 2011/04/17 10:18:

We always tend to have windowed as an option both in game and on the command line but fullscreen is the default behaviour. However, let's not confuse fullscreen with actual resolution switching. Fullscreen should involve making the viewport fill the entire screen, changing the resolution before doing that can often mess up display settings later.

Performance wise using a larger window is definitely slower than using a smaller one for the simple reason that although the number of primitives you render does not change the per-fragment computations are multiplied. The body of a game's runtime, however, is usually divided between two things: per-tick updates and rendering. Only the latter will be affected by screen size. Out game this PyWeek was graphically very simple and consequently has no problem running at very high resolutions!

tartley on 2011/04/17 14:03:

I (lightly hold) the strong opinion that that fullscreen should be the default behaviour. That's how most games run. That provides the best immersive experience. That gives the most coherent behaviour if the game also switches resolution, which is something else I think is important. My old graphics card is frequently fillrate limited. Running at (linearly) half the resolution isn't bad looking on my LCD, and generally approaches FOUR TIMES the framerate.

Most important of all - fullscreen is simply what I prefer.

I'm happy to give people an option to run in a window. Generally my pyweek entries accept '--window' command line args, (documented by --help), and they also support alt-enter keypress to toggle between fullscreen and windowed. Do fullscreen detractors think there are other ways I should expose this option? Are there key binds that are commonly used for this across all platforms?

nitrofurano on 2011/04/17 14:07:

i think i added one day the alt+enter key combo for switching the fullscreen, on some stuff from me, but windowed is (and sould be) always default

hodgestar on 2011/04/17 16:55:

The problem with command-line options is that they're hardly a standard in PyWeek entries and even when they are used they're not implemented in any sort of consistent way (for example, one of the games I judged did something like argsv[1] == '-nofullscreen' without documenting it or providing command-line help). I think that the only sane default is to leave the screen resolution alone by default and provide an option for changing the resolution or fullscreening if you feel you need it.

Cosmologicon on 2011/04/17 21:12:

What if the splash screen says "Press Alt-Enter to switch to windowed mode", and your video settings are restored (as happens naturally with pygame games, I believe). Then you've spent all of 3 seconds of your life. Is that so bad?

hodgestar on 2011/04/17 21:24:

The restoring part has yet to work for me on a system with two screens.

Cosmologicon on 2011/04/18 02:59:

Fair enough. Is the restoring part for dual screens a solved/solvable problem?

john on 2011/04/18 07:48:

hodgestar, switching fullscreen and windowed has always worked fine on my dual screen (pygame/xfce)