Dege wrote:

VEG wrote:

Hi there! I'm an author of NFS3 Widescreen patch. This patch supports extended Glide API which has ability to use modern resolutions. Discussion about this API extension: http://www.zeus-software.com/forum/viewtopic. … hp?p=4397#p4397
Can this API extension be supported by dgVoodoo? It would be very nice.

Yes, I think I could include that extension in the next build, thanks! 😎

Be noticed that we have changed that extension a little and it's described in the next messages (1 and 2). Maybe it will be good to write separate documentation for this extension.

Summary:
USING EXTENDED RESOLUTIONS
- grSstWinOpen( resolution<=0xFF, refresh<=0xFF ) - original behavior using predefined constants
- grSstWinOpen( resolution=width|(height << 16), refresh=(ref<<16) ) - resolution and refresh parameters in an extended format (both greater than 0xFF)

LISTING EXTENDED RESOLUTIONS
- grQueryResolutions( resTemplate.resolution=0x7FFF7FFF and resTemplate.refresh=0x7FFF7FFF, NULL ) - get the structure size (extended format)
- grQueryResolutions( resTemplate.resolution=0x7FFF7FFF and resTemplate.refresh=0x7FFF7FFF, pointer ) - get resolutions list in a GrResolution format, the difference is we will use width|(height << 16) for .resolution and (ref<<16) for .refresh fields instead of predefined constants

Thank you in advance.

I can't speak polite when talking about antivirus crap...

I think we've reached the point where malware moves so quickly that the only sensible way for inexperienced users is to assume anything that might be a virus is one. Trouble is, explaining that false positives are very common is difficult to do.

You need to enable 'Fast video memory access' for that game. Otherwise it's slow, indeed.

Awesome I will try that, thanks.

Another suggestion. Maybe you will like it.

It will be nice if dgVoodoo could read dgVoodoo.conf from a directory from which glide3x.dll was loaded. I would like to move all thrash video drivers (in NFS3) to “drivers” directory. It will be possible to create directory drivers/dgvoodoo, copy here glide3x.dll and voodoo2.dll (NFS3 thrash video driver) files, and use it. It will be very nice if user will be able to put dgvoodoo.conf into this directory. It will allow to keep this group of files together.

It is very easy to detect from which directory glide3x.dll was loaded. Simply call GetModuleFileName with hInstance of current DLL (1st argument of DllMain) and check if in this directory dgvoodoo.conf is presented.

Possible priorities of config files:
1. Current directory of application
2. Directory of loaded glide3x.dll file
3. Directory in the AppData/Roaming

Another suggestion is using of ini files for initialization instead of binary config files 😀 It will allow to edit these files from text editor, compare different config files and other useful things.

And last suggestion about windowed mode. It will be nice if dgVoodoo will keep game's window centered. When game tries to set resolution which is exactly the same as system resolution it will be nice if dgVoodoo will use borderless “fullscreen” window in this case (but it will be still windowed mode, it may be useful in many cases, e.g. when the game doesn't support minimizing, it will prevent losing textures). For example, this behaviour is done in wndmode.dll+ddraw.dll: https://bitbucket.org/veg/tinyddraw/downloads/wndmode.zip (DirectDraw wrapper based on D3D windower).

Tried Desperados with fast memory access option turned on, still has serious performance issues when you turn on the enemy vision indicators (the telescope like icon in the bottom right).

BuckoA51 wrote:

Tried Desperados with fast memory access option turned on, still has serious performance issues when you turn on the enemy vision indicators (the telescope like icon in the bottom right).

Is v-sync off (both in drivers and dgVoodoo2)?

lil update: F1 2000 and F1 Championship Season 2000 with both work with dgVoodoo, but only in software mode (as the config exe doesn't detect dgVoodoo as a hardware device).

VEG wrote:

LISTING EXTENDED RESOLUTIONS
- grQueryResolutions( resTemplate.resolution=0x7FFF7FFF and resTemplate.refresh=0x7FFF7FFF, NULL ) - get the structure size (extended format)
- grQueryResolutions( resTemplate.resolution=0x7FFF7FFF and resTemplate.refresh=0x7FFF7FFF, pointer ) - get resolutions list in a GrResolution format, the difference is we will use width|(height << 16) for .resolution and (ref<<16) for .refresh fields instead of predefined constants

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)?
Enumerating only the really supported ones would be sensible, but on the other hand, dgVoodoo virtually supports any resolution, either in windowed mode or fullscreen (scaled by the system to the closest available physical resolution).

