Widescreen hack and some other fixes aka AiO Patch

Discuss Drakan: Order of the Flame with fellow players and post any technical problems here where an 'unofficial' support team will try and help you. Gameplay help questions can go here too.
User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Just found a new bug (?), right after I enabled the gamepad in options menu and restarted OOTF:

Upon starting drakan.exe, it tries to go fullscreen (as it should), but after 2-3 seconds an error message appears: "The procedure entry point DirectInputCreateW could not be found in the dynamic link library DINPUT.dll".
Then it starts up anyway - but instead of fullscreen, only a tiny game window opens; roughly the size of a matchbox on a 24" screen. I have to press F4 a few times to cycle the fullscreen; oddly, sometimes this makes the "black menu background bug" reappear - but F4-ing a few more times makes it go away.
After that, everything seems to work OK, though. Including the gamepad, oddly enough!

Before I enabled the gamepad support, everything was working perfectly fine.

Relevant system configuration:
  • AMD 8-core CPU, 2x R7 260x GPU (CrossFire disabled), 32GB RAM,
  • Win7 SP1 x64,
  • Using UCyborg's latest OOTF repack + dgVoodoo (no 10th Mod),
  • Logitech F710 gamepad (set to DirectInput mode).
I think I can safely rule out the gamepad itself - it worked perfectly fine in OOTF under XP x86 (on another machine). But that was with OOTF patched with an ancient 2008 pre-AiO patch.

I did, however, manage to narrow it down as being somehow related to dgVoodoo: deleting the 3 dgVoodoo DLL's and running OOTF that way doesn't cause any errors.

A few extra details:
  • The gamepad was hooked up long before OOTF had ever been run on this computer.
  • When I first enabled gamepad support in OOTF, there were no errors - but the gamepad didn't seem to work, either.
  • I then alt-tabbed to the Logitech app - which confirmed that the gamepad is, in fact, fully active and working properly. Still, OOTF wouldn't yet accept any gamepad input at that point.
  • Then I quit and restarted OOTF, and the above happened.
  • Rebooting the OS does nothing.
  • Strangely, the error persists even after disabling gamepad support in OOTF! :?
  • However, disconnecting the gamepad makes the error not happen.
  • Switching it to XInput mode (not recognized by older games) works just as well as physically disconnecting it.

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Added missing exports to dinput.dll. Shouldn't throw that error anymore now. Though Drakan is linked only to DirectInputCreateA, DIrectInputCreateW dependency is coming from 3rd party software.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Thank you, it works fine now :mrgreen:

BTW: the Arokh's Lair download link in the OP seems to be broken; it redirects me to the main page.

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Cool! According to anecdote from another forum, Drakan supposedly has decent gamepad support. Arokh's Twin will probably update the link as soon as he is able.

Regarding dgVoodoo, you only need DDraw.dll and D3DImm.dll for Drakan. You usually get the small window with dgVodoo only if the game loses focus at unexpected moment. It should also return to fullscreen if you alt-tab to something else / open start menu, then return to the game.

The menu background can't be created if the focus is lost while in fullscreen. Direct3D is a bit complicated when it comes to handling app switching.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Arokhs Twin
Site Admin
Posts: 1295
Joined: Wed Jul 18, 2001 9:36 pm
Location: United Kingdom
Contact:

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Arokhs Twin »

I will upload the latest version and update the link(s)

AT
By fire and by blood I join with thee in the Order of the Flame!
Webmaster of Arokh's Lair

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Well, I ran some quick tests last month on my old computer, and I haven't run into any technical problems with OOTF's gamepad support.

The only issue I've seen, is that using the analog sticks for movement doesn't allow for variable fore/aft movement speed; it's all-or-nothing.
Haven't tested with a joystick, but I think it'd be the same.
I think that strafing also behaves the same way, but I'm not positive on that right now.

Oddly, OOTF's labelling of the analog axes seems to lack any rhyme or reason, for an XBox gamepad at least; some axes are even inverted (eg. movement forward/backward).
Trying to use an XBox gamepad with OOTF's default controls (stock, not the ones from your repack) is a very... bizarre experience, to say the least :)

Arokh controls just fine with the gamepad, both on the ground and in the air; and his ridiculous firepower also helps compensate for the reduced precision of aiming. Freelook is very useful, too :D
Playing as Rynn feels kinda wonky though, but that's just my first impression from all of <10 minutes of testing. And having last used a gamepad over a decade ago :)

