OldSchoolHack

Registrieren / Anmelden Deutsch

Renderer unabhängig von Fenstern verwenden


icon Renderer unabhängig von Fenstern verwenden #1

Anmeldungsdatum: Jul 2014

Beiträge: 12

Benutzer-Bewertung:

3 positiv
0 negativ
Hi,

ist es möglich, den Renderer zum Zeichnen von ESP o. ä. zu verwenden? Ich habe bereits viele Konstellationen versucht, so dass ich unabhängig davon zeichnen kann, ob Application::IsEnabled() true liefert. Leider kriege ich es nicht hin.

Wie realisiere ich das, oder ist das nicht vorgesehen?

Danke!

icon #2

Anmeldungsdatum: Aug 2007

Beiträge: 8646

Benutzer-Bewertung:

198 positiv
31 negativ
Natürlich ist es möglich. Wenn du zum Beispiel mit D3D zeichnest, dann könnte es so aussehen:

CPP Code:
  1. long Hook_EndScene(IDirect3DDevice9 *device)
  2. {
  3. using namespace OSHGui::Drawing;
  4.  
  5. static auto initOnce = true;
  6. if (initOnce)
  7. {
  8. initOnce = false;
  9.  
  10. auto form = SetupGui(std::make_unique<Direct3D9ExRenderer>(device)); //initialisiert Application und erstellt die Form
  11. }
  12.  
  13. auto &renderer = Application::Instance().GetRenderer(); //Renderer holen
  14. renderer.BeginRendering();
  15.  
  16. auto geometry = renderer.CreateGeometryBuffer();
  17. {
  18. Graphics g(*geometry);
  19.  
  20. /*hier ESP mit der Graphics Klasse zeichnen
  21. for (player)
  22. {
  23. g.DrawString
  24. g.DrawLine
  25. g.FillRectangle
  26. ...
  27. }*/
  28. }
  29. auto &renderTarget = renderer.GetDefaultRenderTarget();
  30. renderTarget->Activate();
  31. renderTarget->Draw(*geometry); //hier wird der ESP dann letztendlich gezeichnet
  32. renderTarget->Deactivate();
  33.  
  34. Application::Instance().Render(); //GUI zeichnen
  35.  
  36. renderer.EndRendering();
  37.  
  38. return pEndScene(device);
  39. }

Wenn man nicht mit einem der Renderer zeichnen kann, die schon beim GUI dabei sind, wirds natürlich ein bissel komplizierter. Im OSHFusion habe ich dazu Renderer geschrieben, die mit der Unreal Engine und der Quake Engine zeichnen können, weil ich dann den gleichen ESP Code für alle Spiele benutzen kann.
Allgemein sollte das aber kein Problem sein, da man in dem Fall einfach das GUI in D3D zeichnet und den ESP in der Engine-Zeichen Funktion.

__________________

Hallo
icon #3

Anmeldungsdatum: Jul 2014

Beiträge: 12

Benutzer-Bewertung:

3 positiv
0 negativ
Hi,

ich habe nun auf den neuen Branch umgestellt. Gefällt mir an sich schon besser, auch vom Compilen her. Problem: es scheint sehr unstabil zu sein. Sieht für mich nach Threadingproblemen aus, daher undebugbar. Habe schon versucht externe Calls außerhalb des DX-Threads zu deaktivieren. Crasht trotzdem. Selbst wenn ich den kompletten Rendercode auskommentiere.

Hotkey via


TEXT Code:
  1.         app.RegisterHotkey(Hotkey(Key::Insert, []
  2.         {
  3.             Application::Instance().Toggle();
  4.         }));


scheinen auch nicht zu gehen (ausm Sample kopiert).

Schade...

Gruß
Zuletzt geändert von Jules19 (Sa 26. Jul 2014, 04:59)

Grund: kein Grund angegeben

icon #4

Anmeldungsdatum: Aug 2007

Beiträge: 8646

Benutzer-Bewertung:

198 positiv
31 negativ
Was heißt "geht nicht"? Und wie kommst du auf Threadingprobleme?

Wenn Render und Inputthread getrennt sind, musst du die threadsafen Varianten der Inputklasse benutzen.

__________________

Hallo
Zuletzt geändert von KN4CK3R (Sa 26. Jul 2014, 10:18)

Grund: kein Grund angegeben

icon #5

Anmeldungsdatum: Jul 2014

Beiträge: 12

Benutzer-Bewertung:

3 positiv
0 negativ
"Geht nicht" heißt, dass auf den Hotkey einfach nicht reagiert wird. Der MessageHook sieht so aus:

