Widescreen hack and some other fixes aka AiO Patch

[UCyborg]

How did you come to conclusion that the server needs 3D capable card? Because it doesn't from what I can tell. I don't know about Blt performance. What would be the "normal" speed of the server? Using DirectDraw for the server console is unusual, that's for sure. At least you can minimize it to make it use less CPU, it's still more than if the NULL renderer is in place. Blt is called regardless of console window state.

I found the function that deals with DirectMusic and made it return if we're in dedicated server mode. So DirectMusic is no longer invoked when the dedicated server is running. That would be it, we're at version 2.164.

[Mechanist]

Because I tried running it on a non-3D-capable card?

Also, IIRC the server code specifically calls a Direct3D function which asks for 3D caps, I remember having to deal with that in my NULL renderer.

In fact, I'd have to look it up in Olly again, but there's a check that specifically bails out with an error message if the video device doesn't support 3D caps, even if it's running as a dedicated server.

My NULL renderer does the usual thing, reports itself as being capable of everything that's needed, but actually does none of it.

Don't know about the normal speed of Blt, but from what (very little) I know about it, the bit block transfer operations were historically fast, much faster than using MOV or even REP MOVS operations (although the latter point might well be moot, since bit blit originated on hardware which did not support anything like the REP prefix).

The interesting thing is, when I'm accessing the (unmodified) server through a remote connection, the server update rate drops to a crawl (<30 updates/s) whenever the server window is not minimized. That's on modern (and fairly decent) hardware...

In any case, at only 2 opcodes, my NULL implementation of Blt() can't possibly be optimized any further.

At least you can minimize it to make it use less CPU,

With the NULL renderer, I can't even measure the CPU usage, it's off-scale low, always shows as 0.0%...
And before you ask - yes the server is actually running. I can't see the console obviously, but I can connect clients to it just fine.

So whatever is causing the slowdown and excessive CPU usage... it's evidently something in DirectX. I suspect Blt(), since it gets called the most?

[UCyborg]

Strange, I tried it in Safe Mode with Networking, so no graphics drivers were loaded. It shouldn't slow down neither when connected with Remote Desktop.



Built-in frame limiter for dedicated server is a bit bugged (type maxrate ##). Up to certain value is OK, then it doesn't work anymore. Update Rate display might be also bugged at higher rates, when you set the limiter high enough that it bugs, eg. 500, then it shows approximately 2300 FPS. It doesn't occupy single core at 100% when it happens.

[Mechanist]

Hmm, some quick testing shows that although the SERVER does not actually request any 3D caps, the Riot Engine Options dialog for the server DOES require 3D caps. Ridiculous, if you ask me...

That's why it did not work for me in that case, since there were no preexisting registry settings so it automatically invoked the options dialog - which found no 3D capable devices and bailed out with the error.

Try running the dedicated server with -setup option...

Remote Desktop slowdown is massive in my case, no idea what causes it. Maybe it's because of how the "fake display driver" for Remote Desktop works.
For the record, that machine has no monitor connected. Maybe it's somehow related to the problem. I know for sure that it makes the server start up with a blank (completely nonfunctional) console window if it's launched through autostart.

However, I feel that the discussion is primarily academic, since the current system is thoroughly, fatally flawed down to its core, and I will be overhauling it completely in the upcoming months as time allows.
The idea is to make Drakan.exe have no text IO when running as the dedicated server, with the text IO handled by an external launcher .exe which will also take care of restarting Drakan.exe when it crashes.
The launcher will also run the voting code and all the other extensions.

Since that will involve Drakan.exe interacting only with the null renderer instead of the real DirectX, I don't think there's any further point in hacking up the existing code which enumerates the devices etc; the null renderer already makes short work of it.

[UCyborg]

Somehow the FPS/rate counter stopped bugging when I tried it again this time without me doing anything. It did work much slower when started via Remote Desktop session, though the FPS was still around 110, while normally it goes up to about 2000 FPS. The console was empty if started before connecting to machine with Remote Desktop, unless dgVoodoo was used (which dropped max FPS to approximately 600), though restarting it then didn't work. I guess because dgVoodoo doesn't fall-back to WARP on its own. I probably left dgVoodoo in place last time; then the server console still worked when connecting with RD at the same speed.

I didn't get any error when invoking Riot Engine Options dialog though, even when server was autostarted on a VirtualBox virtual machine without graphics controller.

[Mechanist]

I'm just getting really tired of having to deal with the dedicated server and all the technical issues that come with it and its broken-ass console display.

Another bug with it is that the console display is sometimes missing entire rows of pixels in the displayed text, making some of the text mangled and unreadable - and it seems to be a drawing issue, since minimizing and restoring the window does nothing to fix it.

Also, ultimately I'd like to run the server on some really lightweight device like the Raspberry Pi, and if that's to be at all possible then all the inefficient window drawing code has to be neutered anyway.

[UCyborg]

Or the oddity with "Server launch sucessful!" message not appearing under certain circumstances.

[Mechanist]

I think that one happens because of the window contents becoming reset by the subsequent draw calls?

[UCyborg]

Could it have something to do with the length of the text showing the current level? It's like it shows when starting certain levels but not for the others.

If you pass NULL for one Blt parameter that has to do with color filling or something, it can be seen (things go garbled) And also if you pause the code after each frame before it disappears.

When starting Alwarren at least, it's not seen with English version, but it is on at least one non-English version. I forgot which one I tested.

Interesting exception, it stays normally on English version when starting Alwarren if you run the server on Windows NT 4.0. Run it on Windows 9x, any modern Windows version with or without some sort of DirectDraw wrapper and it disappears again. I didn't investigate any further.

[Mechanist]

Huh, very odd.

I wouldn't bother with it though; not only is it unimportant from a practical standpoint, but eventually I'll just replace the functions which draw messages to the screen with my own code, which does not.

[UCyborg]

Small update has been released. I fixed an issue with enabled FPS limiter/vertical synchronization having a negative impact on loading times and added support for automatic port forwarding using NAT-PMP and UPnP protocols.

[Mechanist]

Ok, thanks.
I've got a major update of my own patch coming up, with a lot of engine extensions. But it will take a few more weeks to wrap it up.

So what was the deal with the loading times being affected by frame limiter/VSync?
And do you think that could be related to the multiplayer "stuck at 99% level load" bug? I never did get to the root of that one, not yet at least.

[UCyborg]

Had to re-upload due to some silly mistakes. Regarding loading, you have to go through front/back-buffer swapping function after updating the loading bar to see the results on the screen, where VSync and frame-limiting takes place. So these things are now disabled in such scenario. It won't help with that 99% bug.

Unreal II is one of the most profound examples showcasing this mistake. I guess it updates the bar frequently in very small increments.

[UCyborg]

One more issue fixed in the port forwarding code.