Baldy_Old_Fart wrote:

... With the current (0.77b) setup, it is a right royal pain to try and decode the DBGL numbering in order to "Correct" or add to or remove any screenshots fetched from Moby Games or created by myself.

Not sure why you'd want to modify the packages 'manually' outside DBGL in the first place. If you'd want to change the contents of a package, simply import it into an empty DBGL instance, add/change/remove whatever you like and re-export the thing. What's the issue here, really?

Baldy_Old_Fart wrote:

Having everything for a particular game under its own relevantly named directory would certainly make life easier in that regard.
No need for database cross-referencing "GAME" to "nnn", just TOTAL relative addressing. In fact, the games information currently held in the database could be kept in the .\infroot\GAME_nnn\ folder, in a "profile" (I know that starts to sound like D-Fend Reloaded) or "ini" file. - The few global settings retained in the db could then be stored in a dbgl.ini file, and no database operations would be needed at all.

That is simply not going to happen; there is a good many reasons to have the database (performance, scalability, integrity, flexibility, querying, filtering, structuring, 'ACID') which you cannot (easily) replicate using just the filesystem. Besides, I certainly do not see the problem of just _having_ a database.

Baldy_Old_Fart wrote:

... Similarly, unpacking a multi-game package would require NO database fiddling about, NO checking for ID or duplicated numbers and correcting those potential errors, just unpack and refresh the Games List. Creating a Game-Pack or Multi-Game-Pack would only require the archiving of two folders & contents per Game, with no need to search for .\captures\what_was_that_number? and no need to build an XML reference list within the archive. Neither would there be any need to muck about changing those numbers on import, - just "does .\dosroot\GAME_abc\ exist?"

Why do you mention all these things as if they need to be done by hand? DBGL will take care of everything, so what's your point? I've created the GamePackArchive file format to allow for a high level of flexibility, not for ease of creating or managing one, by hand.

Baldy_Old_Fart wrote:

Having mentioned DFR, it has one particular feature which I do find useful - right-click any screenshot and select "Use as screenshot in Games List" - Beats the heck out of having to find where the captures folder is, then rename the image files to put the one you want as Game List Screenshot as the first in the folder.

In the captures pane, you can right-click on a screenshot, and select 'Open folder' to go there, instantly. I'll add 'Open captures folder' to the context menu for the profiles list, as well.

Hi all, I've just uploaded test build 0.77c with the following changes:

* A fix which should properly remove a Gallery's tooltip on deactivation (onblur) of the main shell (Baldy_Old_Fart)
* Properly update main Gallery image after returning from a DOSBox session when the DBGL thumbs pane is not showing
* Flush cached image data when removing a thumb, so that when a new image is captured inside DOSBox, the Gallery will show the new one (instead of the old, removed one)
* Added 'open captures folder' to profiles list context menu (Baldy_Old_Fart)
* When using the "Confs In game directory" mode, the relative captures folder inside the profile's .conf was broken for DOSBox versions after 0.72. This has been fixed (Baldy_Old_Fart)
* A fix to prevent saving .conf files in DBGL's main directory (when in "Confs In game directory" mode) whenever the profile's main game directory cannot be determined (incomplete [autoexec] section)
* An improvement to prevent changes to .confs when switching the associated DOSBox version in multi-edit-mode - some combo lists could get set to 'altered' while their value was not actually changed
* Allow D-Fend (Reloaded) import on systems other than Windows as well (krull1981)
* Added Arabic translation from Mohammed

All the latest files
To upgrade, grab the dbgl.jar as usual.

Regards,
Ronald

Hello, I'll repost a couple of suggestions I made some times ago and that have been ignored.. maybe it's silly, but I think they would improve the flexibility and usability of DBGL.

* a direct command line option that bypasses DosBox (useful to run some modern ports like for Doom or Descent games, or run a game through a Scumm command line), it would need a new tab in the 'Execute' field of the 'Mount' section, a 'Command Line' option along with 'Dos' and 'Booter'. Not to mention that it would allow using DBGL with builds or new versions with options that aren't supported (you could edit the config file, but there's the problem that if an option isn't supported by DBGL, every time you edit the profile for some reason, the config file is rewritten, and unsupported options are lost; in this regard also a 'use alternative config' option in the general tab of the profile editing window would be useful, so that if checked it uses that file and it ignores other settings).

