Moving screen when u change resolution

[zed_zeek]

gidday im using sdl with opengl, now i can change
screensizes no problems (i have to reload the textures

• glsl shaders again but thats sorted) the thing is i
  cant seem to update either of the following

putenv( “SDL_VIDEO_CENTERED=1” );
putenv( “SDL_VIDEO_WINDOW_POS=100,100” );

useful to keep the new screensize in the center of the
screen, what exact steps do i need to do to recify
this.

cheers zed___________________________________________________________
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

[Bob_Pendleton]

gidday im using sdl with opengl, now i can change
screensizes no problems (i have to reload the textures

• glsl shaders again but thats sorted) the thing is i
  cant seem to update either of the following

putenv( “SDL_VIDEO_CENTERED=1” );
putenv( “SDL_VIDEO_WINDOW_POS=100,100” );

useful to keep the new screensize in the center of the
screen, what exact steps do i need to do to recify
this.

cheers zed

I don’t usually go to the source to try to answer a question, but this
one caught my attention so I looked at source for SDL_x11video.c and
SDL_dx5video.c and it looks like in both cases the environment variables
are only checked if you are creating a completely new window, but not if
you are changing an existing window. The code is in the device level
version of SDL_SetVideoMode() for a specific system.

Of course, I could be completely wrong, but this looks a bit like a bug
to me. Could be that a change is needed in every driver that uses those
flags. A thorough person would check all the environment variable code
to make sure the environment variables are checked every time
SDL_SetVideoMode() is called.

My belief is that if you call SDL_quit(), change the environment
variables, and then call SDL_Init() and SDL_SetVideoMode() you should
see a change.

	Bob PendletonOn Fri, 2005-01-28 at 21:16 +0000, zed zeek wrote:

---

ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[Pete_Elmore]

Bob Pendleton wrote:

My belief is that if you call SDL_quit(), change the environment
variables, and then call SDL_Init() and SDL_SetVideoMode() you should
see a change.
This seems very dirty to me. Environment variables are for the user to
communicate with the program about how to run it, not for the program to
communicate with the library. Adding support to the API (unless it
already exists) seems like a better solution than using environment
variables.

Pete Elmore

(Disclaimer: I must confess that I am not sinless in this area; I have
used environment variables as a hash for storing data when coding in C
and not wanting to write code to do it. )

[David_Olofson]

[…]

My belief is that if you call SDL_quit(), change the environment
variables, and then call SDL_Init() and SDL_SetVideoMode() you
should see a change.

Sounds like the only sensible behavior to me.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 28 January 2005 23.16, Bob Pendleton wrote:

[David_Olofson]

Bob Pendleton wrote:

My belief is that if you call SDL_quit(), change the environment
variables, and then call SDL_Init() and SDL_SetVideoMode() you
should

see a change.
This seems very dirty to me. Environment variables are for the user
to
communicate with the program about how to run it, not for the
program to
communicate with the library. Adding support to the API (unless it
already exists) seems like a better solution than using environment
variables.

Right, but there are some problems:

• Adding stuff to the API breaks binary compatibility
  in at least one direction.

• The system variables are currently the only interface
  to certain features. Adding a “pure” C API means we
  have two ways of accessing the same data, which in
  turn means more chances to screw up.

• We can’t replace the system variable interface with
  a C API, since that would remove features that both
  users and applications rely on. That’s actually worse
  than breaking binary compatibility in both directions.

Note that in general (that’s the idea, anyway, I think), these
features are much more frequently used the “normal” way than (ab)used
by applications. So, the “dirty” usage is the exception; not the
rule.

On the plus side:

• The system variable interface is a portable
  user interface!

• An application can both read the variables to
  see what the user wants, and affect what SDL does,
  using the same interface.

• An application can also just ignore this interface
  entirely, without cutting off the link from the
  user to these SDL features.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 28 January 2005 23.44, Pete Elmore wrote:

[Jon_Colverson]

David Olofson wrote:

Right, but there are some problems:

• Adding stuff to the API breaks binary compatibility
  in at least one direction.

