Arthur's Knights: Tales of Chivalry and Arthur's Knights: Secrets of Merlin

[Marian Apgar]

I saw the thread on the discussion forum regarding Cryo's New Adventures of the Time Machine, and I am writing to ask if the two Arthur's Knights games have ever been tested on dxwnd.  These games have always been difficult to get running properly; players even had problems sometimes when the games were running in their native environment back in the early 2000s.

I have Windows 7.  The only time I was able to get these games running was with Virtual PC with Windows 98SE as a guest, and to get the 3D acceleration I had to enable hardware virtualization in the BIOS.  I also then had to turn the graphics/hardware acceleration down within the guest or else the game character would get stuck when trying to go up and down stairs.
I recently tried dgvoodoo on the first Arthur's Knights game, and once I get to the player screen and try to run the actual game, I get an exe file has stopped working error message and a black screen.  The reason I tried dgvoodoo is someone else I know has the game working with this dgvoodoo method, choosing DirectX and 3D accelerated card and leaving everything else the default.
The first game also requires a patch for faster processors; the patch is available at Patches Scrolls.

Now I am wondering if dxwnd might work for these two games.  I am desperate to get them working somehow - have tried them on different operating systems over the years and could only get them to work with my original Windows 98 computer and also the Virtual PC method described above.
They were released in a similar time frame as that of New Adventures of the Time Machine, although I have no idea if the game engine/programming, etc., is in any way similar.
Thank you for your time and for your consideration.  I would sure like to be able to play these games again.
Marian

[gho]

The two Arthur's Knights games are a little more recent than Time Machine, so in theory it should be easier to manage them. That's the nice thing about theory: it doesn't always work.
There's only one way to get a sure answer: try. Give me some time ...

[gho]

The start is promising. Arthur's Knights first episode has a graphic angine similar to that of Time Machine, same privileged instruction fault and same peculiarity of requiring a loose/gain focus to continue the game after some movies.
Applying a configuration similar to Time Machine (TM from now on, for sake of brevity, and same for AK1 and AK2) the game starts, but doesn't show the 3D part (see screenshot). This is a different problem, I tried all game options (with / without acceleration and graphic enhancement) with no avail.
It seems more a D3D problem, maybe not caused by DxWnd (I set emulation to "none" but the result is the same).
I'll try to take care of it.

[Marian Apgar]

I so appreciate your efforts in looking into this. Tales of Chivalry and Secrets of Merlin are really one game broken into two parts, so if the first game could be gotten to work, I feel sure that the second one would as well.

The other little problem I had, when I got the game working in Virtual PC, was that the character did not want to go up or down the stairs but was rather just stuck in place. In the Windows 98SE guest, I turned graphics/hardware acceleration down to one notch from the left and that corrected the problem.

The reason I was encouraged to post was indeed because I saw that you had been working on Time Machine and my hope was that internally there might be some similarities between the two games.

I will be following this thread with great interest. Thank you so much!

[gho]

Also TM showed a similar bug, the main character stuck in a corner and the arrow keys just making him crouch instead of moving. Likely, a DxWnd bug since it never happened again.

AK1 is frustrating: everything works, no errors whatsoever, just the final blitting to screen that doesn't take place and all is black. Look at some of the textures that DxWnd grabbed while I was blindly trying to move an invisible man in the dark:

[Marian Apgar]

The word "frustrating," unfortunately, is what I thought it would be. Apparently the CD swapping is also broken on newer systems, but I could work around that by mounting the entire game to a virtual drive(s). Interestingly, on the Virtual PC set-up the game was completely stable and I experienced no crashes whatsoever; I did have a few when I ran it on my Windows 98 computer in the early 2000s; this would sometimes occur when I was asked to insert a different CD, but the problem always fixed itself after another attempt.

Again, I really appreciate your looking into this. I am not sure that there has ever been a game from that time period that is more difficult to get working outside of its native environment. It's a lovely game for the patient, thoughtful player, and nothing like it has been released before or since. I have been always hopeful that someday someone would figure out how to "fix" it for newer machines.

And thank you for the uploads of the textures!

[gho]

@anyone with skills in old D3D3 and legacy operating systems

