|
|
|
This thread is locked; no one can reply to it.
|
| Configuration routines |
|
23yrold3yrold
Member #1,134
March 2001
 |
I just started playing with the configuration routines (why is there nothing on this in the examples folder?) and I figured I'd swing by for opinions. My main reason for this is a lot of people wanted the ability to dictate the screen update method in my last demo, and this seems a good way to do it.
Works well enough. Any tips? Any pitfalls I should know of? I've never touched these things before. What's a "section"? What're the hooks for? This bit of the API seems unnecessarily complex to me ... Expect a thread on screen update methods shortly -- |
|
Johnny13
Member #805
October 2000
 |
well i'd choose these by command line instead of reading external file,like exupdate.c Alg3D Praise my Games!!<code>#define SPAMMER (post>=666&&postperday>=6)</code><Mr.spellcaster>What post? <Mr.spellcaster>A useful post by me. |
|
Michael Jensen
Member #2,870
October 2002
 |
It'd be kind of annoying for commandlines -- having to type in "game.exe no 16 1" everytime you run... maybe a command line to accept a different config file or a commandline to accept command line parameters (complicating things is fun) anyways the external file lets the game remember your last choice of configuration anyways #2 I belive "sections" are those parts in the ini files that seperate one part of the file from another for instance [Graphics], [Keys], [Etc], not sure on this tho -- I've used windows support for reading/writing ini files but not Allegros.... sadly enough I used windows support for ini files in a program that used allegro -- I didn't realize allegro had this routines until after I implimented the windows versions in my last game ugh
|
|
Steve Terry
Member #1,989
March 2002
 |
int cd = get_config_int(NULL, "colordepth", 0); The zero in the get_config_int lines should be set to your default value if anything should happen to go wrong.... for instance in that line change it to 8 so that if for some odd reason there is no config file in the directory some default resolution would be set. Another cool thing is to write out the values back to the config file if the user changed them.. so that the next time the user executes the program it loads with the same settings each time. ___________________________________ |
|
spellcaster
Member #1,493
September 2001
 |
Quote: What's a "section" Normally, you'd use the config files like an normaö ini file. [Section} stuff=value [graphics] windowed=no res=640x480 colordepth=16
I didn't even know that you can ommit the "=" Quote: What're the hooks for?
It allows you to specify a couple of functions which will be used if you access a certain section. -- |
|
23yrold3yrold
Member #1,134
March 2001
|
Quote: It'd be kind of annoying for commandlines Bloody right. I hate opening a DOS box, switching to the right directory, typing it all out (don't make a mistake!) ... just double-click and go Quote: The zero in the get_config_int lines should be set to your default value if anything should happen to go wrong... Ah. Right. Good call. Quote: Another cool thing is to write out the values back to the config file if the user changed them... Oh, like in an options menu? Hmmm ... I shall have to contemplate that. It's certianly more intuitive than poking around a text file I'll have to try that [section] stuff. Thanks guys; that was helpful -- |
|
Evert
Member #794
November 2000
 |
