[Problemă] Problema freeze la doua ferestre de client deschise

[Dreu Zmeu]

*Problemă/Întrebare:Salut, ma confrunt cu un freeze total al clientului in momentul in care incerc sa rulez doua instante simultan. Primul client ingheata (Not Responding) imediat ce al doilea client este pornit. Daca nu ingheata, crapa cu erori de memorie video sau erori de tip Granny.
Detalii despre sistemul de Cache/Preload din sursa:
-Sursa foloseste un sistem de pre-incarcare care incearca sa ridice toate resursele (animatii, efecte, modele NPC) in memoria video la startul jocului.
-Animatii: Foloseste LoadStaticCache in PythonPlayerSettingsModule.cpp pentru a bloca fisierele .msa in VRAM.
-Efecte: Inregistreaza mii de efecte cu parametrul bCache = true.
-Threaded Loading: Foloseste FileLoaderThread pentru a procesa aceste cereri in fundal.
Modificari efectuate deja in sursa:
-Optimizare Memorie: Am dezactivat incarcarea statica (LoadStaticCache) in ResourceManager.cpp pentru a evita umplerea VRAM-ului la start.
-Lazy Loading: Am setat efectele si emotiile pe false in PythonPlayerSettingsModule.cpp.
-Device Restore: In CheckDeviceState, am implementat eliberarea resurselor inainte de Reset() si re-initializarea bufferelor Granny (GrannyCreateSharedDeformBuffer) dupa restaurare.
-Logic Fix: Am incercat sa folosesc un goto catre sectiunea de restaurare a device-ului in Process() pentru a opri orice calcul 3D cat timp placa video este pierduta.
Comportament observat:
Desi ambele cliente pornesc cu un consum mic de memorie, exista un conflict in momentul schimburii de focus. Se pare ca thread-ul principal intra intr-o stare de asteptare infinita (Deadlock) asteptand ca driverul video sa redevina disponibil, dar acest lucru nu se mai intampla.

Intrebari:
Ar putea fi o problema legata de sincronizarea thread-ului de incarcare (FileLoaderThread) cu thread-ul de randare in momentul unui "Device Lost"?
Exista vreo setare in CGraphicDevice care sa previna blocajul ferestrei cand DirectX pierde contextul?
Este necesara o gestionare speciala a bufferelor Granny la nivel de CGrannyModelInstance pentru a permite multi-client pe configuratii mai slabe?

*Resursă folosită (sistem/funcție/modificare): Serverfiles M2PROJECT

*Syserr:

Code:

0126 21:08:04142 :: CreateDDSTexture: Cannot create texture
0126 23:58:40839 :: GRANNY DEFORM DYNAMIC BUFFER LOCK ERROR

*Fișier(e) cu problema (link pastebin / code): N/A

*Poze / Video: N/A

[Uriel]

*Problemă/Întrebare:Salut, ma confrunt cu un freeze total al clientului in momentul in care incerc sa rulez doua instante simultan. Primul client ingheata (Not Responding) imediat ce al doilea client este pornit. Daca nu ingheata, crapa cu erori de memorie video sau erori de tip Granny.
Detalii despre sistemul de Cache/Preload din sursa:
-Sursa foloseste un sistem de pre-incarcare care incearca sa ridice toate resursele (animatii, efecte, modele NPC) in memoria video la startul jocului.
-Animatii: Foloseste LoadStaticCache in PythonPlayerSettingsModule.cpp pentru a bloca fisierele .msa in VRAM.
-Efecte: Inregistreaza mii de efecte cu parametrul bCache = true.
-Threaded Loading: Foloseste FileLoaderThread pentru a procesa aceste cereri in fundal.
Modificari efectuate deja in sursa:
-Optimizare Memorie: Am dezactivat incarcarea statica (LoadStaticCache) in ResourceManager.cpp pentru a evita umplerea VRAM-ului la start.
-Lazy Loading: Am setat efectele si emotiile pe false in PythonPlayerSettingsModule.cpp.
-Device Restore: In CheckDeviceState, am implementat eliberarea resurselor inainte de Reset() si re-initializarea bufferelor Granny (GrannyCreateSharedDeformBuffer) dupa restaurare.
-Logic Fix: Am incercat sa folosesc un goto catre sectiunea de restaurare a device-ului in Process() pentru a opri orice calcul 3D cat timp placa video este pierduta.
Comportament observat:
Desi ambele cliente pornesc cu un consum mic de memorie, exista un conflict in momentul schimburii de focus. Se pare ca thread-ul principal intra intr-o stare de asteptare infinita (Deadlock) asteptand ca driverul video sa redevina disponibil, dar acest lucru nu se mai intampla.

Intrebari:
Ar putea fi o problema legata de sincronizarea thread-ului de incarcare (FileLoaderThread) cu thread-ul de randare in momentul unui "Device Lost"?
Exista vreo setare in CGraphicDevice care sa previna blocajul ferestrei cand DirectX pierde contextul?
Este necesara o gestionare speciala a bufferelor Granny la nivel de CGrannyModelInstance pentru a permite multi-client pe configuratii mai slabe?

