Format change for GDB

[GoogleCodeExporter]

I propose changing the GDB format and how it is handled to allow for multiple 
exe's per profile.

Something along the lines of

Profile "Game"
    Executable "game.exe"
    Executable "game2.exe"
    Hookmask "mask hex"
EndProfile

Currently, we have to duplicate stuff to allow for seperate SP and MP 
executables, and for if the game uses a seperate executable for configuration.  

Sonic Racing Transformed is a prime example needing something like this.

Profile "Sonic & All-Stars Racing Transformed"
    Executable "ASN_App_PcDx9_Final.exe"
    Executable "Launcher.exe"
    Hookmask "0x00000002"
EndProfile

Original issue reported on code.google.com by danialho...@gmail.com on 13 May 2013 at 7:49

[GoogleCodeExporter]

This is based off the style of the exported style of the nvidia game database 
(Nvidia SLI profile Export/Import tool) in text form.

The nvidia format also allows for partial paths in case multiple games with the 
same executable are found.

for example, the game Dragon: MMORPG uses the executable Client.exe, as does 2 
other titles (that i saw with a quick glance).  While nvidia directly targets 
the client.exe for Dragon, the other two titles include partial paths

Profile "Dragon : MMORPG"
ShowOn GeForce
ProfileType Application
Executable "client.exe"

Profile "Dou Zhan Shen"
ShowOn GeForce
ProfileType Application
Executable "斗战神/tcls/client.exe" 

Profile "Blade & Soul"
ShowOn GeForce
ProfileType Application
Executable "bns/bin/client.exe"
Executable "bnsclient.exe" 

Original comment by danialho...@gmail.com on 13 May 2013 at 7:56

[GoogleCodeExporter]

I think we can merge this issue with:
Issue 441:  Adapt the x360ce app or make a small app that places the correct 
dll(s) in a folder based on entries in the GDB 

I would go for XML format, because it makes developing much easier (we don't 
have to write our own parsers because we can use native XML serializers.

Problem is that we have to think extra on how to map these settings to database 
because best/valid settings must evolve automatically without manual update 
from developers. Minority of users must pick best/valid/default settings for 
majority (most popular settings = correct ones). It works more or less for 
controller settings. I have to finish code and SQL queries for Executables 
(they are called Programs now).

I guess, every Executable of the same Profile can have different setting of 
hook mask (please correct me if I am wrong). For example:

  game.exe - use DX9
  game_dx11.exe - use DX11

We need this table:

[x360ce_Executables]
  [ExecutableId] [uniqueidentifier] NOT NULL, -- must be MD5 checksum of executable.
  [FileName] [nvarchar](128) NOT NULL,
  [FileProductName] [nvarchar](256) NOT NULL,
  [HookMask] [int] NOT NULL,
  [XInputMask] [int] NOT NULL,
  [InstanceCount] [int] NOT NULL,
  [Comment] [nvarchar](1024) NOT NULL,
  [IsEnabled] [bit] NOT NULL,
  [DateCreated] [datetime] NOT NULL,
  [DateUpdated] [datetime] NULL,

[x360ce_PadExecutables] table in order to store individual modified settings 
(Executable+HookMask) so we can generate list of most popular (correct/default) 
settings.

and [x360ce_Profiles] table to link different Executables by adding ProfileId 
to [x360ce_Executables] table.

[x360ce_Profiles]
  [ProfileId]
  [ProfileName]
  [ProfileType]

XML would look like this:

<?xml version="1.0"?>
<x360ce>
  <Executables>
    <Executable ProfileId="guid1" Name="game.exe" Description="Game" HookMask="" />
    <Executable ProfileId="guid1" Name="game_dx11.exe" Description="Game DX11" HookMask="" />
  </Executables>
  <Profiles>
    <Profile ProfileId="guid1" ProfileName="Some Game" ProfileType="Game" />
  </Profiles>
  ...
<x360ce>

I have to think this trough.

P.S.: I've received new developing machine so I will resume developing of  
application soon.

Original comment by ejocys on 13 May 2013 at 10:40

[GoogleCodeExporter]

"I guess, every Executable of the same Profile can have different setting of 
hook mask (please correct me if I am wrong)."

I don't think this would be necessary, I have never seen 2 game binaries from 
the same title use different implementations of xinput.

" [ExecutableId] [uniqueidentifier] NOT NULL, -- must be MD5 checksum of 
executable.
  [FileProductName] [nvarchar](256) NOT NULL,"

file product name and md5 checksum would be too much trouble 

not every app implements a product name and md5 would be invalidated by things 
such as no cd cracks (which have a valid use to protect game disks imo, as well 
as working around broken copy protections, ie, starforce, securom) game 
updates, exe compresssion, etc.

Also, the more extra lines used, its just going to null what i was trying to 
get out of this, which is keeping the gdb simple for easy manual updating.

Original comment by danialho...@gmail.com on 13 May 2013 at 7:28