Reply: Is their a hidden Direct X or vulkan backend? AMD RX 570 poor Open GL peformance

Sure CHIEFISREAL#7013

Thank you for the bug report, it looks like a crucial bugfix I did for the next update is still incomplete. I would like to investigate more into this. As the bug does not occur on my PC, can I get your Discord or any other instant messaging platform contact details so we can debug this faster?

I downloaded your optionsGui.cs file and put it in PQ/platinum/client/scripts folder along with the already existing optionsGui.cs.dso file that's their and nothing changed when launching from the Game directly. Still broken like my screenshots, big sad. Also, on my Nvidia PC screen is zoomed in to the bottom left quadrant with or without your new file. Tried alt = enter to maybe hope for a windowed mode shortcut so I could set a new Screen res and the game crashes. Attached is the Nvidia PC screenshot.

Am I missing something?

Thanks!

Between 3 weeks to a month before the next update, if lucky, it can happen earlier.
The explanation for your question I could find out was www.reddit.com/r/computergraphics/commen...below_60_if_without/

Any ETA on when the next update would come out?

Ill try those files if that allows me to use fast sync then ill consider this to be a good workaround for AMD GPUs. Is their any technical explanation for how a game would perform better at higher framerates then lower ones? Just curious.

Thanks!

Oops sorry for the bugs, you can fix those if you download this file here and put it in PQ/platinum/client/scripts/optionsGui.cs. This should fix the broken "lower resolution rendered at higher resolution" bug. However you won't be able to get into the Online leaderboards for a while until the next update when this fix will be in it.
Fast mode tries to reduce the "amount of torquescript running per frame" by disabling/reducing calculations of certain things such as cannon trajectories.

Ok...I am confused

My initial results of testing those newer OpenGL binaries were that the issue has been fixed and the massive stuttering is gone! However, I went back to the old binaries and that one level in marble blast gold that had the massive stuttering, and it still didn't stutter with the old ones.

But with the newer OGL binaries there are other levels in the ULTRA maps that stutter for 2-3 seconds and then play perfectly fine after that, so I think 4.6 dose have an Improvement for AMD and maybe should be implemented into main game.

