This is the same xit test that I had before, except this one unpacks
into a subdirectory, iconifies it, even when fullscreen, and
toggles fullscreen mode.
Yippeee!
Iâd be interested in how it works on your system. Please let me know
what window manager you are using, what X server, and what kinds of
problems it has, if any, with your system.
This code will go into the stable release of SDL, albeit there wonât
be the built-in keyboard shortcuts that there are in the demo.
If I remove DGA support (until DGA 2.0), how many people will mind?
This is the same xit test that I had before, except this one unpacks
into a subdirectory, iconifies it, even when fullscreen, and
toggles fullscreen mode.
Realy, where is it ?
Happens to all of us
Yippeee!
Iâd be interested in how it works on your system. Please let me know
what window manager you are using, what X server, and what kinds of
problems it has, if any, with your system.
Works ok in XFree3.3.3.1 on a riva128 from afterstep, x86, SDL1.0.1.
But the videomode-timings seem to be a bit odd, because I had to seriously
readjust my monitor for standard-modes like 640x480 or 800x600. No a real
problem though.
All the best,
robOn Sat, Jan 08, 2000 at 12:44:30AM -0800, Sam Lantinga wrote:
Sam> If I remove DGA support (until DGA 2.0), how many people will
Sam> mind?
HmmmâŚ
I donât use it, but I donât know whether or not any Executor users use
it. Do you have any idea how many people have to say they will mind
before youâll keep it? I would hate to ask on c.e.m.e. and the
Executor mailing list and then have three/five/ten/N people respond
that they will mind, then forward the info to you and have it pulled
anyway.
If I can make a post that says if we get N people to request that it
stays in, it will stay in, then thereâs less of a chance for people to
get upset. My guess is less than 10% of our users read c.e.m.e. or
the Executor mailing list.
BTW, Iâm not against doing some work to make it so that SDL-using apps
can be made setuid and then give up their super powers as soon as
theyâve set up proper access. I havenât looked in depth into the
problem, but sometimes I come up with useful solutions.
This is the same xit test that I had before, except this one unpacks
into a subdirectory, iconifies it, even when fullscreen, and
toggles fullscreen mode.
This is the same xit test that I had before, except this one unpacks
into a subdirectory, iconifies it, even when fullscreen, and
toggles fullscreen mode.
BTW, if youâre having troubles with the program crashing your X server
or doing other funny things, check to make sure that you can switch the
server manually to those modes using Ctrl-Alt-+/-. Sometimes modes are
defined in you XF86Config file that donât match your monitor and/or card.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Softwareâ
âAny sufficiently advanced bug is indistinguishable from a featureâ
â Rich Kulawiec
Sam> If I remove DGA support (until DGA 2.0), how many people will
Sam> mind?
HmmmâŚ
I donât use it, but I donât know whether or not any Executor users use
it. Do you have any idea how many people have to say they will mind
before youâll keep it? I would hate to ask on c.e.m.e. and the
Executor mailing list and then have three/five/ten/N people respond
that they will mind, then forward the info to you and have it pulled
anyway.
The impact would be that you would no longer have HWSURFACE and flipping
support, and the fullscreen code would use the VidMode extension and the
window-manager friendly code I posted yesterday. Fullscreen mode would
no longer require root permissions.
The benefit would mostly be in code maintainability. There are problems
with many X serverâs implementations of DGA, and the new DGA 2.0 that
will arrive with XFree86 4.0 has a completely different (and improved)
interface.
Iâm just curious if it would bother anyone if they lose HWSURFACE capability
under X11. If enough developers wanted both, I could integrate both the
new fullscreen code and the old fullscreen code, but I wanted to make sure
people cared before I went to that much work.
BTW, Iâm not against doing some work to make it so that SDL-using apps
can be made setuid and then give up their super powers as soon as
theyâve set up proper access. I havenât looked in depth into the
problem, but sometimes I come up with useful solutions.
This is already done. SDL internally drops root permissions as soon as
it does itâs dirty work.
BTW, if youâre having troubles with the program crashing your X server
or doing other funny things, check to make sure that you can switch
the server manually to those modes using Ctrl-Alt-+/-. Sometimes
modes are defined in you XF86Config file that donât match your monitor
and/or card.
Added 1024x768 resolution and retried âxit 1024 768 1â and it worked fine.
My default resolution, âxit 1280 1024 1â still messes up the X server.
(Maybe thereâs some other limitation?) I suppose I should add back in all
those resolutions I removed from XF86Config.
(Mine was the ATI All-in-Wonder, Mach64, XFree86 3.3.3.1 machine.)
Paul Braman @Paul_BramanOn Sat, 8 Jan 2000, Sam Lantinga wrote:
If the mode is available, it will use it. Otherwise it will (in all
cases) switch to the mode just larger than the desired mode and use
that.
Great!
Now the fun begins. Play around with and in the various
modes to see how well it works. Switch resolutions on the fly when youâre
in windowed mode, etc. Space will iconify the window, and Return will
toggle fullscreen mode.
Thanks!
Glad to finally be able to contribute. (The conditional variables in
the SDL threads I was going to propose seems a bust. Just not enough
knowledge with Win32 to get a reliable conditional variable there.)
nod
Big thanks to you and all the work youâve done with SDL in making it an
incredible API.
My pleasure. Itâs really great working with people like you. SDL is
useless and boring without people to enjoy it and send feedback.
Now the fun begins. Play around with and in the various
modes to see how well it works. Switch resolutions on the fly when youâre
in windowed mode, etc. Space will iconify the window, and Return will
toggle fullscreen mode.
and seem to work fine. It will restore the window to
fullscreen after being iconified (after a brief pause in windowed mode).
Just one bug left that I can see. If you start in fullscreen mode, hit
to go to windowed mode, then hit it will restore itself to
fullscreen mode instead of staying in windowed mode. Likewise if you
start in windowed mode, hit to go to fullscreen mode, then hit
it will restore itself to windowed mode.
Just a little variable setting/checking to remember which mode weâre supposed to be in, not which mode we started in.
Paul Braman @Paul_BramanOn Sat, 8 Jan 2000, Sam Lantinga wrote:
Just one bug left that I can see. If you start in fullscreen mode, hit
to go to windowed mode, then hit it will restore itself to
fullscreen mode instead of staying in windowed mode. Likewise if you
start in windowed mode, hit to go to fullscreen mode, then hit
it will restore itself to windowed mode.
Thatâs actually not a bug. Itâs code in main() setting a new mode with
the width-128 and height-128 and fullscreen mode you started in.