Quote: The only thing I can think of would be to use to implement encryption or something. Actually, the idea was that it could be used to do some advanced stuff. In principle, you could do c = get_config_int("system_configuration", "processor", 486); to get the type of processor instead of using a seperate function. You could also implement a keyboard handler using the config hooks::) |
|
Ultio
Member #1,336
April 2001
|
What about making options in-game to change all this stuff? Think about your normal everyday average game players. They don't want to have to edit an external file just to play in a larger resolution, or to have a different buffering method. An in-game options menu would do the trick. You could have that directly access a config file to store the settings which will be loaded upon next startup of the game. That's the way I would like to have it when I play a game. Think about having to exit the game every time you want to change something just to test it. Having the results appear automatically through an options menu is the way to go, imo.
--- |
|
23yrold3yrold
Member #1,134
March 2001
|
Ultio: I said that I'm still wondering if I should upgrade to 4.0.2 or 4.1.8. I assume everyone would say the latter? -- |
|
Michael Jensen
Member #2,870
October 2002
|
unless theres some functionality in the unstable version that the stable version lacks, (that you're going to use) why not stick with the stable? (4.02 is stable, and 4.18 is unstable right? -- Im not up on the version numbering but someone said something like that to me)
|
|
Matthew Leverton
Supreme Loser
January 1999
 |
A finished game should definately include an option menu. Being forced to edit a text file (for most options) is 'unprofessional, although sometimes preferable to a 'smart' user. ~~ Upgrade to 4.0.3 it will be out shortly. PS: There's a big difference between 4.18 and 4.1.8. Allegro uses a 2 dot version system. |
|
Michael Jensen
Member #2,870
October 2002
|
that was a typo ::hangs head in shame:: actually on closer examination I also typed 4.02 instead of 4.0.2 -- must just be laziness.... Edit #2:
|
|
23yrold3yrold
Member #1,134
March 2001
|
Quote: Upgrade to 4.0.3 it will be out shortly. Cool; will do. Is 4.0.3 the stablized version of the 4.1.x stuff, or are 4.0.x and 4.1.x two different branches (or whatever you call it) now? Quote: Is there a standard way to impliment version numbers? Well, there's some standard conventions, but no hard, fast rules. Going from a version x to y involves some big interface changes (Allegro 4 and Allegro 5 will differ vastly) and going from 4.x to 4.y is slight improvements to a stable library. 4.1.x to 4.1.y makes some possibly unstable changes. It's right because it makes sense, basically I just want to make sure I can get a good screen update API set up; I tried a while ago, but it didn't work too well and I think it was because of some subtle Allegro bug which has been fixed IIRC. -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
4.0.3 will contain back-ported fixes as long as they won't prevent the alleg40.dll from being incompatible. Quote: and going from 4.x to 4.y is slight improvements to a stable library. 4.1.x to 4.1.y makes some possibly unstable changes. That's not quite right, it's more like this: 4.EVEN.X is stable, Also, 4.0.X versions are binary compatible with each other. If a new feature requires a change in the API, then 4.2.0 will begin. The definatition of unstable is basically new features that haven't been tested or are apt to change. |
|
Evert
Member #794
November 2000
|
Quote: is there a reason people use a numbering system such as 4.0.2 instead of build 85942? (etc)
Yes - the reason Allegro uses it is because the Linux kernel uses the same system: y.even.revision = stable, x.odd.revision = WIP/unstable. Build 85942 doesn't mean that much to me, really Of course, I'm still a big fan of the TeX version numbering |
|
Johnny13
Member #805
October 2000
|
#include<windows.h> int main() {char*cb="Software\\ChrisBarry",*wd="windowed",*cd="colordepth",*um="updatemethod"; HKEY K; DWORD d,WD=1,CD=16,UM=3,S=1; LONG R=RegOpenKeyEx(HKEY_CURRENT_USER,cb,0,KEY_ALL_ACCESS,&K); if(R!=ERROR_SUCCESS) {RegCreateKeyEx(HKEY_CURRENT_USER,cb,0,"",0,KEY_ALL_ACCESS,NULL,&K,&d); RegSetValueEx(K,wd,0,3,(char*)&WD,1); RegSetValueEx(K,cd,0,3,(char*)&CD,1); RegSetValueEx(K,um,0,3,(char*)&UM,1);} RegQueryValueEx(K,wd,NULL,&d,(char*)&WD,&S); RegQueryValueEx(K,cd,NULL,&d,(char*)&CD,&S); RegQueryValueEx(K,um,NULL,&d,(char*)&UM,&S); RegCloseKey(K); printf("R=%s %s=%d %s=%d %s=%d",(R==ERROR_SUCCESS)?"OK":"FAIL",wd,WD,cd,CD,um,UM); }
Quote: WTF[/ulr]? Thanks Spellcaster,that was helpful.:) Alg3D Praise my Games!!<code>#define SPAMMER (post>=666&&postperday>=6)</code><Mr.spellcaster>What post? <Mr.spellcaster>A useful post by me. |
|
spellcaster
Member #1,493
September 2001
|
Let me quote Johan here: WTF? -- |
|
23yrold3yrold
Member #1,134
March 2001
|
cough*cough Thanks Spellcaster; that was helpful. J13: What on Earth ..... -- |
|
spellcaster
Member #1,493
September 2001
|
Oh, I managed to write some hook functions which access the registry instead of a file... while that's not really useful, it was a nice exercise Maybe there's a reason for the hooks after all... -- |
|
Michael Jensen
Member #2,870
October 2002
|
Spell Caster: What is a "hook" function? Arn't there allready functions to access the windows registry? (that are similar to the windows .ini writing functions?) Quote: Build 85942 doesn't mean that much to me, really well by itself it may not mean much but if you have different versions to download you can easily tell which is the latest or more current instead of going ohh 4.0.3 is the newest release even tho 4.1.x has allready been out -- kinda confusing to me -- anyways I guess the even/odd stable/unstable thing is an upside to version numbering....
|
|
spellcaster
Member #1,493
September 2001
|
Quote: What is a "hook" function? hook functions allow you to override the normal behavior of allegro ini files. So, by using a hook I could read / write data from a registry entry instead from allegros normal config files. I could also use it to open a network connection, if I wanted. Check the config file part of the docs for more info on config hooks. Quote: Arn't there allready functions to access the windows registry? Of course. I'm using these function inside my hooks. -- |
|
|
Maybe I ought to upgrade to the latest Allegro before trying that (shall I go stable 4.0.2 or unstable 4.1.8?)
