New GB version coming... feature requests, anyone?

[K.C.]

If time is the problem, maybe at first only make the Global kvsets editable.
For example I would like to be able to type fullscreen=yes or scaler=pal3x somewhere to change the behaviour of all games without digging into the GEMUS script.
To make it work, you only need a text box to edit the k=v pairs and some code that changes the [global] section in the ini file.

[Jimbo]

You'd not have to delve into the gemus script, just the Gemus.ini file, but yeah, an interface for changing the kvsets would be nice.

[K.C.]

You'd not have to delve into the gemus script, just the Gemus.ini file, but yeah, an interface for changing the kvsets would be nice.

Without leaving the frontend, it's your only option.
Starting Windows Explorer, browse to the database dir, open the ini file and edit/save it is more work than editing the GEMUS script, and that's just what I want to avoid.
What I need is a short key to a window where I can quickly type in one or more k=v pairs to change emulator behaviour for all games.
It would be nice if I could select/create kvsets in this screen too.

Something else:
When I start a game from a larger archive, Gamebase needs some time to extract the archive. That's quite normal.
But I don't see anywhere that the frontend is busy with extracting the archive.
Can the Play Game button be greyed out while the archive is extracted and/or when the emulator is running?
Eventually you can also display a small popup message saying that the archive is being extracted.
This will prevent the emulator starting multiple times.

[Jimbo]

What I need is a short key to a window where I can quickly type in one or more k=v pairs to change emulator behaviour for all games.
It would be nice if I could select/create kvsets in this screen too.

Yep, working on this. Also, I've added a "batch" update function to the F2 window, where you can choose to save keys to current game (default), or to all games in current view, or to add/remove the listed k=v pairs to/from all games in current view.

But I don't see anywhere that the frontend is busy with extracting the archive.
Can the Play Game button be greyed out while the archive is extracted and/or when the emulator is running?
Eventually you can also display a small popup message saying that the archive is being extracted.
This will prevent the emulator starting multiple times.

Should be easy to add. I'll change the mousepointer to hourglass and disable the play game button until gemus returns control to the frontend (which could be after repacking an archive). I'll enable the button again if you click another game. I think that should do it.

EDIT: Ah, almost forgot: I've also made some GUI changes - the game name and small icons are no longer in the details tabs, so they still show when you hide the tabs. Also added another (small) box to the status bar, in the bottom right, that always shows the currently selected game-id.

[Jimbo]

New beta:

http://www.leesti.com/gbv13b20100226.zip

- now using the new custom database names in the startup database-selector window, and the GameBase menu
- added status bar box in bottom right showing the id of the currently selected game
- moved game name and icons out of details tabs, so they still show when the tabs are hidden
- Updated per-game "key=value" editor (F2 window) to manage kvsets and batch-update key=values for all games in the current view
- Can now (officially) put comment lines where you enter key=value pairs (lines starting with ; are comments)
- Added GEMUS function Show_KV() (show's the key=value pairs applicable to the running GEMUS script)

Be careful when testing the new kvset and batch key=value stuff. Backup your DBs

[Underfly]

My Gamebase would no longer run after overwriting files to this version.

Just nothing happens after executing gamebase.exe so I reverted back to previous version and it ran fine.

I tried back and forth serveral times. This version will not run.

[Retroplay]

Doesn't work here either.
Reverted back to previous beta and it works.

[Jimbo]

Yep ok, I can reproduce it here. Will get some time on GB tomorrow so will hopefully upload a fixed version then.

Sorry about that.

[Jimbo]

Pfff... I'm stumped right now on this one. GB compiles perfectly from VB. Runs on my dev machine fine. When I try it on my cab (XP), it just quits like you described.

I've checked all the compilation settings, and nothing's changed from the previous version. I've tried putting in debug alerts through the startup code, but it doesn't even get as far as the first Form_Load() - which is the entry point of the program.

Windows event logs say nothing too.

EDIT: OK, seems something went wrong with compiling one of the DLLs. They are supposed to be binary compatible, meaning you don't have to re-register them when they change. I just tried re-registering them on the cab and Bingo, the new beta works fine. I guess I'll have to re-build each DLL to find out the culprit.

If you guys can re-register the following 3 DLLs then try the new beta again, I'd like to know if that works for you. Just open up a dosbox (start->run, type cmd <enter>), then CD to your gamebase folder and type:

regsvr32.exe GBFuncs.dll <ENTER>
regsvr32.exe GBSql.dll <ENTER>
regsvr32.exe Gemus.dll <ENTER>

Thanks

EDIT AGAIN: OK, try this one, if it doesn't work, try the register stuff above.

http://www.leesti.com/gbv13b20100228.zip

Cheers

[sjakie43]

I have downloaded the latest Beta
and regged the dll's,it's working now!

Sjakie43

[Jimbo]

Another new beta:

http://www.leesti.com/gbv13b20100228-a.zip

If it doesn't work, please try the dll registering steps from my previous post. EDIT: OK, it's the Gemus.dll that is the culprit, apparently it needs re-registering - I must have screwed up when compiling. It'll not be a problem when v1.3 is released as the installer/updater will take care of it.

This beta saves all registry keys to HKEY_CURRENT_USER, instead of HKEY_LOCAL_MACHINE. See previous beta notes for what else is new, if you didn't already check.

If someone with Windows 7 can test it, that would be great. Please install GB to an NON-program files directory (e.g. C:\GameBase), and let me know how you get on. If you can try installing v1.2 first, NOT as administrator, then copying these v1.3b files in the newly installed GB folder, we can see if we can now install/run GB as a normal user (if installed outside of Program Files).

Thanks

[K.C.]

I've been testing a bit with the new beta regarding the dll registering problems and can report this back:

• Base situation:
• A clean Windows XP Pro SP3 PC without any Gamebase installation ever installed.
• A portable Gamebase installation (copied the Gamebase folder from a V1.2 installation to C:\Gamebase13, copied 3 OCX files from %systemroot%\system32 to C:\Gamebase13)
• A V1.2 test database copied to C:\Gamebase13)
  
  (note: Used Gamebase13 to avoid standard name Gamebase. V1.2 files in this folder will be overwritten with V1.3 files during testing)

