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.

Moderators: Mechanist, Arokhs Twin, yangez93

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby Mechanist » Sat Jun 23, 2018 4:40 pm

Well, as far as OpenDrakan is concerned, I don't see a problem - since it can be distributed as a game mod, and require the original Drakan.exe to run.

In any case, because of it's nature, OpenDrakan already requires all the other Drakan files to function; adding an extra dependency on Drakan.exe would be pretty trivial (even if it doesn't actually use Drakan.exe for anything, because why would it?).


EDIT:
On an unrelated note, I've finally narrowed down the issue with some levels not loading on clients when they're running on a dedicated server.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!

User avatar
mage150
Dragon
Posts: 166
Joined: Sun Aug 12, 2001 3:05 pm
Location: USA
Contact:

Re: Widescreen hack and some other fixes aka AiO Patch

Postby mage150 » Sat Jun 23, 2018 6:06 pm


EDIT:
On an unrelated note, I've finally narrowed down the issue with some levels not loading on clients when they're running on a dedicated server.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!
That is good to know. Interesting, but great that we figured a huge issue out.
Moderator Of Arokh's Lair.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby UCyborg » Sat Jun 23, 2018 10:09 pm

Sorry if I am reading you wrong but I appreciate everything you have done.

Thanks!

I feel like the last line comes off a bit harsh, unless I am reading you wrong.

It wasn't directed at any specific person, I merely wanted to make it clear to everyone reading to not expect any more miracles when it comes to AiO Patch at this point in time. I've read that line somewhere and it struck me as more original than something like "live with it!".

I didn't think that it could come off as harsh. Either way, the reality of situation is that Drakan is a quirky game and the state in which developers left it doesn't make it trivial to make improvements to it.

I know you have done this on your spare time and trust me if I could fix these things I would. It just never fell into my talent house.

I find programming in general really tricky and cryptic. It seems you gotta figure out a lot on your own. And given the lack of source code for Drakan, I'm surprised about the number of fixes that somehow made it into this patch. Like, I actually did this?

Drakan did come far from when the development started to when it was released. I remember watching some old gameplay video, was it the one showcased on E3? Someone mentioned it, linked it on this forum. One more year in development at least would be very beneficial.

Sorry if I or someone upset you.

Nah, I'm cool.

It was really hot on the day I wrote that post though!

Oh and in regards to this part, I actually do not see the point to remake something that can get shut down. I understand the nature of the remakes, but I do not offer my resources to those because there are potential legal implications with those.

I was actually referring to OpenDrakan - the open-source re-implementation of Drakan's Riot Engine, not OpenOOTF - the remake in Unity remake. There shouldn't be any legal implications with the former. Similar projects are being actively worked on today, eg. OpenMF and OpenRW; the final result would be opendrakan.exe, the alternative to current Drakan.exe, which, when finished, would let you play original Drakan exactly as you would with Drakan.exe (minus the bugs), assuming you own the original game as it depends on its data. It will take a while though and we might get older in the meantime (or not see its fully functional release at all), especially if more knowledgeable programmers don't hop on board. Here's the list of game engine recreations on Wikipedia.

unfortunately within my skill set I can work on drakan maps in the riot level editor and I have a talent for map design.

Yeah, just programmers are needed for this. But in the end, programmers can add more features that can be cleverly used by map makers. I always wondered how you and the others have found their way around the editor. :)

Well, as far as OpenDrakan is concerned, I don't see a problem - since it can be distributed as a game mod, and require the original Drakan.exe to run.

It would be drop-in replacement for Drakan.exe. :wink: Drakan.exe by itself is not very useful neither, need both executable and the data to make the magic work.

In any case, because of it's nature, OpenDrakan already requires all the other Drakan files to function; adding an extra dependency on Drakan.exe would be pretty trivial

Dependency on Drakan.exe would be redundant as the dependency on data files is perfectly sufficient for all intends and purposes. You can play Quake III with ioquake3.exe (or any other unofficial executable) without having to have original quake3.exe in the folder. Since both original data and executable originate from the same source, it can be assumed having access to data means you "own" the game one way or another. The practical difference is that data files are copyrighted in most cases, unless stated otherwise, while executable may not be, especially if it's unofficial and developed from ground up.

