Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicode support #32

Closed
iHimiko opened this issue Jun 9, 2017 · 9 comments
Closed

Unicode support #32

iHimiko opened this issue Jun 9, 2017 · 9 comments

Comments

@iHimiko
Copy link

iHimiko commented Jun 9, 2017

Hey, guys! I liked your implementation, but there are some issues related to rendering text and other elements of overlay.
(1) No Unicode support
(2) When drawing multiple elements, the one that should be in the background will go to the front of the cover, and it should be visible

I could build a library with Unicode support, but there are no files in the source, such as "BOOST/FILESYSTEM.HPP" and the rest of the boost. I hope for your help.

@ghost
Copy link

ghost commented Jun 9, 2017

I don't think that the library itself need to be built as Unicode, because just the Textoverlay need support for it.

The Textoverlay backend itself just support 7 Bit, but can support 8 Bit with a bit of modification.
Unicode/16 Bit need a big change because atm the backend creates one large character-sheet, for each font that is created (no sharing). I don't think this would work with 16 Bit because of RAM usage and the performance to generate it.
I would suggest for 16 Bit support, to implement a shared bitmap for each character. So only characters that are needed would be created. I think this would work, because you don't use each character of Unicode. (@agrippa1994 I think this should be good for overall performance)

For the second problem I would like to see an example (screenshots and the code to reproduce it) of it to understand the problem.

See #30 also for the Unicode issue.

@Gl0
Copy link

Gl0 commented Jun 9, 2017

tbh, we need just support for showing unicode strings. if it can be done with custom ttf font file extracted from game resources (not installed system-wide) - it will be the best.
for (2) - it was calling program issue, fixed already

@ghost
Copy link

ghost commented Jun 9, 2017

@Gl0 I look into it.

Edit: I created a prototype in the last hours, but I think there are some major bugs with formatting. I will look into that in the next days.

Here's the current progress:

@ghost
Copy link

ghost commented Jun 10, 2017

@iHimiko @Gl0 Here are the binaries for Unicode support: https://github.com/shadowlif/DX9-Overlay-API/tree/unicode/bin

Please notice to use TextCreateUnicode, TextSetStringUnicode and TextUpdateUnicode for fully support.
See here: https://github.com/shadowlif/DX9-Overlay-API/blob/unicode/include/c%23/Overlay.cs

At the moment there is no texture sharing, so the performance might be in comparison low.
I would like to hear some feedback, so that Unicode support can be implemented in this repo.

@Gl0
Copy link

Gl0 commented Jun 10, 2017

Seems working, thanks.
But faced with another problem - sometimes GetScreenSpecs() return zero point (I use it to check, whether hook was successful and I can draw anything). Only game restart helps.

@ghost
Copy link

ghost commented Jun 10, 2017

Maybe there's an fake window of the game? Because GetScreenSpecs return the size of the viewport.
The viewport is directly from an DirectX9 call, so it should be reliable.

@Gl0
Copy link

Gl0 commented Jun 10, 2017

May be it shows something dummy while loading and it get hooked. How can I force window reselect?
Now just doing every second:

        // check device for ready draw
        private static bool CheckForDevice()
        {
            DxOverlay.SetParam("process", "TERA.exe");
            return DxOverlay.GetScreenSpecs().X < 200;
        }

@ghost
Copy link

ghost commented Jun 10, 2017

atm I don' think you can force the API to use another window after the first API call because the API just have one IPC-Channel for every process, so just the first opened process is connected.

You can maybe try window and use_window to 1 instead of the process name. Maybe the "invisble window" (if it exists), don't have the name of the real game window.

Maybe we can add an parameter to set the pid. So you could check by yourself if its the real process and then attach the API to it.

@iHimiko iHimiko closed this as completed Jun 11, 2017
@Gl0
Copy link

Gl0 commented Jun 11, 2017

Process should be correct one, it always was only one instance.
But I'll try with window, may be it will be more reliable. At least first 10 attempts of starting game worked fine.

@ghost ghost mentioned this issue Jun 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants