Elimination of the config.exe philosophy.

[joskuijpers]

Personally, I HATE the config.exe system. It is just so ugly. I have a couple of reasons:

• It is not integrated
• It's configuration is used across all sphere games using that engine: can't configure per-game.
• It is not possible to create a nice configuration screen within a game to set the controls.
• It is bound to the engine, not to the user.

Then there are a couple of technical aspects of config.exe that troubles me (and mostly my engine):

• I don't want multiple binaries because the game is shipped with the engine.
• I can't write to the app folder: only application settings folder.

Therefor I propose a new system that replaces config.exe with these perks:

• Programmable integration within the game.
• Per-game configuration, always.
• Stored in ~/config so it is always writable and is bound to the user.

As a game developer, you need to add a configuration pane if you want it to be configured. However, for this, a library could be made available.

function Input.Config() {
    this.players = [
        {
            // Keyboard
            keyA:1,
            keyB:2,
            keyX:3,
            keyY:4,
            keyDown:0,
            keyUp:0,
            keyLeft:0,
            keyRight:0,
            keyMenu:0,

            // Gamepad
            buttonX:0,
            buttonY:0,
            buttonA:0,
            buttonB:0,
        }
    ];
}

Input.Config.getCurrent = function() {
    return current config;
}

Input.Config.setCurrent = function(config) {
}

The actual configuration can be stored any way you want. But I would personally recommend JSON.

[joskuijpers]

The values of buttons and keys are the same as Keyboard.Key, Mouse.Button and Gamepad.Button, but as those are integers, the actual storage is also integer. You can set them using above of course.

Also, getting the KeyX for a player is: Input.Config.getCurrent()[0].keyX; Which can be shortened using:

var playerConfig = Input.Config.getCurrent();
Input.Config.on('change',function() {
     playerConfig = Input.Config.getCurrent();
});

// Usage:
playerConfig[0].keyX;

[FlyingJester]

This is highly implementation specific. I do not believe it should be a part of the Sphere 2.0 specification proper.

[joskuijpers]

Is it? The actual save-file of config.exe is the same on all systems. Then we just build, instead of a separate program, a JS library for it. I don't see much difference.
Please elaborate the multi-platform troubles.

[apollolux]

The intention was for a config bound to the engine rather than a specific game after numerous complaints of having to tediously script in control config. If a dev wants to implement a config specific to a game they're more than welcome to script it into that particular game, but I don't foresee modifying the global config file anytime soon to accommodate a global config AND game-specific overrides (like MAME does and must given its particular multi-machine nature). I can be convinced of game-specific config but right now I don't see the advantage over the existing config system.

[joskuijpers]

Alright, point taken. I still don't like it, but I can live with it. I could make my own config library that overrides the system config.
Then there is the second thing, and that is elimination of a second program: the config.exe. Is there a way? I think it is messy to have such a thing. Also, a problem is that with every windows update, it looks outdated, making using Sphere not attractive for new people (stuff looks outdated). On linux I think graphics is very specific to stuff, or go with X which looks ugly as, well, as ugly.
I can think of one OS where building a config tool is super easy, and that is OSX, but I would have no idea where to put it: it probably ends up to be delivered within each game. If it changes the global config, then that is odd and plain annoying. I can tho add a Preferences menu to the engine to free game developers of the burden.

Enlighten me!

[Radnen]

I'm just going to say, I fully support the idea of games having the ability to create their own config menu. In fact, I don't like config.exe myself and hope games had control over what graphics they showed by saving into their own config file graphics information.

The problem with current Sphere is two-fold. One, we don't have access to graphics features to make our own menus with and two, saving info to the game,sgm get's overwritten by the engine when the engine closes. (Sure changing the screen size is possible, but that's all you can do and is more of/feels like a hack than anything).

I'm not saying we should entirely remove config.exe either, but if games could support their own config menus, then it doesn't matter if we get rid of config.exe. Perhaps all games game.sgm file (whatever we decide to use for the format) store initial default graphics settings (that can at least be modified by hand, which I think is better than using a gui like config.exe).

[joskuijpers]

Welcome back!

I talked to @FlyingJester on IRC and we kind of decided to put these ideas into practice first, and then put then in the core standard. (That is why there is api/core and api/amd now. As there can be api/sfml).

My concern was control settings, but yes, graphic settings can be put in there too. Doesn't have every 'normal' game some standard settings, either in its config, or, because it is missing at initial startup, generated by the engine?

Do you propose a format?