* allow customizing of the interface in the settings (let the user choose which elements to show or not in the context menus). For example this is a context menu for Shadow Warrior, there are a lot of options that I'd never use (Run, Setup, Add, Edit...). Some can be useful in very special cases, that's why I'm not saying they should be removed completely.

* also an aesthetic thing, but for those alternative files to run (Dragon.bat and WantDest.bat in the example), either an option to hide the extension (so that you can rename the file to something that is more informative) or the ability to give it a title (as you can do for links).

code120 wrote:

... Not to mention that it would allow using DBGL with builds or new versions with options that aren't supported (you could edit the config file, but there's the problem that if an option isn't supported by DBGL, every time you edit the profile for some reason, the config file is rewritten, and unsupported options are lost;

While you shouldn't edit the profile's conf files yourself manually (as that is DBGL's job) for reasons you mention, it is perfectly ok to have a 'special DOSBox build' configured in DBGL with your highly specific experimental features enabled in its dosbox.conf. Then, if you create a profile based on that DOSBox version, DBGL will use the dosbox.conf settings as a basis for the profile.

Alternatively, if the experimental feature is configurable inside DOSBox from the command line, you can use the 'Custom Commands' tab to enable or set the special feature for a specific profile.

code120 wrote:

... in this regard also a 'use alternative config' option in the general tab of the profile editing window would be useful, so that if checked it uses that file and it ignores other settings).

Can you provide an example case in which this would really be required, and the 'Custom Commands' feature would not be powerful enough?

rcblanke wrote:

While you shouldn't edit the profile's conf files yourself manually (as that is DBGL's job) for reasons you mention, it is perfectly ok to have a 'special DOSBox build' configured in DBGL with your highly specific experimental features enabled in its dosbox.conf. Then, if you create a profile based on that DOSBox version, DBGL will use the dosbox.conf settings as a basis for the profile.

Alternatively, if the experimental feature is configurable inside DOSBox from the command line, you can use the 'Custom Commands' tab to enable or set the special feature for a specific profile.

I was just trying to convince you. Such a case happened to me once when the Daum build had changed some glide settings and DBGL couldn't get it right (I don't know if that glide config setting could be changed via command line). Now it's not the case anymore, but maybe it could happen again. Anyway it would be rather uncomfortable (I'd edit the config and avoid editing again the profile, instead). The main reason I suggested that was to run a Win application such a port or Scumm via DBGL.

I simply don't understand your distaste for such an option, since it would allow DBGL to do many more things (even run other emulators if the game fits the collection and it can be run through a command line, as you can do with WinUAE) and I don't think it should be that difficult to do (maybe I'm wrong?).
The only problem I can see is about portability and game archive exporting, but if a game is launched via command line rather than DosBOX there could be a warning during the archive creation.

code120 wrote:

... in this regard also a 'use alternative config' option in the general tab of the profile editing window would be useful, so that if checked it uses that file and it ignores other settings).

rcblanke wrote:

Can you provide an example case in which this would really be required, and the 'Custom Commands' feature would not be powerful enough?

In the past I put some GOG games and used their config, DBGL recognized everything but then the config was rewritten and some autoexec lines were lost, it's the only case I can remember when this option would have been useful, but it's not important, sorry, the main thing was the first one.

Thanks for the answer, bye

Just noticed there's an untranslated string in my latest Spanish translation for DBGL. In the contextual menu, after selecting a profile, the option below "Abrir carpeta" should read "Abrir carpeta de capturas" instead of the current "[dialog.main.profile.opencapturesfolder]"

I mention this because I can't decide if this is a mistake on my behalf or rather a new feature that has to be translated in the near future. Either way, I prefer that rcblanke corrects it himself.

Hi,

could you add a view that looks like game boxes on a shelf, similar to the view of your games on gog.com?

@code120: I'll have to think this through a bit more, especially the user-interaction part. If I end up with something that I think could sorta work, I'll post more info.

@Neville: I believe you have an old translation file leftover in your DBGL plugins folder, if you remove it the untranslated string should be found correctly.

@ghoost82: Not anytime soon. If you're into that kind of thing, maybe take a look at http://www.launchbox-app.com/

