Spec Release dgVoodoo version (with Debug Layer)

General information and assistance with dgVoodoo.

Spec Release dgVoodoo version (with Debug Layer)

Postby Dege » 2017-10-23 @ 18:56

Debug layer is about

1) giving feedback to the user about what currently happening, potential error conditions and, how dgVoodoo is driven by the application at all
2) helping debugging a given application/game by the (extensive) feedback and opening the possibility to break into the debugger

dgVoodoo currently has 2 main levels for debug feedback

a) Simple messages with 3 subtypes which can be disabled or associated with a debugger break
INFO: harmless message about various events like creating/releasing an API object, reading a config file, loading a module, etc.
WARNING: a message about a potential error condition
ERROR: a message about an API driving error or an internal error of dgVoodoo. The latter is fatal, while the prior one may be normal.

b) Tracing
Tracing means the full logging of API calls made to dgVoodoo and some additional information of dgVoodoo internals.
Level 0 - Tracing disabled
Level 1 - Logging of API calls
Level 2 - Logging of API calls + some additional info

Messages and tracing are independent on each other. Tracing is mainly for devs, for quick and average usage only the messages are recommended.
All of them are written to the debug output, logging to file is not yet implemented.

So, I recommend you to use DebugView. It's a very cool application for cases when no any debugger is available. Also, if you have more than
one monitors then you can watch the log in realtime: put DebugView on one display and run the game on another.

https://docs.microsoft.com/en-us/sysint ... /debugview

All of the output messages have a '[dgVoodoo]' prefix so the best way to check out a game with dgVoodoo's debug layer is enabling filtering
to the 'dgVoodoo' substring in DebugView (Crtl-L). Every single log output appear in new lines in DebugView - this is nice, except for some
tracing messages written to the output part by part, like D3D8 disassembled shaders. Unfortunately they appear nastily because of that.

It's not really a big problem however because I cannot recommend you to enable tracing. Feedback is so tremendous that DebugView
won't be able to keep up with it and make your game/app crawl at speed near zero. For tracing, a debugger with asynchronous debug output window
is much better, like Visual Studio 2015.

I must emphasize:
1) do not look for a miracle when using the debug layer! If some game doesn't work for you then it can give you some useful feedback
on what's going on, or you can see if dgVoodoo is utilized at all but won't tell you why the game crashes, for example.
Also, if you see an ERROR entry in the log then it doesn't necessarily mean you did something wrong or there is a problem with your game.
Many games rely on error codes got back from an API. So, for example if you see such a log like the following snippet

Code: Select all
...
[15500] [dgVoodoo] INFO: Direct3DDevice (0D3967D8)::EnumTextureFormats: Format XRGB8888 is enumerated to the application.
[15500] [dgVoodoo] INFO: Direct3DDevice (0D3967D8)::EnumTextureFormats: Format ARGB8888 is enumerated to the application.
[15500] [dgVoodoo] INFO: Direct3DDevice (0D3967D8) is released.
[15500] [dgVoodoo] ERROR: DirectDrawSurface (0D2380C8)::DeleteAttachedSurface: Failed, HRESULT: 887601CC
[15500] [dgVoodoo] INFO: DirectDrawSurface (0D2380C8) Plain offscreen rendertarget is released.
[15500] [dgVoodoo] INFO: Direct3D (0ABC87B0)::EnumDevices: Device enumerated, Name: "Direct3D HAL", Description: "dgVoodoo Hardware Accelerated Device", ClassID: IID_IDirect3DHALDevice, hardware accelerated device, ClassID GUID = {84e63de0-46aa-11cf-816f-0000c020156e}
...

Then the error entry about failed 'DeleteAttachedSurface' is not really an error. The application tried to delete a potential attached surface, just to make sure, and doesn't care about the result.
dgVoodoo however treat it as an error because it caused an error in an API method. It's really impossible to make a decision about classifying some conditions as an error or just a plain warning.

2) Use the spec release only for trying to solve an extant problem with an applicaiton. Spec release does some extra checking and validation compared to normal dgVoodoo releases and it can bite off from the speed or cause stuttering.
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: Spec Release dgVoodoo version (with Debug Layer)

Postby CoolGamer » 2017-11-13 @ 22:39

It is time to put some mileage on this debug release.

Dege, I attached two log files for issues that you could not replicate on your machine. This way we will see if the debug layer can be useful to fix errors that you can not replicate on your machine. Log Level is 2 for both of them.

I attached the log for "Evil Dead: Hail to the King" (DirectX8). I am able to start the game and reach the 2D main menu but when I click "Start New Game", the game gets stuck (task manager says Non Responding). I have to close it through task manager. This happens natively or with dgVoodoo. Log file shows some texture format issues.


I have also attached the log file for Star Wars Episode 1 Racer (Podracer) for the case where "Fast Video Memory Access" is disabled in dgVoodoo. When FastVidMem is off, the game does not start and gives a popup error message that says "Unable to open display for 3D". Game plays fine when FastVidMem is On.
Attachments
Podracer_dgVoodooWIP38_NoFastVidMem.LOG
Podracer_dgVoodooWIP38_NoFastVidMem
(11.48 KiB) Downloaded 7 times
EvilDead_dgVoodooWIP38.LOG
EvilDead_dgVoodooWIP38
(124.83 KiB) Downloaded 7 times
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: Spec Release dgVoodoo version (with Debug Layer)

Postby Dege » 2017-11-14 @ 13:08

Unfortunately I cannot check out any game right now, but for Podracer you have some fatal entry in the log:

Code: Select all
00000541   50.90672302   [1944] [dgVoodoo] ERROR: Direct3DDevice (03FB5158)::Init: Cannot initialize device DDI.   
00000542   50.90700531   [1944] [dgVoodoo] ERROR: Direct3DDevice (03FB5158)::Init: Failed.   
00000544   50.90776443   [1944] [dgVoodoo] ERROR: Direct3D (043EC180)::CreateDevice: Creating device has failed.   

dgVoodoo cannot init device DDI (the D3D11-related part) which is weird. Or maybe only the logging code has a bug and the real problem is some other thing. Needs to be check out as well.

Update: you have a NVIDIA GeForce GT 230M, isn't it a DX10.0-level GPU? What is the 'Output API' set to? (I'll insert report-logging about that into the debug layer... :D )
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: Spec Release dgVoodoo version (with Debug Layer)

Postby CoolGamer » 2017-11-14 @ 21:52

Nvidia Control panel says that my GPU's Direct3D API version is 10.1 . I usually have the API set to "Best Available".

For Star Wars Episode 1 Racer, I listed the results with different combinations of APIs and FastVidMem access below:
API 10.1 + FastVidMem Disabled = Game does not start and gives error "Unable to open display for 3D"
API 10.1 + FastVidMem Enabled = Game works OK. (This is how I always play this game)
API 10.0 + FastVidMem Enabled or Disabled = Game works OK.
MS WARP + FastVidMem Enabled or Disabled = Game works but videos are black. Sound of the videos are audible.

Please note that these results are for Star Wars Podracer only. In other games, I do not have problems when I disable FastVidmem or play with API settings.

Star Wars PodRacer game also has the double cursor glitch via dgVoodoo, where both the game cursor and system cursor are displayed on top of each other.

I also attached the latest official patch for StarWars Podracer below. I use this patch, when running the game via dgVoodoo.

On a separate note, have you heard of the program named Apitracer? I learned it from Peixoto. He uses it to debug errors that he can not replicate on his machine. I wrote the link below.
http://apitrace.github.io/#download

I couldn't get Apitracer to work with dgVoodoo, but it has wrappers for dxgi, d3d9.dll, d3d8.dll and ddraw.dll. It is opensource too. If you can make a custom build of Apitracer DLLs that interface nicely with dgVoodoo, it might be possible to use Apitracer to capture all different types of api calls between the game, dgvoodoo and system dlls.
Attachments
StarWarsRacerOfficialPatch.rar
Star Wars Racer Official Patch from LucasArts
(902.12 KiB) Downloaded 7 times
Last edited by CoolGamer on 2017-11-14 @ 23:48, edited 1 time in total.
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: Spec Release dgVoodoo version (with Debug Layer)

Postby CoolGamer » 2017-11-14 @ 23:27

Update:
I found a way to make Apitrace work with dgVoodoo. Apitrace has a wrapper file named dxgitrace.dll (this is under lib\wrappers folder of the release). It can trace both dxgi.dll and d3d11.dll. I renamed dxgitrace.dll to dxgi.dll and d3d11.dll, and put both files under PodRacer game directory. In other words both dxgi.dll and d3d11.dll that I placed in the game directory are the exact same Apitrace wrapper file, dxgitrace.dll, named differently.

Attached rar file contains traces for 3 different cases:

1) FastVidMem Disabled case, where I get the error. This is the important one, since error happens only in this case. The other two below are just for comparison.
2) FastVidMem Enabled case, where I only ran the game up to the main menu.
3) FastVidMem Enabled case, where I ran the game up to the start of the first race. This is a very large trace.

There are multiple trace files in each directory. You can just run the GUI file named qapitrace.exe (located in bin directory of apitrace release zip file) and load trace files into it one by one.

According to apitrace manual, the proper way to run a trace for DX11 application is to use the command "apitrace.exe trace -a dxgi C:\AppFolder\appname.exe". When you run it this way, it is supposed to collect all DX11 calls and create a single trace file. Sadly this did not work for Star Wars racer executable, probably because it does not natively call DX11.

If you make a dgVoodoo debug build which runs all DX11 calls through dxgitrace.dll, it might work better. In theory only one trace file should be generated if all calls go through dxgitrace.dll.

Let me know if Star Wars Racer trace files (especially the FastVidMem Disabled Case) helps you to debug the error.
Attachments
Case1and2_StarWarsRacer_dgVoodoo_ApitracerDX11Trace.7z
(1.34 MiB) Downloaded 2 times
Case3_StarWarsRacer_dgVoodoo_ApitracerDX11Trace.7z
(4.88 MiB) Downloaded 3 times
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: Spec Release dgVoodoo version (with Debug Layer)

Postby ZellSF » 2017-12-08 @ 23:14

CoolGamer wrote:I attached the log for "Evil Dead: Hail to the King" (DirectX8). I am able to start the game and reach the 2D main menu but when I click "Start New Game", the game gets stuck (task manager says Non Responding). I have to close it through task manager. This happens natively or with dgVoodoo. Log file shows some texture format issues.

Did you try running it with anything else than dgVoodoo2? DxWnd is always a nice alternative to try to see if something really is rendering related. Because I get the same thing and it isn't rendering related, the game needs single core affinity.
EvilDead 2017-12-09 00-07-44-71.jpg
The texture format errors are irrelevant (I get them too).
ZellSF
Oldbie
 
Posts: 935
Joined: 2006-1-01 @ 18:19


Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 1 guest