Renderer unabhängig von Fenstern verwenden

Fri 25. Jul 2014, 23:35	Renderer unabhängig von Fenstern verwenden	#1
Jules19 Join Date: Jul 2014 Posts: 12 User-Rating: 3 positive 0 negative	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 is offline

KN4CK3R

Administrator

Join Date: Aug 2007

Posts: 8643

User-Rating:

199 positive

33 negative

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

Sat 26. Jul 2014, 04:43		#3
Jules19 Join Date: Jul 2014 Posts: 12 User-Rating: 3 positive 0 negative	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ß Last edited by Jules19 (Sat 26. Jul 2014, 04:59) Reason: no reason given
Jules19 is offline

Sat 26. Jul 2014, 10:17		#4
KN4CK3R Administrator Join Date: Aug 2007 Posts: 8643 User-Rating: 199 positive 33 negative	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 Last edited by KN4CK3R (Sat 26. Jul 2014, 10:18) Reason: no reason given
KN4CK3R is offline

Jules19

Join Date: Jul 2014

Posts: 12

User-Rating:

3 positive

0 negative

"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.

Sat 26. Jul 2014, 14:15		#6
KN4CK3R Administrator Join Date: Aug 2007 Posts: 8643 User-Rating: 199 positive 33 negative	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 is offline
1 positive 0 negative	This post has been rated by: Jules19 (Sat 26. Jul 2014, 15:18)

Sat 26. Jul 2014, 15:16		#7
Jules19 Join Date: Jul 2014 Posts: 12 User-Rating: 3 positive 0 negative	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... Last edited by Jules19 (Sat 26. Jul 2014, 15:16) Reason: no reason given
Jules19 is offline

Sat 26. Jul 2014, 15:57		#8
KN4CK3R Administrator Join Date: Aug 2007 Posts: 8643 User-Rating: 199 positive 33 negative	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 is offline
1 positive 0 negative	This post has been rated by: Jules19 (Sat 26. Jul 2014, 16:18)

Sat 26. Jul 2014, 16:18		#9
Jules19 Join Date: Jul 2014 Posts: 12 User-Rating: 3 positive 0 negative	...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 is offline