Archief - Window width en height aanpassen aan OpenGL inhoud (edit: opgelost)

Ik heb een hook geschreven die het toelaat Worms: Reloaded in een window te spelen (zie hier): http://omploader.org/vNWVqOA/fredwp-worms-reloaded-windowed.png

Het is bijna perfect. Bij v1.3 probeert het spel wel nog altijd de resolutie van de desktop aan te passen, wat ik in v1.4 opgelost heb.

Het enige probleem nu is, ik zou graag willen weten hoe ik de width en height van de OpenGL inhoud kan verkrijgen, zodat ik mijn raam aan die waardes kan aanpassen.

Momenteel ziet het er zo uit om een idee te geven: http://omploader.org/vNWVvag/fredwp-worms-reloaded-windowed-development-v14.png

De resolutie waardes worden gelezen uit een configuratiebestand. Het zou inefficiënt zijn zou ik die waardes nog eens uit dat document lezen voor mijn hook, terwijl deze al ergens in het geheugen zitten, maar ik moet ze nog vinden.

EDIT: Oplossing kan gevonden worden in post #14.

Ik ben niet bepaald thuis in OpenGL, maar is glGet met als parameter GL_VIEWPORT niet wat je zoekt?

NeverwinterX zei:

Ik ben niet bepaald thuis in OpenGL, maar is glGet met als parameter GL_VIEWPORT niet wat je zoekt?

Klik om te vergroten...

Dat heb ik al geprobeert maar voor een of andere reden gaat hij nog altijd vol scherm met die zwarte delen zoals op de screenshot, met deze code:

GLint gameViewport[4];
glGetIntegerv(GL_VIEWPORT, gameViewport);

Klik om te vergroten...

Ik geef dan het raam de waardes mee:

nWidth = gameViewport[2];
nHeight = gameViewport[3];

Klik om te vergroten...

En het resultaat is dan hetzelfde als op de screenshot.

Momenteel heb ik het opgelost door de waardes direct van hun geheugenadres te lezen:

// Read the game resolution from memory
int *pGameWidth = (int*)0x0018FDB8;
int *pGameHeight = (int*)0x0018FDBC;
nWidth = *pGameWidth;
nHeight = *pGameHeight;

Klik om te vergroten...

Maar ik zou deze liever willen verkrijgen via een schonere methode.

En GL_SCISSOR_BOX?

NeverwinterX zei:

En GL_SCISSOR_BOX?

Klik om te vergroten...

Blijkbaar ook niet.

GLint gameScissorBox[4];
glGetIntegerv(GL_SCISSOR_BOX, gameScissorBox);
nWidth = gameScissorBox[2];
nHeight = gameScissorBox[3];

Klik om te vergroten...

Er verschijnt niets, maar kan het spel wel zien via alt + tab methode (screenshot), en op de taskbar thumbnail viewer (screenshot), waar deze nog altijd een zwarte omranding heeft.

EDIT: window code was aan het conflicten er mee, het resultaat is precies hetzelfde als met GL_VIEWPORT).

misschien een ineffeciente methode, maar als je aan de pixels zelf zou raken (dus wat er op het scherm staat), zou je toch eenmalig het aantal zwarte pixels kunen tellen vanaf linkerbovenhoek en rechteronderhoek. Dan heb je de offset waarmee je je window width en height moet verminderen. Nu dit is er wel vanuitgaande dat de resoluties niet veranderen binnen het scherm (zoals misschien bij sommige games die video filmpjes tonen). Maar dan nog misschien zou je dat ook kunnen opvangen en eventueel dan opnieuw de zwarte pixels tellen. allee ik zou wel meer als 1 lijn pixels tellen voor het geval er ooit zwart gebruikt wordt in de "echte game frame's" of een aantal frames na elkaar de calculatie opnieuwe uitvoeren om zeker te zijn.

Misschien niet zo een mooie oplossing maar kan misschien werken als je aan de pixel data raakt ?

hmm effe domme vraag misschien maar die screenshot met die zwarte borders, is dat van je volledige scherm ? of heb je alt+printscreen gebruikt, dus het actieve venster dan ?

indien het venster je volledige desktop vult (initieel) is dit volgens mij normaal, maar ben er niet zeker van, omdat het spel waarschijnlijk die resolutie meegeeft ???

heb je al geprobeerd de volgende waarden : x, y, nWidth, nHeight in jouw hook "te loggen" dus wegschrijven naar een tekst file ? om te zien welke waarden je juist (initieel) binnenkrijgt.

een andere vraag ... ik zie dat je writeprocessmemory gebruikt, nu ik ben hier niet zeker van maar blokkeerd windows dit niet tegenwoordig als je buiten je eigen process geheugen gaat wijzigen (DEP execution prevention is die optie in windows dacht ik). Misschien wordt dit omzeilt omdat je een hook gebruikt, maar vroeg het me gewoon af. Ik weet dat ik vroeger in alle geval wirteprocessmemory gebruikte voor trainers te maken (cheats voor games) en dat dit nu niet meer werkt tenzij je dep uitschakelt in windows ...