• The system variables are currently the only interface
  to certain features. Adding a “pure” C API means we
  have two ways of accessing the same data, which in
  turn means more chances to screw up.

• We can’t replace the system variable interface with
  a C API, since that would remove features that both
  users and applications rely on. That’s actually worse
  than breaking binary compatibility in both directions.

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the environment
variables; they aren’t part of the API.

SDL_VIDEO_CENTERED looks like the only variable which provides
potentially portable functionality, and as such, I think it would be a
good candidate for being added to the C API (presumably as a flag for
SDL_SetVideoMode(), which I believe could be added without breaking
binary compatability in any direction).–
Jon

[David_Olofson]

[…]

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the environment
variables; they aren’t part of the API.

Good point. Changing this stuff might break some applications - but
"they had it coming…"

SDL_VIDEO_CENTERED looks like the only variable which provides
potentially portable functionality, and as such, I think it would be
a good candidate for being added to the C API (presumably as a flag
for SDL_SetVideoMode(), which I believe could be added without
breaking binary compatability in any direction).

…if we can squeeze in another flag in those 32 bits.

Anyway, ++votes for SDL_VIDEO_CENTERED as a flag to
SDL_SetVideoMode().

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 29 January 2005 00.32, Jon Colverson wrote:

[Rainer_Deyke]

Jon Colverson wrote:

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the
environment variables; they aren’t part of the API.

If there was no need to access this functionality, these environment
variables wouldn’t exist in the first place. That said, I wouldn’t mind at
all if these environment variables were replaced with functions in the C
API.

SDL_VIDEO_CENTERED looks like the only variable which
provides potentially portable functionality, and as such,
I think it would be a good candidate for being added to
the C API (presumably as a flag for SDL_SetVideoMode(),
which I believe could be added without breaking binary
compatability in any direction).

I’d like to see at least the following in the C API:

SDL_VIDEODRIVER (plus some way of enumerating available video drivers)
SDL_VIDEO_CENTERED
SDL_WINDOWID
SDL_AUDIODRIVER (plus some way of enumerating available audio drivers)–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

[Petri_Latvala]

Adding symbols doesn’t break the ABI, right?

How about SDL_SetAttribute() (just like SDL_GL_SetAttribute) that allows
one to set SDL_VIDEO_CENTERED etc, and other stuff that’s supposed to be
set from the application, not from the user.On Fri, 2005-01-28 at 23:32 +0000, Jon Colverson wrote:

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the environment
variables; they aren’t part of the API.

SDL_VIDEO_CENTERED looks like the only variable which provides
potentially portable functionality, and as such, I think it would be a
good candidate for being added to the C API (presumably as a flag for
SDL_SetVideoMode(), which I believe could be added without breaking
binary compatability in any direction).

–
Petri Latvala

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050129/6e54e362/attachment.pgp

[Michael_Wyrzykowski]

Relating to what the first poster had mentioned about:

the thing is i cant seem to update either of the following

putenv( “SDL_VIDEO_CENTERED=1” );
putenv( “SDL_VIDEO_WINDOW_POS=100,100” );

I used to be using VC++, but I couldn’t find a way around getting the window to center, so I switched to using MinGW for Windows. All I do is set ‘putenv(“SDL_VIDEO_CENTERED=1”);’ at the beginning of my program and when I change resolutions, the window auto-centers.

My game also uses OpenGL (so I need to reload all the textures), but I don’t need to call SDL_Quit to make the window recenter. What platform are you running and which compiler?___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!

[Bob_Pendleton]

[…]

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the environment
variables; they aren’t part of the API.

Good point. Changing this stuff might break some applications - but
"they had it coming…"

SDL_VIDEO_CENTERED looks like the only variable which provides
potentially portable functionality, and as such, I think it would be
a good candidate for being added to the C API (presumably as a flag
for SDL_SetVideoMode(), which I believe could be added without
breaking binary compatability in any direction).

…if we can squeeze in another flag in those 32 bits.

Anyway, ++votes for SDL_VIDEO_CENTERED as a flag to
SDL_SetVideoMode().

