Wow application mirror with another GUI

[Fbx]

How possible is this? Some people's UI is too complicated to understand, and they movies/streams are not successful, while they are good players.If we could mirror the whole game client to another monitor and somehow configure default game UI there. As I know such tools not exists at the moment, but maybe programmers can give some answers or ideas, thanks.

[Fbx]

If we could only render game without GUI on second monitor (while keep rendering with your normal UI on first monitor, where player actually playing) this problem could be probably solved.
Using any viewport addon we can show default UI on black screen of third monitor, overlay it on second monitor while recording video (or record separated, but merge when making video).

[namreeb]

That is an interesting question. I suppose you could hook the appropriate graphics engine functions for rendering, mirror the output to cloned device, and combine that with a hook to the function that handles rendering the interface. That's assuming there is one, but since there is an easy way to toggle the interface, I imagine that there should be. This would result in no interface being rendered on the second display, rather than the default one instead.

[Jadd]

I thought about this pretty well in-depth a while ago. But it's a lot of work, I never even began writing it.

1. Load the world.
2. Copy current objects.
3. Hook player movement functions and forward them to the viewer client.
4. Hook CGObject_C constructors/destructors on host, create and destroy them on the viewer's client.
5. Forward incoming packets to the viewer's client. Game server -> host client -> viewer client.

It sounds easy, but 1, 2 and 3 will probably cause a few headaches. And of course, without any prior testing, there's probably a LOT I'm not accounting for. The viewer client is going to get confused a lot without a LOT of hacks and tweaks.

[Frosttall]

I thought about this pretty well in-depth a while ago. But it's a lot of work, I never even began writing it.

1. Load the world.
2. Copy current objects.
3. Hook player movement functions and forward them to the viewer client.
4. Hook CGObject_C constructors/destructors on host, create and destroy them on the viewer's client.
5. Forward incoming packets to the viewer's client. Game server -> host client -> viewer client.

It sounds easy, but 1, 2 and 3 will probably cause a few headaches. And of course, without any prior testing, there's probably a LOT I'm not accounting for. The viewer client is going to get confused a lot without a LOT of hacks and tweaks.

Why not hook the function which accesses the current render-device (aka the current DirectX-Viewport) and forward these actions to a self-created viewport and call the original viewport aswell. It should display the whole game including the custom UI, but proves that it is working.

From this point check the stack trace on each call to that hooked function and determine which function has the job to draw the interface. Now start playing and there could be magic happening.



Your way would basically copy the technical background of the whole action which is happening on the client, even though only the visible part is important.

[Master674]

I thought about this pretty well in-depth a while ago. But it's a lot of work, I never even began writing it.

1. Load the world.
2. Copy current objects.
3. Hook player movement functions and forward them to the viewer client.
4. Hook CGObject_C constructors/destructors on host, create and destroy them on the viewer's client.
5. Forward incoming packets to the viewer's client. Game server -> host client -> viewer client.

It sounds easy, but 1, 2 and 3 will probably cause a few headaches. And of course, without any prior testing, there's probably a LOT I'm not accounting for. The viewer client is going to get confused a lot without a LOT of hacks and tweaks.

1. Hook CWorldSceneRender::Render
2. Copy Color Buffer to a second Texture that you use later on (can be done in DirectX)
3. Write this blank world frame to a new window (doesn't have any UI but it would look like in a screenshot).

Easy to do, can be done in 1-2 hours.

- Deferred shading technique could cause some trouble if the frame isn't written to the color buffer until after the UI has been drawn but for forward rendering this method should work.

[Jadd]

1. Hook CWorldSceneRender::Render
2. Copy Color Buffer to a second Texture that you use later on (can be done in DirectX)
3. Write this blank world frame to a new window (doesn't have any UI but it would look like in a screenshot).

Easy to do, can be done in 1-2 hours.

- Deferred shading technique could cause some trouble if the frame isn't written to the color buffer until after the UI has been drawn but for forward rendering this method should work.

This would use just as much bandwidth as a normal stream (Twitch), my point was to avoid that. Mine also allows for a better spectator vision (free camera etc.).