TEXT Code:
  1.  
  2. LRESULT CALLBACK Gui::MessageHook(int code, WPARAM wParam, LPARAM lParam)
  3. {
  4. if (lParam & 0x80000000 || lParam & 0x40000000)
  5. {
  6. return CallNextHookEx(Implode::Gui->messageHookHandle_, code, wParam, lParam);
  7. }
  8.  
  9. if (code == HC_ACTION)
  10. {
  11. //if (reinterpret_cast<LPMSG>(lParam)->message == WM_MOUSEMOVE)
  12. //{
  13. // return 0;
  14. //}
  15.  
  16. if (Implode::Gui->input_.ProcessMessage(reinterpret_cast<LPMSG>(lParam)))
  17. {
  18. return 1;
  19. }
  20. }
  21.  
  22. return CallNextHookEx(Implode::Gui->messageHookHandle_, code, wParam, lParam);
  23. }

Auf Threadingprobleme komme ich, da es für mich ziemlich zufällig scheint, wann es crasht. Meiner Erfahrung nach passiert sowas bei häufig bei Threadingprobleme. Ist aber nur ein Verdacht. Ich versuche, das weiter zu beobachten.
icon #6

Anmeldungsdatum: Aug 2007

Beiträge: 8646

Benutzer-Bewertung:

198 positiv
31 negativ
Und welche Input Klasse benutzt du? Für unabhängige Threads wäre das WindowsMessageThreaded verbunden mit einem input.PopulateMessages(); im Zeichenthread bevor das GUI gezeichnet wird.
Der Hotkey an sich funktioniert auch in meinen Projekten. Im Beispiel Projekt tuts bei dir ja sicherlich auch.

__________________

Hallo
1 positiv
0 negativ
Dieser Beitrag wurde bewertet von:
Jules19 (Sa 26. Jul 2014, 15:18)
icon #7

Anmeldungsdatum: Jul 2014

Beiträge: 12

Benutzer-Bewertung:

3 positiv
0 negativ
Danke, der Fehler mit dem Input ist behoben. Ich nutze nun die Threaded-Version. Wichtig war die PopulateMessages() Funktion. Die hatte ich vorher nicht drin. Problem war auch folgendes: der Thread, der DirectX verwendet, ist nicht unbedingt der Message-Thread. Lösung (kann vermutlich besser gemacht werden): alle Threads auf WM_GETMESSAGE hooken und sobald ein Hook aufgerufen wird, alle Hooks entfernen außer den, woher der Call kam. So habe ich jetzt garantiert, dass ich immer den richtigen Inputthread erwische. Nun funktionieren auch die Hotkeys. Sorry, dass ich dachte, dass es an der Lib liegt ;-)

Ich probiere nun weiter rum, wie sich das mit den Crashes verhält. Das debuggen gestaltet sich da schwierig. Fest steht, dass es nur crasht, solange ich OSHGui initialisiere. Kann aber auch sein, dass dadurch andere Seiteneffekte ausgelöst werden, die mit der Lib an sich nichts zu tun haben...
Zuletzt geändert von Jules19 (Sa 26. Jul 2014, 15:16)

Grund: kein Grund angegeben

icon #8

Anmeldungsdatum: Aug 2007

Beiträge: 8646

Benutzer-Bewertung:

198 positiv
31 negativ
Oder gleich ganz auf WM_GETMESSAGE verzichten und

CPP Code:
  1. SetWindowLongA(hwnd, GWLP_WNDPROC, reinterpret_cast<LONG>(NewWndProc))

nehmen. Da gibts keine "falscher Thread" Probleme. Was bei dir eventuell Probleme verursacht, ist, dass sich dein Set/GetCursorPos Hook nicht an das Threading hält.

__________________

Hallo
1 positiv
0 negativ
Dieser Beitrag wurde bewertet von:
Jules19 (Sa 26. Jul 2014, 16:18)
icon #9

Anmeldungsdatum: Jul 2014

Beiträge: 12

Benutzer-Bewertung:

3 positiv
0 negativ
...so einfach :-D Werde ich gleich umbauen...
Die Crashprobleme sind weg. Es lag - wie du richtig geraten hast - am Hook.

Ich werde nun noch rumsuchen, wie ich den Windows-Cursor im Hauptmenü ausblende. ShowCursor() reicht nicht aus - offensichtlich. Wenn das fertig ist, poste ich mal meine Lösung, mit der man das Menü dann problemlos Ingame und im Menü verwenden kann.