Apparently, it only ever happens if the dedicated server is running on an Intel CPU; never happens on AMD!

That's an interesting observation. It could be just occurring on certain models/models from certain generations.

Can you try setting DisablePerformanceCounter=1 in Arokh.ini and tell us if it makes any difference? It's a rather strange option I implemented only because I've read on the internet about strange behaviors of QueryPerformanceCounter/QueryPerformanceFrequency functions that supposedly occur on certain CPUs. Disabling them will use timeGetTime instead.

That's the only CPU related thing I can think of. Maybe it actually does something if all stars align properly... My two computers are both AMD and the one game I have that has CPU related bugs is Pro Rally 2001. They tend to show on (certain?) AMD CPUs as freezing on the load screen. The game does the number of CPUID queries, which I haven't figured out myself. The guy behind nGlide says the bug is connected to timing and the issue disappears after making the code skip those CPUID queries.

The first patch that was made actually just faked the CPU vendor string, so the game thought it was running on Intel even if you had AMD and that apparently solved it for some people. It didn't work on my Phenom II X4 920 until I found and disabled the function call that does all those queries.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby Mechanist » Sun Jun 24, 2018 4:14 am

That's an interesting observation. It could be just occurring on certain models/models from certain generations.

Can you try setting DisablePerformanceCounter=1 in Arokh.ini and tell us if it makes any difference?
Thanks, I'll try that.

(EDIT: Tried that. Makes no difference whatsoever.)

We did some other testing in the meantime yesterday, and there was another interesting conclusion that we reached:
  • Running on an AMD CPU (both x86 and x64 OS) - works fine;
  • On an old Intel Atom, x86 OS - fails to load certain levels;
  • But on a Celeron 925 with x64 OS, it also works perfectly fine - despite this CPU supporting the exact same instructions (MMX, SSE, etc.) as the Atom!

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby Mechanist » Sun Jun 24, 2018 3:30 pm

OK, so I tried modifying Drakan.exe to make the CPUID queries never branch at the "Authentic AMD" check, thus fooling it into thinking that Intel = AMD.
This only required changing a single byte; making it compare a string with itself, so it'll always succeed.

Unexpectedly, that resulted in serious brokenness - suddenly it was no longer reading settings from the correct Drakan.cfg, causing the GUI graphics (as well as the text font) to be seriously mangled; as well as some other settings being changed from what they should be.
That happened despite running the client on an actual AMD machine, where it shouldn't even make any difference!

I suspected that the dinput.dll does some checksum checking on Drakan.exe. Apparently, indeed it does.

The most likely culprit is around this point:

Code: Select all

67003870 68 84790067 PUSH DINPUT.67007984 ; ASCII "DllMain: Invalid Drakan.exe"
But I tried setting breakpoints in that general area (especially where the actual checksum calculation call is made from), and they never triggered.

For reference, here's what the CPUID queries returned on both systems (AMD = works; Intel Atom = causes dedicated server brokenness in levels like Auropolis):
AMD:
CPUID 0x00:
EAX 0000000D
ECX 444D4163
EDX 69746E65
EBX 68747541

CPUID 0x01:
EAX 00600F20
ECX 3E98320B
EDX 178BFBFF
EBX 02080800

CPUID 0x80000000:
EAX 8000001E
ECX 444D4163
EDX 69746E65
EBX 68747541

CPUID 0x80000001:
EAX 00600F20
ECX 01EBBFFF
EDX 2FD3FBFF
EBX 10000000

Intel Atom:
CPUID 0x00:
EAX 0000000A
ECX 6C65746E
EDX 49656E69
EBX 756E6547

CPUID 0x01:
EAX 000106CA
ECX 0040E39D
EDX BFE9FBFF
EBX 00020800

CPUID 0x80000000:
EAX 80000008
ECX 00000000
EDX 00000000
EBX 00000000

CPUID 0x80000001:
EAX 00000000
ECX 00000001
EDX 20100000
EBX 00000000

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby UCyborg » Sun Jun 24, 2018 6:14 pm