• Test 1
  Started the frontend by executing C:\Gamebase13\Gamebase.exe
  Frontend starts, everything works OK.
  3 DLL files seem to autoregister. After starting Gamebase V1.2, these filenames are found when searching for it in the Windows Registry (under HKEY_CLASSES_ROOT\CLSID\<Long number>\InprocServer32).
  Before the startup of Gamebase V1.2, they were not there.
  Conclusion:
  Gamebase 1.2 starts and autoregisters needed DLL's.
  
  Test 2
  After Test1 was done, copied files from gbv13b20100228-a.zip to C:\Gamebase13.
  Frontend did not start. Registered 3 DLL's manually (one by one, tried to start the front end after each DLL). After registering the last DLL, the frontend started without problems.
  Conclusion:
  Gamebase 1.3 does not start with DLL's registered by a Gamebase V1.2 installation. These DLL's need to be re-registered after a V1.3 installation.
  
  Test 3
  Reverted to the base situation (see above).
  Copied files from gbv13b20100228-a.zip to C:\Gamebase13, without starting V1.2 first.
  Gamebase 1.3 Beta did not start. DLL's were not found anywhere in the registry.
  After manually register the 3 DLL's, the frontend started without problems.
  Conclusion:
  Gamebase 1.3 does not auto-register the 3 needed DLL's, but Gamebase 1.2 autoregisters them every time the frontend is started.
  
  Test 4
  After Test 4, copied a portable V1.2 Gamebase to C:\Gamebase12, as described above.
  Tried to start the frontend, without problems.
  Conclusion:
  Gamebase V1.2 works good with DLL's registered by V1.3 installation.
  
  Test 5
  Tried to start Gamebase 1.3 again after Test 4.
  No problems with starting Gamebase.
  Conclusion:
  Gamebase 1.2 seems to autoregister the DLL's only when needed. It does not overwrite the registry settings if they are already registered.
  So what V1.3 needs to do to avoid the need of registering manually:
• check if the files are registered. If not: register them automatically.
• check if the registry entries are valid for V1.3. If not, they are registered by 1.2 and need to be re-registered. Do this automatically.
• if the registry entries are valid for V1.3, do nothing.
  
  The first step seems to be implemented in V1.2, but is removed or doesn't work anymore in V1.3.
  The second step needs to be added in V1.3 to avoid error messages after upgrading from V1.2 to V1.3 (or on systems were both versions are installed).

[Jimbo]

Thanks for testing that, K.C.

It's the Gemus.dll that is the problem (I'm assuming that's the one you registered last - which is why it then worked).

But it sounds like you have uncovered a problem with the auto-registering. I've not changed that code at all (since Brataccas added it to v1.2) so it's strange that it's not working in v1.3. I'll have to do some more testing myself I guess. Luckily I use VirtualBox, so I can create a clean XP snapshot.

[K.C.]

Yes, gemus.dll was the last one I registered manually.
I've added some tests to my previous post that were crossing your post.

[Jimbo]

Thanks.

Is it possible for you to test if the autoregistering is working in an earlier v1.3 beta?