The AK1 game, with DxWnd settings similar to TM, runs ok but the fact that no textures appear on screen (see screenshots above).
Using ApiTrace is possible to investigate what's going on exactly, or also reading DxWnd logs.
So far I found nothing strange (beware: last public DxWnd release has some bugs in D3D3 Viewport methods, but if you see anything strange with these operations it's simply DxWnd fault!) but (maybe) this operation:

Lock(4): lpdds=864fff8 flags=1(DDLOCK_WAIT) lpDDSurfaceDesc=18f938 rect=(NULL)
Lock: lPitch=1600 lpSurface=aca0028 SurfaceDesc: [Locked] Flags=100f(DDSD_CAPS+HEIGHT+WIDTH+PITCH+PIXELFORMAT) Width=800 Height=600 Pitch=1600 Caps=840(DDSCAPS_OFFSCREENPLAIN+SYSTEMMEMORY) Caps2=0() Caps3=0() Caps4=0()  PixelFormat flags=40(DDPF_RGB) BPP=16 RGB=(f800,7e0,1f)
Unlock(4): lpdds=864fff8 rect=(NULL)
TextureDump(4): lpdds=864fff8
Unlock OK
GetDC: lpdss=864fff8
GetDC: res=0(DD_OK) hdc=46011186
ReleaseDC: lpdss=864fff8 hdc=46011186
Lock(4): lpdds=9cc4f0 flags=1(DDLOCK_WAIT) lpDDSurfaceDesc=18f8d8 rect=(NULL)
Lock: lPitch=1664 lpSurface=4023000 SurfaceDesc: [Locked] Flags=100f(DDSD_CAPS+HEIGHT+WIDTH+PITCH+PIXELFORMAT) Width=800 Height=600 Pitch=1664 Caps=1000605c(DDSCAPS_BACKBUFFER+COMPLEX+FLIP+OFFSCREENPLAIN+3DDEVICE+VIDEOMEMORY+LOCALVIDMEM) Caps2=0() Caps3=0() Caps4=0()  PixelFormat flags=40(DDPF_RGB) BPP=16 RGB=(f800,7e0,1f)
Lock(4): lpdds=864fff8 flags=1(DDLOCK_WAIT) lpDDSurfaceDesc=18f8d8 rect=(NULL)
Lock: lPitch=1600 lpSurface=aca0028 SurfaceDesc: [Locked] Flags=100f(DDSD_CAPS+HEIGHT+WIDTH+PITCH+PIXELFORMAT) Width=800 Height=600 Pitch=1600 Caps=840(DDSCAPS_OFFSCREENPLAIN+SYSTEMMEMORY) Caps2=0() Caps3=0() Caps4=0()  PixelFormat flags=40(DDPF_RGB) BPP=16 RGB=(f800,7e0,1f)
Unlock(4): lpdds=9cc4f0(BACK) rect=(NULL)

Enabling testure dump you can see that the surface 0x864fff8 in effect received some good piece of graphics, but then nothing appeared on screen. Following that surface you see that il is locked again below and together with the backbuffer surface 0x9cc4f0, but no operation is traced.
It is possible that this game, following the tradition of its predecessor, implements a blit transfer by its own, and that operation fails with no evidence? It really seems that there is a "missing link" between a working 3D part (textures are read and processed) and the 2D part (movies and the game 2D parts are visible).

[Marian Apgar]

Interesting idea, the possibility that there is a "missing link." That would certainly help explain the craziness. I really, really hope that at some point the cause will be revealed and corrected/patched.

For now, I am SO grateful that you have taken the time to look into this!! Trying to get this game to run has been testing my sanity...

I have never bothered trying to run AK2 with dgvoodoo or dxwnd, as I figured that the same problem exists. But I will give it a try, although I sadly expect the same result.

[gho]

Let's summarize: the game has (I think) two problems:
1) the CPUID assembly instruction directs the program to use extended instrictions that are not allowed on modern operating systems
2) for some unknown reason the textures are correctly loaded but not blitted to the backbuffer surface

Now DxWnd can take care of problem #1, but the runtime assembly patches are incompatible with a debugging session (the debugger caches and destroys the DxWnd patches) so, in order to investigate problem #2, I had to hardcode the CPUID fixes in the executable.
I'm using the attached ARTHKNIA.fixed.EXE file to better investigate problem #2, but I whish to share this file with anyone would like to help. Let's hope the patcher's community will answer the call. This exe runs on Win7 also without DxWnd and shows very clearly the problem #2.

[gho]

Another interesting piece of information is the fact that the game does not require a problematic Win95 environment: it runs perfectly on a VirtualBox VM with WinXP, no need for my patch.
This will be good for comparing the good and bad behaviours.

[gho]

Here is another very important fact: the black rendering is due to DxWnd patching! If I run the game on XP with the "Disable CPU MMX support" flag I get the same black screens. If, instead, I turn that flag off, on XP the MMX privileged instructions are allowed and the game runs smoothly also in DxWnd window mode.
This suggests to find a CPUID answer that may lead the program to use some CPU feature that is both working and allowed by the OS! Let's hope there's at least one ...