DEP staat hier volledig aan (op alle toepassingen, niet alleen standaard belangrijke toepassingen) en het werkt degelijk. UAC staat ook aan, en beiden toepassingen (spel en loader) werken op een normale gebruiker level.

Het is een normale screenshot. Ik heb de waardes bekeken van die glViewPort() (waar ik normaal gezien moet in zoeken) en de waardes zijn ofwel niets (leeg), of rare tekens.

Ik heb het op verschillende locaties in de hook gezet om het te bekijken, en die waardes blijven maar raar uitkomen.

Ik snap niet hoe het spel die waardes kan vinden en die view port mooi kan instellen, maar dat ik die waardes nergens via een functie kan verkrijgen, om zo mijn raam aan te passen naar die view port.

Maar ik blijf proberen, ik ben er zeker van dat het mogelijk moet zijn als het spel dit zelf ook kan lezen en gebruiken, zonder de waarde opnieuw te moeten halen van een configuratiebestand, of via een read pixels methode.

EDIT:

Het zelf proberen instellen van glViewport() doet het spel crashen. Vanwege mijn raam methode denk ik dat ik ergens anders moet zoeken, en het ligt niet ver af vermoed ik.

waarschijnlijk omdat je hooking gebruikt wordt dep niet getriggerd, ik gebruikte een extern programma bij mijn trainers.

afin ja het spel zelf heb ik niet en ben het ook niet vanzin om aan te kopen, maar je zit wel al met een probleem. Je codeerd de geheugen addressen als constante zie ik, nu dat is allemaal goed en wel, echter wanneer het spel ooit een update krijgt (moest dat nog gebeuren) dan moet je je programma herschijven, omdat zo goed as zeker dat adres niet meer hetzelfde zal zijn. Je hebt eigenlijk nog een geluk dat het constant blijft elke keer je het process start. Wat niet het geval is bij alle applicaties. Afin je zou dat wel kunnen oplossen door *iets* te zoeken als referentie punt dat altijd dichtbij de locatie staat van die width & height (maar dat is nog altijd niet een zekerheid en dan ga je verschillende versies moeten testen).

Afin dat terzijde, ben je zeker dat je het juiste geheugenaddres hebt, juiste casts maakt (dus rekening houd met het datatype ?), endianness, calling convention etc ?

Ik gebruikte vroeger tsearch (een mem searcher) , maar daarvoor zal je wel dep moeten uitschakelen denk ik is vrij oud programma. ma afin meeste commerciele hex editors laten ook toen om het geheugen van een process te bekijken. Wat ik wou zeggen is dat je misschien eens kunt zoeken achter de waarde van de resolutie dat het spel gebruikt.

Heb tevens ook geen visual studio, gebruik meestal gcc toolchains en weet niet direct of het hiermee te compileren valt, maar ja dan heb ik het spel nog niet kwam waarschijnlijk van steam zeker ?

Ja, ik heb TSearch ook gebruikt om snel die geheugenadressen op te zoeken (heb TSearch.exe ook op DEP white list moeten zetten, dat is zowat de enige applicatie die ik ooit gevonden heb die niet DEP compatible is).

Van die dynamische geheugenadres techniek heb ik weet, en dat de addressen veranderen bij een update ook, daarvoor dat ik het een tijdelijke oplossing noemde. ^^

Anyway, hopelijk vind ik vandaag een oplossing.

fred,

Ik heb gezien op steam dat er een demo versie bestaat van worms reloaded, ik heb die gisteren gedownload, maar heb voor de rest nog niets gedaan. Ik vermoed dat dit daar ook mee zal werken, Het zal waarschijnlijk wel een ander geheugen adres hebben maar dat kan ik zelf vinden.

Weet je soms of jouw code kan gecompileerd worden met gcc ? (mingw / cygwin ), want visual studio gebruikt ik niet. Heb je soms een makefile ? heb niet veel zin om daar aan te prutsen, en momenteel zit ik ook op het werk dus kan niet veel doen. vanavond heb ik ook niet veel tijd, misschien morgen of in het weekend

Zolang de dependencies er zijn zal het wel in orde zijn geloof ik (weinig ervaring met GCC).

Van de Dll:

// #pragma entries
#pragma comment(lib,"user32")
#pragma comment(lib,"shell32")

// Library inclusion
#include <windows.h>

Klik om te vergroten...

Van de loader:

// #pragma entries
#pragma comment(linker,"/SUBSYSTEM:WINDOWS")
#pragma comment(lib,"shell32")
#pragma comment(lib,"user32")
#pragma comment(lib,"advapi32")

// Library inclusion
#include <windows.h>
#include <tlhelp32.h>
#include <direct.h>
#include <stdlib.h>

Klik om te vergroten...

Ik hoop tegen vandaag dat geheugenadres probleem opgelost te hebben door de waardes te verkrijgen via een functie.

PS: Het is met Visual C++ 2010 Express gemaakt (de gratis versie, zie hier) indien dat van enige interesse kan zijn.

