Just tested it does compile in Delphi 2007 - I will get to work on the bugs once I finish sorting the games I have to use with it, I worked around my own problems by making dosbox.exe switch the resolution then run dosbox_main.exe, then I discovered that the error I was having was fixed if I re-installed directx 9c manually after installing my PC - I used a RyanVM lite directx and it obviously has something missing in Windows 10 RS1- worked fine in Win 10 RS0 tho.

Thank you for responding to this thread I have been checking for updates and thought it was never gonna get a response to help, but glad I was wrong. I have collected all the versions so I can base my builds off the existing ones without sourceforge, just until I see how well I can code in Delphi, been a loooong time since I used anything other than Visual Basic or Real Basic/Xojo now.

Well, LiveFreeDead, if you will need some help you may ask (e-mail preferably).
But I still hope that Alexander will comeback in some reasonable time.

DarkTemplar wrote:

Dear creator of D-Fend Reloaded, I noticed that the list has a bit of an issue with displaying high-res png icons. I attached two files, one is a screenshot showing the problem, the other one is the png file. I think the problem is displaying the alpha channel. I am currently working on the creation of a beautiful set of icons for all my 500 entries but I can't continue as long as I don't know if you get this sorted. Would be cool in any case and I am looking forward to your reply. Best regards, Dan

Images: http://imgur.com/a/avosg

I have started looking in to this problem, I noticed in the Program Settings - User Interface - Image Scaling that if you change the method from B-spline it changed how the problem looked, I then went on to resize the icon you provided above and resized it from 314x314 to 256x256 using IcoFX and exported it as a png again this improved the look of the icon a little - until I changed the size to 128x128 in the settings. The remaining problem I see is the icon is applied to the tListView after it had been scaled on a solid background color, meaning mine is white (yours was black, due to the theme you have set) on all but the 255 (fully) transparent sections as the list view shows in binary transparency and not an alpha channel, I will look in to the issue to see if the list view used can accept alpha channels instead but this may be a limitation of the list view control and not a coding problem at all. I will edit this post as I find more.

-EDIT 1-

As far as I can tell he already has adopted the use of Common Controls v6 over the default v5.8 to fix the alpha channel issues in Delphi's ImageList controls, but I am new to the code so haven't found where he scales the images yet to see if he applies it to a solid color or not yet.

-EDIT 2-

The problem lays in "IconLoaderUnit.pas", I think it's to do with the variable clWhite or the CreateMask routine being used instead of the alpha channel being used it converts to binary transparency. I can't even get Delphi to show me a MessageBox from within this existing code, so although I could find a new way to process the image to work, I can't figure delphi enough to do it yet, lacking time to work on things, so I'll have to wait until I have some more to spend.

ScummVM support is pretty well borked at this point. Nearest-neighbor scaling has been moved to the render_mode ini config option and there's no way at all to get it to work properly in D-Fend Reloaded v1.4.4. You can use OpenGL scaling by adding the option to the Filters but it upscales using bilinear interpolation.

SedrynTyros wrote:

ScummVM support is pretty well borked at this point. Nearest-neighbor scaling has been moved to the render_mode ini config option and there's no way at all to get it to work properly in D-Fend Reloaded v1.4.4. You can use OpenGL scaling by adding the option to the Filters but it upscales using bilinear interpolation.

Can you explain (to someone who is not very knowledgeable in this area) what you mean by ScummVM support being borked? I have D-Fend Reloaded 1.4.4 and the Scumm games that I have added seem to be working (Full Throttle, Monkey Island, The Dig). Furthermore I don't see any parameter for "nearest-neighbor scaling" anywhere in scummvm documentation..

Am I limiting my experience by playing ScummVM games through D-Fend Reloaded in any way?

Also, how can I get ScummVM to work as a portable install with D-Fend Reloaded?

lukeman3000 wrote:

Can you explain (to someone who is not very knowledgeable in this area) what you mean by ScummVM support being borked? I have D- […]
Show full quote

SedrynTyros wrote:

ScummVM support is pretty well borked at this point. Nearest-neighbor scaling has been moved to the render_mode ini config option and there's no way at all to get it to work properly in D-Fend Reloaded v1.4.4. You can use OpenGL scaling by adding the option to the Filters but it upscales using bilinear interpolation.

