02-24-2007, 11:41 AM,
|
|
rookie1
Member
|
Posts: 231
Threads: 32
Joined: Nov 2006
|
|
joevenzon Wrote:Quote:p.s.: Is there a way to have the build number built into the binary and displayable? Maybe stick it under the FPS counter in a small font or maybe in the menus somewhere? Again, JAT.
This is an excellent idea. I'll put it on my TODO list (although if someone else gets around to it before me that'd be great too).
Slightly OT - I've changed the scons script to include the svn revision number. Now the revision number is displayed at bottom right corner of the menu screen.
|
|
02-25-2007, 12:14 AM,
|
|
rookie1
Member
|
Posts: 231
Threads: 32
Joined: Nov 2006
|
|
rookie1 Wrote:Slightly OT - I've changed the scons script to include the svn revision number. Now the revision number is displayed at bottom right corner of the menu screen.
Just noticed that with the change I made to scons script, everytime there is a revision change, all the source files are getting recompiled. I think this is due to the -DREVISION the script added. In fact, REVISION is only need to be defined for main.cpp. Is there way to specify in the scons script that -DREVISION should only be added when compiling main.cpp?
|
|
02-25-2007, 02:35 PM,
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
Nathan (FFuser) has told me in IRC that reloading textures in Windows is the same problem as in OS X - OK the first time, but messed up the second time.
Rather than try to guess which menu to reload textures in, etc., we need to just make the game restart after changing display settings once (except for in Linux where this isn't necessary). In order to make the game restart itself, we'd need to change a lot...like make main into a class, that can be re-initialized. That's a lot of stuff I'd like to save for the next release cycle, so for now we could just do as we have before, and force the user to quit after changing display options once.
Also the ChangeDisplay function could be smarter, and only reload textures when it's necessary for some reason (I noticed the other day that this isn't quite the case - it doesn't seem to reload textures when I change the texure size in the advanced menu). We can't assume that users won't press OK in the Advanced Display Options menu, and then press Cancel in the Display Options menu. This is perfectly valid, and in the case where someone's only changing texture size on the Advanced menu, then pressed OK, and then Cancel, the changes would not be applied.
|
|
02-25-2007, 04:16 PM,
|
|
joevenzon
Administrator
|
Posts: 2,679
Threads: 52
Joined: Jun 2005
|
|
Quote:Rather than try to guess which menu to reload textures in, etc., we need to just make the game restart after changing display settings once (except for in Linux where this isn't necessary). In order to make the game restart itself, we'd need to change a lot...like make main into a class, that can be re-initialized.
I don't quite follow you here. The program shouldn't need to restart itself, it just needs to re-init everything, which is what it used to do whenever you clicked OK in the graphics options.
Quote:We can't assume that users won't press OK in the Advanced Display Options menu, and then press Cancel in the Display Options menu.
I realize this would be a band-aid, but it seems better than just doing nothing. Your idea of having a "game must be restarted before changes are applied" dialog pop up works, too.
I think the ideal would be to not re-init things when you leave the advanced screen and only re-init things when you leave the graphics options screen according to the following logic:
if OK on graphics screen: re-init
if CANCEL on graphics screen: re-init if OK was pressed on the advanced screen
|
|
02-27-2007, 06:26 AM,
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
joevenzon Wrote:Quote:Rather than try to guess which menu to reload textures in, etc., we need to just make the game restart after changing display settings once (except for in Linux where this isn't necessary). In order to make the game restart itself, we'd need to change a lot...like make main into a class, that can be re-initialized.
I don't quite follow you here. The program shouldn't need to restart itself, it just needs to re-init everything, which is what it used to do whenever you clicked OK in the graphics options. What I mean, is that on Windows and OS X, if you change the resolution twice, the graphics get messed up. If you restart the game things are better again. So if we had a way to destroy our SDL Window, and create a new one, that would be (I think) the same thing as a complete restart. This would be pretty easily possible if we abstracted most of the stuff in main.cpp into a manager class that could be reinitialized itself. Does that make more sense?
joevenzon Wrote:I realize this would be a band-aid, but it seems better than just doing nothing. Your idea of having a "game must be restarted before changes are applied" dialog pop up works, too. I'll set up one of those for now. This is how we have solved the problem in the past and I think it works fairly well.
|
|
02-27-2007, 12:40 PM,
|
|
joevenzon
Administrator
|
Posts: 2,679
Threads: 52
Joined: Jun 2005
|
|
Quote:So if we had a way to destroy our SDL Window, and create a new one, that would be (I think) the same thing as a complete restart.
That's the purpose of the ChangeDisplay() function in main.cpp. We can experiment with completely de-initting SDL there also... but I don't want to do anything too drastic before the next release.
As a side note, ChangeDisplay used to destroy the main SDL surface, but this was changed in R1534 by abs1nth (see above posts), and I think I'm going to change it back to destroying the surface. Although the SDL docs say not to free the surface because it gets freed by SDL_Quit, I think only the surface from the last SetVideoMode call gets freed, and I think we'll end up with a memory leak and other problems if we don't free the surface before replacing it with a new SetVideoMode call. If this makes anything worse for you on your platform, abs1nth, then let me know, but otherwise I'm going to keep it this way.
|
|
02-27-2007, 07:15 PM,
|
|
abs1nth
Senior Member
|
Posts: 358
Threads: 5
Joined: Sep 2005
|
|
[quote="joevenzon"][quote]Although the SDL docs say not to free the surface because it gets freed by SDL_Quit, I think only the surface from the last SetVideoMode call gets freed, and I think we'll end up with a memory leak and other problems if we don't free the surface before replacing it with a new SetVideoMode call.[/quote]
are you sure? "Note: This rule includes consecutive calls to SDL_SetVideoMode (i.e. resize or rez change) - the pre-existing surface will be released automatically."
also the source ( http://www.libsdl.org/cgi/viewvc.cgi/tag...iew=markup) indicates that the documentation is right.
[quote="joevenzon"][quote]
If this makes anything worse for you on your platform, abs1nth, then let me know, but otherwise I'm going to keep it this way.[/quote]
ok
i doubt it will make anything worse since it was the default until i changed it a few days ago.
|
|
|