Ik was van plan de waardes gewoon terug uit het configuratiebestand te lezen, maar dit zorgt voor heel veel werk in vergelijking met het uit het geheugen lezen via een schone methode.

Als ik alles moet dekken voor gebruikersfouten, kom ik bij een van de volgende situatie terecht:
-> Als het spel geen configuratiebestand kan lezen (Default.cfg bestaat niet), neemt deze default waardes (resolutie = native).
-> Gebruikers kunnen resolutie aanpassen, maar het spel maakt geen nieuw configuratiebestand aan, dus komt er de fout dat het raam full screen borderless blijft, maar de game resolutie kleiner wordt, waardoor je weer die zwarte omranding krijgt.

Ik kan ook gewoon een error geven als er geen waardes kunnen gelezen worden en het spel eindigen indien dat het geval is, maar dat probeer te vermijden dat het spel moet beëindigt worden of niet gestart moet worden in het geval van een fout.

fred,

heb nog geen tijd gehad maar misschien dat ik er vanavond eens naar kijk. (is beetje dilema, want heb ook mijn caanoo net toegekregen (zie andere thread in dit subform)).

ik vraag me tevens af wat er gebeurd als je jouw desktop resolutie (native) bvb op 800x600 zet en het spel laat draaien op 1280x1024 zit je dan ook niet met een probleem ? normaal is dit mogelijk bij games dacht ik dat je hogere resoluties kunt gebruiken dan wat je in windows gebruikt. De applicatie gaat dan mogelijk een venster creeren dat groter is dan jouw scherm resolutie

Ik geloof dat ik het gevonden heb, en het is simpeler dan ik dacht.

Eerst en vooral, het spel maakte een nieuw local.cfg aan met de resolutie waardes, maar dat is niet meer van nut aangezien ik met functies aan het werken ben om die waardes te verkrijgen.

Ten tweede heb ik dit zonet gerealiseerd. Als het spel zijn eigen resolutie probeert toe te passen op het scherm, roept deze ChangeDisplaySettings() op. Ik had deze al naar een lege functie laten gaan om zo er voor te zorgen dat het spel de desktop resolutie niet meer zou aanpassen.

Nu komt het net op in mij dat het spel de resolutie waardes dus naar ChangeDisplaySettings() stuurt, het enige wat ik moet doen is deze opvangen en doorgeven aan mijn raam functie.

Tot zover is het bijna gelukt (heb het nog maar een paar minuten geleden ondervonden), de breedte van het raam blijkt zich al aan te passen, maar de hoogte doet raar, zal eens moeten kijken wat het probleem is, zal de oplossing posten als ik klaar ben.

EDIT:

Het is gelukt (had per ongeluk de hoogte de waarde van de breedte gegeven).

Dit is de test code (ga het wat schoner implementeren, bij test code kijk ik niet naar optimalisatie maar alleen naar de werking):

LONG WINAPI hkChangeDisplaySettings(DEVMODE *lpDevMode, DWORD dwflags)
{
DEVMODEW test = *lpDevMode;
ScreenWidth = test.dmPelsWidth;
ScreenHeight = test.dmPelsHeight;
return 0;
}

Klik om te vergroten...

Hey,

Heb zelf geen Opengl hooking ervaring, maar hoe hook je juist als ik dat mag weten? Of waar vind ik info?
Via een windows hook installeren en dan de lijst van ingeladen dll's/functies afgaan? Of via createreometethread() (als opengl bv dynamisch wordt ingeladen)? Of anders?

Litheon zei:

Hey,

Heb zelf geen Opengl hooking ervaring, maar hoe hook je juist als ik dat mag weten? Of waar vind ik info?
Via een windows hook installeren en dan de lijst van ingeladen dll's/functies afgaan? Of via createreometethread() (als opengl bv dynamisch wordt ingeladen)? Of anders?

Klik om te vergroten...

Ik heb het als vrije software uitgegeven, je kan altijd het downloaden en door de broncode snuffelen, ik heb wat meer en duidelijker commentaar gezet bij het hookproces, in v1.6 zal ik nog meer commentaar in de code zetten om het duidelijker te maken.

Ha, ok, cava, had over de link heen gelezen.

Super hard bedankt om de source code te delen!!!!!
Ik kan nog iets leren van je hookit functie. Momenteel doe ik mijn directx hook via APIHijack en dat werkt goed (behalve als je dx inlaad via LoadLibrary(...) dan werkt het niet), maar ik moet nog gewoon de loadlibrary functie overschrijven en dan komt dat wel in orde.

Heel hard bedankt om te delen!

Litheon zei:

Ha, ok, cava, had over de link heen gelezen.

Super hard bedankt om de source code te delen!!!!!
Ik kan nog iets leren van je hookit functie. Momenteel doe ik mijn directx hook via APIHijack en dat werkt goed (behalve als je dx inlaad via LoadLibrary(...) dan werkt het niet), maar ik moet nog gewoon de loadlibrary functie overschrijven en dan komt dat wel in orde.

Heel hard bedankt om te delen!

Klik om te vergroten...

Geen probleem.

hey, goed idee !
Ik ga het ook eens proberen voor RCT2