Can you explain (to someone who is not very knowledgeable in this area) what you mean by ScummVM support being borked? I have D-Fend Reloaded 1.4.4 and the Scumm games that I have added seem to be working (Full Throttle, Monkey Island, The Dig). Furthermore I don't see any parameter for "nearest-neighbor scaling" anywhere in scummvm documentation..

Am I limiting my experience by playing ScummVM games through D-Fend Reloaded in any way?

Also, how can I get ScummVM to work as a portable install with D-Fend Reloaded?

So, when you use OpenGL scaling it upscales the image using a nearest-neighbor algorithm, so you get a nice, crisp version of the original image versus what happens when an image is upscaled using a bilinear algorithm, where it ends up looking like you're viewing it through a glass of water; all blurry, hard to look at for more than a few minutes without getting a headache (so it amazes me that some people prefer it this way).

The problem is that ScummVM changed the way it handles the image scaling, at least in the current SVN builds I use. It used to be that all you had to do was set "openGL_nearest" in the filters option. But now they've split the functionality into two settings. You need to set "opengl" as the filter but you also need to set "vga" under the "render_mode" setting. D-Fend Reloaded 1.4.4 currently appends the render mode setting as "render-mode" to the commandline rather than, say, adding the line "render_mode=vga" under the [scummvm] heading in the ini file. If you right-click one of your scummvm games and choose to view the config file you can see how D-Fend lays it all out, and right now it's borked; adding "render-mode=whatever" to the commandline of scummvm does squat and that's all D-Fend is able to do currently, probably because that's how it worked in older scummvm versions.

As to your second question, there's a setting in D-Fend that allows you to point to where your ScummVM install is located. If you want you can store a folder named "ScummVM" within your D-Fend Reloaded folder and use relative paths so that it always knows to find it there.

SedrynTyros wrote:

So, when you use OpenGL scaling it upscales the image using a nearest-neighbor algorithm, so you get a nice, crisp version of the original image versus what happens when an image is upscaled using a bilinear algorithm, where it ends up looking like you're viewing it through a glass of water; all blurry, hard to look at for more than a few minutes without getting a headache (so it amazes me that some people prefer it this way).

The problem is that ScummVM changed the way it handles the image scaling, at least in the current SVN builds I use. It used to be that all you had to do was set "openGL_nearest" in the filters option. But now they've split the functionality into two settings. You need to set "opengl" as the filter but you also need to set "vga" under the "render_mode" setting. D-Fend Reloaded 1.4.4 currently appends the render mode setting as "render-mode" to the commandline rather than, say, adding the line "render_mode=vga" under the [scummvm] heading in the ini file. If you right-click one of your scummvm games and choose to view the config file you can see how D-Fend lays it all out, and right now it's borked; adding "render-mode=whatever" to the commandline of scummvm does squat and that's all D-Fend is able to do currently, probably because that's how it worked in older scummvm versions.

As to your second question, there's a setting in D-Fend that allows you to point to where your ScummVM install is located. If you want you can store a folder named "ScummVM" within your D-Fend Reloaded folder and use relative paths so that it always knows to find it there.

I'm using ScummVM version 1.9.0.2. I've played around with this a bit, and I think I've got it to work, at least with this build.

If you right-click the game, go to "ScummVM settings" and in the Custom settings box, add this:

[scummvm]
gfx_mode=opengl_nearest
render_mode=VGA
updates_check=0

It should work. I added updates_check=0 because every time I launched the game (after adding the other two parameters), it kept asking me about how often I wanted to update. I am not sure why it asks me in this scenario, versus when I have nothing in the Custom settings box. Though I might add, I got opengl_nearest to work without setting the render mode to VGA. I just let it stay as "default" and it seemed to work exactly the same. Is there any reason in particular why I shouldn't let render mode stay as default if it seems to work otherwise (when using opengl_nearest)?

In your opinion, is it preferable to play ScummVM games with the OpenGL (no filtering) option? Is that the only mode that gives you that crisp image that you're talking about?

Another question - when using opengl_nearest, is there any way to increase the size of the ScummVM window upon launch? I noticed that you can click and drag the window to make it whatever size you want, but I'd prefer to have it automatically be larger when I launch the game so I don't have to manually resize it and try to get it just right so black borders aren't showing.

lukeman3000 wrote:

I'm using ScummVM version 1.9.0.2. I've played around with this a bit, and I think I've got it to work, at least with this build […]
Show full quote

SedrynTyros wrote:

So, when you use OpenGL scaling it upscales the image using a nearest-neighbor algorithm, so you get a nice, crisp version of the original image versus what happens when an image is upscaled using a bilinear algorithm, where it ends up looking like you're viewing it through a glass of water; all blurry, hard to look at for more than a few minutes without getting a headache (so it amazes me that some people prefer it this way).

The problem is that ScummVM changed the way it handles the image scaling, at least in the current SVN builds I use. It used to be that all you had to do was set "openGL_nearest" in the filters option. But now they've split the functionality into two settings. You need to set "opengl" as the filter but you also need to set "vga" under the "render_mode" setting. D-Fend Reloaded 1.4.4 currently appends the render mode setting as "render-mode" to the commandline rather than, say, adding the line "render_mode=vga" under the [scummvm] heading in the ini file. If you right-click one of your scummvm games and choose to view the config file you can see how D-Fend lays it all out, and right now it's borked; adding "render-mode=whatever" to the commandline of scummvm does squat and that's all D-Fend is able to do currently, probably because that's how it worked in older scummvm versions.

As to your second question, there's a setting in D-Fend that allows you to point to where your ScummVM install is located. If you want you can store a folder named "ScummVM" within your D-Fend Reloaded folder and use relative paths so that it always knows to find it there.

I'm using ScummVM version 1.9.0.2. I've played around with this a bit, and I think I've got it to work, at least with this build.

If you right-click the game, go to "ScummVM settings" and in the Custom settings box, add this:

[scummvm]
gfx_mode=opengl_nearest
render_mode=VGA
updates_check=0

It should work. I added updates_check=0 because every time I launched the game (after adding the other two parameters), it kept asking me about how often I wanted to update. I am not sure why it asks me in this scenario, versus when I have nothing in the Custom settings box. Though I might add, I got opengl_nearest to work without setting the render mode to VGA. I just let it stay as "default" and it seemed to work exactly the same. Is there any reason in particular why I shouldn't let render mode stay as default if it seems to work otherwise (when using opengl_nearest)?

In your opinion, is it preferable to play ScummVM games with the OpenGL (no filtering) option? Is that the only mode that gives you that crisp image that you're talking about?

Another question - when using opengl_nearest, is there any way to increase the size of the ScummVM window upon launch? I noticed that you can click and drag the window to make it whatever size you want, but I'd prefer to have it automatically be larger when I launch the game so I don't have to manually resize it and try to get it just right so black borders aren't showing.

Yeah, I tried that already; it no workie. Adding a 2nd [scummvm] header seems to void some of the settings in the default one. It may work on the ScummVM version you're using but I've never used 1.9.0.2; it must be before the changes to render_mode that are present in the current daily builds. "opengl_nearest" isn't a valid selection any longer in the current builds. It's now just "opengl" with the nearest-neighbor scaling being moved to render mode. I want to use the current builds because they have updated Munt emulation that was added in December. So I've just been running ScummVM outside of D-Fend Reloaded. The long term fix for this is for the D-Fend Reloaded developer to change the way it handles the render_mode variable.

I think there are other scaling methods that will deliver the same crisp image, like 2x or 3x scaling. I prefer OpenGL because it's more flexible than using the integer scaling methods; you can resize the window to be whatever size you want with OpenGL or go fullscreen and have the image scale to fill your monitor's viewing area.

There were a few different opengl options in the older builds and I think one of them may have automatically created a larger window ... but I can't remember. opengl_nearest is the one I decided to go with and if you alt-enter to fullscreen it'll maintain the correct aspect ratio while filling your screen. If you want to see what the other filter options are you can launch the ScummVM client and look at them there.

SedrynTyros wrote:

Yeah, I tried that already; it no workie. Adding a 2nd [scummvm] header seems to void some of the settings in the default one. It may work on the ScummVM version you're using but I've never used 1.9.0.2; it must be before the changes to render_mode that are present in the current daily builds. "opengl_nearest" isn't a valid selection any longer in the current builds. It's now just "opengl" with the nearest-neighbor scaling being moved to render mode. I want to use the current builds because they have updated Munt emulation that was added in December. So I've just been runnning ScummVM outside of D-Fend Reloaded. The long term fix for this is for the D-Fend Reloaded developer to change the way it handles the render_mode variable.

There were a few different opengl options in the older builds and I think one of them may have automatically created a larger window ... but I can't remember. opengl_nearest is the one I decided to go with and if you alt-enter to fullscreen it'll maintain the correct aspect ratio while filling your screen. If you want to see what the other filter options are you can launch the ScummVM client and look at them there.