Yes, I’ll vote for that… But, you have to make sure that it doesn’t
change the current behavior in anyway.

If we keep adding flags we will need to move to a 64 bit int some day or
change to a vector based flag passing technique, which I don’t like at
all.

	Bob PendletonOn Sat, 2005-01-29 at 00:40 +0100, David Olofson wrote:

On Saturday 29 January 2005 00.32, Jon Colverson wrote:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[Bob_Pendleton]

Jon Colverson wrote:

As mentioned at:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
neither users nor applications should be relying on the
environment variables; they aren’t part of the API.

If there was no need to access this functionality, these environment
variables wouldn’t exist in the first place. That said, I wouldn’t mind at
all if these environment variables were replaced with functions in the C
API.

SDL_VIDEO_CENTERED looks like the only variable which
provides potentially portable functionality, and as such,
I think it would be a good candidate for being added to
the C API (presumably as a flag for SDL_SetVideoMode(),
which I believe could be added without breaking binary
compatability in any direction).

I’d like to see at least the following in the C API:

SDL_VIDEODRIVER (plus some way of enumerating available video drivers)
SDL_VIDEO_CENTERED
SDL_WINDOWID

I’d be surprised if that one every became available through a C API. It
is a hack that is only supported by a small number of video drivers.
Making it an environment variable means that only the drivers that
support it need to even be aware that it exists. OTOH, making it a
standard part of SDL means that every driver has to have code to
handle it, even if all the code does is return an error message.

The same thing is true of the SDL_VIDEO_CENTERED but a flag is a lot
easier to ignore than an API.

SDL_AUDIODRIVER (plus some way of enumerating available audio drivers)

In most cases video and audio driver selection is moot. You rarely have
more than one choice. When you do it is usually the case that one is
automatically used as a fall back for a better driver. Or, in some cases
the alternative driver requires special permission to use. Consider the
difference between the X driver and the other Linux drivers. Anyone can
run an SDL_X11 program, but using the DGA requires you to have root
privileges. On windows, when would you use the DIB driver if you could
use the DirectX driver?

	Bob PendletonOn Fri, 2005-01-28 at 20:27 -0700, Rainer Deyke wrote:

[Olivier_Fabre]

Anyway, ++votes for SDL_VIDEO_CENTERED as a flag to
SDL_SetVideoMode().

Yes, I’ll vote for that… But, you have to make sure that it doesn’t
change the current behavior in anyway.

Well, the behaviour was already changed between 1.2.6 were the window
was always centered, and 1.2.7 where it wasn’t (which is one of the
reasons why I stayed with 1.2.6 for my Win32 build.)

I would also prefer a way to set the window position in the API instead
of using an envvar (which makes no sense IMHO).

If we keep adding flags we will need to move to a 64 bit int some day
or change to a vector based flag passing technique, which I don’t like
at all.

If I was responsible for this, I’d use varargs… (possibly introducing
a new “SDL_SetVideoModeVarargs()” function in order not to break source
compatibility.)On 31/01/2005, Bob Pendleton, you wrote:

–
Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.

[Stephane_Marchesin]

Bob Pendleton wrote:

I’d be surprised if that one every became available through a C API. It
is a hack that is only supported by a small number of video drivers.
Making it an environment variable means that only the drivers that
support it need to even be aware that it exists. OTOH, making it a
standard part of SDL means that every driver has to have code to
handle it, even if all the code does is return an error message.

The nice thing about a backend selection API is that you don’t need
support from all the backends

The same thing is true of the SDL_VIDEO_CENTERED but a flag is a lot
easier to ignore than an API.

SDL_AUDIODRIVER (plus some way of enumerating available audio drivers)

In most cases video and audio driver selection is moot. You rarely have
more than one choice. When you do it is usually the case that one is
automatically used as a fall back for a better driver. Or, in some cases
the alternative driver requires special permission to use. Consider the
difference between the X driver and the other Linux drivers. Anyone can
run an SDL_X11 program, but using the DGA requires you to have root
privileges. On windows, when would you use the DIB driver if you could
use the DirectX driver?

