Good Ol' TarviS wrote:

Hey there, I'm having a strange problem with the icon view. Game names on multiple lines cause them to overlap the icons below them instead of just pushing them down - how do I fix this?

Pic here: http://forum.zdoom.org/download/file.php?id=11321

Thanks in advance.

Additionally, icon transparency, whether from a .ICO or a .PNG doesn't seem to work right. Does D-Fend Reloaded only have 1-bit transparency?

VileRancour, Ykhwong's build includes linewise too, i tried this + CGA and game looks almost the same, except for some blinking on the target cursor ( in Amstrad mode). Didn't know linewise fixed the scroll on this game, i should figure it. Maybe if we try with some other Amstrad games we could see the diference, but i don't own any.

@Raideoul:
"Hardware 2x (hardware2x)" and "Hardware 3x (hardware3x)" will be added/removed when activating/deactivating pixel shader GUI. Also GUI for "mt32reverb.*" will be added to the MIDI page of the profile editor if "mt32" is selected as MIDI device. I haven't check with yhkwong's build: The mt32reverb.* settings in the conf file go to the [midi] section?

@Firefairy:
The list of supported games is directly read from ScummVM (see External programs->ScummVM page in the program settings dialog). It's exactly the list you get if you run "ScummVM -z".

@Good Ol' TarviS:
I'm just using the Windows icon view common control to display the lists. So saidly there is nothing I can do with this.

Yes they go in the [midi], like this:

[midi]
# mpu401: Type of MPU-401 to emulate.
# Possible values: intelligent, uart, none.
# mididevice: Device that will receive the MIDI data from MPU-401.
# Possible values: default, win32, alsa, oss, coreaudio, coremidi, mt32, synth, timidity, none.
# midiconfig: Special configuration options for the device driver. This is usually the id of the device you want to use.
# When using a Roland MT-32 rev. 0 as midi output device, some games may require a delay in order to prevent 'buffer overflow' issues.
# In that case, add 'delaysysex', for example: midiconfig=2 delaysysex
# See the README/Manual for more details.
# mt32reverb.mode: MT-32 reverb mode
# Possible values: 0, 1, 2, 3, auto.
# mt32reverb.time: MT-32 reverb time
# Possible values: 0, 1, 2, 3, 4, 5, 6, 7.
# mt32reverb.level: MT-32 reverb level
# Possible values: 0, 1, 2, 3, 4, 5, 6, 7.

mpu401=intelligent
mididevice=default
midiconfig=
mt32reverb.mode=auto
mt32reverb.time=5
mt32reverb.level=3

Alexander wrote:

@Good Ol' TarviS:
I'm just using the Windows icon view common control to display the lists. So saidly there is nothing I can do with this.

So it uses Windows' settings? I see then. I think I messed with Vertical Icon Spacing a while back and saw it didn't affect the desktop at all. Thanks for the help.

I have changed the mt32 settings from simple text fields to (in the setup dialog editable) dropdown list.

Another item for the wishlist:

An "Override profile", able to overrule any setting in the individual profiles on startup of the game would be really nice. This would be really useful in cases were one wants to temporarily override specific settings without having to change the settings in the individual profiles. Ideally this override profile would have an additional boolean value for every option that determines whether this specific override is active or not.

At first sight, one might think this functionality is already covered more ore less by the (very handy) "edit multiple options" function. But that's not quite the case, since changing back the overridden values to their former state is not possible with "edit multiple options" if those former states weren't the same for all changed games.

Edit: a most likely much easier to implement form of this (and good enough for me) would be a "Global custom settings" box to manually add options for all games at once. Just like the custom settings box in the profile editor, but active for all games at once.

Is there a way to pass command-line parameters to ScummVM with D-Fend Reloaded? I am building a USB stick of cool portable apps, and would like to use DFR to manage all the games. ScummVM can be made portable by using a command-line parameter to tell it to look for its ini file in it's own directory, rather than using the windows setup, but I don't see any way to tell D-Fend Reloaded to pass on a command-line parameter for all instances of ScummVM. When I run it normally, it pulls the ini file for my computer's install of ScummVM, not the one from the USB stick. I do see a way to pass parameters to it when it loads a profile, but I am not sure what format I would use to pass a -c command using that field.

