It isn't, really - because of the LODs, the affected texture is rendered too small to actually make out any real detail.I can see how the texture you fixed in System.txd is messed up when I try to paint it, but can't figure out where the brokenness is encountered during normal gameplay.
Speaking of the Editor: a lot more fixes have been added.Alwarren was quite troublesome to update with new visibility data using the editor.
I'll try to consistently reproduce the issue when I can spare some time, and report back.With dgVoodoo, resource consumption is even greater. I don't have any problems with Fast video memory access here though, all 26 textures I've replaced showed normally.
LFE's were quite broken (again...) the last time I checked. Again, something I'll have to look into more carefully.Fast video memory access just helps with lag spikes when lens flares are on the screen.
I just didn't like the idea of intentionally leaving in something that I know is broken; and it was a "5 minute fix" anyway.
Speaking of the Editor: a lot more fixes have been added.
In other news: I've made a new patch DLL (DSOUND.DLL) with my post-AiO fixes.
Ok, I'll try that.Regarding dgVoodoo, can you try selecting "Direct3D 11 MS WARP (software)" for the "Output API" to see if you still get the texture problem then?
True.Didn't you say you won't be messing with it again for the foreseeable future?
Um, ok. Not sure we're quite on the same page here...Replacement DirectSound DLLs are frequently used to restore EAX effects and positional audio in games that refuse to do 3D sound mixing when no hardware accelerated sound buffers are detected. (...)
The only oddity is that KERNEL32.GetProcAddress fails when there are multiple DLLs of the same name loaded!
Also I finally (and properly!) fixed the issue of blocking execution while the 3D view is idle.
But isn't that just the "software rasterizer" (or the 3D equivalent, whatever that is)?
Originally I started out with using MPR.dll instead: it would have been perfect - except that it doesn't work in Win10.Yeah, dinput.dll also isn't the ideal way for hooking, there must be some use cases for intercepting DirectInput calls too, I remember some guy ranting why everyone uses dinput proxy DLLs as that prevent usage of real replacement dinput/dinput8 DLLs.
Oldest one in the book: Sleep(1).So what trick did you use?
I have no idea what's going on, really.What are you talking about? Then how do all other proxy DLLs out there work successfully without hooking GetProcAddress?
Wait, so are you trying to tell me that those other soundcards instead require placing a fake dsound.dll in the game folder of each game that needs to have EAX "emulated"? Because that sounds crazy...
Oldest one in the book: Sleep(1).
Basically what happens is this: the instant I release (all of) the movement keys, the 3D View freezes instantly - while the camera should keep moving for a fraction of a second due to "momentum".Not sure what goes wrong on your end that my method fails to work properly (...)
Uh-oh. But pressing any movement key also causes the 3D View to return to "flying mode"...(...) to toggle (...)
Fair enough...Well, it's as crazy as having dgVoodoo DLLs for each and every game.
Uh, what?Also, on Windows, I haven't managed to make the 3D engine ever crash (dgVoodoo or not), but the editor itself is pretty easy crash.
Oh, and one more thing: pressing SPACE doesn't actually release focus - it only releases the MOUSE POINTER; the 3D view does stay in focus... maybe that's the problem?
Also: I've edited my previous post (just as you replied to it at the same time...), asking for your input about how to go about redoing my DLL hooking; please take a look at that.
Unfortunately, the DLL injection method you've linked to is not useful in my case:The only idea I have besides InjectDLL shim you've mentioned is writing the launcher that injects it. It's quickly described here.
My fixes are almost entirely in assembly.Out of curiosity, was there a lot of assembly work in your other fixes?
Hmm, not sure I quite follow what's going on there.Go to 0x438594; the function was moved up a bit to make space for extra conditional check
And in any case, lack of EAX wouldn't be an issue in the 3D View anyway, even if it had sound.
Having DSOUND.dll as the patch for the Engine won't affect the Editor itself, because in my CP the 3D View engine sits in \Engine folder - this is so that dgVoodoo can be used with it, as it would otherwise interfere badly with the Editor (the 2D part).
TL;dr: I'm currently redoing my code as DINPUT.dll; the CP installer will then install your DINPUT.dll as AiO.dll, and my DINPUT.dll has that listed in its import table.
The only function of the InjectDLL shim will be to check if the DINPUT.dll is still the CP version; I don't want to put any other functionality in the shim, in case it doesn't actually activate for whatever reason. (In particular, are those shims even supported in WINE?)
Hmm, not sure I quite follow what's going on there.
I can clearly see that the circumstances leading to the infinite loop are now accounted for, breaking out of the loop if that's the case - but what's the actual meaning of [EAX + 8]?
Ah, ok then. I haven't been messing around with those yet.It does have sound (STOMP sequences).
Yes.So you'll have 3rd DLL that verifies dinput.dll since InjectDll takes DLL paths/names as parameters?
Interesting. So does it mean that the AiO patch doesn't work in WINE without messing with the configs?And proxy DLLs to system DLLs such as dinput.dll aren't loaded by default without altering WINE's configuration.
Whatever works, I guess.Who knows, just guesswork. The actual bug might be somewhere else.
Because by the time the shim code fires, the PE loader already has a lock on DINPUT.dll and has loaded it into process space, the file cannot be deleted (why? the hardcopy is no longer needed...); it has to be renamed instead (which actually works, for no adequately explained reason!).
Interesting. So does it mean that the AiO patch doesn't work in WINE without messing with the configs?
Users browsing this forum: No registered users and 3 guests