rcblanke wrote on 2023-04-16, 16:19:

Hi jophran, […]
Show full quote

Hi jophran,

Not being able to delete actual game files using DBGL has been a specific design-choice on my part, because it can be unclear what files exactly should then be removed. Some DOS(Box) games store files in multiple directories, or even in the C root folder. Also, some games can be run from within a disk or CD image, with additional game files somewhere on the C drive. And some games come with additional documentation files, for example. I decided it is probably best to have the end-user decide which files should be removed, manually.

Hmm, good question about Launchbox. I must say I haven't looked at Launchbox for ages and I do not know what features it has to import DOS games. Importing DBGL desktop shortcuts might work, I don't know. I will have a look at Launchbox soon-ish to see what might work.

Regards,
Ronald

Thank you for your answers. I agree now that it's better to not delete those folders when the profile it's deleted, I didn't realize all the other scenarios where files could be stored in many different places.

As for the Launchbox import, I can confirm that it is posible to mass import windows shortcuts and put them under de MS-DOS category without problem, and if the filenames reflects well the actual game title, they will get scrapped by LB without much problems. The only problem now would be that, as the shortcuts that DBGL creates point to the DOSBox version itself, if I change the asociation of a game to a different DOSBox version in DBGL I would have to remember to create that shortcut again so those changes get reflected when I launch them from LB. But it's not a big deal and for now I will do just that.

Thank you!

Just found and installed dbgl and really like it, thanks so much Ronald!

One issue, I get this Fatal Error message "Invalid CEN header (invalid zip64 extra data field size)" when I try to import three of the Ancient DOS Games game packs, the first (adg_collection.dbgl.zip), third and sixth packs. The other packs imported fine. I'm running Windows 11, dbgl v0.97 and Java SDK 17.0.8.

Any thoughts on what's going on?

How I use DOSBox-X and MIDI on DBGL?

In my local Spanish board some people are complaining they get an Invalid CEN header (invalid zip64 extra data field size) message error when importing game packages UNLESS they use the portable JAVA installation available at the DBGL homepage.

Don't know if this was to be expected or if said packages should work with every JAVA version supported, and therefore it's a bug.

I've been heavily using DBGL lately since I restarted with my game database (I had 3000 games in my old one ...) because I moved to DOSBOX-X to have integrated MT-32, AWE64 and Sound Canvas 55 support not to mention shaders and ZIP overlays.

I have a few suggestions of potential improvements. It's funny because I made a ton waaaay back in 2006-2007 but I guess I got more demanding over the years 😉.

- a search function. I know I'm one of the few to have such big libraries but once you have several hundred games it can be tedious to find a game. Aladdin for example is ranked under D from Disney's Aladdin and so quite a few games are not at the same letter as you'd expect.

- you have the game's name but it would be nice to have a "sort by ..." name which overrides the game's name for sorting. This way Secret of Monkey Island is ranked right above Monkey Island II.

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I grab a ZIP file for the C drive I get:

..\..\ZIPs\CD Install\Caesar 2.zip

But when I grab it to add an exe file to the Execute section, it changes it to :

N:\Retro\MS DOS\ZIPs\CD Install\Caesar 2.zip\

... which breaks the relative paths. These files are hosted on a NAS which is why it's important it remains relative.

This seems like such a silly oversight - would it be possible to fix this?

Thank you and thank you once more for all your hard work over the years.

charliemcd wrote on 2023-07-21, 22:10:

One issue, I get this Fatal Error message "Invalid CEN header (invalid zip64 extra data field size)" when I try to import three of the Ancient DOS Games game packs, the first (adg_collection.dbgl.zip), third and sixth packs. The other packs imported fine. Any thoughts on what's going on?

It seems that in most recent Java versions, when opening zip files a check was added to make sure it does fully comply to the zip file standard. I'm not sure why (the feature might be broken), but this seems to have caused issues for many Java users and developers (for example, see here). AFAIK my game pack zip files are perfectly valid, so I do not see why this new check fails.

