Sh1nRa358 wrote on 2024-03-20, 03:30:

Can't get this to work on AMD. Works when starting but when entering gameplay, it just crashes the game. Tried with Final Fantasy XIII.

Also, can you add NEGATIVE LOD BIAS: CLAMP?

Could you be more specific a bit plz? Is it happens only with the D3D12 backend, or is it backend agnostic, or AMD only?
I'm afraid I cannot test FFXIII. Do you have another game crashing with WIP95 in the same way?
Or maybe, is there anything interesting in the log with the _dbg version?

As for the options, I'll see. TBH I don't really like such options because they are too low level and a tons of them could be added. But, I'll see.

Dege wrote on 2024-03-20, 18:09:

Could you be more specific a bit plz? Is it happens only with the D3D12 backend, or is it backend agnostic, or AMD only? I'm afr […]
Show full quote

Sh1nRa358 wrote on 2024-03-20, 03:30:

Can't get this to work on AMD. Works when starting but when entering gameplay, it just crashes the game. Tried with Final Fantasy XIII.

Also, can you add NEGATIVE LOD BIAS: CLAMP?

Could you be more specific a bit plz? Is it happens only with the D3D12 backend, or is it backend agnostic, or AMD only?
I'm afraid I cannot test FFXIII. Do you have another game crashing with WIP95 in the same way?
Or maybe, is there anything interesting in the log with the _dbg version?

As for the options, I'll see. TBH I don't really like such options because they are too low level and a tons of them could be added. But, I'll see.

Rog Ally Windows 10 AMD. Worked just fine on my Win3 Intel based device. Same thing happens on FFXIII-2 and Lightning Returns. Unfortunately i cant get the debug version to produce a logfile. I activated everything on the secret debug tab and set logtofile to true in the config file using 32bit dx9 dll in the MS folder. Crash seems to happen on all backends for those FFXIII games. Maximum Trace Level 3rd option prevents the game from running altogether.

Sh1nRa358 wrote on 2024-03-26, 03:37:

Unfortunately i cant get the debug version to produce a logfile. I activated everything on the secret debug tab and set logtofile to true in the config file using 32bit dx9 dll in the MS folder. Crash seems to happen on all backends for those FFXIII games. Maximum Trace Level 3rd option prevents the game from running altogether.

Last I checked the log to file option doesn't work. Download and run DebugView++ and keep it open, then run the game. DebugView++'s window will be filled with the debug information which you can then save to a file.

This is all I see. I don't have ms edge open so i dunno why info on that popped up in between game start and game end.

Sh1nRa358 wrote on 2024-03-31, 16:15:

This is all I see. I don't have ms edge open so i dunno why info on that popped up in between game start and game end.

Do this to prevent edge from running in the background: https://www.microsoft.com/en-us/edge/learning … g-in-background

Make sure you are using the debug build of dgvoodoo. If the maximum trace level (+Additional trace info for internals) doesn't work, choose "API functions and methods", but I don't think these are even needed. "ERROR message severity" should be enough.

Make sure debugview's window is empty before you run the game. If you see any other exe process, close that program.

4197998 is the line where the game crashes and here is the debug log:
https://mega.nz/file/fglAFQDQ#5MpCsjQhyABDFNj … xDZUb6fxxAbsqiA

Sh1nRa358 wrote on 2024-04-01, 17:17:

Why would i have to do that at all? this is not an issue on my intel based machine. it's literally the same ssd with the same data on it just transfered on a new device with a different graphics card company.

What are you even talking about?? You said edge shows up in debugview, I posted a link that shows how to prevent that. You have to disable edge from running in the background when it's closed. Later you can enable it if it's that important.

Also close/exit any other program that shows up in debugview before running the game.

The rest is about getting a log file from dgvoodoo.

I showed you exactly what transpired between the start of the game and the crash of the game. it was almost impossible to have the log clear for everytime i searched for the exe to launch it, something appeared on it so i had to keep starting it all over. but there it is, i was in the middle of editing my prev post before you responded.

"What are you even talking about??"
I was informing you that i had no issue with using this on my intel machine. Only on this Amd machine i am currently on.

Any other process that shows up in debugview besides ffxiiiimg.exe, you have to close it or kill it in task manager. msedge.exe always runs in the background even when closed unless you prevent that by the method that is mentioned in the link I posted.

In any case, if the log you posted is clean, dege can probably figure out what's happening.

I was informing you that i had no issue with using this on my intel machine. Only on this Amd machine i am currently on.

Alright, that makes sense now. Different hardware behaves differently. It's probably a driver compatibility issue with dgvoodoo.

I create a new topic for this. This seems to be a general problem, not FFXIII only.

So, if I get it right, the latest and older versions also crash on a Rog Ally, not just WIP95?
Looking into your log, I cannot see any problem reported (aside from the texture lock fail, but that seems to be normal). The last lines are