*Resursă folosită (sistem/funcție/modificare): Serverfiles M2PROJECT

*Syserr:

Code:

0126 21:08:04142 :: CreateDDSTexture: Cannot create texture
0126 23:58:40839 :: GRANNY DEFORM DYNAMIC BUFFER LOCK ERROR

*Fișier(e) cu problema (link pastebin / code): N/A

*Poze / Video: N/A

Salut! Problema descrisă indică un conflict clasic de gestionare a resurselor DirectX și sincronizare a thread-urilor în timpul unui "Device Lost" (pierdere de context DirectX), frecvent întâlnit la rularea multi-client. Erorile din syserr confirmă acest lucru.

Iată răspunsurile la întrebările tale și o direcție de rezolvare:

1. **Ar putea fi o problema legata de sincronizarea thread-ului de incarcare (FileLoaderThread) cu thread-ul de randare in momentul unui "Device Lost"?**
* Da, absolut. Acesta este un scenariu foarte probabil. Când DirectX pierde contextul, toate resursele

Code:

D3DPOOL_DEFAULT

devin invalide. Dacă FileLoaderThread încearcă să creeze sau să acceseze resurse DirectX în timp ce device-ul este pierdut sau în curs de resetare, poate duce la blocaje (deadlock) sau erori. Thread-ul principal de randare trebuie să semnaleze FileLoaderThread să-și suspende operațiunile legate de DirectX până la restaurarea completă a device-ului.

2. **Exista vreo setare in CGraphicDevice care sa previna blocajul ferestrei cand DirectX pierde contextul?**
* Nu există o "setare" directă. Soluția constă într-o implementare robustă a gestionării stării device-ului. Funcția

Code:

IDirect3DDevice9::TestCooperativeLevel()

trebuie apelată regulat.
* Dacă returnează

Code:

D3DERR_DEVICELOST

, clientul trebuie să oprească orice încercare de randare sau creare de resurse și să aștepte (ex:

Code:

Sleep(100)

) până când device-ul devine disponibil pentru resetare.
* Dacă returnează

Code:

D3DERR_DEVICENOTRESET

, atunci trebuie apelată funcția de restaurare a device-ului (ex: CGraphicDevice::RestoreDevice()).
* Blocajul ferestrei apare când aplicația încearcă să folosească un device DirectX invalid sau intră într-o buclă de așteptare fără a elibera resursele corect.

3. **Este necesara o gestionare speciala a bufferelor Granny la nivel de CGrannyModelInstance pentru a permite multi-client pe configuratii mai slabe?**
* Da, este esențială. Eroarea

Code:

GRANNY DEFORM DYNAMIC BUFFER LOCK ERROR

indică direct o problemă cu bufferele de deformare Granny. Acestea sunt adesea partajate și trebuie eliberate (

Code:

GrannyFreeSharedDeformBuffer()

) înainte de

Code:

IDirect3DDevice9::Reset()

și re-create (

Code:

GrannyCreateSharedDeformBuffer()

) după resetare, în cadrul funcției de restaurare a device-ului. Asigură-te că aceste apeluri sunt sincronizate și se întâmplă la momentul potrivit.

**Recomandări de verificare și implementare:**

1. **Sincronizare FileLoaderThread:**
* În CGraphicDevice.cpp sau unde gestionezi starea device-ului, adaugă un mecanism (ex: un flag global sau un mutex/event) care să semnaleze FileLoaderThread când device-ul este pierdut.
* În FileLoaderThread, înainte de orice operațiune care implică resurse DirectX (ex: încărcarea texturilor), verifică acest flag și așteaptă dacă device-ul este pierdut/resetat.

2. **Verifică logica de restaurare a device-ului:**
* Unde exact se află implementarea ta pentru RestoreDevice() (sau funcția echivalentă)?
* Asigură-te că în această funcție, toate resursele

Code:

D3DPOOL_DEFAULT

(texturi, vertex/index buffere, buffere Granny) sunt eliberate înainte de apelul

Code:

IDirect3DDevice9::Reset()

și re-create după un reset de succes.
* Verifică apelurile

Code:

GrannyFreeSharedDeformBuffer()

și

Code:

GrannyCreateSharedDeformBuffer()

în CGraphicDevice.cpp sau GrannyManager.cpp pentru a te asigura că sunt în ordinea corectă în timpul restaurării.

3. **Gestionarea erorilor de textură:**
* Eroarea

Code:

CreateDDSTexture: Cannot create texture

sugerează că CTextureManager sau o funcție similară încearcă să creeze o textură pe un device invalid. Asigură-te că CTextureManager este notificat să elibereze resursele la pierderea device-ului și să le reîncarce după restaurare.

Te rog să specifici unde ai implementat exact logica de restaurare a device-ului (numele funcției și fișierul) pentru a putea oferi o verificare mai precisă.

[Nermin]

I guess you tried to make DX9 multithread capable?
I'm afraid I have to disappoint you. The only things that are thread safe are
file I/O
decompression
parsing
building CPU-side blobs
You have to let Granny work alone (single).
You can preheat in the background, but that's it. DX9 + Granny are very limited.

Without src, it's hard to say, the error could be anything. Build in a debug for WinDBG, you might see the error there.

[Dreu Zmeu]

I guess you tried to make DX9 multithread capable?
I'm afraid I have to disappoint you. The only things that are thread safe are
file I/O
decompression
parsing
building CPU-side blobs
You have to let Granny work alone (single).
You can preheat in the background, but that's it. DX9 + Granny are very limited.

Without src, it's hard to say, the error could be anything. Build in a debug for WinDBG, you might see the error there.

I appreciate the advice. I'm avoiding multi-threaded rendering now, but the issue persists.

It seems to be hardware-dependent: the freeze only affects low-spec computers. On better rigs, everything works smooth.

Do you think the slower execution on weak CPUs is causing the background thread to desync or lock the device before the main thread can reset it?

[Nermin]

I don't think it's the CPU. Does the src have full DX9 or Semi DX8/9?
I've worked on a few src files where DX9 works, but GrpDevice + Statemanager were written a little confusingly, which causes Intel iGPUs + Nvidia (Optimus dgpu + igpu) notebooks in particular to crash.
This usually doesn't happen with AMD setups.

[Dreu Zmeu]

I don't think it's the CPU. Does the src have full DX9 or Semi DX8/9?
I've worked on a few src files where DX9 works, but GrpDevice + Statemanager were written a little confusingly, which causes Intel iGPUs + Nvidia (Optimus dgpu + igpu) notebooks in particular to crash.
This usually doesn't happen with AMD setups.

You are absolutely right! It seems to be exactly what you described.The source is indeed a "Semi DX8/9" hybrid, and the issue is specific to Intel iGPU / Nvidia Optimus setups.
Here is what I've done so far to debug and fix it:

Code:

-I implemented a ForceResetState function in StateManager to unbind textures and reset states immediately after Reset() succeeds.
-I verified GrpIndexBuffer, and the Lock flags are set to 0 (correct), so that wasn't the issue.
-I added a "Render Barrier" in CPythonApplication::Process to completely stop rendering logic when the window is inactive or minimized to save the CPU/GPU.

However, after adding verbose logging, I managed to pinpoint exactly where it freezes. The client hangs indefinitely inside the resource cleanup phase, specifically when handling RenderTargets.
The last log line before the hard freeze is: DEBUG_LOG: Device Lost. Cleaning up resources (Priority RenderTarget).
It seems the driver enters a deadlock when calling Release() on the RenderTarget textures while the device is in a 'Lost' state. I am currently trying to force unbind these textures via StateManager before releasing them, but it seems CRenderTargetManager is the main culprit here.

[Nermin]

Easy. Good luck. Once you've fixed that, MSAA should also be possible without artifacts in the UI with Intel+Nvidia.

[[HF]White]

Easy. Good luck. Once you've fixed that, MSAA should also be possible without artifacts in the UI with Intel+Nvidia.

Off: MSAA is too much of a hustle to be worth it.. Players do not care about that stuff.

They play on servers where shadows and fog is disabled.

[Dreu Zmeu]

Easy. Good luck. Once you've fixed that, MSAA should also be possible without artifacts in the UI with Intel+Nvidia.

Off: MSAA is too much of a hustle to be worth it.. Players do not care about that stuff.

They play on servers where shadows and fog is disabled.

Salut! Am gasit o postare pe un alt forum unde cineva intampina problema pe care o am eu acum, am vazut ca in comentarii ai lasat si tu ceva, iti mai aduci aminte cum ai rezolvat atunci?

[Dreu Zmeu]

The Administrator Rights Issue (Crucial Fix for Stability) I noticed that on my main PC (where everything worked), the client launched directly. On the laptops where it froze, the client required "Run as Administrator". Running as Admin can cause isolation issues with the GPU driver and drag-and-drop features. Disabling this requirement significantly improved stability on the affected PCs.

How to remove the Administrator requirement (Visual Studio):

You need to modify the project settings for UserInterface (or whatever your binary generation project is named, e.g., Metin2Release/Distribute).

Code:

Right Click on the UserInterface project (in Solution Explorer) -> Properties.

On the left panel, go to: Configuration Properties -> Linker -> Manifest File.

On the right panel, look for the line: UAC Execution Level.

It is likely set to requireAdministrator.

CHANGE IT to: asInvoker (/level='asInvoker').

Click Apply and OK.

Important: After making this change, make sure to Rebuild the UserInterface project to generate a fresh .exe with the new manifest.

Thanks to everyone for the hints regarding the semi-DX9 hybrid source and the texture unbinding logic! The client is now stable.