Test build 0.77d is up, fixing 403 HTTP errors when querying MobyGames. I wonder what MG change will be the next cause of more breakage... (thanks for the report, firestom2009)

All the latest files
To upgrade, grab the dbgl.jar as usual.

Regards,
Ronald

EDIT: Oh, just noticed some HTML was altered resulting in the game's description getting mangled. Will fix a.s.a.p.

EDIT2: Fixed in a new build, 0.77e.

rcblanke wrote:

I'll have to think this through a bit more, especially the user-interaction part. If I end up with something that I think could sorta work, I'll post more info.

Thanks, I didn't want to be too insistent, it's kind of trivial stuff in the end.

Test build 0.77g is up, fixing yet more issues (caused by HTML design changes) when querying MobyGames.

All the latest files
To upgrade, grab the dbgl.jar as usual.

EDIT: more MG changes, updated the build to 0.77g

Hi everyone,
I've just uploaded test build 0.77h, adding support for querying TheGamesDB.net for game information.

All the latest files
To upgrade, grab the dbgl.jar as usual.

Hey, I'm having a little trouble after updating from 0.76. After extracting the DBGL.jar I put it in the base directory where the launch.exe is. After that I preceded to download the other 2 files. The 0.6.0 gallery jar I put in the lib folder. As for the Default.xml when I clicked on it to download it sent me to a web page with code on it instead of downloading. So instead I right clicked and then clicked "save target as" and I got the Default.xml and then put it in the templates folder as instructed. But when I clicked on the launch.exe nothing happened. I started task manager and watched it while clicking on the launch.exe and javaw.exe starts but then stops. I've tried about 15 times to start DBGL but it isn't launching. Did I do something wrong? Do I need to remove the gallery 0.5.3 jar? I've upgraded before and didn't have a problem. Any ideas?

Hi SaberWolfXM,

Sounds like you did everything right, I can't really tell what's wrong with your setup. Could you put this file in your DBGL folder, start it and report back with contents of the dbgl_stdout.log and dbgl_stderr.log files, please?

Hey, after I downloaded and ran the program I wasn't sure if it did anything so I ran it a second time so the results got doubled. But here the are.

dbgl_stdout.log

Launching DBGL using 64-Bit VM 1.6.0_21 on Windows 7 v6.1amd64, HSQL Database Engine 1.8.1.3, SWT v3659win32
Startup
Launching DBGL using 64-Bit VM 1.6.0_21 on Windows 7 v6.1amd64, HSQL Database Engine 1.8.1.3, SWT v3659win32
Startup

dbgl_stderr.log

Exception in thread "main" java.lang.NoSuchMethodError: org.eclipse.swt.widgets.Display.getMenuBar()Lorg/eclipse/swt/widgets/Menu;
at org.dbgl.gui.MainWindow.createFileMenu(MainWindow.java:1757)
at org.dbgl.gui.MainWindow.createContents(MainWindow.java:254)
at org.dbgl.gui.MainWindow.open(MainWindow.java:150)
at org.dbgl.gui.Launcher.main(Launcher.java:47)
Exception in thread "main" java.lang.NoSuchMethodError: org.eclipse.swt.widgets.Display.getMenuBar()Lorg/eclipse/swt/widgets/Menu;
at org.dbgl.gui.MainWindow.createFileMenu(MainWindow.java:1757)
at org.dbgl.gui.MainWindow.createContents(MainWindow.java:254)
at org.dbgl.gui.MainWindow.open(MainWindow.java:150)
at org.dbgl.gui.Launcher.main(Launcher.java:47)

What do you think?

Ah, looks like an outdated SWT library. Simply remove all files from your DBGL lib folder, and replace them with the 8 files from the standard distribution's lib folder.

That worked!! Everythings back up and running. Much appreciated. I've noticed as I've been on here that this is a thread for requests as well. So if you will I would like to make one as well. Specifically a way to make a profile of a shortcut or a games MAIN.EXE without having to mount anything. Basiclly for GoG.com games that already have there on dosbox and for non dos games. With GoG games sometimes you don't really know how they got a game to work and for non dos games you don't need to mount anything. I recall trying to do this when I first got DBGL and it didn't work. Niether is essential but there's something about having boxart, screenshots and a short description that make a digital game feel complete. Anyway, thanks for the help and thanks making such a great program 😀

Hi all,