BuckoA51 wrote:
Tried Desperados with fast memory access option turned on, still has serious performance issues when you turn on the enemy vision indicators (the telescope like icon in the bottom right).

Is v-sync off (both in drivers and dgVoodoo2)?

Yes, vsync must be off, or else you get performance penalty when moving the mouse cursor, in fact the game stalls because all it does is update the screen synchronizing it to the vertical refresh.
It's the same issue as with Icewind Dale II.

Is any solve for RALLY CHAMPIONSHIP low fps?
Without voodoo have 40-50fps but with only 20-30fps

I think I got messed up with these Rallies earlier... 😀
When you mentioned it for the first time I thought of International Rally Championship which works fine for me, sorry.
Now I have a Rally Championship 2000 and indeed, I don't get 60fps with dgVoodoo but only 30-50. It works at full speed natively.
This game has a buffer-locking issue, it cannot be workarounded with the current version. 🙁
I think the solution is to improve the video memory access ('Fast video memory access') further in the future like it is done in Glide.

Dege, any chance of looking at F1CS2000 demo I mentioned on the last page? It only detects dgVoodoo as a software device, same issue affects the full game and F1 2000 (the earlier version).

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 😀

VirtuaIceMan wrote:

Dege, any chance of looking at F1CS2000 demo I mentioned on the last page? It only detects dgVoodoo as a software device, same issue affects the full game and F1 2000 (the earlier version).

Just looked at it. No hw devices because this game identifies they by name, and dgVoodoo uses different device names for DX6-7 than MS. 😵
Anyway, if I set it to DX5-style in the code then the game menu works but it crashes when I want to enter a quick race. It also crashes natively, don't know why, for the time being.

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 😀

Well, OK. 😀

It is very easy to detect from which directory glide3x.dll was loaded. Simply call GetModuleFileName with hInstance of current D […]
Show full quote

It is very easy to detect from which directory glide3x.dll was loaded. Simply call GetModuleFileName with hInstance of current DLL (1st argument of DllMain) and check if in this directory dgvoodoo.conf is presented.

Possible priorities of config files:
1. Current directory of application
2. Directory of loaded glide3x.dll file
3. Directory in the AppData/Roaming

Ok, this one could fit into the impl because I don't see any practical situation that it sets against. But of course this applies to all other components, Glide, DX.

Another suggestion is using of ini files for initialization instead of binary config files 😀 It will allow to edit these files from text editor, compare different config files and other useful things.

Perhaps it would be cool for programming goals or sg, but a GUI is more intuitive for an average user (or even a GUI is too complicated - don't get me wrong but I don't know why many users think they must change the default configuration before running anything for the first time, dgVoodoo is designed to work out-of-the-box without configuring.)
Anyway, I don't want to bother with it for now, unfortunately there are more serious issues around I would like to address first.

And last suggestion about windowed mode. It will be nice if dgVoodoo will keep game's window centered. When game tries to set resolution which is exactly the same as system resolution it will be nice if dgVoodoo will use borderless “fullscreen” window in this case (but it will be still windowed mode, it may be useful in many cases, e.g. when the game doesn't support minimizing, it will prevent losing textures). For example, this behaviour is done in wndmode.dll+ddraw.dll: https://bitbucket.org/veg/tinyddraw/dow ... ndmode.zip (DirectDraw wrapper based on D3D windower).

But borderless window is not even windowed mode... 😀
Losing textures only affects DX games, but it shouldn't be a problem because dgVoodoo
- either emulates lost mode (the default) but includes an auto-recovery mechanism if the game is buggy
- or doesn't emulate lost mode (when Alt-Entering for changing display mode is enabled), the video memory is always available towards the application

Outlive actually has a demo. It's not important (mediocre game that works perfectly natively anyway), but it's probably only a simple check you're missing:
http://www.fileplanet.com/56536/download/Outlive-Demo

Dege wrote:

But borderless window is not even windowed mode... 😀

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):