But things get interesting after that: I did some other testing and both with the new binaries and the old ones if the frame cap was set to 100 the game ran perfectly fine regardless except massive frame tearing. I then went to add the game to my AMD control panel to activate fast sync considering my 1080P projector is 60hz and I need around 100 FPS to remove all stutters I go to launch the game itself and its very broken when not launching with the launcher (pics attached I couldn't describe this if I tried). I tried adding the launcher itself, but my fast sync setting didn't apply to the main game because I had the launcher selected. Expected that but still tried. This strange behavior happens on both my AMD GPU pc and Nvidia as well. The AMD GPU performs more consentient at a higher framerate then a locked lower one. Usually, lower frame rate caps are established to maintain more consistent performance but for this case I had to do the opposite with a dramatic improvement to smoothness.

If I could launch the game directly and not use the launcher but only to check for updates I, then could use AMD fast sync with a 100 fps cap and any frame drops I would have would be above my 60hz projectors output therefore would produce a perceived flawless experience. Is directly launching the game possible? Is this fixable? Is their another way to add MBP to the control panel?

Thanks!

(None of the images are cropped in any way or form this is just how the screen looks.)

Also what is fast mode in the game settings do? Seemed to do nothing when I tried it.

For the wrapper I mentioned, the "per-app" installation does not seem to work with PQ on my system and I have not tried the system wide installation(would rather not). The answer to all the settings is "no".
As for the binary, it is in the attachments, replace <PQ Install Location>/plugins/GraphicsExtension.dll.

Yea those binaries sound useful I can definitely check them out.

I also came across that wrapper I was playing with it earlier today but some of the options I don't know what to select maybe you can help?

64 bit app? No, I know that one
Do I want Desktop open GL drivers?
Do I need OpenGL ES support?
off screen rendering?
Graw Library??

Thanks!

I appreciate the incite! I am a computer Science student, but we haven't done anything like this yet. Best I can do is try RandomityGuys 4.6 GL binaries and try the vulkan wrapper.

Speaking of which I'm looking into the wrapper atm it seems far more straight forward then the documentation makers it out to be. it asks me some questions I'm not sure what answer to put for some of them maybe you can help?

64 bit app? No I know that one
do I want Desktop OGL drivers?
Open GL ES support? what dose this mean?
off screen rendering?
graw library?

Regardless ill probably pick up a rtx 4080 when it comes out and replace my RX 570 with my current GTX 1080. Amd's biggest problem is OpenGL always has been everything else works fine but OpenGL just crashes and burns quite sad. AMD should just release a driver level wrapper that can be turned off and on at this point per app. Even with all the bottlenecks in the game my 1080 pushes out 144 frames a sec with no hiccups. NVidia's OGL is just unbeatable.

Thanks Again!

We looked into rewriting the parts of the engine that used immediate mode OpenGL 1.1 graphics, somewhere around 2015. We determined that trying to patch such a change into the game was way outside the ability of anyone on the team, and the best we could get would be OpenGL 2.1 under the compatibility profile with some basic shaders. So what we ended up with was a weird chimera hybrid of 2003 immediate mode rendering code (CPU tells the GPU where the triangles are, one vertex at a time, it's really slow) and a 2015 implementation of shaders from like 2006. The amount of context switching the game ends up doing is considerable, trying to support both of these different pipelines on each frame, and the costs add up pretty fast.

At the time we were testing on a couple different setups, notably Intel Iris Pro (MacBook Pro ~2015) and GTX 1060/similar. This was before AMD GPUs really took off again and we didn't have the resources to test on systems other than the ones we used daily. My FPS target upon release of 2.0 in 2017 was 60fps on that MacBook in nearly all PQ levels. Since then, more features and graphics settings were added, decreasing frame rates without as much performance testing. Combine that with hardware/software moving beyond those older graphics modes, and many implementations just being shims over modern APIs (OpenGL on M1 is just a crappy wrapper around Metal), the frame rates never really recovered.

Also mentioned by RandomityGuy is how the engine itself is single-threaded, and the scripting language is really slow. There is A LOT of script code in PQ that executed every frame, and it can take upwards of 5-10ms on a decent setup. We ported a number of features to C++ that were really slow in MBP <2.0 (radar, network physics, and the new team ported moving objects), but even so there is plenty more that was not. Scripting overhead is not super affected by Wine/M1 translation the way rendering was, but it still adds considerable cost to every frame.

Reverse engineering for MBP/PQ was mostly done using Hopper Disassembler ($80) because it was available for macOS and cheap. A couple people used IDA Pro, but licenses for that start at around $10,000 so you probably won't get your hands on a legal copy. Later on in development, other tools like Ghidra (free) and Binary Ninja ($300) became available and we played around with them, but by that point the mod had shipped and most of the development had been scaled back. These days there is also Cutter (uses Ghidra's backend but with rizen as a core?) and angr Management (under heavy development and imo unusable), but since Ghidra is free and legal that's probably what you'd use for this now.

Most of the reversing I did was on straight assembly since Hopper's decompiler was hot trash, but the people using IDA had access to decent decompiled source code that was a lot easier to read. I would recommend a good decompiler if you're starting out, since assembly (and x86 in particular) has lots of weird semantics that are confusing and require you to read lots of manuals to understand what is going on.

The general process used for reversing the game was to look for functions that sounded like they did what we wanted, and then replace them with our own versions. We were lucky that in the mac version of MBG, the function names were still available. This made it pretty easy to search for functions by name, which we could then use to find those same functions in the Windows version. That process was generally done by looking up strings that were used only in our target functions and finding functions on the Windows version that had the same strings. It worked pretty well. Also helpful was finding the VTables used for all the C++ classes, which showed us where all the virtual functions were for each class.

Secondarily, we also had to reverse engineer structures and classes used in the engine. Luckily for us, we found a copy of a very similar version of the Torque engine, and most of the header files lined up with what MBG did. In cases where there were differences, we cursed a lot and basically just guessed as to what each member of a structure did, using clues from the assembly/decompilation for more accuracy. Hopper had extremely garbage support for structures, so this was mostly just throwing numbers into a header and running the game to see what values came out.

If you're interested in reverse engineering and have a decent computer science background, I would recommend looking into beginner-level CTFs like OverTheWire. I ended up getting a career in that industry, aided by all the skills I picked up reverse engineering MBG, and it's a challenging but rewarding space if you're interested. Also the salaries are astronomical in case that matters to you.

Whew this was a bit of a diversion. Hope this clarifies some of the process by which PQ got to its current state. It's hard to teach an old engine new tricks and you can really see in the subpar performance. I'm not sure of any good solution other than someone like RandomityGuy pouring 100s of hours into profiling and optimization, and I don't think he'd particularly want to do that. You might see some gains with an OpenGL wrapping layer, but the overhead of translation is probably not greater than the savings, and it won't do much to improve script performance. It's worth a shot though if your performance is bad, I just don't know any tools for it off-hand that I would recommend.

Unfortunately I only tested the OpenGL 4.6 hack on my own NVidia GPU. I can send the patched binaries if you want to test.

So far the only OpenGL to Vulkan "wrapper" I could find was Zink , which you could try to see if it works before I actually add support for it, which is much easier than the backend rewrite.

As for reverse engineering the binaries, you need a IDA/ghidra disassembler(any disassembler works as long as it has "translate to C"), the Torque Game Engine source , the MBG windows and mac binaries and C/C++ knowledge. Then you throw in both the windows and mac binaries into the disassembler. The mac binaries still have their function names and symbols into it. Then the "task" is to find the appropriate functions that you want to override in the windows disassembly by comparing the with the Torque source code as well as the mac disassembly, theres lots of operations that is "obfuscated" due to it being converted into pointer arithmetic such as accessing class members/fields. One of the most easily accessible things in either of the binaries is the virtual function table, basically a list of consecutive virtual functions for a class, the order being the same in both the binaries. Once you find these out, you can find the starting points of from where to carry out the above task. Once you find the appropriate functions, you then copy its address and make a new entry in the MBExtender source code in the appropriate location, and then you can override that function using the extender plugins. You can see the plugin source codes , the function addresses , etc in the above mentioned MBExtender source.

Sounds like I actually got to a Dev..Cool!

Which Gpus did you test with the 4.6 OGL? I would think the AMD gpu would benefit at least some in that jump.

I've been looking into OGL to Vulkan wrappers but it's all a little over my head even as a computer science student, could some implication of a translation layer possibly be added? I figure that would be simpler than a from scratch Vulkan backend rewrite, by a lot. Has this by chance been experimented on?

The nature of OGL is hurting AMD here I'm sure as well as AMD seems to stick to stock OGL and is single threaded bound while NVidia has some hacked multithreading thing going on boosting the performance from what I've read, and I suppose after reading above brute forcing its way to run MBP with high frame rates when literally nobody else can apparently.

Out of curiosity and the fact I'm bored out of my mind whit all the time in the world what would be some of the first steps in reverse engineering the binaries? like what tools are used etc. Problem with my programming assignments is their all boring to me I have no connection to them therefore don't really care, this I care about therefore I'm interested in learning more.

Anyways thanks for the nice conversation regardless!

I did try to bump the OpenGL context version to 4.6 once for testing and it did not improve the performance slightest. Most likely due to the fact that the game is still using the obsolete OpenGL immediate mode rendering. This can only be changed by...rewriting all of the rendering code for everything to use modern OpenGL features.

Vulkan backend could in theory exist if a large amount of time was invested in making it by doing the rendering code rewrite. It is not something I or the other devs can do currently.

PlatinumQuest scripts are open sourced at github.com/The-New-Platinum-Team/PlatinumQuest-Dev However the engine that the game uses is not and we do not have its sources so we cannot recompile the binaries. PlatinumQuest instead uses github.com/RandomityGuy/MBExtender to inject code into its binaries for various features such as shaders. So a rendering rewrite will also involve reverse engineering the binaries to find where the rendering functions are located and what data is used by them so that it code can be injected in those places.

TLDR: It's a mess due to the game using obsolete methods of rendering and a rendering rewrite is not currently feasible.

Sounds like performance is bad across the board on everything but an Nvidia Chip. Open GL 2.1 is quite old and isn't helping my AMD GPU issue at all and I suspect is the source of the problem. Is there any way to bump the OpenGL verson up to 4.6+ (I know this is easier said than done probably)? This mirrors the Minecraft issue people with AMD gpus have where they had at least in the past terrible performance in Minecraft due to its very old version of OpenGL it used but then Use a mod like optifine or sodium to use a much more modern verson OpenGl eg: 4.6+.

Now since this a cross platform game with mac and windows (I get why direct x isn't a thing now), mac has depreciated open GL support, but older versions still work however to my knowable Vulkan is fully supported in MacOS, performs well across the board on basically everything (except intel igpus ive herd) and is more multithreaded in nature. I know this is asking for the world but in theory would it be possible for a vulkan backend to exist? (I know this is a hell of a lot easier said than done but I just want my marble to run smoothly lol) also is this project open sourced?

One odd thing ive noticed on problem levels which includes marble blast gold level pack intermediate level 1 ramps, it would stutter for a while then be perfectly smooth on my AMD rx 570 kind of acting like emulators are when shaders are being generated but then if I backout to the level and go back in it still stutters again.

Anyways thanks for your incite hope to gain even more on this. I first played marble blast gold in a mac lab in 7th grade and the game stook with me.

The version of OpenGL rendering done by PlatinumQuest comes under OpenGL 2.1 immediate mode rendering which modern hardware does not seem to like (except for the shaders/post processing, they use the modern rendering methods).

People running the game on M1 mac through wine face heavy performance issues(~15-45fps) and bugs. On Intel macs, the performance isn't much better.

One of the major bottlenecks of the game is that it runs on a single thread and interpreting a fair amount of Torquescript every frame due to which combined with immediate mode OpenGL, the rendering is tied to how fast the engine can process this code.

I see well then remove information that says AMD GPUs are supported because in reality there not because it's a stutter mess that's easily reproduceable. AMD GPUs can do everything but edge cases where Open GL is used. I'll get a Nvidia GPU for the secondary system then. Disappointing.

How the hell dose this supposedly work on Mac when Macs use AMD Gpus and this is open GL based? Same problem would exist unless people are happy wither stutters and don't mind terrible frame consistency that's my only explanation.

Last question I've herd latter versions of Open GL Eg: 4.6 work better with AMD gpus then older versions. What Version is MBP using?

Thanks!

There is no DirectX support in PQ. Support in MBG was flaky at best and PQ dropped the feature for easier compatibility between mac/windows renderers.

The reason you're not getting a good response is because I don't think anyone really knows if DirectX even exists in PQ anymore. The original developers are not working on this project anymore. You could however still join our discord server if you still wish to speak to the current developers. discord.com/invite/UEkTDwg

Soooooooo is there an ETA on when I might get a useful response on this