So, does the build that I'm using (which I think is the "latest stable" build?) have MUNT emulation, but just an older version?

I've only recently become aware of MUNT and the MT-32 and what it can mean for some of the Sierra games that I like to play (for example Space Quest 3 has incredible MT-32 music). I didn't know anything about this before. Now I have a special build of DOSBox with built-in MUNT support that I got from the Sierra help pages and I'm still figuring out exactly which games sound better with which sound drivers.

As it relates to ScummVM games, what's the story there? Does ScummVM come with MT-32/MUNT support by default and is pre-configured to run this way, or do I need to adjust some things in order to get the best sound experience in ScummVM? What exactly is the "best experience"?

ScummVM 1.9.0.2 has Munt 1.5.0 integrated into it. All the ScummVM builds have Munt now. The latest daily builds include Munt 2.0.1, but Munt 1.5.0 was pretty good. I haven't done a side-by-side comparison to see if the games I play are noticably better in Munt 2.0.1; I just wanted to use the latest version as it's usually an improvement over the old when it comes to Munt.

But yeah, all ScummVM builds include Munt ... but you'll need to have the Control and PCM ROMs, of course. Either the MT-32 or CM-32L ones will do (but the CM-32L will have additional sounds in certain games). You just plop those ROMs in the ScummVM folder and you're good to go ... well, you do need to configure the game to use MT-32 as the sound option too.

If I remember correctly, with Space Quest 3 you're going to miss out on some digital sound effects if you go with MT-32 for sound .... at least I think that's the case for that game ... I have it setup to use SoundBlaster emulation in my collection and I'm pretty sure that's the reason.

SedrynTyros wrote:

ScummVM 1.9.0.2 has Munt 1.5.0 integrated into it. All the ScummVM builds have Munt now. The latest daily builds include Munt 2.0.1, but Munt 1.5.0 was pretty good. I haven't done a side-by-side comparison to see if the games I play are noticably better in Munt 2.0.1; I just wanted to use the latest version as it's usually an improvement over the old when it comes to Munt.

But yeah, all ScummVM builds include Munt ... but you'll need to have the Control and PCM ROMs, of course. Either the MT-32 or CM-32L ones will do (but the CM-32L will have additional sounds in certain games). You just plop those ROMs in the ScummVM folder and you're good to go ... well, you do need to configure the game to use MT-32 as the sound option too.

If I remember correctly, with Space Quest 3 you're going to miss out on some digital sound effects if you go with MT-32 for sound .... at least I think that's the case for that game ... I have it setup to use SoundBlaster emulation in my collection and I'm pretty sure that's the reason.

Hmm... I'm pretty sure one of the options is MT-32 with Soundblaster or something like that, which is what I use (talking about the setup.exe of Space Quest 3). I noticed that with only MT-32 you don't hear Roger say "where am I".

So if I grab these files, do I need to change sound settings in ScummVM or is it automatically set up?

lukeman3000 wrote:

SedrynTyros wrote:

ScummVM 1.9.0.2 has Munt 1.5.0 integrated into it. All the ScummVM builds have Munt now. The latest daily builds include Munt 2.0.1, but Munt 1.5.0 was pretty good. I haven't done a side-by-side comparison to see if the games I play are noticably better in Munt 2.0.1; I just wanted to use the latest version as it's usually an improvement over the old when it comes to Munt.

But yeah, all ScummVM builds include Munt ... but you'll need to have the Control and PCM ROMs, of course. Either the MT-32 or CM-32L ones will do (but the CM-32L will have additional sounds in certain games). You just plop those ROMs in the ScummVM folder and you're good to go ... well, you do need to configure the game to use MT-32 as the sound option too.

If I remember correctly, with Space Quest 3 you're going to miss out on some digital sound effects if you go with MT-32 for sound .... at least I think that's the case for that game ... I have it setup to use SoundBlaster emulation in my collection and I'm pretty sure that's the reason.

Hmm... I'm pretty sure one of the options is MT-32 with Soundblaster or something like that, which is what I use (talking about the setup.exe of Space Quest 3). I noticed that with only MT-32 you don't hear Roger say "where am I".

So if I grab these files, do I need to change sound settings in ScummVM or is it automatically set up?

You need to configure the game to use mt32 sound.