Of course it is not a necessity, it's just an idea. Currently for games like NFS3, which uses exclusive DirectInput mode, windowed mode has more serious problem: user can't move this window because as soon as mouse pointer turn out over the window title it disappears and caught by DirectInput. But windowed mode is very useful for debugging and thanks for your hard work I could debug and investigate internals of the NFS3 😀

Dege wrote:

VirtuaIceMan wrote:

Dege, any chance of looking at F1CS2000 demo I mentioned on the last page? It only detects dgVoodoo as a software device, same issue affects the full game and F1 2000 (the earlier version).

Just looked at it. No hw devices because this game identifies they by name, and dgVoodoo uses different device names for DX6-7 than MS. 😵
Anyway, if I set it to DX5-style in the code then the game menu works but it crashes when I want to enter a quick race. It also crashes natively, don't know why, for the time being.

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.

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.

I goofed on Desperados, sorry, when I changed my configuration file I accidentally placed it in the folder with the launcher, not the game itself. With "Fast video memory access" turned on the game does run pretty well.

Croc - Legend of the Gobbos (D3D version) also works well!

Folks asking for borderless window mode, you might find it useful to know that when a game runs with dgVoodoo2 you can use the in-game overlay Evolve (evolvehq.com). It supports all games (you can add your own custom rule for any that aren't supported yet) and lets you access web browser, chat (Yahoo, ICQ, Jabber, Steam) and various other useful things, pretty much whatever you'd need to do, without the need to have desktop clutter when you're actually playing.

ZellSF wrote:

Outlive actually has a demo. It's not important (mediocre game that works perfectly natively anyway), but it's probably only a simple check you're missing:
http://www.fileplanet.com/56536/download/Outlive-Demo

This games uses OLE32 to create a DDraw object (CoCreateInstance) so it's incompatible with dgVoodoo... 🙁
I don't know how to workaround these cases, I don't want to create an installer which replaces system files, etc.
I think the simpliest way would be creating a small ole32 wrapper dll but I don't want to target this for the time being.

It should be possible to hook CoCreateInstance on init in your d3d wrapper dll if required by a program. There are a lot of libraries that make this a painless process (detours, easyhook etc.).

Caveat 1: It's not exactly best practice like recommended by MS to do something like that in a dll init routine, which may lead to issues if functions used by the hooking library aren't available yet. But on the other hand this would ensure that the hook is installed before CoCreateInstance is called by the program in most cases.

Caveat 2: If a game uses LoadLibrary/Ex(A/W) to get CoCreateInstance, things get more complicated as you would also have to hook LoadLibrary etc.

dosmax wrote:

It should be possible to hook CoCreateInstance on init in your d3d wrapper dll if required by a program. There are a lot of libraries that make this a painless process (detours, easyhook etc.).

Caveat 1: It's not exactly best practice like recommended by MS to do something like that in a dll init routine, but on the other hand this would ensure that the hook is installed before CoCreateInstance is called by the program in most cases.

Caveat 2: If a game uses LoadLibrary/Ex(A/W) to get CoCreateInstance, things get more complicated as you would also have to hook LoadLibrary etc.

Yes, hooking is fine in general, but the problem here is that CoCreateInstance is called before my ddraw.dll gets loaded (if it get at all). CoCreateInstance resolves the ole object guid to a registered dll (by the registry) and loads that dll, make it create the appropriate object, etc., so CoCreateInstance always find the native ddraw.
So the only way would be a tiny ole32 wrapper dll, but I don't want to duplicate system dlls, it could be confusing to the users.

What about a loader/injector that starts the game suspended and injects your ddraw.dll (or an extra .dll with the hook) before allowing it to run? With some luck this way the .dll may get initialized before CoCreateInstance is ever called. Not sure about that though. The registry issue may be solvable by hooking the function that is used to read the registered .dll path which would have to return the path to your ddraw.dll instead of the system path. Admittedly quite a few 'mays', but maybe worth a try.

After PM'ing dege regarding this, I discovered issues with Startopia's 1.02 patch when using dgVoodoo 2's DirectX emulation are caused by the game not recognizing dgVoodoo 2's virtual GPU and forcing the game into a safe mode, resulting in the loss of certain rendering features - most notably real-time shadows. You'll need to modify a file called CardID.tom in the game's root directory and comment out all the tweaks it makes for "Unknown" cards.