I obviously don't have any influence on dgVoodoo2's development... but I have to ask: what is your use case here? The way I see it you always want to play games at a specific resolution (your display's native resolution or the game's native resolution) so in an inclusion list you have to add two entries (menus if static + game resolution) at most. To exclude resolutions until you only get the ones you want surely would result in a longer list. I don't really see how that could possibly be any more convenient.

A way to change resolution enumeration order (like DXGL has: https://www.dxgl.info/help/configuration/disp … rt-video-modes/), might be an idea, but Dege has stated before he doesn't want unnecessary confusing options and there are very very few games where this is necessary. I've run into like, 5 of them and DisableDefaultResolutions+ExtraEnumeratedResolution is already a perfect workaround for them.

Sorry ZellSF but you missed my "use case" completely. Yes, I can play game if I do as I described...but the point is I can't make this **universal** fix. Everytime I want to start this on another computer one has to "read how-to-do-it manual" to make this work. I like to repack my old games for preservation (if I wanted to play Forsaken I would use free ProjectX option 🙁..). I can't use ExtraEnumeratedResolutions in my repack if I want setup to be generic as it can be...for example, if my kid wanted to install this on pc with different monitor he must *manually* edit configuration and he must know where. If I can exclude a few resolutions I would exclude ONLY "EXOTIC" ONES, (for example 1768x992 ( !) ). With this excluded I can have Forsaken (and it is not the only old game with this problem!) setup display ALL resolutions and one can pack it with dgvoodoo.config that need no changes whatsoever, just "plug-n-play". Maybe reason for my post is more clear now...
Regards

Sorry I missed the part where you wanted a configuration that wasn't hardware specific. Exclusion lists still doesn't make any sense though.

1: Those exotic resolutions are enumerated by your display. Another display might give different exotic resolutions you haven't though about.

2: Those "exotic" resolutions are probably enumerated by your display because they're resolutions that actually are somewhat commonly in use. It could be a semi-common laptop resolution, in which case your exclusion list idea could mean someone wouldn't be able to play the game at native resolution.

3: Modern graphic drivers can add custom resolutions, so a user might have added all kinds of exotic resolutions you haven't considered and no monitor would enumerate.

What would make a lot more sense to me would be to add a "native" option to be used in ExtraEnumeratedResolutions, so you could have this:

1ExtraEnumeratedResolutions          =  640x480,1280x720,1920x1080,native

That way you have 640x480 if the game needs it for menus (for example), 1280x720 & 1920x1080 for fallbacks if your system is too weak to render at native resolution and native resolution last. What would be missing to you in this scenario?

ZellSF wrote:

What would make a lot more sense to me would be to add a "native" option to be used in ExtraEnumeratedResolutions, so you could […]
Show full quote

What would make a lot more sense to me would be to add a "native" option to be used in ExtraEnumeratedResolutions, so you could have this:

Copy code to clipboard

1ExtraEnumeratedResolutions          =  640x480,1280x720,1920x1080,native

That way you have 640x480 if the game needs it for menus (for example), 1280x720 & 1920x1080 for fallbacks if your system is too weak to render at native resolution and native resolution last. What would be missing to you in this scenario?

As I said in my first post, "of course there could be better solutions", this is fine, I agree, your idea is very acceptable. I already implemented something like this in my repack, setup will pick my current desktop resolution and write in dgvoodoo.config setting that values during installation.. 😎

BTW, there is only one problem in current implementation of ExtraEnumeratedResolutions (in general, not related to Forsaken) - resolution noted there are reported to game/program even if your graphic card/monitor does not support it at all 🙁 For example, I could write ExtraEnumeratedResolutions=1920x1080,1920x1200 and ingame settings will report 1920x1200 resolution even if my monitor is only FullHD, so 1920x1080 max. 🙁 Maybe I'm wrong but it seems to me that ExtraEnumeratedResolutions should have "safety switch" that will check if that noted resolution is valid for current run.. something like ExtraEnumeratedResolutionsCheck=true setting that will prevent picking up wrong resolutions.

Regards

If you use any of the ScalingMode settings except "unspecified", "centered" and "stretched" dgVoodoo2 will internally scale any resolution, so supported resolutions by display/GPU is irrelevant. That's what the ExtraEnumeratedResolutions was for, DisableDefaultResolutions was a feature added later.

It's actually preferable to use "stretched_ar" ScalingMode where applicable (some games have mouse issues with this) anyway, since some GPU driver configurations will distort aspect ratio otherwise.

Though the "unspecified", "centered" and "stretched" options should maybe check if ExtraEnumeratedResolutions are valid Dege?

ZellSF wrote:

Though the "unspecified", "centered" and "stretched" options should maybe check if ExtraEnumeratedResolutions are valid Dege?

One of the nicest feature of DXGI (part of DX11) is that it supports any resolution in full screen mode so resolutions larger than the native one should still work. Somehow. 😀
Using a "supported" resolution along with a "supported" refresh rate only means that DXGI doesn't have to insert proxy buffers with extra timing mechanism when working in full screen mode - the video card hw can manage that all ending up in the most optimal solution.

ZellSF wrote:

What would make a lot more sense to me would be to add a "native" option to be used in ExtraEnumeratedResolutions, so you could have this:
CODE: SELECT ALL
ExtraEnumeratedResolutions          =  640x480,1280x720,1920x1080,native

It's a good idea, but: native resolution cannot be detected, that's why I use the term 'desktop resolution' in dgVoodoo. But even 'desktop resolution' is deceptive because of the difference in aspect ratios of the desktop and the games.
I think I either

1. should enable 'max', 'max_isf" and so on in ExtraEnumeratedResolutions like for forced resolutions.
2. Or enable defining the max number of resolutions enumerated if we approach from the 'excluding' side.
Say, the video card reports 100 supported resolutions but suppose we have 40 as an enabled maximum. Then 40 could be evenly chosen from the ascending order of the reported 100, taking care for most common ones like 1680x1050 and such.

Thank you very much for your reply Dege! However I like my "excluding" idea even less now...defining limit in ascending order will only help for games that crash on high number of reported resolutions (and then we will probably be stuck on lower playable resolution than it can be achieved)...
But it will not help in Forsaken case at all (if I understood your 2nd option right) because game will still pick max 32bit resolution as 800x600x32 (it picks resolutions in ascending order, first all 16bit then 32bit and it will stop at 800x600x32 in my case. I presume that with different graphic card or monitor it will stop at earlier resolution or later. Better not to implement this option at all. When I was talking about exclusions I was thinking about filtering out "not-so-common-resolutions-for-that-oldgames-times" but I'm more or less convinced now that this approach is not "universal" as I thought it was.

Anyway...your 1. option is looking very promising to me..If I understood it correctly you are considering possibility to add max,max_isf,max_fhd etc. keywords **along** with other resolution in this list? So, for example, I can write ExtraEnumeratedResolutions=640x480,1280x720,max ? That will probably work very good in many cases, thank you for considering this.

P.S. As we are already on the subject, one more suggestion if it's not too much - can you remove or at least increase ExtraEnumeratedResolutions limit of 8?

Thanks,
regards

Ok, excluding resolutions isn't a good idea, I must admit too. Enabling and disabling certain bit depths (8, 16, 32) however is a handy one.

ggms wrote:

Anyway...your 1. option is looking very promising to me..If I understood it correctly you are considering possibility to add max,max_isf,max_fhd etc. keywords **along** with other resolution in this list? So, for example, I can write ExtraEnumeratedResolutions=640x480,1280x720,max ? That will probably work very good in many cases, thank you for considering this.

Yes, that's what I thought of. One thing didn't came to my mind at the same time. 'max' and its counterparts are relative resolutions in the sense that their calculated value are based on desktop resolution and an aspect ratio.
Aspect ratio is defined by the application resolution. But ExtraEnumeratedResolutions defines application resolutions so they can only be absolute ones. But, I think we could assume an aspect ratio of 4:3 here by default.

ggms wrote:

P.S. As we are already on the subject, one more suggestion if it's not too much - can you remove or at least increase ExtraEnumeratedResolutions limit of 8?

I thought 8 would be enough as ExtraEnumeratedResolutions was intended for defining just some extra resolutions, like 400x300 for Jazz Jack Rabbit, or 320x200, 320x240, 640x400, 640x480 for Micro Machines v3 and such.

Now I think the best would be something like this:
[code]DefaultEnumeratedResolutions = [none | classics | all] ; this property would replace DisableDefaultResolutions
ExtraEnumeratedResolutions = 640x400, ..., max, max_qhd@60 ; increased number of them, say 16, extended with the usage of some of the usual keywords
EnumeratedResolutionBitdepths = 8, 16, 32 ; or any subset of that list[/code]
I'd like to release a little patch version for 2.55, containing some fixes. My only concern about this reso thing is that I released a small API package for 2.55 so the configuration structure of dgVodoo became public.
I should keep compatibility with that. Or, I'll just simply change it, regarding that I doubt anybody is relying on that currently.

Dege wrote:

ggms wrote:

Anyway...your 1. option is looking very promising to me..If I understood it correctly you are considering possibility to add max,max_isf,max_fhd etc. keywords **along** with other resolution in this list? So, for example, I can write ExtraEnumeratedResolutions=640x480,1280x720,max ? That will probably work very good in many cases, thank you for considering this.

Yes, that's what I thought of. One thing didn't came to my mind at the same time. 'max' and its counterparts are relative resolutions in the sense that their calculated value are based on desktop resolution and an aspect ratio.
Aspect ratio is defined by the application resolution. But ExtraEnumeratedResolutions defines application resolutions so they can only be absolute ones. But, I think we could assume an aspect ratio of 4:3 here by default.

I think such a feature would be useful for 16:9 games too? I'm not sure what you mean that you can assume a 4:3 aspect ratio.

Not that I actually would use such a feature.

Speaking of this limiting resolutions and bit depths business I would like to mention Army Men RTS. It is programmed to list the first 22 available resolutions, and since it shows 16 bit ones too, the options menu shows only up to 1280x1024 32-bit. Other resolutions can be forced with dgVoodoo, so it's not really a problem, but I just wanted to mention it.

antrad wrote:

Speaking of this limiting resolutions and bit depths business I would like to mention Army Men RTS. It is programmed to list the first 22 available resolutions, and since it shows 16 bit ones too, the options menu shows only up to 1280x1024 32-bit. Other resolutions can be forced with dgVoodoo, so it's not really a problem, but I just wanted to mention it.

It's not only programmed to just list the first 22 resolutions, it's also specifically programmed not to list any resolutions exceeding 1280x1024 (and if your display doesn't support lower ones it will just crash).

The latter of those two limitations is actually easy to fix with a hex editor (both for Army Men RTS and Dark Reign 2), and with DisableDefaultResolutions + ExtraEnumeratedResolutions you can make higher resolutions fit into the 22 resolution limit easily.

It's pretty pointless though. The UI gets way too tiny.

ZellSF wrote:

Dege wrote:

ggms wrote:

Anyway...your 1. option is looking very promising to me..If I understood it correctly you are considering possibility to add max,max_isf,max_fhd etc. keywords **along** with other resolution in this list? So, for example, I can write ExtraEnumeratedResolutions=640x480,1280x720,max ? That will probably work very good in many cases, thank you for considering this.

Yes, that's what I thought of. One thing didn't came to my mind at the same time. 'max' and its counterparts are relative resolutions in the sense that their calculated value are based on desktop resolution and an aspect ratio.
Aspect ratio is defined by the application resolution. But ExtraEnumeratedResolutions defines application resolutions so they can only be absolute ones. But, I think we could assume an aspect ratio of 4:3 here by default.

I think such a feature would be useful for 16:9 games too? I'm not sure what you mean that you can assume a 4:3 aspect ratio.

Not that I actually would use such a feature.

I thought that most if not all old DX games were coded for 4:3 aspect ratio because that was the standard back then. But, widescreen-patched ones this doesn't stand for, indeed.
Also, meanwhile I realized that the only keyword making sense for extra enum resos is 'max'. Max_QHD means 1920x1440 in fact, ISFs cannot be interpreted here, etc.

So, for keywords, what about the logic that we could define the max resolution for a given aspect ratio, and also its halved. tierced, etc. variants. For example, 'max_4_3', 'max_4_3_div2'. Or it all is unneeded and doesn't worth anything? 😀

So, for keywords, what about the logic that we could define the max resolution for a given aspect ratio, and also its halved. tierced, etc. variants. For example, 'max_4_3', 'max_4_3_div2'. Or it all is unneeded and doesn't worth anything? 😀

I think this is overkill and it will only make confusion...max is all that is needed IMHO.

DefaultEnumeratedResolutions = [none | classics | all]

sound perfect

EnumeratedResolutionBitdepths = 8, 16, 32

one thing only about this - if you implement it add all keyword...of course in 99% cases it will be equivalent to 8,16,32 but all is more self-explanatory and it could be default value so EnumeratedResolutionBitdepths=all unless somebody needs to change it to 32,8 or whatever...

ggms wrote:

So, for keywords, what about the logic that we could define the max resolution for a given aspect ratio, and also its halved. tierced, etc. variants. For example, 'max_4_3', 'max_4_3_div2'. Or it all is unneeded and doesn't worth anything? 😀

I think this is overkill and it will only make confusion...max is all that is needed IMHO.

If max was all that's needed you would have no way to account for different aspect ratio games (4:3 and 16:9). There's a ton of old games that either have widescreen hacks or support widescreen "natively".

The divisions Dege proposes are IMO useless for plain bilinear scaling (1280x720 bilinearly upscaled to 2560x1440 doesn't look any better than 1366x768 bilinearly upscaled to 2560x1440 for example), but would be essential if you want to combine it with resolution forcing for games that need nearest scaling of UI elements to look good or integer scaling for 2D games with multiple resolution support. I don't know how common either of those scenarios are.

Integer scale factor isn't exposed via the UI, so that's a non-issue for you (but still might be relevant for others), but resolution forcing is exposed via the UI. Your acquaintance might opt to force the rendering resolution to his desktop resolution in the UI, but if you've allowed non-divisible resolutions in ExtraEnumeratedResolutions he might choose an ingame resolution that will look really bad because of that.

Ok, it seems that I did not understood what Dege meant with "max"...I thought that max is something like "max monitor resolution" or "current desktop resolution".... Because current desktop resolution is only thing what I would like to have here. I can see the use of settings you and Dege are mentioning but that's beyond my reasons for starting this thread, I would be satisfied with current desktop resolution keyword in ExtraEnumeratedResolutions, other options are just welcomed bonus..

Ok Guys, thanks for the feedback and thoughts.
I think keywords are only useful for giving the possibility for restricting the number of resos in a hardware-independent way.
For all other cases, one can edit the config file and type the resolutions for their current display hardware.

So, to keep it all simple, I think 'max_4_3' and 'max_16_9' (meaning the max resolution for the given aspect ratio, based on the desktop resolution) could be enough.

How did you install Forsaken on Windows 10?

I'm trying to run it on Windows 10, but I can't. I've installed it with compatibility mode enabled (Windows 95) and applied the Patch 1.01. So, I've copied D3DImm.dll and DDraw.dll to the installation folder. Windows asked me to install DirectPlay and to restart the computer. Done. The game window opens and I can see all the splash screens (widescreen), including the intro movie. But, after that, the game crashes. I've tried every renderer (from software to 512MB, download here).

Espreitador wrote:

How did you install Forsaken on Windows 10?

Yes, it's a pain to install it...you can't install it on 64-bit Windows directly from CD because of 16-bit InstallShield setup but I guess you replaced that setup.exe with 32 bit version already. No compatibility mode was needed during install BUT install must be run as admin. Also, ForsakenHW.exe, ForsakenSW.exe and Forsaken.exe MUST be set to started with "Run this program as administrator". I'm not sure if this was needed but I also used .SDB (created with Microsoft Compatibility Administrator) for ForsakenHW.exe and ForsakenSW.exe that enabled "VirtualRegistry" option. Google on how to do that if required (can't really remember why I set this compatibility mode..).
For dgVoodoo 2.55 you need only DDraw.dll and D3DImm.dll with default dgVoodoo settings. (you will get limited number of 32bit resolutions with default settings but it should work, discussed in this thread..)
Forget that opt files, setting old Forsaken engine to 512MB option is overkill, create your own dgVoodoo.opt file in notepad, write:
TriLinear
MipMap
pw <yourdesktopwidth> (without <>, for example 1920)
ph <yourdesktopheight> (without <>, for example 1080)
ScreenMemory 65536
It shoud work, at least on my nVidia card. My guess is that you did not start .exes as admin, start everything as admin including setup...
Regards

ggms wrote:

Yes, it's a pain to install it...you can't install it on 64-bit Windows directly from CD because of 16-bit InstallShield setup b […]
Show full quote

Espreitador wrote:

How did you install Forsaken on Windows 10?

Yes, it's a pain to install it...you can't install it on 64-bit Windows directly from CD because of 16-bit InstallShield setup but I guess you replaced that setup.exe with 32 bit version already. No compatibility mode was needed during install BUT install must be run as admin. Also, ForsakenHW.exe, ForsakenSW.exe and Forsaken.exe MUST be set to started with "Run this program as administrator". I'm not sure if this was needed but I also used .SDB (created with Microsoft Compatibility Administrator) for ForsakenHW.exe and ForsakenSW.exe that enabled "VirtualRegistry" option. Google on how to do that if required (can't really remember why I set this compatibility mode..).
For dgVoodoo 2.55 you need only DDraw.dll and D3DImm.dll with default dgVoodoo settings. (you will get limited number of 32bit resolutions with default settings but it should work, discussed in this thread..)
Forget that opt files, setting old Forsaken engine to 512MB option is overkill, create your own dgVoodoo.opt file in notepad, write:
TriLinear
MipMap
pw <yourdesktopwidth> (without <>, for example 1920)
ph <yourdesktopheight> (without <>, for example 1080)
ScreenMemory 65536
It shoud work, at least on my nVidia card. My guess is that you did not start .exes as admin, start everything as admin including setup...
Regards

Thank you so much. I was running .exes as admin. My mistake was the compatibility mode (and maybe opt file). I disabled Win95 compatibility mode and voilà... It's working now. Compatibility is not only unnecessary, but also a problem.