#1098 Alternate overlay implementation path for clients that want to pull overlay information

Unassigned
open
nobody
None
5
2014-05-07
2013-04-30
No

I like to sketch a proposal for making an opt-in API to allow game clients to render the overlay without requiring DLL injection or hooking Direct3D APIs. This would reduce some crashes, and allow games to skin the UI for Mumble appropriately for the game content. Sorry, but I am sketching this proposed feature without knowledge of the precise techniques Mumble uses to generate the overlay, or of Mumble's overall code architecture.

The client software would check for the existence of Mumble in the process address space with GetModuleHandle, and then retrieve one or more entry points for the opt-in API with GetProcAddress. Calling these procedures would disable the automatic overlay, allow polling of the state of the UI features to display and the user list.

Related

Feature Requests: #1098
Feature Requests: #1155

Discussion

  • Kissaki
    Kissaki
    2013-05-11

    Replacing injection logic with provided functions the game itself calls would certainly be good, from an architectural point of view. Less hacky.

    For a mumble DLL to be available via GetModuleHandle it has to have been loaded by the process already. The DLL loading would thus have to stay.

    The current injection code also injects the CreateDevice function.
    For the game developer the implementation would not be as simple as calling a present function; he would have to adjust his device creation (D3D initialisation) etc.
    (Otherwise, the injection code would have to inject anyway, because it does not know yet whether the game will present on its own, or if mumble has to present.)
    I’m not sure how applicable that would be; and especially how many developers would actually go through the work of implementing this correctly.

    An initial implementation would just allow third parties to call the necessary functions for presenting the overlay.
    Providing data and allowing them to draw their own overlay in their own style would be much more work / more complex.

     
  • Hi Kissaki,

    I’d like to introduce myself: I’m the lead graphics programmer at Cryptic, Dave Richardson. I reported the crashes and filed this tentative feature suggestion due to crash reports we’ve been seeing in our games. I’m sorry I don’t yet have more solid information to give you. The earliest crash report I’ve seen for Mumble was about a year ago, if I recall correctly.

    Thank you for the detailed reply. I’m not sure if it’s the injection that’s the problem, since I can’t repro the crashes. As I get more information, I’ll update the bug report (#983). For now, though, I would appreciate if you would list our game’s compatibility issues on your Wiki.

    Let me know if there is any specific information I can give you that might help you resolve this compatibility issue.

    Sincerely,

    Dave Richardson
    Cryptic Studios

    From: Kissaki [mailto:kissaki@users.sf.net]
    Sent: Saturday, May 11, 2013 7:53 AM
    To: [mumble:feature-requests]
    Subject: [mumble:feature-requests] #1098 Alternate overlay implementation path for clients that want to pull overlay information

    Replacing injection logic with provided functions the game itself calls would certainly be good, from an architectural point of view. Less hacky.

    For a mumble DLL to be available via GetModuleHandle it has to have been loaded by the process already. The DLL loading would thus have to stay.

    The current injection code also injects the CreateDevice function.
    For the game developer the implementation would not be as simple as calling a present function; he would have to adjust his device creation (D3D initialisation) etc.
    (Otherwise, the injection code would have to inject anyway, because it does not know yet whether the game will present on its own, or if mumble has to present.)
    I’m not sure how applicable that would be; and especially how many developers would actually go through the work of implementing this correctly.

    An initial implementation would just allow third parties to call the necessary functions for presenting the overlay.
    Providing data and allowing them to draw their own overlay in their own style would be much more work / more complex.


    [feature-requests:#1098]

    Alternate overlay implementation path for clients that want to pull overlay information

    Status: open
    Created: Tue Apr 30, 2013 06:15 PM UTC by SuperAnonymousDave
    Last Updated: Tue Apr 30, 2013 06:15 PM UTC
    Owner: nobody

    I like to sketch a proposal for making an opt-in API to allow game clients to render the overlay without requiring DLL injection or hooking Direct3D APIs. This would reduce some crashes, and allow games to skin the UI for Mumble appropriately for the game content. Sorry, but I am sketching this proposed feature without knowledge of the precise techniques Mumble uses to generate the overlay, or of Mumble's overall code architecture.

    The client software would check for the existence of Mumble in the process address space with GetModuleHandle, and then retrieve one or more entry points for the opt-in API with GetProcAddress. Calling these procedures would disable the automatic overlay, allow polling of the state of the UI features to display and the user list.


    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mumble/feature-requests/1098/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Feature Requests: #1098