Renderer unabhängig von Fenstern verwenden

Fr 25. Jul 2014, 23:35	Renderer unabhängig von Fenstern verwenden	#1
Jules19 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!
Jules19 ist offline

KN4CK3R

Administrator

Anmeldungsdatum: Aug 2007

Beiträge: 8646

Benutzer-Bewertung:

199 positiv

33 negativ

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

CPP Code:

long Hook_EndScene(IDirect3DDevice9 *device)
{
	using namespace OSHGui::Drawing;
 
	static auto initOnce = true;
	if (initOnce)
	{
		initOnce = false;
 
		auto form = SetupGui(std::make_unique<Direct3D9ExRenderer>(device)); //initialisiert Application und erstellt die Form
	}
 
	auto &renderer = Application::Instance().GetRenderer(); //Renderer holen
	renderer.BeginRendering();
 
	auto geometry = renderer.CreateGeometryBuffer();
	{
		Graphics g(*geometry);
 
		/*hier ESP mit der Graphics Klasse zeichnen
		for (player)
		{
			g.DrawString
			g.DrawLine
			g.FillRectangle
			...
		}*/
	}
	auto &renderTarget = renderer.GetDefaultRenderTarget();
	renderTarget->Activate();
	renderTarget->Draw(*geometry); //hier wird der ESP dann letztendlich gezeichnet
	renderTarget->Deactivate();
 
	Application::Instance().Render(); //GUI zeichnen
 
	renderer.EndRendering();
 
	return pEndScene(device);
}

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

Sa 26. Jul 2014, 04:43		#3
Jules19 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: app.RegisterHotkey(Hotkey(Key::Insert, [] { Application::Instance().Toggle(); })); 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
Jules19 ist offline

Sa 26. Jul 2014, 10:17		#4
KN4CK3R Administrator Anmeldungsdatum: Aug 2007 Beiträge: 8646 Benutzer-Bewertung: 199 positiv 33 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
KN4CK3R ist offline

Jules19

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:

 
LRESULT CALLBACK Gui::MessageHook(int code, WPARAM wParam, LPARAM lParam)
{
	if (lParam & 0x80000000 || lParam & 0x40000000)
	{
		return CallNextHookEx(Implode::Gui->messageHookHandle_, code, wParam, lParam);
	}
 
	if (code == HC_ACTION)
	{
		//if (reinterpret_cast<LPMSG>(lParam)->message == WM_MOUSEMOVE)
		//{
		//	return 0;
		//}
 
		if (Implode::Gui->input_.ProcessMessage(reinterpret_cast<LPMSG>(lParam)))
		{
			return 1;
		}
	}
 
	return CallNextHookEx(Implode::Gui->messageHookHandle_, code, wParam, lParam);
}

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.

Sa 26. Jul 2014, 14:15		#6
KN4CK3R Administrator Anmeldungsdatum: Aug 2007 Beiträge: 8646 Benutzer-Bewertung: 199 positiv 33 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
KN4CK3R ist offline
1 positiv 0 negativ	Dieser Beitrag wurde bewertet von: Jules19 (Sa 26. Jul 2014, 15:18)

Sa 26. Jul 2014, 15:16		#7
Jules19 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
Jules19 ist offline

Sa 26. Jul 2014, 15:57		#8
KN4CK3R Administrator Anmeldungsdatum: Aug 2007 Beiträge: 8646 Benutzer-Bewertung: 199 positiv 33 negativ	Oder gleich ganz auf WM_GETMESSAGE verzichten und CPP Code: 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
KN4CK3R ist offline
1 positiv 0 negativ	Dieser Beitrag wurde bewertet von: Jules19 (Sa 26. Jul 2014, 16:18)

Sa 26. Jul 2014, 16:18		#9
Jules19 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.
Jules19 ist offline