Edit: I have managed to import some profiles from my desktop install of DFR, but they don't seem to work properly- ScummVM doesn't recognize the games correctly. If I delete and re-add from the same folder, they run fine, but since I can't save changes to the ini file for the profile, I have to do that each time I play. I am currently on the fence as to whether this is better or worse than losing the easy access to docs and screenshots by just using ScummVM directly.

So, now the question is- is there any way to manually edit the ScummVM parameters for a particular profile, or is there another way to make ScummVM play nicely with portable DFR? I feel like I am missing some simple step to get this to work...

@dosbox:
1. I understand your wish and think a global override profile with checkboxes for every setting would be a nice thing to have. I have thought a few days how to implement this - and then decided not to add a feature like this: First this would require a complete rewrite of the profile data base. For each setting we would need a "is active?" bool value. One could say that these switches are only needed for the one override profile and not for each profile but because the override profile would be a normal profile, I would need to rewrite the whole profile system (or add a second profile system for the override profile - which wouldn't be less work). Second I would need to write a complete second profile editor with additional checkboxes on every page.
2. Having a "Global custom settings" box for each DOSBox installation should be no problem. I have added this to my todo list.

@Firefairy:
1. There is no way to pass command line parameter directly to ScummVM yet, but I can add a command line parameters input line to the profile editor and the ScummVM page in the setup dialog.
2. DFR is building a temporary configuration ini file when starting ScummVM. The ini files from the ScummVM program directory, the ScummVM data directory (...\AppData\...) or the Windows directory are used only for setting the themepath=..., the gui_theme=... und and extrapass=... keys. But anyway, I will check DFR with ScummVM in portable mode.

Thanks very much for the fast response. 😀 I realized afterward that DFR automatically points ScummVM to a specific ini file when running a profile anyway, so that problem only applies to running it on its own.

I think version 1.3.0 of ScummVM might have incompatibilities with DFR in general- I am now testing a new install of both on my laptop under Vista, and ScummVM is having the same problem on this (non-portable) install- the profiles appear to install correctly, but when I try to run them. ScummVM doesn't find the files. I can point it internally to the relevant folder, and everything is fine, but somehow what is being passed from DFR isn't what it expects. I think they might have changed some key parameters in the latest update, and that is causing the problem, rather than any portability issue. 🙁

Thanks for considering this at all.

Maybe text based overrides are the better solution anyway. Not only from a programmers point of view. Keeping track of options that are disabled or enabled would be anything but easy within the profile editor.

One (not too important) other thing: Would it be possible to make the integrated image viewer non-modal? As of now it completely blocks the main window.

At the moment my todo for 1.2b is empty. Next weekend I will try to check compatibility with ScummVM 1.3 and then if everything is fine with this, we can have a 1.2b1 release.

In the past I had many problems with modal/non-modal windows (for example the main window hotkeys were not correctly disabled when opening a dialog etc. which caused some strange bugs). When making the image viewer non-modal this would cause many new problems so I would really prefer not to do this.

On my computer compatibility with SCUMMVM is broken as of version 1.3.0. I have been able to get a game working adding it as a windows game using command-line parameters.

Hi, ...

I am back, ... 😉

@Alexander = At the moment my todo for 1.2b is empty.

Respond = i will think of, new thing(s) to do soon, inside D-Fend Reloaded.

For the moment 2~3 months, not using D-Fend Reloaded = Other work to do in that 2~3 months time.

I have time this summer, with D-Fend Reloaded and others things.

I have try to see updated version "beta, rc, final", after 1.1 version final, but no new release.

At my side,

"This summer" , i will test my skill to made, a "100% Portable Apps Package, of D-Fend Reloaded". That use the latest portable "version and standart" used of build PortableApps software package, ... I dont think that it will be a public version, of my work. Only if Alexander ask to be made it public.

No bug to report.

Hi, ... Alexander

@Alexander

I have updated the help files, that is inside the portable version.
It can be included in your "D-Fend Reloaded PortableApps" package.
Please look at your private message box.

First:
The ScummVM 1.3 incompatibility is fixed now.

@sst:
The PortableApps.comInstaller is failing to compile a DFR package based on your framework and I can't get it to work. Additionally trying to compile a DFR PortableApps package without using the PortableApps.comInstaller just compiling the nsi file with NSIS already fails on the first line. (And for releasing DFR I don't want to use the graphical PortableApps.comInstaller tool, I just want to add a line like "makensis DFR-PortableApps.nsi" to my batch file which is used for creating all versions.) So I have removed all new PortableApps data based on specification 2.0 and will stay with the current 0.9.8 PortableApps specification. If you think this is no acceptable, the other possible way would be removing PortableApps support completely from DFR. - I'm not interested in a PortableApps version of DFR at all, so just removing support for this would be an option for me.

Hi, ... Alexander

@Alexander

Did you know, if i am the only one that use, the portable version ?

I think also, to not really use anymore the portable version.

Then if i am the only one, to use the portable version, then you can cancel the portable version.

Then i will use the setup installation D-Fend Reloaded = not the portable version.

Did you keep the "help.html file" ?

Did you keep the "icons file" ?

Alexander wrote:

In the past I had many problems with modal/non-modal windows (for example the main window hotkeys were not correctly disabled when opening a dialog etc. which caused some strange bugs). When making the image viewer non-modal this would cause many new problems so I would really prefer not to do this.

Understandable, although I still would really like the idea. Would make the viewer much more usable as a viewer for maps and other image based material while playing.

sst wrote:

Then if i am the only one, to use the portable version, then you can cancel the portable version.

Noooo, stop! I'm using it too. At least if 'portable' means the version with relative paths. My whole game collection, including various batch files etc., is organized with relative paths in mind. D-Fend without relative path support would be a major bummer for me.

I don't care about the Portable Apps installer though. If that would be gone, I wouldn't miss it. Didn't know it exists, to be honest.

Hi, ...

@Alexander
The PortableApps.comInstaller is failing to compile a DFR package based on your framework and I can't get it to work. Additionally trying to compile a DFR PortableApps package without using the PortableApps.comInstaller just compiling the nsi file with NSIS already fails on the first line. (And for releasing DFR I don't want to use the graphical PortableApps.comInstaller tool, I just want to add a line like "makensis DFR-PortableApps.nsi" to my batch file which is used for creating all versions.) So I have removed all new PortableApps data based on specification 2.0 and will stay with the current 0.9.8 PortableApps specification. If you think this is no acceptable, the other possible way would be removing PortableApps support completely from DFR. - I'm not interested in a PortableApps version of DFR at all, so just removing support for this would be an option for me.

@Alexander
Respond :
Then, if you whant and also other(s) user(s) of your software, that the portableapps ".paf.exe" package version, can be canceled.

@dosmax
I don't care about the Portable Apps installer though. If that would be gone, I wouldn't miss it. Didn't know it exists, to be honest.

@dosmax
Respond : I use the Portable Apps installer, because i have portable apps softwares, and the portable Apps main software(s), and i help on that website, to translate and test portable softwares. Also, before the PortableApps structure is needed for D-Fend Reloaded, but not anymore to me = because Alexander simply use only one main directory for all files, then i have transfert the software, outside the PortableApps package, to an external directory, not related to PortableApps. D-Fend Reloaded work with relative path, even if not in the PortableApps structure.

I'm very busy again at the moment, so just a short update:
- Help file and icon files have been added to the PortableApps package.
- Updates to the PortableApps package do not affect the portable run mode of DFR in any way.
- Non modal image previewer: I'm thinking about how to implement this. 1.2b1 should bring at least a hidden option to test this. Depending on how good it works may be also a normal option to turn this on.