If your application is alpha blitting intensive you don’t want the
DirectX driver, because alpha blits to screen will become prohibitively
expensive.

Similarly, you don’t want to use glSDL if your application wasn’t tuned
for it, because you will very likely get very bad performance.

Also, if the application has the backend selection interface available,
it can in turn give the user a friendly interface to choose betwen the
different audio/video backends. Not everyone knows how to setup an env
variable.

That said, such a mechanism would probably be the cause for a lot of
trouble too.

Stephane

[Bob_Pendleton]

Anyway, ++votes for SDL_VIDEO_CENTERED as a flag to
SDL_SetVideoMode().

Yes, I’ll vote for that… But, you have to make sure that it doesn’t
change the current behavior in anyway.

Well, the behaviour was already changed between 1.2.6 were the window
was always centered, and 1.2.7 where it wasn’t (which is one of the
reasons why I stayed with 1.2.6 for my Win32 build.)

I would also prefer a way to set the window position in the API instead
of using an envvar (which makes no sense IMHO).

If we keep adding flags we will need to move to a 64 bit int some day
or change to a vector based flag passing technique, which I don’t like
at all.

If I was responsible for this, I’d use varargs… (possibly introducing
a new “SDL_SetVideoModeVarargs()” function in order not to break source
compatibility.)

Good idea, makes thing easy for the user. But, what about the internals
of SDL? Inside SDL there is a LOT of code that believes that the flags
are stored as bits in a word. Internally the options are to either
switch to a 64 bit int or, at some point, switch to a vector based
system. That is true whether or not the user interface is based on
varargs or on bit masks.

I wouldn’t want to be the guy who had to change all the flags related
code to use a vector representation

	Bob PendletonOn Mon, 2005-01-31 at 17:33 +0100, Olivier Fabre wrote:

On 31/01/2005, Bob Pendleton, you wrote:

[Bob_Pendleton]

Bob Pendleton wrote:

I’d be surprised if that one every became available through a C API. It
is a hack that is only supported by a small number of video drivers.
Making it an environment variable means that only the drivers that
support it need to even be aware that it exists. OTOH, making it a
standard part of SDL means that every driver has to have code to
handle it, even if all the code does is return an error message.

The nice thing about a backend selection API is that you don’t need
support from all the backends

Yep, you are correct on that. The back end selection is done before the
backend is intialized. I was wrong on that one. There is even a comment
in that code saying that it will be replaced at some time.

The same thing is true of the SDL_VIDEO_CENTERED but a flag is a lot
easier to ignore than an API.

SDL_AUDIODRIVER (plus some way of enumerating available audio drivers)

In most cases video and audio driver selection is moot. You rarely have
more than one choice. When you do it is usually the case that one is
automatically used as a fall back for a better driver. Or, in some cases
the alternative driver requires special permission to use. Consider the
difference between the X driver and the other Linux drivers. Anyone can
run an SDL_X11 program, but using the DGA requires you to have root
privileges. On windows, when would you use the DIB driver if you could
use the DirectX driver?

If your application is alpha blitting intensive you don’t want the
DirectX driver, because alpha blits to screen will become prohibitively
expensive.

So, as a programmer, you set the environment variable to the value you
want. In this example you don’t need to know which back ends are
available, you just set the variable to request the one you want, and
then you have to live with the one you get. The end users version of SDL
may not have both windib and directx support compiled in.

Similarly, you don’t want to use glSDL if your application wasn’t tuned
for it, because you will very likely get very bad performance.

Also, if the application has the backend selection interface available,
it can in turn give the user a friendly interface to choose betwen the
different audio/video backends. Not everyone knows how to setup an env
variable.

I think we are talking across each other here. It is rare that an end
user will ever set an environment variable to select a back end of any
kind… Unless of course the documentation that comes with the program
tells them to do it and tells them how to do it.

The way things are is mostly for the programmer and rarely of interest
to the end user.

That said, such a mechanism would probably be the cause for a lot of
trouble too.

Stephane

	Bob PendletonOn Mon, 2005-01-31 at 20:52 +0100, Stephane Marchesin wrote:

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl