Java anwendung VOR vollbildspielen (schon wieder...)

[mac21]

Hallo,
hiermit will ich das thema wiederaufgreifen, denn es ist im netz schon 1000 mal da doch es gab nie ne richtige lösung.
kann man eine java anwendung schreiben, die vor einem spiel läuft, und ich meine im vollbild.
im fenstermodus nur "setAlwaysOnTop" aber im vollbild gehts ja net.
hab 1000 lösungsideen gefunden, und bei einem sah ich DASS es geht
er benutzt ein JNA-plugin für eclipse, womit er in java die WindowsAPI einschließt.
er erklärte, dass so etwas(wie das xfire overlay, fraps oder mumble) zwischen grafikkarte und renderer laufen müsste.
ich hab leider das video nicht mehr aber das fenster war VOR dem vollbild spiel (oder er kann sehr gut videos maniulieren ^^)

gestern fand ich den "hack" 😀 (die nennen es so), wie man den hintergrund eines undekorierten jframes unsichtbar macht, die inhalte aber voll da sind (nicht durchsichtig). und wie man dieses undekorierte fenster per mouselistener verschieben kann.

aber ich sah selbst dass es geht... weiß nur irgendwer WIE ZUR HÖLLE DER DAS GEMACHT HAT 😀 ?

 

[tröööt]

es stimmt das die frage nach sog. fullscreen-overlays auch hier mehrfach kam ... und auch ich persönlich kann mich nicht daran erinnern mal eine funktionierende lösung gesehen zu haben ... es wurde immer auf JNI/JNA delegiert ... und dann verschwanden die threads im nirgendwo ...

soweit ich weis gibt es verschiedene möglichkeiten von overlays ...
das geht von hooking der game-dll bis hin zum selbst rendern ... hab schon viele ansätze gesehen ...

persönlich würde ich das hooking verfolgen ... allerdings würde ich mich nicht direkt in die game-dll hooken sondern mit hilfe des OS zwischen die render-engine des games und die OS-schnittstelle zur grafikkarte ... außerdem müsste man zusätzlich noch einen input-hook basteln um bei angezeigtem overlay dieses auch steuern zu können ...


aber egal wie man es macht ... ganz grob gesagt trifft doch folgendes zu : vieles müsste man in C/++ schreiben ... oder sich zumindest damit gut auskennen ... egal ob man JNI oder JNA nutzt ... und ich denke selbst wenn man einen guten hooking-layer hat (als ganz doofes beispiel : man hooked sich bei nem OpenGL game in die OpenGL-lib und schreibt dann da selbst z.b. mit LWJGL rein) dürfte das mit java ein echter krampf werden ...

persönlich würde ich für sowas einfach dierekt C nehmen ... und dafür sollte es bereits mehrere lösungen geben

 

[mac21]

hey vielen dank für die schnelle antwort.
das habe ich mir gedacht..
hooken omg 😀 ist doch wieder so viel arbeit und alles kapier i au net...
außerdem kann ich keine 5 zeilen C schreiben^^
n bisschen VB bzw. VBA und java.
und html/css wird hier nix bringen^^
aber genau dieses hooken von game-dll's meinte ich, das HAB ich gesehen dass es einer zum laufen bekommen hat, nur find ichdas **** video nichtmehr, anscheinend wurde der youtube-kanal deaktiviert -,-
nicht zufällig javanesen hier, die sich au mit C gut auskennen 😉 ?
sonst switch ich mal ins C-Forum
ich dachte mir sowas:
java anwendung wie gewohnt schreiben,
mit einer C-anwendung, die die java anwendung in sich aufnimmt, auf den screen schmeißen.
vllt weiß da jemand was, wie das "relativ" einfach geht, und somit schriebe ich mein overlay eifnach in java..
mal gucken, danke dir schonmal 😉

 

[tröööt]

naja ... also game-dll-hooking ist jetzt vielleicht nicht gerade die beste variante ... vor allem wenn man moderne systeme mit "anti-hook" methoden a la STEAM VAC betrachtet ... da wäre einfach die gefahr einer ungewollten sperrung zu groß ...

selbst teamspeak 3 warnt vor dem einsatz seines overlays in zusammenhang mit steam da es wohl schon mehrere fälle gegeben habe soll wo sich user die dies genutzt haben und dann eine VAC sperre erhielten bei teamspeak beschwert haben und schadensersatzt forderten ...

das natürlich steam's eigenes overlay akzeptiert wird ist klar ... ist ja auch von valve selbst ... aber ich glaube sich da noch rein-hooken wäre wohl wieder das gleiche risiko ...

nach möglichkeit solltest du dich also an einer stelle dazwischen klinken die außerhalb des bereiches liegt in denen eine mögliche ziel-anwendung überhaupt noch was davon mitbekommt ... und das wäre meiner meinung nach irgendwo zwischen der grafik-lib (DirectX / OpenGL) und dem treiber ... genaues weis ich allerdings nicht ...

das wird schon irgendwie machbar sein ... und auch in einer art und weise die "ungefährlich" ist ... aber ich denke das geht dann doch zu weit in OS-abhängige native programmierung ... das einzige was man da noch mit java machen könnte wäre halt über callbacks auf inputs reagieren und dem overlay irgendwie informationen rüberschieben was anzuzeigen ist ... aber das wäre dann glaube ich schon nicht mehr wirklich sinn und zweck .. auch wenn es proof-of-concept sicher funktionieren würde

 

[mac21]

hm das dachte ich mir, habe ich auch gelesen
habe selbst gemerkt, dass zB das "mumble" (ist wie ts3) probleme macht, wenn das overlay läuft... openGl spiele zb minecraft starten nicht, stürzen ab oder...ach kA..dzu viele probleme..
und das mit steam ist völlig richtig, manipulation vonm spieldaten->sperrung
hab mal im C-forum nachgefragt...die meinen "hooking"

ja toll -,-
also wirds wohl nix werden mit dem overlay...schade
danke dir

 

[tröööt]

wie gesagt ... proof-of-concept wird man das sicherlich irgendwie umsetzen können ... aber wenn man sich halt platformen wie eben steam ansieht die (zwar nicht gleich sofort) bei manipulationen von spiel-daten so hart durchgreifen wäre mir persönlich einfach das risiko zu hoch ...

ich kenne mich mit dem thema nicht aus ... aber wenn müsste man halt wie gesagt recht nah am treiber ansetzen um anderen anwendungen wie z.b. steam gar nicht erst die möglichkeit der prüfung zu geben ... und ob es sich dann noch lohnt da irgendwie mit java noch was machen zu wollen obwohl der rest eh über C läuft .. naja ich kanns mir nur als performance-bremse vorstellen ...


ich will dich nicht entmutigen ... im gegenteil ... finde das thema recht interessant ... aber ich denke halt mehr als n proof-of-concept wird nicht bei rauskommen