I've set up the gamepad assignments to be as close to those in TAG as reasonably possible.
The only problem is, OOTF doesn't have any provision for locking onto targets, having been designed with mouse & keyboard in mind.
It remains to be seen just how much of a problem does that cause in actual practice.

The point of this whole exercise with a gamepad in OOTF is primarily for me to get more-or-less used to such a control scheme, so that I won't be struggling to adapt to it when I get around to playing TAG.

UCyborg wrote: Arokh's Twin will probably update the link as soon as he is able.
Ah yes, I've half expected that this might be the case; but pointed it out anyway, on the off chance that something else might have gone wrong.

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Game-breaking bug (array index out of bounds and/or dangling pointer?): placing a 2-slots-wide inventory item in the rightmost column (doing that shouldn't be allowed in the first place!) causes bizarre results, up to and including duplication of the item in question.
However, the duplicated item isn't quite a perfect copy of the original: saving and reloading can cause the copies to become corrupted and impossible to interact with; also, while experimenting with the duplication, I managed to cause a very nasty crash (not a BSOD) which effectively brought down the entire OS.
Fixed the duplication bug. When placing the item in the rightmost column, it wraps around so the second half of the item occupies the column at the beginning.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Nice, thanks.
Wait, 122? What happened to 121, have I missed something?
Out of technical curiosity, what was the underlying cause of the cloning bug? I mean, beyond simply being able to place an item where it shouldn't have been possible to? :?:

I'll still show this bug off in my LP, though; both because of its importance for speedrunning, and also because of how long it's been around for. :wink:

That crash I mentioned, it happened when I was experimenting with duplicating a Worn Chain Mail: I duped it a few times, dropping the duplicates nearby, and at some point I accidentally clicked on (I think) the very bottom row of pixels on the screen, approx. 20-30% of screen width counting from the left, while a duplicate of the armor was still on the cursor. That immediately caused the system to lock up solid - there was no BSOD, but it also wouldn't respond to any inputs whatsoever.
I can't rule out the possibility that at some point I might've gotten confused as to which one was the original armor, and tried to duplicate a duplicate instead! (oops...)

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Re-uploaded it after noticing the first version broke more stuff than it fixed. There is counter in some loop, I guess it's for inventory cells. It was set to 26, I set it to 24. Though the number 26 still appears in many places, so it means something. There's far less instances of 24. Oh well, the duplication bug appears to be gone! :mrgreen:
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Oh, and there's also one other issue I've been wondering about; maybe you can enlighten me on this:

I've recently noticed that both the topmost row, and the leftmost column of pixels on the screen don't appear to be updated properly.
I wasn't using dgVoodoo when I noticed that - but then again, only noticed it after about an hour of playing.
It's happening in true fullscreen mode (no borderless hooks), @ 1920x1200.

This effect is especially evident if ie. a torch flame is visible on the affected row/column, and the menu is opened and closed.
But opening and closing the menu several times causes these "ghost images" to gradually fade to black with each cycle :?

Sadly, no screenshots at the moment, because I need to be leaving in a few minutes; I'll mess around with that some more at a later time.

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

That inventory bug is an interesting oversight. If you place something that takes 2 cells horizontally at far lower right, there's still space in the first two rows on the far left. But place that something in the far upper right, then there is conflict when placing something else in 2nd/3rd row on the far left, as it should be. No wrap around as I initially thought.

Regarding those pixel updating problem, I think I've seen something like you describe once or twice. Things like that can happen when forcing certain anti-aliasing methods on a game, though i don't think this is it in this case. I wasn't paying attention whether I was doing anything special when it happened. Should definitely keep an eye on this.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

The 'sword block flying' glitch is no more! It appears the code for handling that case is already present, but was never executed until now.

Regarding that first bugged version of the patch for the inventory bug, it might be possible to get it to work correctly with more assembly tweaking. I did manage to make the game refuse to put the item outside of the bounding, though that resulted in the crash if you tried to equip Rynn with the item right after trying to place it out of bounds. Items spanning 2 slots in horizontal direction are a bit special. Some code there tells if part of the item is outside, though it also does something else which makes the thing crash.

I'll leave things as they are. I might come back to it some other time. So maybe later, maybe never; depends on whether I'll feel like messing with this again.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

UCyborg wrote:The 'sword block flying' glitch is no more! (...)
UCyborg, the bane of OOTF speedrunners :D

UCyborg wrote: Regarding those pixel updating problem, I think I've seen something like you describe once or twice. Things like that can happen when forcing certain anti-aliasing methods on a game, though i don't think this is it in this case.
Well, my testing confirms that AA seems to be the culprit here, after all.
It also confirms that only the topmost row and leftmost column of pixels are affected, but not the opposite sides.

No AA = no pixel updating bug;
dgVoodoo 4x MSAA = pixels not updating, but only due to the health bar sliding into place diagonally, not due to the flame effects;
Radeon forced 4xEQ FSAA = pixels also not updating, both due to the health bar, and due to any flame effects being visible on the affected row/column when entering the menu.

Take a look at these screenshots (cropped to show only the relevant part in the bottom left corner of the screen):
Attachments
no dgVoodoo, 4xEQ FSAA.png
no dgVoodoo, 4xEQ FSAA.png (95.65 KiB) Viewed 10259 times
with dgVoodoo, 4x MSAA.png
with dgVoodoo, 4x MSAA.png (91.58 KiB) Viewed 10259 times

UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

I inspected the CPU feature detection, which is there basically to tell the game if CPU supports 3DNow! instructions. Noticed 2 oddities, one being that after it reads feature flags from CPUID opcode, it checks if flag indicating SSE support (not 3DNow!) is active. If it is, it tries to execute one SSE opcode to verify that it actually works. That code block must have been wrapped in __try block in the original source code to catch illegal instruction exception and turn off the feature flag in the variable that stores them.

The second oddity is, I guess because of mixing C code with inline assembly, the compiler's optimizations interfered and produced the code that stored wrong value in some variable used by Structured Exception Handling mechanism, preventing the code in __except block from being executed and crashing.

I corrected the code so the exception handling in that function works and replaced the SSE instruction with 3DNow! one. 3DNow! is only supported by older AMD CPUs and some old VIA CPUs. The Intel developer's manual says the exact bit that would indicate presence of 3DNow! on AMD CPUs is reserved and should be ignored. So this update could prevent the game crash if some CPU has that bit set, but doesn't actually implement the 3DNow! instruction set.

The alternative solutions would be simply making the game skip the CPU feature detection by default or instructing users to set the game shortcut to pass "-no3dnow" command line parameter. Did anyone here know that the "Session creation failed!" error that occurs in 445 version of the game when trying to host a server on modern operating systems can be taken care of passing by "-ip 0.0.0.0" parameter?

Well, my testing confirms that AA seems to be the culprit here, after all.

Right, I thought that maybe something else was going on, given that the pixels on the upper side of the screen were affected. I knew about the pixels after health bar slides into place. It happens after enabling Fix Texture Coordinates (called Text Adjustment in Graphics menu) option. This option was meant to fix the corrupted text on the first Voodoo 3D accelerator card. By modifying the code a little, the corrupted text as the result of anti-aliasing can be fixed. There's something about the way game renders text that can be fixed by shifting those vertices by -0.5. The vertex shifting trick is a known thing among the folks knowledgeable about computer graphics.

At least with MSAA, it's supposed to work fine and is probably the best method for Drakan. There's no FSAA option on my end, though I did mess with other anti-aliasing options at one point. I don't know why health bar leaves that trace. Interestingly, with unmodified option (TexelShitMode=0 in Arokh.ini) and enabling "Fix Texture Coordinates" in Riot Engine Options, this trace doesn't show if you also utilize "Alternate pixel centers" feature in ATI/AMD drivers. Today, if the option is still present, it can be enabled with registry editing and works only when legacy Direct3D is used, meaning it won't work with dgVoodoo, plus it's AMD specific fix.

Either way, issues when forcing anti-aliasing on old games isn't unusual. They weren't designed with it in mind. VOGONS Wiki says that MSAA appeared with GeForce3 series cards on NVIDIA side; year 2001.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

It's interesting why dgVoodoo's MSAA fixes the problem only partially, so that the health bar is still affected, but the flames aren't.

Even more strangely, I've just now tested with forcing MSAA (instead of FSAA) via Radeon Settings, and there is no change in behavior from FSAA - both the health bar and flame effects still cause the "dead pixels glitch".

This is only a minor issue in normal gameplay, just cycle the menu a bunch of times and it goes away.
But it looks bad when recorded in HD.

I think I'll use a sort of an engineer's workaround here: use a specially crafted image as a mask overlay, in order to force the offending row and column of pixels to show up as pure black.
They aren't updated properly anyway - and since they're at the very edge of the screen, this kind of "cover-up" isn't easily noticeable, even if these pixels had been otherwise functional.

Post Reply