From: Joerg H. <jo...@lu...> - 2007-11-28 23:12:17
|
Hi Paul, just a quick answer: [...] > I am trying to write a patch to allow users to change the screen Great! > resolution from the display configuration menu. This sounds simple, but > I have found a complication I did not anticipate, so any help would be > appreciated :). [...] > everything is fine. The only difference I can find between the > character selection menu and the others is the calls to ssgContext, so I > presume that this is an ssg (PLIB) issue. I know very little about PLIB I wouldn't be too surprised :) [...] > Could any of you that know more about the code tell me if I am going in > the right direction, and if so what to look at? I have read that SSG > does 'lazy state changes' so is this the problem? It shouldn't - I would have to look at plib again, but lazy means that (say) if during the tree traversal a state is changed twice, only the first change will actually trigger a change in OpenGL (or perhaps the state change get postponed till it is actually needed, e.g. because something is output). There is a force() call, which forces the state to be set ... not sure when/why this is necessary (see race_gui.cpp) > Hope you don't think I am too much of an amateur, I really appreciate > your help and enjoy my 'attempts' to contribute. Not at all - your contributions are highly appreciated, and it's much better to ask for help early, than wasting days of your time. I will be busy finishing the physics for the next two days or so (I just finished the redesign, after we decided to abandon non-bullet physics, now I 'only' have to fix some hopefully minor problems with the behaviour of sparks/rockets). If anyone else can have a look before that, that would be great, otherwise I'll do this in a few days (after my next commit). Just to be on the safe side: you are not using windows or mac? (opengl on these platforms has some issues with changing to fullscreen, and I guess changing resolution as well). BTW, it might be worth sending the patch here, too. Cheers, Joerg |
From: Joerg H. <jo...@lu...> - 2007-11-29 05:19:34
|
Hi Paul, I think I have found the problem: you most likely have to redefine the glViewport (see scene.cpp for an example), that's probably all that's missing - at least it matches your description. The character selection gui fixes the issue, since it sets a viewport. [...] > @Joerg, I am using linux so opengl should not cause problems. Sorry, wasn't sure :) And everything is different with windows :( (well, it's not actual a problem - afaik it's something the opengl standard didn't specify, and so the behaviour from one implementation to the next can change. Windows and Mac apparently chose the less 'forgiving' implementation). Cheers, Joerg |
From: Paul E. <pau...@f2...> - 2007-11-29 21:22:22
Attachments:
screenResolution.patch
|
Hi List, Thanks to Joerg for pointing me in the right direction.. > I think I have found the problem: you most likely have to > redefine the glViewport This was a success :) and a working patch is attached! I have put in menu items for selecting 1024x768, 800x600 and 640x480. We may want to discuss whether these are the 'right' resolutions to offer or if we want to add more options? More options would be very easy to do as I have added a changeResolution function which does all the work (see patch). However, I have noticed one bug with this :( When the original resolution is < the selected (new) resolution, the larger text in some widgets (ie:titles) is missing and occasionally some of the longer text gets truncated (ie: long track names). I don't know if this is a bug particular to this patch or if it is just exposing something in the new widget code (Any ideas Coz?). I presume it is down to the font and/or widget sizing, but as this code is new I thought I would ask for views before spending too much time on something 'known'. When the resolution changes, the widgets and fonts DO change size, so presumably the fonts are increasing by too much or something similar??? Anyway, if anyone has time:) have a look and let me know what you think. Cheers, Paul |
From: Robert S. <the...@gm...> - 2007-11-29 22:35:32
Attachments:
signature.asc
|
Paul Elms schrieb: > Hi List, >=20 > Thanks to Joerg for pointing me in the right direction.. >=20 >> I think I have found the problem: you most likely have to >> redefine the glViewport=20 >=20 > This was a success :) and a working patch is attached! I have put in > menu items for selecting 1024x768, 800x600 and 640x480. We may want to= > discuss whether these are the 'right' resolutions to offer or if we wan= t > to add more options? More options would be very easy to do as I have > added a changeResolution function which does all the work (see patch). I would go a completely different route. As soon as you enter the screen size menu: a) Create a list of screen sizes internally. b) Find out at which position (-> index) the currently active display size is. c) Create a label with the current display size. d) create 3 buttons "previous", "next" and "apply" - previous goes backwards to your list of sizes, next goes forward - after each change the label with the display size must be updated (since widgets do not relayout put "9999x9999" in at first) advantage: - you only need a fixed number of widget tokens - you do not hinder me to use display sizes you did not think of (I have a widescreen display here. all of the 3 display sizes look awful on my screen. :) ) It is done similar in the lap amount dialog. You may grab some code from there. Regards Robert |
From:
<coz...@gm...> - 2007-11-30 04:18:23
|
Hi list, sorry for joining late, internet problems >.<' > layout calculation again. STK is very undynamic in this regard. Even if > you change the label of a widget and the label is bigger than the space > the widget provides it does not resize. But I think this is OK since we > are writing a game not a windowing toolkit. :) You just need keep those I added the ability to resize the widget to the label's length when calling layout, but I was forced to remove it from there, don't remember why. The function to resize is still inside the widget.cpp file, because I might add a resize function, but I'm not sure still how the interface to the programmer would be yet. > This was a success :) and a working patch is attached! I have put in I hope Stephan reads this and is happy someone finally found a solution and that a menu for multiple resolutions can finally go in :) > However, I have noticed one bug with this :( > When the original resolution is < the selected (new) resolution, the > larger text in some widgets (ie:titles) is missing and occasionally some > of the longer text gets truncated (ie: long track names). I don't know > if this is a bug particular to this patch or if it is just exposing > something in the new widget code (Any ideas Coz?). I presume it is down Well, actually what I think that happens in your case is that, all text is truncated to the rectangle of the widget, so that scrolling text looks as in it's inside the widget. However, in my system, the widgets' text scales proportionally, so I couldn't find any truncated or missing text. Could you give more details on how to reproduce this? > I think 99% of the users would actually prefer to just select from a > list (some people might not even know the right resolution, but > recognise the numbers :) ). It's much easier to use. It doesn't make too > much sense to inconvenience a significant majority imho. I would prefer > usability over 'configurability' :) I actually like Robert's approach better, since we don't know what kind of monitors the players might have(yes, I would rather have a list, if the list has the resolution I want); however, since there might not be an easy way to get the list of supported resolutions, at least for now I would rather have a list. I think that allowing the 10 resolutions listed at http://www.tamingthebeast.net/blog/web-development/screen-resolution-statistics-0907.htm would be fine. There are two resolutions there, which I believe that are for widescreen monitors. -Coz |
From: Paul E. <pau...@f2...> - 2007-11-30 00:13:03
|
Hi Robert, You present some interesting ideas and I will look at implementing them. I especially like not having a large list of resolutions, I like the idea of selecting a greater or smaller resolution. I have a couple of queries though.. > - you do not hinder me to use display sizes you did not think of > (I have a widescreen display here. all of the 3 display sizes look > awful on my screen. :) I also have a widescreen display, and if I use fullscreen then the display is stretched and it doesn't look right. I assume the graphics are designed for a 4:3 screen. Using a lesser resolution in a 4:3 ratio looks OK to me (although it is in a window, but that is OK by me). What resolution do you run STK under? Do you set it with the supertuxkart -s ****x**** argument at startup? On the same point, what do the rest of the list use as their STK resolution? ( I always used fullscreen before, then changed to the default 800x600, but now use 1024x768, although during the testing of this patch I became quite fond of 640x480..) This area could be improved further once we have the input widget that was discussed in another thread:), then the resolution could be changed to a user selected (custom) resolution. Thanks for your input:) Paul |
From: Joerg H. <jo...@lu...> - 2007-11-30 00:36:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, [...] > You present some interesting ideas and I will look at implementing them. > I especially like not having a large list of resolutions, I like the > idea of selecting a greater or smaller resolution. I have a couple of > queries though.. Yes, it's a very good idea. Is there a portable way of getting all supported screen resolutions? I am not aware of any. Unless we find something, we should put the most useful ones in the st config file, and use this list. >> - you do not hinder me to use display sizes you did not think of >> (I have a widescreen display here. all of the 3 display sizes look >> awful on my screen. :) > > I also have a widescreen display, and if I use fullscreen then the > display is stretched and it doesn't look right. I assume the graphics Yes, we would probably need two background images for that. Or we find one image, and don't stretch it to fill the whole window, instead selecting which bits of the image should be displayed (depending on screen ration and image ratio we cut off parts of the picture). > are designed for a 4:3 screen. Using a lesser resolution in a 4:3 ratio > looks OK to me (although it is in a window, but that is OK by me). What > resolution do you run STK under? Do you set it with the supertuxkart -s > ****x**** argument at startup? I've heard of people using 1600x??? - one of the Mac guys iirc. > On the same point, what do the rest of the list use as their STK > resolution? ( I always used fullscreen before, then changed to the > default 800x600, but now use 1024x768, although during the testing of > this patch I became quite fond of 640x480..) I am usually using 800x600 in a window, to be able to see some debug output :) If I actually play, I would use 1024x768 or 1280x1024 on my desktop, and 1280x800 on my (widescreen) laptop I guess ... if it's fast enough for that, not sure atm :) > This area could be improved further once we have the input widget that > was discussed in another thread:), then the resolution could be changed > to a user selected (custom) resolution. I think it would be alright to just supply a list of resolutions from the config file - it's a lot of work for perhaps one or two people who want to run at 1167 by 933 :)) - they can easily modify the stk-config file :) Or start it with -s once, since we would always use the resolution in the user config file. I think 99% of the users would actually prefer to just select from a list (some people might not even know the right resolution, but recognise the numbers :) ). It's much easier to use. It doesn't make too much sense to inconvenience a significant majority imho. I would prefer usability over 'configurability' :) 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 iD8DBQFHT1r8LC0mrNKFwF4RAhDEAJ9WZwULIj/8DVkWe13V2mWYJglWlwCeIbm9 EG7xpvdKxIZWPvaTHjt4rnA= =8ANm -----END PGP SIGNATURE----- |
From: Joerg H. <jo...@lu...> - 2007-11-30 05:21:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, [...] >> I think 99% of the users would actually prefer to just select from a >> list (some people might not even know the right resolution, but >> recognise the numbers :) ). It's much easier to use. It doesn't make too >> much sense to inconvenience a significant majority imho. I would prefer >> usability over 'configurability' :) > > I actually like Robert's approach better, since we don't know what > kind of monitors the players might have(yes, I would rather have a Somehow I got the feeling that I didn't express myself correctly :) I am all in favor of Robert's approach, and I think it's an unnecessary and too complex overkill to allow people to enter the resolution. A list is the way to go. > list, if the list has the resolution I want); however, since there > might not be an easy way to get the list of supported resolutions, at I am not really sure that there is a (portable) way, so supporting a list of common resolutions should be fine. After all, how many professional games support all kind of resolutions? They are usually restricted to a few. That should be acceptable for us then as well (considering that odd resolutions are supported on the command line - let's just put this in the FAQ. The launcher on the Mac somehow gets a list of supported resolutions, and uses it to let the user select a resolution and pass it on to STK). > least for now I would rather have a list. I think that allowing the 10 > resolutions listed at > http://www.tamingthebeast.net/blog/web-development/screen-resolution-statistics-0907.htm > would be fine. There are two resolutions there, which I believe that > are for widescreen monitors. http://www.prismo.ch/comparisons/ contains the aspect ratio as well. 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 iD8DBQFHT53TLC0mrNKFwF4RAkAYAKCaYDphbUcblxTB30QSAgvODTDECQCdFKcX +AGeCrvWvNRuBwxX7vn1JAk= =AE/V -----END PGP SIGNATURE----- |
From:
<coz...@gm...> - 2007-12-01 00:42:47
|
Hi, > > least for now I would rather have a list. I think that allowing the 10 > > resolutions listed at > > http://www.tamingthebeast.net/blog/web-development/screen-resolution-statistics-0907.htm > > would be fine. There are two resolutions there, which I believe that > > are for widescreen monitors. > http://www.prismo.ch/comparisons/ contains the aspect ratio as well. The list I supplied contains quite a bit of widescreen resolutions (including the third one) according to the comparisons :) So I think it can be used? And another thing, I found a minor bug with the patch: if I'm in full screen, and I change the resolution, I get out of full screen mode. -Coz |
From: Robert S. <the...@gm...> - 2007-12-01 12:22:47
Attachments:
signature.asc
|
Hi, Joerg Henrichs schrieb: > Hi, >=20 > [...] >> You present some interesting ideas and I will look at implementing the= m. >> I especially like not having a large list of resolutions, I like the >> idea of selecting a greater or smaller resolution. I have a couple of= >> queries though..=20 > Yes, it's a very good idea. Is there a portable way of getting all > supported screen resolutions? I am not aware of any. Unless we find > something, we should put the most useful ones in the st config file, an= d > use this list. ??? We are using supercool libsdl which can do this for us: SDL_Rect **modes =3D SDL_ListModes(NULL, SDL_FULLSCREEN | SDL_HWSURFACE | SDL_SWSURFACE); libsdl.org is currently not responding for me. They have a nice Wiki explaining all functions but it is not working atm. If you want to see some simple sample code check out qonk.sf.net and look at the file src/videooptions.cpp inside trunk/. Regards Robert |
From: Paul E. <pau...@f2...> - 2007-12-01 12:51:27
|
Hi Robert, > ??? We are using supercool libsdl which can do this for us: > > SDL_Rect **modes = SDL_ListModes(NULL, SDL_FULLSCREEN > | SDL_HWSURFACE > | SDL_SWSURFACE); > > > libsdl.org is currently not responding for me. They have a nice Wiki > explaining all functions but it is not working atm. If you want to see > some simple sample code check out qonk.sf.net and look at the file > src/videooptions.cpp inside trunk/. Thanks for this, I too can't get libsdl.org at present, but I have had a look at the code in qonk which looks like just what we need. I will have a little play at putting this in STK unless anyone else comes up with a reason against it. Thanks, Paul |
From:
<coz...@gm...> - 2007-12-01 13:57:08
|
Hi, > ??? We are using supercool libsdl which can do this for us: Yes, SDL is pretty cool :) > SDL_Rect **modes = SDL_ListModes(NULL, SDL_FULLSCREEN > | SDL_HWSURFACE > | SDL_SWSURFACE); Now that his is in, I have a request. If it's not too much trouble, you could verify that the resolutions that STK makes available are returned by SDL_ListModes(), and not add the buttons if it's not? that way, players won't click on a resolution they can't use. -Coz |
From: Paul E. <pau...@f2...> - 2007-12-01 15:07:46
|
Hi Coz, [..] > > SDL_Rect **modes = SDL_ListModes(NULL, SDL_FULLSCREEN > > | SDL_HWSURFACE > > | SDL_SWSURFACE); > > Now that his is in, I have a request. If it's not too much trouble, > you could verify that the resolutions that STK makes available are > returned by SDL_ListModes(), and not add the buttons if it's not? that > way, players won't click on a resolution they can't use. The way I had envisaged this is how Robert described it initially, which is to have Increase Resolution, Decrease Resolution, and Apply buttons. Clicking increase shows the next higher resolution (****x****) as described in a list created from SDL_ListModes. This would only make available usable resolutions as you suggest. With regard to your later mail re:glScissor: >Let's see, the only glScissor() calls are in the widget.hpp file, and >it deals with text, so I suppose this is the issue you wrote about. >You only have to call widget_manager->layout(POSITION) with the same >argument as before, to recalculate the widget's position. You correctly identify the issue. What happens, is that if you start STK in say, 800x600, and then change the resolution to 1024x768 in-game, all text in widgets that are now positioned outside the previous 800x600 display area have no text (if positioned higher than 600) or truncated text (if the text extends beyond 800 wide). This is mainly visible on the 'full' screens like Character selection and track selection. The widgets all size correctly and the layout is correct, so it is not a problem with the layout call or the widgets themselves. If I comment out the glScissor enable in widget.cpp, then the text is drawn correctly in all the widgets, which suggests that glScissor is clipping those outside the original scissor rectangle. (This bug is even more severe if you start STK in a smaller resolution like 640x480 and then change to 1024x768. Then nearly every menu you navigate too has text missing or truncated, because a lot of the widgets are now outside the original 640x480 area.) Anyway, I am making progress with it and will work it out eventually. I am also learning lots of new stuff along the way as well, which is great:) Cheers, Paul |
From: Joerg H. <jo...@lu...> - 2007-12-01 14:53:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert, [...] > ??? We are using supercool libsdl which can do this for us: Glad that we have an SDL expert here! > SDL_Rect **modes = SDL_ListModes(NULL, SDL_FULLSCREEN > | SDL_HWSURFACE > | SDL_SWSURFACE); I googled for something like this, but didn't find anything. Should have had a bit more patience :) 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 iD8DBQFHUXVeLC0mrNKFwF4RAslOAJ4yVsoc/ufDx+qo81ym+SpKwxW7BgCghUU6 xooxFZf73M+LBdScEgurxG8= =l1M3 -----END PGP SIGNATURE----- |
From:
<coz...@gm...> - 2007-12-01 18:34:55
|
Hi Paul, > > Now that his is in, I have a request. If it's not too much trouble, > > you could verify that the resolutions that STK makes available are > > returned by SDL_ListModes(), and not add the buttons if it's not? that > > way, players won't click on a resolution they can't use. > > The way I had envisaged this is how Robert described it initially, which > is to have Increase Resolution, Decrease Resolution, and Apply buttons. > Clicking increase shows the next higher resolution (****x****) as > described in a list created from SDL_ListModes. This would only make > available usable resolutions as you suggest. Maybe it's time for voting? Joerg would rather have a list of resolutions, while others would like to have increase/decrease buttons. About my request: in case we make a list of resolutions, if you don't do it it's fine as I wouldn't stop the patch from being applied because of that, which is why it's a request :) > >Let's see, the only glScissor() calls are in the widget.hpp file, and > >it deals with text, so I suppose this is the issue you wrote about. > >You only have to call widget_manager->layout(POSITION) with the same > >argument as before, to recalculate the widget's position. > > You correctly identify the issue. What happens, is that if you start > STK in say, 800x600, and then change the resolution to 1024x768 in-game, > all text in widgets that are now positioned outside the previous 800x600 > display area have no text (if positioned higher than 600) or truncated > text (if the text extends beyond 800 wide). This is mainly visible on > the 'full' screens like Character selection and track selection. The > widgets all size correctly and the layout is correct, so it is not a > problem with the layout call or the widgets themselves. If I comment > out the glScissor enable in widget.cpp, then the text is drawn correctly > in all the widgets, which suggests that glScissor is clipping those > outside the original scissor rectangle. > (This bug is even more severe if you start STK in a smaller resolution > like 640x480 and then change to 1024x768. Then nearly every menu you > navigate too has text missing or truncated, because a lot of the widgets > are now outside the original 640x480 area.) > > Anyway, I am making progress with it and will work it out eventually. I > am also learning lots of new stuff along the way as well, which is > great:) Hmm, you sound so serious today. By the way, if you are wondering, the reason we need glScissor, is the scrolling, because otherwise the text could be seen outside of the widget. Consider the offer of adding the argument-less layout() function, as it would solve the problem easily, thought you might want to fix this in another way; you would just have to call it each time you change the resolution, not even during fullscreen / window switching. -Coz |
From: Paul E. <pau...@f2...> - 2007-12-01 20:15:35
|
Hi Coz and list, [...] > Maybe it's time for voting? Joerg would rather have a list of > resolutions, while others would like to have increase/decrease > buttons. I assume we want to use SDL_ListModes, to get appropriate resolutions far any computer running STK? The discussion only centres around using either a list or increase/decrease buttons, is this correct? I think I favour the increase/decrease buttons even though they may be less conventional. The reasons for this are: <sales pitch> To give a reasonable choice of resolutions in a list we will need many buttons, which I think would look quite cluttered. To back this point up, I have just put run SDL_ListModes on my machine and cout my possible resolutions: I have a choice of 20 ranging from 320x240 up to 1440x900. Now, obviously I wouldn't want to play at some of the lower ones, so we could automatically discount those. But, I have a choice of 9 modes between 800x600 and 1440x900, I may want any one of those and I think 9 buttons in a list would look odd :p To get around this, I think we would have to decide how many (and which, within a range) resolutions we can offer, and this takes away some of the freedom that using SDL_ListModes gives us. Using increase/decrease buttons would allow me to select from up to 20 resolutions, giving me a greater individual choice as well as keeping the GUI tidy. </sales pitch> [...] > Hmm, you sound so serious today. I am fine:), I have just been busy with 'real life' today which means I have had to write more quickly than I usually would, and haven't used as many :) > By the way, if you are wondering, the reason we need glScissor, is the > scrolling, because otherwise the text > could be seen outside of the widget. I was wondering, but I wonder a lot about different bits of STK because I have not got much of a clue about some aspects of it... :) It becomes clearer everyday though :) > > Consider the offer of adding the argument-less layout() function, as > it would solve the problem easily, thought you might want to fix this > in another way; you would just have to call it each time you change > the resolution, not even during fullscreen / window switching. I am probably missing something here (wouldn't be the first time..), but I don't think calling layout helps :) The text is missing/truncated on every GUI screen (with enough widgets) after an increase in resolution, not just the display config screen after the initial change. Each of these screens has had layout() called in its constructor hasn't it? These calls to layout occur after the change and so incorporate the new height and width (this must be the case, because the layout is OK, just some widgets are empty.) I think it must be that the scissor box for each widget is not having its position updated with that of the actual widget when layout is called, so text is not being drawn in those widgets that are now outside the original screen width and height. Does this make any sense??? Cheers, Paul |
From: Paul E. <pau...@f2...> - 2007-12-01 21:07:06
|
Hi list, Replying to yourself is probably a bit daft but that's how I feel right now XD. > I am probably missing something here (wouldn't be the first time..), I was missing something...(some openGL knowledge..) So, after commenting out the call to enable the glScissor test and finding that the 'text missing' bug resolved I knew that glScissor was causing it. But, commenting out all three individual calls to glScissor while leaving the test enabled did not resolve the bug >.< I then realised with a bolt from the blue, that in the same way that I had to call glViewport after changing the resolution, I also had to call glScissor with the new height and width! This is probably all obvious to most of you!! but this is the first time I have heard of glScissor (and a lot of other gl...) So, bug resolved!! Thanks for listening :) Paul |
From: Paul E. <pau...@f2...> - 2007-12-01 21:10:12
|
Hi Coz, [...] > > Consider the offer of adding the argument-less layout() function, I have considered it, and it would be very useful if you have a chance to do it. At present, I have a very ugly method of refreshing the window after changing the resolution. It works, but that is the only good thing about it :) Cheers, Paul |
From: Paul E. <pau...@f2...> - 2007-12-01 23:49:03
Attachments:
screenResolution_v2.patch.gz
|
Hi List, In order to help you decide whether you would like to select your screen resolutions from a list or via increase and decrease buttons, I have attached a patch that uses the buttons, so you can try it out and see if you like it. If we decide a list is the way to go, that is no problem, I will convert this, I just wanted to have a play with this idea:) This patch uses SDL_ListModes, as suggested by Robert earlier, so the resolutions you can select from should be those your system is capable of. I have fixed this bug.. >And another thing, I found a minor bug with the patch: if I'm in full >screen, and I change the resolution, I get out of full screen mode. as described by Coz and the glScissor bug as repeatedly described by me... :) Let me know what you think about the functionality and any bugs, I know the config_display GUI could do with being organised a bit better, but I didn't want to spend too long on making it pretty only to scrap it for a list :) Cheers, Paul |
From:
<coz...@gm...> - 2007-12-03 21:21:55
|
Hi list, > Let me know what you think about the functionality and any bugs, I know > the config_display GUI could do with being organised a bit better, but I > didn't want to spend too long on making it pretty only to scrap it for a > list :) I think it works pretty good :) However, I would like it if could separate the current resolution, from the selected resolution to apply. This could be done simply by displaying a widget that reads 'Current resolution: <resolution>' and another one that reads 'Resolution to apply: <resolution>', thought that text sounds ugly, so if you think of better text please use it :) Constantin, if it's not too much of a bother, could you try Paul's patch to see how well you think it works with widescreen? -Coz |
From: Magne D. <mai...@hv...> - 2007-12-03 21:26:48
|
Eduardo Alberto Hernández Muñoz skrev: > Constantin, if it's not too much of a bother, could you try Paul's > patch to see how well you think it works with widescreen? > > -Coz > I could test this as well (I have 1440 x 900), but since I am a real noob, I need to know excactly where the .patch file should be extracted. Sorry for bothering you. :) |
From:
<coz...@gm...> - 2007-12-03 22:46:38
|
Hi, > Eduardo Alberto Hern=E1ndez Mu=F1oz skrev: > > Constantin, if it's not too much of a bother, could you try Paul's > > patch to see how well you think it works with widescreen? > >[...] > I could test this as well (I have 1440 x 900), but since I am a real > noob, I need to know excactly where the .patch file should be extracted. > Sorry for bothering you. :) I don't know how to apply patches on Windows(I don't know which OS you run), but on GNU/Linux I can tell you how using the command-line: * Move to the directory where the patch is. * do 'gunzip screenResolution_v2.patch.gz' without the 's. The .patch.gz file will now end in .patch instead. * Go to the STK base directory. * do 'patch -p0 < (insert directory to patch here)/screenResolution_v2.patc= h'. Run make, and you should see the new options in the Display menu. -Coz |
From: Magne D. <mai...@hv...> - 2007-12-04 14:40:39
|
Eduardo Alberto Hernández Muñoz skrev: > Hi, > > >> I could test this as well (I have 1440 x 900), but since I am a real >> noob, I need to know excactly where the .patch file should be extracted. >> Sorry for bothering you. :) >> > > I don't know how to apply patches on Windows(I don't know which OS you > run), but on GNU/Linux I can tell you how using the command-line: > > * Move to the directory where the patch is. > * do 'gunzip screenResolution_v2.patch.gz' without the 's. The > .patch.gz file will now end in .patch instead. > * Go to the STK base directory. > * do 'patch -p0 < (insert directory to patch here)/screenResolution_v2.patch'. > > Run make, and you should see the new options in the Display menu. > > -Coz Thanks, but it returned this: ------------------------------------------------ supertuxkart$ patch -p0 < screenResolution_v2.patchpatching file src/sdldrv.cpp Hunk #2 FAILED at 140. Hunk #3 FAILED at 156. 2 out of 4 hunks FAILED -- saving rejects to file src/sdldrv.cpp.rej patching file src/sdldrv.hpp Hunk #1 FAILED at 29. 1 out of 1 hunk FAILED -- saving rejects to file src/sdldrv.hpp.rej patching file src/gui/menu_manager.cpp patching file src/gui/menu_manager.hpp patching file src/gui/config_display.cpp patching file src/gui/config_display.hpp ------------------------------------------------------------------ And after make, I got this: -------------------------------------------- sdldrv.cpp: In function ‘void drv_toggleFullscreen(int)’: sdldrv.cpp:122: error: ‘setVideoMode’ was not declared in this scope make[1]: *** [sdldrv.o] Error 1 make[1]: Leaving directory `/home/magne/supertuxkart/src' make: *** [all-recursive] Error 1 ----------------------------------------------------- Sorry for bothering you with this, as this isn´t an official release, and I´m just a user. Thanks for your time! |
From: Paul E. <pau...@f2...> - 2007-12-04 15:06:08
|
Hi Magne, This is not a very good patch of mine as it also contains some formatting changes to Robert's code that don't actually change anything. > ------------------------------------------------ > supertuxkart$ patch -p0 < screenResolution_v2.patchpatching file > src/sdldrv.cpp > Hunk #2 FAILED at 140. > Hunk #3 FAILED at 156. > 2 out of 4 hunks FAILED -- saving rejects to file src/sdldrv.cpp.rej These two failures are unimportant as they just change some formatting as I wrote above. > patching file src/sdldrv.hpp > Hunk #1 FAILED at 29. > 1 out of 1 hunk FAILED -- saving rejects to file src/sdldrv.hpp.rej This failure causes the problem with your make. Fortunately, it is easy to fix manually. If you open up src/sdldrv.hpp in any text editor you can insert this line (make sure you copy it exactly:)): void setVideoMode(); after this line (~line 82): void drv_toggleFullscreen(int resetTextures=1); then save and try running make again, it should work this time. > Sorry for bothering you with this, as this isn´t an official release, > and I´m just a user. Thanks for your time! Sorry, for the problems with the patch. Paul. |
From:
<coz...@gm...> - 2007-12-04 18:37:31
|
Hi, > > Sorry for bothering you with this, as this isn=B4t an official release, > > and I=B4m just a user. Thanks for your time! > > Sorry, for the problems with the patch. Sorry to both for the headaches my last commits are causing >.<' -Coz |