Tip: Standalone Projects and Config Files

edited October 2010 in General discussions
Yesterday I converted my project from the plugin API to a standalone exe project, which compiled and ran fine. But the first thing I noticed when I ran the project, my screen size was not 640 x 480 that I chose, but rather 800 x 600.

Actually, that isn't quite accurate. My game screen was indeed 640 x 480 but it was being rendered and stretched into an 800 x 600 window. The following is some of my code after converting to a standalone:



orxSTATUS orxFASTCALL Init()
{

	/* Loads config file and selects main section */
	orxConfig_Load("../Game.ini");

...
...
}



Game.ini
--------
; orx - Tutorial config file
; Should be used with orx v.1.0+

@../GameExtras.ini@
@../GameMisc.ini@

[Display]
Title			= MyGame
Smoothing		= true
ScreenWidth		= 640
ScreenHeight	= 480

[Viewport]
Camera = Camera

[Camera]
FrustumWidth  = @Display.ScreenWidth
FrustumHeight = @Display.ScreenHeight
FrustumFar    = 1.0
FrustumNear   = 0.0
Position	= (320.0, 240.0, -1.0) 

...
...


At first I couldn't work out what going on. I figured maybe it was overriding some settings from the default orx.ini config but this turned out not to be the case. I had my Game.exe in project/bin and my three configs located in project/ (or ../ relative the .exe). From reading everything I could on standalone projects, the name of the .ini must be the same name as the exe: Game.exe / Game.ini.

Which means that loading it with orxConfig_Load("../Game.ini"); should not be nescessary, but orx still needs to locate it somehow.

Looking at the 10_StandAlone.ini config from the tutorial, the penny dropped. This config sits right to the .exe. And 10_StandAlone.ini is simply a pointer to a second 10_StandAlone.ini in ../ that contains the actual data. Also, 10_StandAlone.cpp does not contain a config loader line.

So I moved my Game.ini next to the .exe, commented out the config loader line, and the screen size is correct again.

So the extra steps in brief when converting to a standalone project are:

1) Comment out the orxConfig_Load loader from your Init()
2) Move your main .ini config next to your .exe or create a new .ini config (with the same name as the exe) that simply points to your main config back in ../



I can only guess that the problem (or feature) occurs because my standalone project is looking for a config with the same name as the .exe. If it can't find one, it will get it's [Display] (800 x 600) information from some default, most likely orx.ini. When it comes across the [Display] config based on the orxConfig_Load("../Game.ini") in Init(), it's already too late and the settings there (640 x 480) will scale to the window already set as 800 x 600. If that reasoning isn't right, someone please correct me.

Hope this helps out others that may come across this problem.

Comments

  • edited October 2010
    sausage wrote:
    [...]At first I couldn't work out what going on. I figured maybe it was overriding some settings from the default orx.ini config but this turned out not to be the case. I had my Game.exe in project/bin and my three configs located in project/ (or ../ relative the .exe). From reading everything I could on standalone projects, the name of the .ini must be the same name as the exe: Game.exe / Game.ini.

    Which means that loading it with orxConfig_Load("../Game.ini"); should not be nescessary, but orx still needs to locate it somehow.

    I knew that things were too good to be true. I totally forgot to mention that part. Sorry about that. :/

    It's actually the same rule used for both versions (launcher/stand alone), except that in the launcher version the exe is named orx.exe which will try to load the default settings from orx.ini whereas, when one is using the stand alone version orx.ini will be ignored (unless the stand alone game is indeed called orx.exe :)).
    So the extra steps in brief when converting to a standalone project are:

    1) Comment out the orxConfig_Load loader from your Init()
    2) Move your main .ini config next to your .exe or create a new .ini config (with the same name as the exe) that simply points to your main config back in ../

    That's exactly it.
    I can only guess that the problem (or feature) occurs because my standalone project is looking for a config with the same name as the .exe. If it can't find one, it will get it's [Display] (800 x 600) information from some default, most likely orx.ini. When it comes across the [Display] config based on the orxConfig_Load("../Game.ini") in Init(), it's already too late and the settings there (640 x 480) will scale to the window already set as 800 x 600. If that reasoning isn't right, someone please correct me.

    Your analysis is totally correct, except for the orx.ini part. It won't get read at all unless you manually load it in code or via a @include@ tag in your default config file (the one that is named after your stand alone executable).

    Orx used to have a default hardcoded resolution in the display plugin (800 x 600 x 32b) but it's not true anymore on the current SVN version (it was changed a couple of days ago). For all available display plugins: if no value is to be found when initializing the display, the current desktop mode/resolution will be used.

    As a side note: the orxConfig_Load() (and orxConfig_Save()) can still be useful, even for stand alones, as it can be used to load save games or level informations, for example.

    The config system is a very versatile tool and can be used for a lot of things, including adding on-the-fly (and/or temporary) properties to objects at runtime, for example.

    I personally also use it for automatic mapping of UI buttons to inputs/actions. I should probably open a thread about this so that everyone can share their own config tricks.

    I know that I found myself regularly new config tricks that make my life much more easier when I work on a game. :)
    Hope this helps out others that may come across this problem.

    Thank you for this detailed post!
  • edited October 2010
    No problems at all. Happy to contribute something useful! Seeing I'm on the right track, I'll update the standalone project tutorial in the wiki with this brief tip.
  • edited October 2010
    That's a good idea. I added you to the editor group on the wiki. I can't give edition rights by default as the wiki was vandalized a couple of times in the past and I don't have enough time to moderate it myself.
Sign In or Register to comment.