Dege wrote:
Ok, I have read your conversation with Zeus about the new way extended resolutions are to be handled.
One little thi […]
Show full quote
Dege wrote:
Ok, I have read your conversation with Zeus about the new way extended resolutions are to be handled.
One little thing however isn't clear for me, maybe it's not important:
Should the extended method enumerate the legacy Glide resolutions (like 400x256) too, or just the ones the adapter supports (DX-like enum)?
Yes, it's just like DirectX enum. When program uses extended API it means that this program supports modern resolutions and would like use it instead of legacy ones. Also, I'm hiding resolutions lower than 640×480 in the my patch 😀
Ok, I've just implemented it. Tried with your patch and seems to work OK. 😎
The only flaw is that I can't try it on a widescreen monitor at the moment (tomorrow I will). 🤣
There are however some considerations with these extensions that I must take into account to finish it completely.
Since 3Dfx card type is an integral part of dgVoodoo and so the implementation always checks if there is enough on-board videomemory for a given resolution, and, organization of video memory can be tiled (buffer stride is always 1024 pixel) or unified (UMA) according to the card type, this extension can only be used with dgVoodoo if 'Other greater' is set up for the emulated card type. This card type means a freely configurable one in fact, +I don't want to mess with tiled layout when larger than 1024xsomething resolutions are present along with lower ones, and anyway, it would be inconsequential to use hiperlarge resolutions on a Voodoo1 or Voodoo2. 😀
So, for the extensions the lib will not check the amount of onboard videomemory.
When game sets same resolution as used in system, game's window can't fit on screen with borders. Forced centering (when ingame resolution is changed) of the window + hiding borders when they doesn't fit screen might be useful 😀
This mode allows to user do this thing without minimizing game's window (press win to show taskbar, choose IM window, reply, click on game's “fullscreen” window and play further):
Hmmm.... I'm very used to the fact that I always use 2 monitors. One for the game and one for the rest, browser, thisandthat... 😀
(But of course mainly for debugging graphics, it would be nearly impossible otherwise.)
But with one monitor this can indeed be a problem, it all is not so bad idea. I will consider this, after all a there is room for a 'borderless, centered' option on the General tab.
I found it could be crash happy using software mode, I ended up deleting the contents of the savegame folder (I think) and it behaved better after that. Before that/the other day it crashed if I turned up texture quality/model quality too high, but both F1 2000 and F1CS2000 work fine in dgVoodoo software now maxxed out. However in software mode the rain spray effects are not see through, so you can't drive! n.b. that's on my Nvidia 980.
I think I will have to investigate this game further as the crash doesn't seem to be wrapper-related at first glance.