[gho]

Uhm, a good idea, maybe:
Since the game runs under VirtualBOX + WinXP, supposing (my mistake!) that XP should not allow privileged instructions, I logged the VirtualBOX CPU answers and emulated them by DxWnd.
This way the game should behaves on Win10 as if run under VirtualBOX. Unfortunately Win10 is more picky and not everything went ok, but the following Win10 screenshot is anyhow an improvement, isn't it?
.

[gho]

Ah, much better now!
There are aonly awful clipping problems but that is (maybe) more manageable.

[gho]

A good ZBUFFER cleaning and the clipping disappears, but the continuous interrupt handling is making the game a little choppy. Well, anyway not a bad result for today.

[Marian Apgar]

Thank you again so much for continuing to investigate this problem. I am on Windows 7 so haven't been able to test the game on Windows 10. I did try AK2 yesterday on Windows 7 and as expected, after choosing my player and trying to run the game, I received the exe file has stopped working message along with a black screen - exactly the same problem I am having with AK1.

[gho]

As I feared, it's quite too early to say "hurray!". Playing to be a rude exception patcher exposes to some risks. Here is the result of same settings on Win7: you can't see that, but it kept rotating! ;)

[Marian Apgar]

At this point I would almost be willing to try to play the game that way - seeing something other than a black screen, I could almost consider this to be playable. LOL!

[gho]

Playable? I doubt, but that depends also on your luck. As a matter of fact, this configuration was perfect on virtual XP, good enough on Win10, impossible to use on Win7. Since the idea is bypassing the hundreds of exceptions that are generated by privileged instructions, you don't really know what may happen. Good luck!
Anyway, be aware that I'm continuing hard my work, I have some interesting ideas to implement (unfortunately, quite ambitious but not so simple, so it will take some time ...) so this is not the last word about these games.
Try using this exported file in attach, then:
1) update the path field according to your game install folder
2) after the intro movie the game hangs: you have to Alt-Tab to lose focus and click inside again to reacquire it and unbloc the game
3) Use hardware acceleration in the game options panel, software mode doesn't work.
4) Let me know what happened ...

[gho]

I promised some news, and here I am.
Peeking inside the game I found that it has 7 (seven !!!) rendering modes plus a 8th default one that are selected according to CPU features and maybe DirectX capabilities. But understanding how it determines which one is the good one is not an easy task. A good compromise solution was to patch the executable in a way that forces the program to select the default rendering mode, that is one that uses no 3DNow!, MMX, SSE or other features that may be disabled on Win7 and later.
This works fairly well, provided that you select video acceleration and let DxWnd fix some ZBUFFER cleaning. So, just for now be happy with these instructions:

1. copy ArthursKnights.exe on the game folder
2. import the attached export file in DxWnd and fix the game path
3. Run the game and, before starting the gameplay, in the game options select accelerated mode
4. Now everything should be fine (well, almost ... there are still some texture z-ordering problems)

Of course, this solution requires a patched exe, so it won't work with the second chapter until either I fix that exe too, or I find a better solution with DxWnd only. We will see ...

[Marian Apgar]

I really can't thank you enough for spending so much of your valuable time on this; it really means a lot to me, and I know that it will to other players as well. I will have some time this weekend to follow your instructions and to do this, and then will report my findings! :-)

[gho]

The game blocked after the fairie's movie .... work isn't finished, perhaps ...

[Marian Apgar]

I was going to give it a try today. Perhaps I should wait a while, then, in light of your recent findings. Maybe trying to get this game working on Windows 7 will prove to be a lost cause, unless I use VirtualBox or something like that? If that is the case, so be it, but you have really made great progress!

[gho]

I would suggest to give it a try just in case you get other problems, better know them all asap

[gho]

The game crashed again on a forbidden FPADD instruction belonging to the 3DNow! extended set. Apparently, after the first into part and the movie the game selects again the 3D rendering procedures using some different logic from the code that I already patched. I could search and patch this code as well, but it's not an optimal solution because I don't really know how many times and where the patching is needed. It should be better to emulate a "special" environment (CPU, capabilities or whatever) that could work in any case.
Too bad that the game crashed just before I could walk in this beautiful scenario that I could only recover from the dropped textures.

[Marian Apgar]

Yes, I understand what you are saying. I will download and install Virtual Box one of these days with Windows 98 as a guest. Hopefully with a little time and patience I will be able to get the game running that way. Thank you again for your time and effort expended with this game. It is much appreciated.