From: Joerg H. <jo...@lu...> - 2007-12-13 23:19:30
|
Hi, gee, this issue looks more complicated than I thought :( [...] > black screens in fullscreen, with some resolutions (not 800x512 though). > This appeared to be vary variable though! Many of the resolutions were > fine in fullscreen sometimes, but then I would try them again and they > wouldn't work. Did it make a difference if you just switched to a certain resolution (without restarting the game), and actually starting the game with the same resolution? If the problem does not occur when starting from scratch, there are a few options: 1) we could try the windows/mac code (on windows/mac all textures have to be reloaded after a change in resolution, which afaik is not necessary on on linux) - perhaps that solves the problem? Just try using the #ifdef'ed code in sdldrv::setVideoMode for linux as well. 2) we might try to restart STK from scratch (or ... not a good solution, but better than black screens of near death ... we could keep the old resolution, update the config file, and tell the user to restart STK) > In addition, I had more problems if I selected the > resolutions while windowed and then changed to fullscreen, than if I Perhaps these two issues should be decoupled? E.g. as soon as fullscreen is (de)selected, do the switch? [...] > I did find that I had more trouble with resolutions below 800x600 than > above, but then this may be more expected as I have a 1440x900 screen. > All res lower than 800x600 gave a variable function in fullscreen. > Unfortunately, I also had variable trouble with one common resolution, > 1024x768, which was variably black/worked in fullscreen. This suggests I hate the word 'variably' in there ;( Perhaps it depends on the previous resolution? > to me that defining a list of resolutions that can be checked against > the SDL_ListModes() output may not resolve this issue completely. What resolution are actually defined in the X-config file? Do they correspond to the list returned by SDL? > If others could check at which resolutions these problems occur on their > setups, that may provide valuable info in fixing this bug. It may be When does the problem occur? Immediately after switching the resolution, or after starting the game? Cheers, Joerg |
From: Joerg H. <jo...@lu...> - 2007-12-13 23:21:59
|
Hi, > I have the same native resolution as you, but I doesn=C2=B4t see any prob= lems=20 > with any resolution. Strangely; all seems to work fine here. The only=20 > thing is that with lower resolutions, the text appears to not be=20 > centered. But that=C2=B4s the only thing I can see which is wrong. Oh yes, I noticed that as well: when switching resolutions the text wouldn't be centered anymore. But going 'back' and then return to the same menu would fix that issue - so this looks more like an widget issue Otherwise it might be time to compare the x server versions we are all runn= ing. Cheers, Joerg |
From: Joerg H. <jo...@lu...> - 2007-12-13 23:43:21
|
I googled a bit, and here some ideas: I don't know much about X programming, but it looks like XF86VidModeSwitchToMode takes a modeline index to switch to - and I would think that 0x320000e is way too large. But then the real question is: how does this value turn up? Would 0x0e be the correct value (perhaps it's expecting 2 bytes, but gets 4 bytes???). On: http://happypenguin.org/show?bzflag someone solved a similar problem by updating the nvidia drivers. And some comments suggest inconsistencies with the xorg configuration (e.g. the x driver does not support the requested resolution): http://www.gamedev.net/community/forums/topic.asp?topic_id=441765 What about error handling? Could we just test in sdldrv::setVideoMode for an error code? There isn't much (if any) error handling happening. So that might just solve the problem: if an error occurs, switch back to the previous resolution. Cheers, Joerg |
From: Joerg H. <jo...@lu...> - 2007-12-14 03:46:38
|
ReHi I think we might be lucky if the problem is reproducible for you! > I just tested a bunch of resolutions, and only 800x512 gave problems. Is this resolution specified in your xorg.conf file? And do you get an error returned by SDL_SetVideoMode, e.g. from the manual: screen = SDL_SetVideoMode(640, 480, 16, SDL_SWSURFACE); if ( screen == NULL ) { fprintf(stderr, "Unable to set 640x480 video: %s\n", SDL_GetError()); exit(1); } Cheers, Joerg |
From:
<coz...@gm...> - 2007-12-14 04:15:57
|
Hi, > I think we might be lucky if the problem is reproducible for you! 100% of the time. Apparently I should fix the bug since it might be a mess if someone else tries. XD > Is this resolution specified in your xorg.conf file? Nope. But that is not the problem, as I only have 640x480, 800x600, and 1024x768 if I remember correctly. > And do you get an error returned by SDL_SetVideoMode, e.g. from the manual: > > screen = SDL_SetVideoMode(640, 480, 16, SDL_SWSURFACE); > if ( screen == NULL ) { > fprintf(stderr, "Unable to set 640x480 video: %s\n", SDL_GetError()); > exit(1); > } Sadly, no. I also tried SDL_VideoModeOK() and it doesn't returns and error either. Either way, I'm going to try updating drivers and Xorg, so keep this bug on hold meanwhile. -Coz |
From: Joerg H. <jo...@lu...> - 2007-12-16 12:03:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got 800x600, 1024x768, and 1280x1024 - I could switch to and from them without any problems (I assume that the error occurs as soon as the new resolution is selected, not only when a race is started?) Cheers, Joerg - -- - ---------------------------------------------------------------- Joerg Henrichs Luding Administration e-mail: jo...@lu... URL: http://luding.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZRSGLC0mrNKFwF4RAt2FAJ9k+mtn+1qUpkjaP+aqosKtWF85nACeO779 ZbT5KKqbjXQ+Xvs+jWvEELg= =TRdV -----END PGP SIGNATURE----- |
From:
<coz...@gm...> - 2007-12-16 15:11:37
|
Hi, > I've got 800x600, 1024x768, and 1280x1024 - I could switch to and from > them without any problems (I assume that the error occurs as soon as the > new resolution is selected, not only when a race is started?) Are you talking about the fullscreen crash bug (the one that has to do with my hardware probably) or the one related to the GUI? If it's about the fullscreen bug, I'm in the process of updating my whole system. I expect huge breakage :) I just think that SDL reports resolutions that are possible in theory, but that maybe due to the combination of screen, video card, Nvidia drivers and X11, there is a problem somewhere. If it's the one with the GUI where the text moves to the left, I am not thinking of fixing it for the next release, since I suspect it's wrong size reports and we aren't going to remove PLIB for the next release (thought maybe I should bite the bullet and try it after the GUI, if I think I could switch to something else before the physics are ready, but I doubt I can even now). By the way: if you think that the physics are nearly ready for a release, I could switch for now to bug fixing mode and hunt down what it's in the tracker till the release, since the widgets are stable enough (until someone finds another bug) to use them in a release. Actually, you know what... I'll work on the bugs at least till the next year, since from the next year I plan to start the discussion about user-visible GUI changes. -Coz |
From: Joerg H. <jo...@lu...> - 2007-12-17 00:15:45
|
Hi, [...] > > I've got 800x600, 1024x768, and 1280x1024 - I could switch to and from > > them without any problems (I assume that the error occurs as soon as the > > new resolution is selected, not only when a race is started?) > > Are you talking about the fullscreen crash bug (the one that has to do > with my hardware probably) or the one related to the GUI? Fullscreen bug, well, can't switch to certain resolutions bug - and I think you are not the only one with this problem(?) .. but the only one who can reproduce it :) > If it's about the fullscreen bug, I'm in the process of updating my > whole system. I expect huge breakage :) I just think that SDL reports > resolutions that are possible in theory, but that maybe due to the > combination of screen, video card, Nvidia drivers and X11, there is a > problem somewhere. That would be good! [...] > By the way: if you think that the physics are nearly ready for a > release, I could switch for now to bug fixing mode and hunt down what >it's in the tracker till the release, since the widgets are stable > enough (until someone finds another bug) to use them in a release. Just from my timelime: I don't have much time now (till Thursday, 1st deadline), the I will be busier between end of Feburary and April (2nd deadline), and won't have any time anymore starting in June :) So a good time for a release would be mid February. Main point would be the new physics (and fixed handling of driving off track). Perhaps we can get some additional player visible changes in? E.g. one more collectable (glue??), or replay? I think I can fix all physics issues by then (auto rescue is already fixed, commit should follow soon) - so it's mainly wheelies/zipper, and then improve the rockets (which are not too good atm). All of this shouldn't take too long, I hope to have this ready beginning of January (fingers crossed). This would give us one month for release candidates and bug fixing. Main issue would be to get a Mac RC package, so that all the addictes fans on the Max forum could do some testing - with Xeno not having an internet connection atm that might be a bit of a problem. Hopefully he will be back to normal soon :) [then again: this is off topic and should go into a separate thread :) ] Cheers, Joerg |
From:
<coz...@gm...> - 2007-12-17 00:49:06
|
Hi, > > Are you talking about the fullscreen crash bug (the one that has to do > > with my hardware probably) or the one related to the GUI? > Fullscreen bug, well, can't switch to certain resolutions bug - and I think > you are not the only one with this problem(?) .. but the only one who > can reproduce it :) > > If it's about the fullscreen bug, I'm in the process of updating my > > whole system. I expect huge breakage :) I just think that SDL reports > > resolutions that are possible in theory, but that maybe due to the > > combination of screen, video card, Nvidia drivers and X11, there is a > > problem somewhere. > That would be good! Actually, I think this was the wrong choice. Let's say I find it's my hardware, then what? it's not like it will help to get a fix. So instead, I propose that after clicking the apply button, you are asked to confirm that the resolution works within 10 seconds, otherwise, it will change back, and STK should record in a file that the resolution probably doesn't works. Even better if it displays a message about it whenever you are about to apply a resolution that wasn't confirmed in 10 seconds before. > So a good time for a release would be mid February. Main point would be the > new physics (and fixed handling of driving off track). Perhaps we can get some > additional player visible changes in? E.g. one more collectable (glue??), > or replay? I think I can finish all the GUI changes by then, add some more user-visible improvements. In the end we might end with version 0.5 instead of 0.4 :p -Coz |
From: Paul E. <pau...@f2...> - 2007-12-17 22:14:56
|
Hi, Sorry, for taking so long to reply to a thread I started :) Ok, I have been playing around with my xorg.conf file to try to discover what was causing my black screens with many resolutions. I didn't have much luck with that, but I did manage to recreate (I think) the bug Coz gets. I had a look in my xorg.conf file to see which resolutions were specified and none were, I had let the xserver work it out. So I tried adding the resolutions that my monitor's manual said it could support, hoping to fix my black screens. But, one of the resolutions I added (1280x1024) gave a similar error to Coz's: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 135 (XFree86-VidModeExtension) Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) Value in failed request: 0x155 Serial number of failed request: (this value varies) Current serial number in output stream: (this value varies but is always the number above + 2) If this resolution is not in my xorg.conf file then I am not offered this as a choice by STK ( I am offered lots of resolutions, most are not listed in xorg, none cause a crash/error other than 1280x1024). As an aside, my system does not like displaying the 800x512 that Coz has trouble with, it doesn't crash or give an error, but always cuts the left side of the screen off in order to display as fullscreen. Having played around for a while with various resolutions, I am not convinced that my black screen bug is really related to Coz's bug. If I get a black screen, I can usually get out of it by one click of the mouse.. it is almost as if X needs a kick up the ass to display the new resolution.. To answer the previous points raised about this: If I start STK in resolutions that sometimes cause black screens, they do not occur as far as I can tell. I tried removing the windows ifdef around the code in sdldrv::setVideoMode as suggested by Joerg, but that only resulted in various textures being used instead of the STK background :) The occurrences of black screens do not depend on the previously selected res, as they can occur after changing from any other res or just by alternating between window and fullscreen at the same res. Just to clarify the black screens occur immediately after pressing Apply. The black screens can not be solved by switching to another tty (in response to Coz), but as I said above a mouse click seems to work:) So: This does seem to be a problem between what SDL thinks is possible and what the video card, driver, monitor and X think are possible, as Coz has suggested. Therefore I am inclined to agree with Coz in the need for a (fairly broad) list of sensible res that are checked against the SDL list, and (I am a belt and braces sort of person!) then also implementing the OK'ing of resolution changes as he recently suggested. Then if a black screen or crash occurs the user is not offered that choice again. Sorry again for the delay with my response and the length of this email:) Paul |
From:
<coz...@gm...> - 2007-12-19 01:24:10
|
Hi, > Therefore I am inclined to agree with Coz in the need for a (fairly > broad) list of sensible res that are checked against the SDL list, and > (I am a belt and braces sort of person!) then also implementing the > OK'ing of resolution changes as he recently suggested. Then if a black > screen or crash occurs the user is not offered that choice again. I would actually suggest that when a black screen/crash happens, you get a confirmation *before* setting the resolution (explaining that this mode was found faulty before) in addition to the confirmation after hitting apply, since it would be quite a problem if I install STK in an old monitor, then I have to delete configuration files if I get a better monitor. If no one opposes to this approach, would you be willing to do this Paul? -Coz |
From: Paul E. <pau...@f2...> - 2007-12-19 07:27:27
|
Hi, > > Therefore I am inclined to agree with Coz in the need for a (fairly > > broad) list of sensible res that are checked against the SDL list, and > > (I am a belt and braces sort of person!) then also implementing the > > OK'ing of resolution changes as he recently suggested. Then if a black > > screen or crash occurs the user is not offered that choice again. > > I would actually suggest that when a black screen/crash happens, you > get a confirmation *before* setting the resolution (explaining that > this mode was found faulty before) in addition to the confirmation > after hitting apply, since it would be quite a problem if I install > STK in an old monitor, then I have to delete configuration files if I > get a better monitor. > > If no one opposes to this approach, would you be willing to do this Paul? I will get cracking with this if no one else objects or has other suggestions. Paul |