I just checked and on the version of SpaceQuest III have (which I think game from the CD collection so probably the latest) the only sound option you have is Music. In most Sierra titles after this period you'd have a separate option for Music and Sound and could choose whatever driver to use for each. However, I think it's Space 1 VGA (the remake) where they give you the option to have MT32 + Soundblaster both in the same sound setting.

SedrynTyros wrote:

lukeman3000 wrote:

SedrynTyros wrote:

ScummVM 1.9.0.2 has Munt 1.5.0 integrated into it. All the ScummVM builds have Munt now. The latest daily builds include Munt 2.0.1, but Munt 1.5.0 was pretty good. I haven't done a side-by-side comparison to see if the games I play are noticably better in Munt 2.0.1; I just wanted to use the latest version as it's usually an improvement over the old when it comes to Munt.

But yeah, all ScummVM builds include Munt ... but you'll need to have the Control and PCM ROMs, of course. Either the MT-32 or CM-32L ones will do (but the CM-32L will have additional sounds in certain games). You just plop those ROMs in the ScummVM folder and you're good to go ... well, you do need to configure the game to use MT-32 as the sound option too.

If I remember correctly, with Space Quest 3 you're going to miss out on some digital sound effects if you go with MT-32 for sound .... at least I think that's the case for that game ... I have it setup to use SoundBlaster emulation in my collection and I'm pretty sure that's the reason.

Hmm... I'm pretty sure one of the options is MT-32 with Soundblaster or something like that, which is what I use (talking about the setup.exe of Space Quest 3). I noticed that with only MT-32 you don't hear Roger say "where am I".

So if I grab these files, do I need to change sound settings in ScummVM or is it automatically set up?

You need to configure the game to use mt32 sound.

I just checked and on the version of SpaceQuest III have (which I think game from the CD collection so probably the latest) the only sound option you have is Music. In most Sierra titles after this period you'd have a separate option for Music and Sound and could choose whatever driver to use for each. However, I think it's Space 1 VGA (the remake) where they give you the option to have MT32 + Soundblaster both in the same sound setting.

Interesting. Here is what my Space Quest III setup looks like. As you can see, it has an option for Roland MT-32 with Sound Blaster...

How does one know which option is the best to choose for any given game?

Interesting. This is my driver selection:

As far as I remember, the MTBLAST.DRV file doesn't get installed with Space Quest III so I'm wondering if it actually works properly with that game, allowing both MT-32 music and digital sound effects.

EDIT:

See this discussion from 2005:

http://www.spacequest.net/topic/876-space-que … ch-not-working/

Looks like you're using a fan-hacked driver. I'll have to track that down and try it.

I think that I originally stumbled upon that driver in the steam forums for the Space Quest series. In fact, I think that Musically Inspired was involved in the discussion there and he may have posted the driver himself. But it looks like you can get it from running the SQ3 with MUNT installer (at the end of the first post), based on that discussion you linked to.

Although I think I ran the VU 2006 SQ series installer from Collector''s website more recently, so it's possible it might be included in that as well.

Yeah, it appears the hacked driver was posted on this site:

Sierra/Dynamix sound driver hacking

After playing around with D-Fend Reloaded and ScummVM a little more I can see how some updates would be nice. It's a little disconcerting that the developer of this program hasn't visited this site for nearly a year now...

Hi guys!
Anybody can share the D-Fend collection?

Maybe there is a repository of screenshots and other things, because the built-in repository is almost empty.

Once again came the nostalgia, I wanted to gather a beautiful collection of Dos-games, and I'm surprised that there is no single resource for such things.
Only handmade to add information to the collection...

I googled on this things (d-fend collection, repos etc), but found nothing.

lukeman3000 wrote:

After playing around with D-Fend Reloaded and ScummVM a little more I can see how some updates would be nice. It's a little disconcerting that the developer of this program hasn't visited this site for nearly a year now...

Yeah, I've just been running my SCUMMVM games using the SCUMMVM interface for now. I don't play many SCUMMVM games to begin with and using D-Fend to launch them was a minor convenience that I live with not having.

lukeman3000 wrote:

After playing around with D-Fend Reloaded and ScummVM a little more I can see how some updates would be nice. It's a little disconcerting that the developer of this program hasn't visited this site for nearly a year now...

I am afraid that this project is dead like dosbox daum. The last visit of alexander on vogons since nearly two years (april 2016).