Okay, another remark. It's EXTREMELY easy to fuck up the entire database it seems. I merely added one entry manually (in the database file) and the program wouldn't even boot anymore, because the database version was not correct or something. I tried to put back the backup I made, but it refused 🙁 I hope I can fix this, I added too many games already.

EDIT: okay this is exactly why I hate the use of Jave for apps like these. I get the following error even AFTER I completely removed the old app, and downloaded it fresh again:

Technical Information
java.sql.SQLException: Wrong database file version.

EDIT: I was able to fix it by completely uninstalling the java runtime software and reinstalling it. Again, this is why I hate Java 🙁 It's just too fiddly and unstable.

red_avatar wrote:

Okay, another remark. It's EXTREMELY easy to fuck up the entire database it seems. I merely added one entry manually (in the database file) and the program wouldn't even boot anymore, because the database version was not correct or something.

No offense, red_avatar, but it is also extremely easy to mess up the Windows registry (for example) if you do not know exactly what you're doing. Just like you said:

red_avatar wrote:

...it would be safer and easier to have an option to do it inside the program which wouldn't potentially harm the database...

And that's why we have DBGL version 0.53 today:

* Implemented profile duplication using mouse popup menu or ctrl-d (red_avatar).
* Added profile table column chooser in the setting dialog screen, so that you can choose the columns that you would like to be visible. Please note that changing the visible columns will reset column order and sorting (red_avatar).
* Added the option to automatically sort the profiles table after adding a profile (instead of putting the new profile at the end of the list) (red_avatar).
* Implemented auto-complete for developer/publisher/genre and status fields (red_avatar).
* Profile sorting among multiple criteria is now correctly stored across sessions. It is also quite a lot faster now.
* Made precautions to prevent accidental database overwriting using a differently named default database file (wd).
* Drive letters in uppercase now (old, cranky fella 🙄).
* Check for Java JRE 1.5 availability in batchfiles (MiniMax).
* Updated SWT to 3.2.1 and internal DOSBox CVS build to Jan. 9th for the Windows package. Note that DBGL currently does NOT work correctly on newer CVS builds since joystick configuration was changed on the 10th, effectively breaking support for that.

Check it out folks!

Regards,
Ronald

Thanks for keeping it updated.

There shouldn't be any more changes to the configfile layout starting now. (so the autofire,swap34 and timed are the last planned additions for 0.66)
The core stuff is still open. Not entirely sure which cores will be visible in userland.

Qbix wrote:

There shouldn't be any more changes to the configfile layout starting now. (so the autofire,swap34 and timed are the last planned additions for 0.66)

Glad to hear that. Any reason why you choose to make autofire, timed and especially swap34 set to true as per default?

1	secprop->Add_bool("timed","true");
2	secprop->Add_bool("autofire","false");
3	secprop->Add_bool("swap34","false");

Looks correct to me (only timed being true by default).

Strange, generating a new dosbox.conf using 'config -wc dosbox.conf' results in:

[joystick]
joysticktype=auto
timed=true
autofire=true
swap34=true

ah crap.
sorry. I will fix it.

Hi all,

Just a small step for DBGL, a giant leap for DOSBox; 0.54 is up:

* Implemented support for the new joystick configuration options such as 'timed mode', as introduced in DOSBox CVS on Jan. 9th. NOTE: Do not use these options with any of the DOSBox 0.66 beta builds, it will not work correctly. If you really need to use those beta builds, stick with DBGL 0.53.
* Added keyboardlayout support (another new DOSBox CVS feature).
# Added multiple image mounting support (yet another new DOSBox CVS feature).
* Fixed a regression where pressing either one of the reload buttons in the edit profile dialog would reset the captures directory setting.
* Internal DOSBox CVS build to Jan. 22nd for the Windows package.

I feel I really must congratulate the DOSBox team for all the great new features and speed-improvements that you've been able to achieve these last few weeks. Most joystick-related problems seem fixed thanks to your (hal, wd, qbix, harekiet and many more) hard work, prompt's image swapping patch has finally been committed, wd's dynamic core improvements have made it in and hal's serial port and timer related enhancements have found their place in CVS. Maybe, just maybe, someday vasyl's SVGA patch will also emerge in there!

Guys, I take a bow! Thank you thank you thank you...

Ronald

Great work by you too Ronald.

Have you looked at D.O.G ? I think some of the things Erik is doing with SDL is quite clever.

Thanks MiniMax, you honor me,

Well, the SDL_SPY you're talking about and its Music Drive implementation are one of my best idea's yet 🙄 .

I'm building towards a frontend that enables DOSBox doing things it couldn't do before, like zip, 7-zip and MP3/Jpg capture. I'm also thinking of the future so that future features in DOSBox intergrate into D.O.G. without the user knowing it. If version 0.66 ( or 0.67 as seen the progress DOSBox made ) allows zip archives to be mounted then I'll integrate that so that my internal routines won't be used, but the ones of DOSBox. This is also for the KeyB feature of DOSBox 0.66 and my internal KeyB routines. I'm also looking for compatibility ( DOSBox 0.62, 0.61, 0.60 and 0.58 ) and user friendlyness.

I think that DBGL is progressing very well. It still has the Java fealing to it but as time passes it gets better. There are a few recommendations if I may,
- Center Window routine.
- Make the unused features for the selected DOSBox version invisible, in stead of disabled in the edit profile window.
- For the DFend import routine, don't depend on the original path, like C:\DFend\Confs\Profile.prof but make your own path "Path of profiles.dat"\Confs\Profile.prof.

The SDL_SPY is one of those things that Java won't be able to use because of its multiplatform nature and the dll form of SDL_SPY.

rcblanke : Have you been able to use the DOSBox shortname routine?

Erik.

> The SDL_SPY is one of those things that Java won't be able to use

JNI 😀 (yes I know you need an implementation for every platform then)

mm, JNI, never heard of it before, good to know,

Thanks.

Erik.

ErikGG wrote:

Make the unused features for the selected DOSBox version invisible, in stead of disabled in the edit profile window.

Erik.

This is merely a matter of preference. I, for one, like to see what might be available with other versions of DOSBox, even if I already know what those options are.

The new version looks great 😀 I'll try it out tonight. I love your front end, honestly. It works great in Windows Vista too.

A suggestion: Write some of the information from the Info-tab (like title, publisher, and year) as comments into the profiles\NNN.conf file.

Somethiing like:

1# Title:     StarGunner 1.1
2# Developer: Apogee Software, Ltd.
3# Year:      1996
4# Genre:

Maybe with an option to import said information into the database.

I am not sure it is a good idea to include the Link, Status, and Notes info. Those fields seems more 'personal' to me.

I am also not sure if the information should go into profiles that are stored in the game directory. These files are a little more 'outside' of D.O.G's control, so maybe it is better not to muck about with any comment text there?

This would help people that want to share their profiles with others.

rcblanke wrote:

@ykhwong: Thanks for your script! Still, I think I will use the .exe packaging method h-a-l-9000 showed us earlier for his tunneling server Java app (Re: Direct serial port working) since this wrapper also checks the JVM version number (must be 1.5+) and autodetects the path to the JVM etc.

What happended with the idea of using JSmooth?

Here is the "source" for the exe files I posted earlier in this thread.

Captures.... Where are they supposed to be saved when using DBGL? It seems to me, like they are being saved in the captures directory where the dosbox.exe is located, and not in the numbered captures directory created by DBGL?

MiniMax wrote:

Captures.... Where are they supposed to be saved when using DBGL? It seems to me, like they are being saved in the captures directory where the dosbox.exe is located, and not in the numbered captures directory created by DBGL?

They should be stored in the DBGL numbered captures directories. Note that you can hover over the captured screenshots to see a tooltip showing its path.

There was a bug introduced in version 0.50 (fixed in 0.54) where pressing 'Reload Settings' in the edit profile dialog window would reset the captures folder to the default 'capture' setting, which might explain your findings?!

Nope (well, I think not). This was with a fresh profile created with an updated 0.54 DBGL.
I found my snap in the capture folder where my dosbox.exe resides, and moved them manually to the DBGL captures folder. When I did that, the snap showed up below the profile list in DBGL.

Edit: Okay - it works on my laptop, so it must be something in the setup on my desktop. Must be something I did somewhere 😖