Anyway, the workaround is straightforward (disable the check) and available in DBGL 0.98beta2.

Neville wrote on 2023-08-05, 12:42:

In my local Spanish board some people are complaining they get an Invalid CEN header (invalid zip64 extra data field size) message error when importing game packages UNLESS they use the portable JAVA installation available at the DBGL homepage. Don't know if this was to be expected or if said packages should work with every JAVA version supported, and therefore it's a bug.

He he, no, to be clear, my mini portable JRE package is there only for convenience reasons; whichever Java version you use (as long as it's version 11 or up) should not matter whatsoever. If it does, then I'll certainly look into it.

Ronald

red_avatar wrote on 2023-08-06, 15:49:

I've been heavily using DBGL lately since I restarted with my game database (I had 3000 games in my old one ...) because I moved to DOSBOX-X to have integrated MT-32, AWE64 and Sound Canvas 55 support not to mention shaders and ZIP overlays.

I have a few suggestions of potential improvements. It's funny because I made a ton waaaay back in 2006-2007 but I guess I got more demanding over the years 😉.

Always nice to hear from you again, Red!

red_avatar wrote on 2023-08-06, 15:49:

- a search function. I know I'm one of the few to have such big libraries but once you have several hundred games it can be tedious to find a game. Aladdin for example is ranked under D from Disney's Aladdin and so quite a few games are not at the same letter as you'd expect.

Eh, did you know about ctrl-F? That will open up the Create Filter dialog, which you can use to find specific profiles. If you just type in part of the name of the profile's title, it should be found (maybe with additional similar results).

red_avatar wrote on 2023-08-06, 15:49:

- you have the game's name but it would be nice to have a "sort by ..." name which overrides the game's name for sorting. This way Secret of Monkey Island is ranked right above Monkey Island II.

Maybe use the custom fields (in the profile editor's 'Custom Info'tab) for that? You can add these custom fields to the columns in your profile list, and sort on them. Their names can also be altered in the File->Preferences dialog screen (Profile Table tab).

red_avatar wrote on 2023-08-06, 15:49:

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I gra […]
Show full quote

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I grab a ZIP file for the C drive I get:

..\..\ZIPs\CD Install\Caesar 2.zip

But when I grab it to add an exe file to the Execute section, it changes it to :

N:\Retro\MS DOS\ZIPs\CD Install\Caesar 2.zip\

... which breaks the relative paths. These files are hosted on a NAS which is why it's important it remains relative.

This seems like such a silly oversight - would it be possible to fix this?

Strange thing, I'll look into that.

red_avatar wrote on 2023-08-06, 15:49:

Thank you and thank you once more for all your hard work over the years.

Thanks for your kinds words and suggestions, Red.

red_avatar wrote on 2023-08-06, 15:49:

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I gra […]
Show full quote

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I grab a ZIP file for the C drive I get:

..\..\ZIPs\CD Install\Caesar 2.zip

But when I grab it to add an exe file to the Execute section, it changes it to :

N:\Retro\MS DOS\ZIPs\CD Install\Caesar 2.zip\

... which breaks the relative paths. These files are hosted on a NAS which is why it's important it remains relative.

This seems like such a silly oversight - would it be possible to fix this?

Actually, I'm confused. Can you explain a bit more what it is exactly that you're doing? What is the location of your DBGL installation, what buttons in DBGL do you press?

rcblanke wrote on 2023-08-13, 15:46:

red_avatar wrote on 2023-08-06, 15:49:

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I gra […]
Show full quote

- when you use relative paths, it breaks them when you use "grab". This is quite tedious to constantly fix. For example if I grab a ZIP file for the C drive I get:

..\..\ZIPs\CD Install\Caesar 2.zip

But when I grab it to add an exe file to the Execute section, it changes it to :

N:\Retro\MS DOS\ZIPs\CD Install\Caesar 2.zip\

... which breaks the relative paths. These files are hosted on a NAS which is why it's important it remains relative.

This seems like such a silly oversight - would it be possible to fix this?

Actually, I'm confused. Can you explain a bit more what it is exactly that you're doing? What is the location of your DBGL installation, what buttons in DBGL do you press?

I'll add a picture that shows the steps:

a) add a relative path to a ZIP file
b) "grab" ZIP file --> correctly added as a relative path
c) select EXE from inside ZIP file using the "Browse" button
d) DBGL replaces the relative path with an absolute path

I always have to edit the path. When the path is outside of the DBGL folder it always does this. Same goes for adding manuals and such.

rcblanke wrote on 2023-08-13, 15:24:

Eh, did you know about ctrl-F? That will open up the Create Filter dialog, which you can use to find specific profiles. If you j […]
Show full quote

red_avatar wrote on 2023-08-06, 15:49:

- a search function. I know I'm one of the few to have such big libraries but once you have several hundred games it can be tedious to find a game. Aladdin for example is ranked under D from Disney's Aladdin and so quite a few games are not at the same letter as you'd expect.

Eh, did you know about ctrl-F? That will open up the Create Filter dialog, which you can use to find specific profiles. If you just type in part of the name of the profile's title, it should be found (maybe with additional similar results).

red_avatar wrote on 2023-08-06, 15:49:

- you have the game's name but it would be nice to have a "sort by ..." name which overrides the game's name for sorting. This way Secret of Monkey Island is ranked right above Monkey Island II.

Maybe use the custom fields (in the profile editor's 'Custom Info'tab) for that? You can add these custom fields to the columns in your profile list, and sort on them. Their names can also be altered in the File->Preferences dialog screen (Profile Table tab).

I considered the custom fields tab but it would be an awful lot of work to manually copy over the names now + I'd need to have another list on-screen for this to work and I like to keep the window as small as possible. The "sort by" feature I had in mind is more an override than a fixed field so you only need to do this if the main name is not really where you'd look for the game. For example Disney's Aladdin you'd look for at the letter A. It's OK if you don't want to add it but I wanted to explain why it's handy as just an extra field.

I didn't know about CTRL+F - will definitely use that!

red_avatar wrote on 2023-08-06, 15:49:

- when you use relative paths, it breaks them...

Thanks for your explanation, Red.

The issue with your use-case is that you expect ANY file located on the drive on which DBGL was started, to be accessed 'relative'. Even if that means the file has to be reached by going 'upwards' (..\..\) in the directory-chain first, before the correct subdirectory (zips\exodos\game.zip) can be found.

This is not how DBGL uses relative paths. DBGL will use relative paths only if the target file or directory is located underneath a certain location (in most circumstances, DOSROOT). Locations outside are considered absolute. The reason for this is that by using this logic, one can safely move the DBGL directory to another location without breaking any file or directory locations.

On the other hand, I guess your use-case might benefit from relative paths, like you explained. I've made the behaviour configurable. Grab this new dbgl.jar (and update the ones in the lib folder), and start DBGL. Immediately close it again; the settings.conf will then contain a new entry

1[directory]
2parentscanberelative=false

If you set this to 'true', all 'Browse..' buttons in DBGL should relativize paths as you expect.

DBGL 0.98beta3

Regards,
Ronald

rcblanke wrote on 2023-09-19, 17:15:

Thanks for your explanation, Red. […]
Show full quote

red_avatar wrote on 2023-08-06, 15:49:

- when you use relative paths, it breaks them...

Thanks for your explanation, Red.

The issue with your use-case is that you expect ANY file located on the drive on which DBGL was started, to be accessed 'relative'. Even if that means the file has to be reached by going 'upwards' (..\..\) in the directory-chain first, before the correct subdirectory (zips\exodos\game.zip) can be found.

This is not how DBGL uses relative paths. DBGL will use relative paths only if the target file or directory is located underneath a certain location (in most circumstances, DOSROOT). Locations outside are considered absolute. The reason for this is that by using this logic, one can safely move the DBGL directory to another location without breaking any file or directory locations.

On the other hand, I guess your use-case might benefit from relative paths, like you explained. I've made the behaviour configurable. Grab this new dbgl.jar (and update the ones in the lib folder), and start DBGL. Immediately close it again; the settings.conf will then contain a new entry

Copy code to clipboard

1[directory]
2parentscanberelative=false

If you set this to 'true', all 'Browse..' buttons in DBGL should relativize paths as you expect.

DBGL 0.98beta3

Regards,
Ronald

Thank you - I replaced the files in my old folder with this beta but sadly enough DBGL freezes whenever I want to edit a game profile now 😖 so I can't test it.

Sorry to hear that. Please try starting DBGL with dbglcons.cmd in order to keep the debugging screen open, and report back with the stacktrace that you get when the application freezes.

EDIT: Please also make sure that you have updated the .jar files in your DBGL/lib folder, as well as dbgl.jar.

rcblanke wrote on 2023-10-01, 11:28:

Sorry to hear that. Please try starting DBGL with dbglcons.cmd in order to keep the debugging screen open, and report back with the stacktrace that you get when the application freezes.

EDIT: Please also make sure that you have updated the .jar files in your DBGL/lib folder, as well as dbgl.jar.

I did a clean install - all works well. It's when I load my old database that it starts to freeze.

dbglcons.cmd gives me an error about it being compiled with a more recent version but even if I update my Runtime to the latest version I keep getting this error ...

Hi! 😀

Does DBGL supports (or will it do, at the future) any DOSBox clones (like DOSBox Staging or DOSBox X)?

Don't get it wrong, I love the original DOSBox, but as the time goes by and stays unmaintained, it gets more and more difficult, to compile it at Linux.
(Linux nowadays, is very unfriendly, with old program editions. Almost everything is dynamic (depending on external libraries) which are usually not backwards compatible).
The repo version then, is your only option and in case it's at a faulty - buggy condition, it leaves you out of options.

Bye!!! 😀

Go here and read https://dbgl.org/

Indeed, it says that DBGL supports Staging, but when I tried it, DBGL accepts only the original DOSBox binary (and not the Staging one).
Did I stumble upon a bug, or maybe I'm missing something?

Sorry! The situation isn't very clear to me.

Hi Achaen,

Yes, DBGL has (limited) support for DOSBox forks such as Staging and DOSBox-X. They should work, but keep in mind that not all features may be implemented in the options screens. What Linux distribution are you using? With Fedora, I've configured DBGL like this:

As long as you're using a native Linux DOSBox executable (thus not flatpak or similar) you should be able to add it into DBGL.

The problem (from my point of view) with the DOSBox forks is simply that there are many, with many different settings. And the settings they have in common, sometimes have different names, different default values and different possible values. Imagine the nightmare tying this all together. Especially since they're all evolving rapidly, adding and changing possible settings as they go.

But keep in mind that if you really want to use a specific DOSBox version, having a specific feature that you need, you can still use that in DBGL. Just add it to DBGL as a DOSBox Version, and then edit the dosbox.conf from that version by hand (thus, in a text editor) as to define your needs. For example, configure some very exotic experimental graphic shader option. Then, while this specific feature might not be configurable in DBGL, it will still be used when running a profile based on this DOSBox version! That is because first the dosbox.conf settings are loaded, and on top of that, the profiles' settings.

Beta 5 fixes the issue mentioned by red_avatar, and adds the image width and height in the title of the screenshot browser (as requested by red_avatar).

Ronald

THANKS Ronald!!!
I'll try it.

.. Moving straight on with beta 6, slightly improving profile title readability in Gallery view when using dark mode on Windows. Also a few libraries were updated; SWT now requires at least Java version 17. This means that the next DBGL release will no longer work with Java 11, but will require Java 17 or newer!

Ronald