I've made another GamePackArchive (225MB) available for testing (here's a MyFlare mirror); the third collection of freeware, shareware and demo games as reviewed in ADG, episodes 99 to 133. It contains the following games:

3D CyberPuck (a.k.a. 3D Ball Blaster)
Amulets & Armor Classic
Aquanoid
Betrayal at Krondor
Carmageddon
Crusader: No Remorse
Descent II
Earthworm Jim
God of Thunder
Impulse Tracker
Jane's Combat Simulations: Advanced Tactical Fighters
Lawn Mower
Magic Carpet 2: The Netherworlds
Out of This World (a.k.a. Another World)
Rogue (a.k.a. Dungeons of Doom)
Roketz
Sango Fighter 2
SimCity 2000
Skunny Kart
Terra Nova: Strike Force Centauri
Words of Jesus
Worms
Worthy Opponent

Most are shareware/demo versions. I'm still awaiting some confirmations to allow the inclusion of Sango Fighter 2 and Amulets & Armor Classic. Comments and suggestions are welcome!

Good news, I've got confirmations for both games:

Hello, Ronald. […]
Show full quote

Hello, Ronald.

Thanks for your interest in Sango Fighter 2.

> Please allow me to introduce myself; I'm Ronald Blankendaal, author of the free, open-source frontend for DOSBox called DOSBox Game Launcher (DBGL). As you can see on my website, I do not only host the application itself, but also provide some game packs containing freeware and shareware games which can be very easily imported into DBGL, so that DOSBox users can easily get some games running.
>
> Some of the package collections that I like to make available, contain games reviewed by Kris Asick in his webshow called Ancient DOS Games. Recently, Kris reviewed Sango Fighter 2, so what I would like to ask is whether it would be possible for me to include your great Sango Fighter 2 game into one of my packages? That new GamePackArchive would then also be made available on my website.

Sure, you're welcome to include it. We want the game to be played & enjoyed by as many people as possible. Your support will no doubt help with that.

Please consider adding the first game, Sango Fighter, as well.
Here are the download links to both games, to get you started...

http://www.sangofighter.com/files/Sango_Fighter.zip
http://www.sangofighter2.com/files/Sango_Fighter_2.zip

Box art scans for both games can be found on MobyGames, I contributed them myself. 😀

If you need anything else, please let me know.

Would you like to be added to our mailing list, by the way? We'll keep you updated about all the new retrogames we produce & release.

Have a nice day.

--

- Brandon Cobb
President
Super Fighter Team

bcobb@superfighter.com
http://www.superfighter.com

"Never let dreams die!"

Yes, feel free to put the game into it. Is there any thing I need to do to ensure it will always have a valid link?

Lysle Shields

Thus, you can find the new GamePackArchive on the website, together with the new DBGL 0.78 release. the latest changes since the last test build include:

* fixed thegamesdb http 403 response, release year and rank calculation
* fixed game rank for pouet entries reached without intermediate results screen
* pre-process resourcebundles (translations), and no longer build jar with extended debug information to reduce dbgl.jar file size
* updated launch4j to 3.3

Regards,
Ronald

Hi, I'm using dbgl version 0.78 in Windows 7 64 bits and i've found strange behaviour in "Mount zip" i don't know if it is the way it works.

I'm using the Ykhwong's build to mount zip files.
If the path indicated in the write textbox of "Mount zip" section exists, game data (i.e save files) can be created, but if don't, a 0 byte file is created with the provided name and the game shows an error message.

For example, if i have a folder c:\saves with no more subfolders, and I indicate that write will be in C:\saves\Prince2, when i run the game an empty file with no extension ("Prince2") is created, and game saves are not possible. But if I manually create the folder before running the game, saving works fine.

Is this an issue?

@Soko; I do not consider this to be a DBGL issue, but rather behavior imposed by Ykhwong's DOSBox. Simply provide an existing folder and it should work correctly, right?

Hi all,
I've just uploaded test build 0.78a:

* fixed extraction of very specific files (containing a tilde in its filename) in GamePackArchives, for Windows systems (Neville)
* adding a Greek translation by George kaub (BraiNKilleR)
* some Polish translation updates from ZeroX4
* updated SWT to 4.3.2

All the latest files
To upgrade, grab the dbgl.jar as usual.