OK, so I tried modifying Drakan.exe to make the CPUID queries never branch at the "Authentic AMD" check, thus fooling it into thinking that Intel = AMD.

The results of the queries after AuthenticAMD check are never used, it just checks for support of Extended 3DNow! instructions and two other things. Whether that code runs or not doesn't make any difference in program workflow. The only purpose of that entire function is to check whether CPU supports 3DNow! instruction set. It's done before comparing "AuthenticAMD" string. 3DNow! has been deprecated for years and is not present on any modern CPU, apart from two instructions, PREFETCHW and another variant of prefetch instruction I don't recall from memory. Drakan uses PREFECTHW in one loop on the client-side, just a pointless micro-optimization at best. If you start Drakan.exe with "-no3dnow" parameter, it won't be used neither.

I suspected that the dinput.dll does some checksum checking on Drakan.exe. Apparently, indeed it does.

Intentional so the DLL doesn't interfere unless it's loaded by EXE it's designed to patch.

But I tried setting breakpoints in that general area (especially where the actual checksum calculation call is made from), and they never triggered.

Drakan.exe is dynamically linked to dinput.dll at load-time, so its DllMain function runs before Drakan.exe's main function. Maybe your debugger doesn't set breakpoints yet at that stage.

(EDIT: Tried that. Makes no difference whatsoever.)

So the issue is elsewhere. Still, If you want to try another timing related thing:

Code: Select all

bcdedit /set useplatformclock true
And to undo:

Code: Select all

bcdedit /deletevalue useplatformclock

Both commands go to administrative Command Prompt and require reboot to apply. Another thing that's been thrown around on the internet, an urban myth? This one's actually supposed to help with in stuttering games or it may just make things laggier.

If the timing is the issue in the first place. Seems odd to me. 0 A.D. game is coded to be able to use multiple timing sources and the QueryPerformanceCounter and timeGetTime aren't at the top of the preferred list. HPET is. Though QueryPerformanceCounter must rely on either TSC, HPET or something else, depends on the system.

Turning on useplatformclock supposedly sets HPET as the only clock source.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby Mechanist » Sun Jun 24, 2018 7:03 pm

After many hours, I finally tracked down the problem!

All that CPUID stuff was just a red herring after all, just like you said.
The real problem was that there's some sort of race condition caused by setting the priority of Drakan.exe to anything above Normal on Intel CPUs!
Well, on Intel Atoms at least, since that's the only Intel I have.

I feel foolish! I haven't been paying attention!

BTW, thanks for the help anyway :)

EDIT: I've done some more testing - it is a timing issue of some sort, just not in the way we expected.
Setting priority to "Above Normal" makes Auropolis load occasionally.
Running on Normal priority, it loads correctly most of the time.
Priorities below Normal don't help.

On AMD, the server works and Auropolis loads OK, even with the priority set to Realtime.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Postby Mechanist » Sun Jul 08, 2018 8:26 pm

This is most aggravating. So it turns out that it's not actually related to CPU type at all.
The first sign of trouble was when on my new AMD server (with cable Ethernet connection, no wireless), Auropolis worked for me - but not for everyone else :!:

The next step was to take the old Intel Atom server and connect it via cable, instead of wireless :arrow: exact same behavior as with the AMD server.

Further testing with dummynet to cause artificial packet delays revealed that (additional) packet delays as low as <10 ms are sufficient to prevent Auropolis from loading.

I've attached the capture output from Wireshark (logged on the server side) - the first 2 connection attempts were successful (I quit the game after a few seconds), the 3rd attempt was unsuccessful (stuck on 99% load).
192.186.0.102 is the server, 192.168.0.101 is the client.

Look for a packet with a length of 686 - this appears to be the critical packet that tells the client to actually spawn the player after the level is otherwise done loading.
In the unsuccessful connection attempt, that packet had never been sent, for whatever as-of-yet not understood reason.
Attachments
Drakan 2 successful and 1 unsuccessful connections.zip
(22.16 KiB) Downloaded 2 times


Return to “Drakan (PC) Game Discussion & Technical Support”

Who is online

Users browsing this forum: No registered users and 2 guests

cron