1Direct3DDevice9::SetStreamSourceFreq (this = 40B24400, StreamNumber = 8, Setting = 0x1)
2105.673767	2024/04/01 13:35:01.790	38608	ffxiiiimg.exe	Direct3DDevice9::SetStreamSource (this = 40B24400, StreamNumber = 9, pStreamData = 00000000, OffsetInBytes = 0, Stride = 0)
3105.673788	2024/04/01 13:35:01.790	38608	ffxiiiimg.exe	Direct3DDevice9::SetStreamSourceFreq (this = 40B24400, StreamNumber = 9, Setting = 0x1)
4105.982864	2024/04/01 13:35:02.099	38608	ffxiiiimg.exe	<process started at 13:33:16.110 has terminated with 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)>
5106.017852	2024/04/01 13:35:02.134	11720	explorer.exe	WM_DISPLAYCHANGE Recieved
6106.727482	2024/04/01 13:35:02.844	11720	explorer.exe	RESOLUTION CHANGE DETECTED

Direct3DDevice9::SetStreamSourceFreq is the last call into dgVoodoo before the crash. That method cannot crash in dgVoodoo, it's a very simple function.
Running out of memory is a typical case for these kind of crashes. Isn't the 2GB memory limit is reached? Did you try patching the executable for 4GB (maybe it comes patched out-of-the-box, I don't know)?

Hi Dege,

i use dgVoodoo2 on a Steam Deck with Steam OS and every version after WIP93_1 just crashes at game launch.
As both the Steam Deck and the Rog Ally use a similar AMD APU the problems could be related.

I don't have access to FF13 so i used another D3D9 game.
This is the debug output of WINE as DebugView is not available.

dgVoodooWIP93_1:
https://pastebin.com/bTkSwsre

dgVoodooWIP93_2:
https://pastebin.com/c8juKMkB

I hope this helps in any way.

Dege wrote on 2024-04-03, 15:48:

I create a new topic for this. This seems to be a general problem, not FFXIII only. […]
Show full quote

I create a new topic for this. This seems to be a general problem, not FFXIII only.

So, if I get it right, the latest and older versions also crash on a Rog Ally, not just WIP95?
Looking into your log, I cannot see any problem reported (aside from the texture lock fail, but that seems to be normal). The last lines are

Copy code to clipboard

1Direct3DDevice9::SetStreamSourceFreq (this = 40B24400, StreamNumber = 8, Setting = 0x1)
2105.673767	2024/04/01 13:35:01.790	38608	ffxiiiimg.exe	Direct3DDevice9::SetStreamSource (this = 40B24400, StreamNumber = 9, pStreamData = 00000000, OffsetInBytes = 0, Stride = 0)
3105.673788	2024/04/01 13:35:01.790	38608	ffxiiiimg.exe	Direct3DDevice9::SetStreamSourceFreq (this = 40B24400, StreamNumber = 9, Setting = 0x1)
4105.982864	2024/04/01 13:35:02.099	38608	ffxiiiimg.exe	<process started at 13:33:16.110 has terminated with 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)>
5106.017852	2024/04/01 13:35:02.134	11720	explorer.exe	WM_DISPLAYCHANGE Recieved
6106.727482	2024/04/01 13:35:02.844	11720	explorer.exe	RESOLUTION CHANGE DETECTED

Direct3DDevice9::SetStreamSourceFreq is the last call into dgVoodoo before the crash. That method cannot crash in dgVoodoo, it's a very simple function.
Running out of memory is a typical case for these kind of crashes. Isn't the 2GB memory limit is reached? Did you try patching the executable for 4GB (maybe it comes patched out-of-the-box, I don't know)?

yes, it is patched with the 4gb patcher and ive tried 8 previous versions and they all crash. This didnt happen on my intel based machine, only amd. the game works just fine without dgvoodoo2 and dvxk works fine with the game as well.

TBH then no idea for the time being. But it's also not important, you can play the games without dgvoodoo.

but dxvk wont implement downsampling *cries* 🤣. That is the real thing that is needed. The graphics card innert feature doesn't look as good as dgvoodoos. The way they implemented upscaling in the game is no good. The ground is very pixelated and shimmery when i don't use dgvoodoo2 and the way the game handles mouse and window/fullscreen transitioning is very awful

One idea: if you could attach another log, using D3D12 (you must select it from the API list) and forcing the game to run on a single cpu core, then I could look into it.
Under such conditions the rendering is single threaded in dgvoodoo, so the latest trace line would tell where the crash happens, by a good chance.

That took forever 🤣. Here it goes. I started the debug at the loading screen instead of when turning the game on. it was taking hours. The crash is at the very bottom.

https://mega.nz/file/vwkR0D4Y#BMuYMM7N0wcDnvx … ytMYlqDBUXyda_k

Hours? Sorry for the torturing... It shouldn't take more than creating the previous log.

Anyway, thanks, I might have a guess now, in fact the d3d11 and 12 logs points to the same culprit.
Now, could you make a crash dump plz?

I made a pack with a prepared version of d3d9. Also, to enable generating dump files by the OS by default, you need to add some registry keys, but I also created a .reg file for that in the pack.
For the details, see: https://learn.microsoft.com/en-us/windows/win … user-mode-dumps

If you just apply the .reg file I created, then the .dmp files will be create in folder c:\Users\{user}\AppData\Local\CrashDumps\

When you want to disable auto-creating dumps then just delete the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key, it shouldn't be there by default.

I'm going to send you a link in a PM.

https://mega.nz/file/3gMxzLYY#lzgqLwRf8uE1dyV … B5rktEWuknJoWZY

Thanks! Indeed, I found a bug that a driver may not like, and fixed it.
Could you try if this version is working?

http://dege.fw.hu/temp/dgVoodoo2_82_4_d3d9_ffxiii_fix.zip