Why is that RO runs so badly even in ultra high end systems?

[qwiojhqwoid]

Aside from bad programming on Gravity's part, why is that RO runs so badly even with an "ultra" high end system? (Example: a 6700k, low latency DDR4, PCIe SSD, 1080 GTX 8GB)

I'm looking for solid information about this, since I don't really know how else to measure it and I don't have deep knowledge about gaming or systems programming. From what I could find, the client is still using DX7 (or some kind of DX9 adapter, not sure). Gravity was working on a DX11 port but I can't find any information if they will ever release a complete version of it.

Anyway, here's what I concluded in my tests in the system mentioned:

• None of this have significant impact on getting constant 60+ FPS without drops and decent frame times, if they are properly configured or installed: drivers or Windows library versions, anti-aliasing or anisotropic filter settings, CPU priority, screen resolution, fullscreen on or off (if you have the ddraw fix installed, it's the same as borderless window fullscreen, since the low fps here is caused by a bug), custom dinput, any of the ingame settings like /skip /lightmap, power settings that might cap resources turned off, GPU shader caching. What I mean is, none of this is going to magically solve the FPS problems. It's not hard to get 60 FPS, the problem is frame drops and bad frame times. And the cause for that is something else!
• Some hack shields can make your average FPS worse, but I don't think they are the root cause since a pure hexed still suffers from the same problems.
• Replacing all the spr/act files (for player visual items) with empty one's have almost zero impact on FPS. Same thing for effects (str, bmp, tga). At the same time, if  you stand still in a city like prontera with a lot of autotraders, your FPS will drop to 30 or less, screen tearing all over the place. Turning packetfilter on doesn't help. What causes this?
• At the same time, turning effects off does help with the frame drop problem. Why is that loading close to 0 bytes files doesn't help but turning effects off does? Even after they are alreaded loaded (and in memory) you don't get the same benefits. Does it turn off some kind of indexing?
• Grey world GRF does help but only if you would have less than 60 fps, so again, it doesn't help improving frame drops and latency.
• Water cells are indeed one of the problems, I wish I could remove them all without editing maps or using grey world. If you know how to do it, please share.
• Some maps like arug/schg runs like complete shit.
• Some, but not all, older systems suffers less from frame drops and tearing (while having lower average FPS). Probably has something to do with newer GPUs and drivers losing optimizations.

So, what exactly causes the game to drop frames, have weird screen tearing (even with some kind of vsync forced with double or triple buffering), stutter or have bad frame times? What is the resource that the game client needs? What's the bottleneck? What can I feed this dog for it to stop barking?

Edited February 18, 2017 by qwiojhqwoid
typo

[Ai4rei]

Part of the issue is that the client was designed during the Win9x-era, where the GPUs weren't all that great with 3D rendering and CPUs were single-core (I still use this kind of system as main, so I can compare). Graphics are rendered by DirectX and all graphics card power makes difference in the game fluency (even an upgrade from a 8MB GPU to 32MB GPU is like two different worlds).

But there are few factors in the modernization, that may be partly at fault, why the client chokes on newer systems:

• Back then your typical resolution was 640x480 or 800x600, or if you were very high-end you could play on a 1024x768(!) resolution. The code in use is increasingly inefficient with today's resolutions like FullHD or 4K (that also are no longer 4:3 / 3:2 ratio as was common back then, which causes screw ups on certain ultra wide resolutions).
• There is something, that is not rendered by DirectX and that is all text. Text is rendered by the GDI, the Windows raster graphics engine. While this engine was hardware-accelerated (just like DirectX) in Windows XP and older, since Vista the GDI is (mostly) software-based to allow hardware-accelerated DWM for 3D-effects in Windows UI (e.g. Aero). This is also why plain GDI applications run slower on Vista and newer than they did before on the same hardware. Under certain conditions text rendering by GDI can cause delays on Windows XP and newer due to some Unicode handling, that is absent on the Windows 9x platform.
• The client is a multi-threaded application, designed for single-core systems with the assumption that two threads will never run at the same time, so some synchronization between the threads can take out any advantages from multi-core systems, or dead-lock the client in the worst case. Also some update in the last few years introduces an unidentified thread-leak into the client, so there may be delays from contention between synchronized resources.
• Another issue introduced in the last years, mainly with the introduction of Lua and new features based on it, is increased RAM usage (not just the amount of memory consumed, but also the amount of memory blocks), mostly during startup. This incurs delays during allocation/freeing, not all that visible on powerful systems today, but on the older ones you notice a sudden increase from a 5 second start up time, to 2 minutes.

Hope this helps your investigation somewhat.

Edited February 18, 2017 by Ai4rei
copy-editing