Yardım Belli bir süre sonra render etkisinin kaybolması

DeadLyEscaPe · Pazartesi 18:47

Oyuna ilk girişte harita, objeler, efektler vs ilk defa yüklenir. Bu yüzden ilk loading ekranı hep uzun olur. Fakat oyuna girip ışınlandıktan sonra loading ekranı kısalır çünkü daha önceki etkiler hala devam etmektedir. (Client kapanmadığı sürece.) Burada da buna benzer bir durum söz konusu. Aslında ilk zırh giyişte de kasma oluşmaması gerek. İlk giyilen zırhın ardından belli bir saniye sonra tekrar giyildiğinde sanki ilk defa giyiliyormuşçasına tekrardan bir kasma mevcut. Umarım düzgün bir şekilde anlatabilmişimdir. Daha önceki konuma benzer bir sorun gibi görünüyor fakat burada daha detaylı anlatmak istedim. Konum kapatılmaz ise sevinirim.

Öncelikle, bunun sebebi;
1-) %100 client source tarafında mıdır? Game source tarafında bir etkisi olabilir mi?
2-) Eğer öyle ise RENDER_TARGET sistemi ile bir bağlantısı olabilir mi?
3-) Harita optimizasyon kodları ile ilgili olabilir mi?
4-) Bu sorun için öncelikli olarak hangi dosyalara ve fonksiyonlara göz atılmalı?

Not: Sorun sadece ekipman giyip-çıkartma değil. Evet, oyunu alta alınca veya belli bir süre sonra bu sorunun olması gayet normal. Fakat asıl sorun ilk giyişte de olmaması gerekir.
Kısaca sorun özeti: Daha önce bir defa render alınmış kodlar, belli bir zaman sonra sanki render alınmamış gibi oluyor. (Client kapanmadıkça olmaması gerekir.)

İkinci zırh giyiş saniyesi: 01.08

Kaiser · Pazartesi 21:56

Öncelikle senin senaryonda cache ile alakalı bir durum söz konusu değil. Sorunun kaynağı birden fazla sebebe bağlı olabilir.
Bunu çözebilmek için öncelikle kendine bir yol çizmen gerekiyor, konuda belirttiklerin ve + olarak tam hangi durumlarda bu sorun yaşanıyor? Hangi zamanda yaşanıyor? ne yapınca yaşanıyor veya ne giyince yaşanıyor?

İç ve dış itemlerin giy-çıkar olayı en genel anlamda equip olayına bağlanır. Eğer equip ve bağlantıları ile alakalı olsaydı tüm itemlerde aynı şey olurdu.

İç itemlerin dünya sahnesi ile alakası olmadığı için böyle bir şeye sebep olacaklarını sanmıyorum zaten.
Dış itemlere gelince; saçlar, kostümler, silahlar ve sonradan eklenen giyilebilir sistemler (kuşak-kanat-aura vs) her birinde bu sorun yaşanıyor mu?

Eğer sadece zırhlarda bu sorunu yaşıyorsan bu sana bir başlangıç noktası gösterir.
O da InstanceBase.cpp içindeki SetArmor ve ChangeArmor fonksiyonları. Özellikle de ChangeArmor fonksiyonunda bir takım farklı olaylar gerçekleşiyor, fonksiyon içeriğine bakarsan fark edeceksin.

En basit test olarak da fonksiyonun içeriğini gösterdiğim gibi düzenle.

C++:

bool CInstanceBase::ChangeArmor(DWORD dwArmor)
{
    return false;
    [...]
}

Yani fonksiyonu tamamen devre dışı bırak.
Ve videoda yaptığın işlemin aynısını tekrar dene. Syserr veya oyun içi hatalar alabilirsin doğal olarak, onları boşver. O esnada client'ın takılıp takılmaması önemli sadece, bu senaryoda zırhın değişmesini zaten beklemiyoruz.
Bunu denedikten sonra client donma sorunu çözülürse burası sana ikinci referans noktası olacaktır.

Daha sonrasında fonksiyonu eski haline getirip içerisindeki çağrıların her birini live debug ile sırasıyla yoruma çevir ve tekrar tekrar dene. Bu şekilde ilerlemen gereken yolu visual studio sana gösterecektir.

DeadLyEscaPe · Pazartesi 23:44

Kaiser demiş ki:
Öncelikle senin senaryonda cache ile alakalı bir durum söz konusu değil. Sorunun kaynağı birden fazla sebebe bağlı olabilir.
Bunu çözebilmek için öncelikle kendine bir yol çizmen gerekiyor, konuda belirttiklerin ve + olarak tam hangi durumlarda bu sorun yaşanıyor? Hangi zamanda yaşanıyor? ne yapınca yaşanıyor veya ne giyince yaşanıyor?

İç ve dış itemlerin giy-çıkar olayı en genel anlamda equip olayına bağlanır. Eğer equip ve bağlantıları ile alakalı olsaydı tüm itemlerde aynı şey olurdu.

İç itemlerin dünya sahnesi ile alakası olmadığı için böyle bir şeye sebep olacaklarını sanmıyorum zaten.
Dış itemlere gelince; saçlar, kostümler, silahlar ve sonradan eklenen giyilebilir sistemler (kuşak-kanat-aura vs) her birinde bu sorun yaşanıyor mu?

Eğer sadece zırhlarda bu sorunu yaşıyorsan bu sana bir başlangıç noktası gösterir.
O da InstanceBase.cpp içindeki SetArmor ve ChangeArmor fonksiyonları. Özellikle de ChangeArmor fonksiyonunda bir takım farklı olaylar gerçekleşiyor, fonksiyon içeriğine bakarsan fark edeceksin.

En basit test olarak da fonksiyonun içeriğini gösterdiğim gibi düzenle.

C++:

bool CInstanceBase::ChangeArmor(DWORD dwArmor) { return false; [...] }

Yani fonksiyonu tamamen devre dışı bırak.
Ve videoda yaptığın işlemin aynısını tekrar dene. Syserr veya oyun içi hatalar alabilirsin doğal olarak, onları boşver. O esnada client'ın takılıp takılmaması önemli sadece, bu senaryoda zırhın değişmesini zaten beklemiyoruz.
Bunu denedikten sonra client donma sorunu çözülürse burası sana ikinci referans noktası olacaktır.

Daha sonrasında fonksiyonu eski haline getirip içerisindeki çağrıların her birini live debug ile sırasıyla yoruma çevir ve tekrar tekrar dene. Bu şekilde ilerlemen gereken yolu visual studio sana gösterecektir.

Merhaba. Sizinle discord üzerinden aylar önce yardımlaşmıştık. Epey bir vakit ayırıp yardımcı olmuştunuz. Bu durum sadece zırhta oluyor. Dediğiniz gibi süper bir başlangıç noktası oldu. Aylardır silahı denememem de ayrı bir acemilik. En azından artık sorunun zırhla ilgili olduğunu biliyorum. Dediğiniz gibi return false koyduktan sonra zırh envanter üzerinde değişiyor fakat karakterin üzerinde değişmiyor. Donma söz konusu değil. Bundan sonra çağırdığı fonksiyonlara bakıp ilerleyeceğim.

Ekstra şöyle bir durum mevcut. (Birbirleriyle bağlantılı olabilir mi diye soruyorum...) İlk kez karakter ekranına giriş yapalım. Karakterler arasında ilk kez gezmeye çalıştığımızda yine bir gecikme söz konusu. Bu da karakterin üzerinde giyili olan zırhlardan mı kaynaklanır yoksa komple karakter modellemesinden mi? O da bir soru işareti. Devamında karakterler arasında gezdiğimizde takılma söz konusu değil. (İki karakterinde zırhlarını çıkartıp öyle test ettim.) Sorun karakter ekranında karakterlerin zırhlarından kaynaklı değil, bizzat kendi modellemesinin ilk kez yüklendiğinde olan gecikmesi. Bu konuyu çok uzattım, bu sorun zaten metin2 bilindiğinden beri mevcut. Asıl konuya gelecek olursak;

Konuda bahsetmeyi unuttuğum bir şey var. Oyunun official, bilinen en ham halinde karakter ekranındaki durum mevcut. Peki ya bu zırh değiştirme konusu mevcut mu? İlk kez açılan bir clientte, ilk kez değiştirilen bir zırhta donma yaşanıyor mu? O bir problem mi? Hayır... O bir problem değil, 1 dakika geçmeden tekrardan donma gerçekleşmesi mi asıl olan problem?

Bana kalırsa mevcut sorun tamamen render optimizasyonu ile alakalı. Oyun özellikle alt sekmeye alınınca arkada biriken her ne ise oyunu yavaşlatıyor. Bu da modellerden mi efektlerden mi kaynaklanıyor bilemiyorum.

Kafanızı çok karıştırdıysam kusura bakmayın.

luigina · Salı 00:58

Yaşadığınız problem speculardan olabilir normal bir fileste bu tarz bir durum mevcut değil. Kullandığınız fileste grafik geliştirmesi adı altında yapılan bir çok işlem olduğu için oralara bakmanızda fayda var.

DeadLyEscaPe · Salı 01:01

luigina demiş ki:
Yaşadığınız problem speculardan olabilir normal bir fileste bu tarz bir durum mevcut değil. Kullandığınız fileste grafik geliştirmesi adı altında yapılan bir çok işlem olduğu için oralara bakmanızda fayda var.

Evet. Directx9 ve grafikleri zenaristen çekmiştim. Specular kısımlarına tekrar bakacağım ama ben daha önceden eklediğim Render target sisteminden şüpheleniyorum. Ya komple kaldırmayı deneyeceğim ya da grafikleri çektiğim filestan render target çekmeyi deneyeceğim.

Buradan bir çıkış yolu bulamıyorum.

Kaiser · Salı 11:13

DeadLyEscaPe demiş ki:
Merhaba. Sizinle discord üzerinden aylar önce yardımlaşmıştık. Epey bir vakit ayırıp yardımcı olmuştunuz. Bu durum sadece zırhta oluyor. Dediğiniz gibi süper bir başlangıç noktası oldu. Aylardır silahı denememem de ayrı bir acemilik. En azından artık sorunun zırhla ilgili olduğunu biliyorum. Dediğiniz gibi return false koyduktan sonra zırh envanter üzerinde değişiyor fakat karakterin üzerinde değişmiyor. Donma söz konusu değil. Bundan sonra çağırdığı fonksiyonlara bakıp ilerleyeceğim.

Ekstra şöyle bir durum mevcut. (Birbirleriyle bağlantılı olabilir mi diye soruyorum...) İlk kez karakter ekranına giriş yapalım. Karakterler arasında ilk kez gezmeye çalıştığımızda yine bir gecikme söz konusu. Bu da karakterin üzerinde giyili olan zırhlardan mı kaynaklanır yoksa komple karakter modellemesinden mi? O da bir soru işareti. Devamında karakterler arasında gezdiğimizde takılma söz konusu değil. (İki karakterinde zırhlarını çıkartıp öyle test ettim.) Sorun karakter ekranında karakterlerin zırhlarından kaynaklı değil, bizzat kendi modellemesinin ilk kez yüklendiğinde olan gecikmesi. Bu konuyu çok uzattım, bu sorun zaten metin2 bilindiğinden beri mevcut. Asıl konuya gelecek olursak;

Konuda bahsetmeyi unuttuğum bir şey var. Oyunun official, bilinen en ham halinde karakter ekranındaki durum mevcut. Peki ya bu zırh değiştirme konusu mevcut mu? İlk kez açılan bir clientte, ilk kez değiştirilen bir zırhta donma yaşanıyor mu? O bir problem mi? Hayır... O bir problem değil, 1 dakika geçmeden tekrardan donma gerçekleşmesi mi asıl olan problem?

Bana kalırsa mevcut sorun tamamen render optimizasyonu ile alakalı. Oyun özellikle alt sekmeye alınınca arkada biriken her ne ise oyunu yavaşlatıyor. Bu da modellerden mi efektlerden mi kaynaklanıyor bilemiyorum.

Kafanızı çok karıştırdıysam kusura bakmayın.

Eğer return false işleminden sonra takılma sorunu olmuyorsa ChangeArmor içindeki çağrıları tek tek yorum satırına çevirip (pasif hale getirip)
live debug ile hangi çağrının buna sebep olduğunu tespit edebilirsin. Konunun modellerle veya render ile doğrudan bir alakası olduğunu düşünmüyorum. Yine de emin değilim. Ancak böylesine basit bir işlemde bile clientın donması, öte yandan yanlış bellek yönetimi ihtimalini de aklıma getiriyor. Bunu yüzeysel olarak test etmek için görev yöneticisinde metin2.exe nin bellek kullanımını zırh değiştirme ve donma anında takip et. Eğer arka arkaya zırh değiştirirken 1-2MB gibi bir oynama oluyorsa bellek yönünden sorun yoktur. Ancak daha fazla miktarda oynama olursa bu durum da dikkate alınmalı.
Ama en nihayetinde tüm bunlardan farklı olarak çok basit bir çözümü de olabilir.. Metin2 bu gibi konularda çok şaşırtabiliyor.

ChangeArmor içindeki şüpheli çağrıyı tespit ettikten sonra o çağrının yapısını incelemen gerekir.
GameLib/ActorInstance ailesi ve EterGrnLib kütüphanesiyle bağlantısı olması muhtemel.

DeadLyEscaPe · Salı 22:34

Kaiser demiş ki:
Eğer return false işleminden sonra takılma sorunu olmuyorsa ChangeArmor içindeki çağrıları tek tek yorum satırına çevirip (pasif hale getirip)
live debug ile hangi çağrının buna sebep olduğunu tespit edebilirsin. Konunun modellerle veya render ile doğrudan bir alakası olduğunu düşünmüyorum. Yine de emin değilim. Ancak böylesine basit bir işlemde bile clientın donması, öte yandan yanlış bellek yönetimi ihtimalini de aklıma getiriyor. Bunu yüzeysel olarak test etmek için görev yöneticisinde metin2.exe nin bellek kullanımını zırh değiştirme ve donma anında takip et. Eğer arka arkaya zırh değiştirirken 1-2MB gibi bir oynama oluyorsa bellek yönünden sorun yoktur. Ancak daha fazla miktarda oynama olursa bu durum da dikkate alınmalı.
Ama en nihayetinde tüm bunlardan farklı olarak çok basit bir çözümü de olabilir.. Metin2 bu gibi konularda çok şaşırtabiliyor.

ChangeArmor içindeki şüpheli çağrıyı tespit ettikten sonra o çağrının yapısını incelemen gerekir.
GameLib/ActorInstance ailesi ve EterGrnLib kütüphanesiyle bağlantısı olması muhtemel.

Ram kullanımı oyuna ilk girişte zırh giymeden önce 1.070 MB.
İlk giyişte donma yaşandıktan sonra 1.155 MB.

85 MB fark var. Konudaki videodaki gibi bekleme sonrası ram kullanımı kendi kendine tekrardan ilk haline 1.070 MB düşüyor. Sonrası malum tekrar zırh giyildiğinde tekrardan 60 - 70 MB ram artışı söz konusu. Kendi kendine düşmesi biraz ilginç geldi. Bu konu hakkında ne düşünüyorsunuz. Dediğiniz gibi render ve modellemelerle ilgili olduğunu ben de artık sayenizde düşünmüyorum. Hangi dosyalara ve nerelere yönümü çevirmeliyim bu konuda?

Bu arada SetArmor, tam karakterin zırh değişimi esnasında lag oluyor. O satırı kaldırınca karakter yere çakıldı ve lag oluşmadı. (Zırhı giyemedi.)

@Kaiser

Kaiser · Çarşamba 11:01

Sadece zırh değiştirme ile bu kadar bellek oynaması çok anormal.
Dediğim gibi sebep olan fonksiyon çağrılarını sırasıyla tespit ederek ilerlemen bu sorunu çözmene yardımcı olacaktır.
ChangeArmor'dan SetArmor'u tespit edip geçiş yaptığın gibi, SetArmor'dan da bir sonraki sebep olan çağrıyı tespit etmen lazım. Bu şekilde sorunlu kısımları bulabilirsin.

Bir buffer veya yanlış yönetilen işaretçi sorunu olabilir.

DeadLyEscaPe · Çarşamba 22:18

Kaiser demiş ki:
Bir buffer veya yanlış yönetilen işaretçi sorunu olabilir.

Burada tam olarak ne demek istediniz?

Kaiser · Dün 13:43

DeadLyEscaPe demiş ki:
Burada tam olarak ne demek istediniz?

C++ bazı işlemler için geçici tampon bellek oluşturulur ve işlem bitince bu bellekler kendini yok eder/etmeli.
Eğer bu tampon belleklerle ilgili bir taşma-zorlama veya yanlış yönetim gibi bir durum söz konusu olursa, bu bellekteki verilerin işlenmesi de zorlaşabilir.

Örnek olarak:

C++:

char buffer[10];
strcpy(buffer, "Türkiye'nin başkenti Ankara'dır.");

Burada 10 karakterlik bir bellek ayrılıyor ve içerisine veri yazılmaya çalışılıyor. Bu kod zaten başlı başına hatalı olduğu için çalışmayacaktır çünkü strcpy ile belleğe yazılmaya çalışılan veri 10 karakter sınırını aşıyor.

Aşağıdaki örnekten devam edeyim:

C++:

char buffer[10];
strcpy(buffer, "abc");

Bu kod ise sorunsuz olarak çalışacaktır.
Ancak buradaki kritik nokta şu; burada oluşturulan belleği işlem sonunda yok etmezsem veya doğru bağlamlarda yönetmezsem her kullanımda doluluk oranı artacaktır ve finalde de sorunlar yaşatacaktır.

Daha iyi anlaşılması için bu durumu senin senaryona uyarlayayım:

C++:

void CInstanceBase::SetArmor(DWORD dwArmor)
{
    //ORNEK
    char buffer[10];
    strcpy(buffer, "abc");
    //ORNEK
 
    [...]
}

Burada buffer belleği bir şekilde yok edilmediği veya iyi yönetilmediği sürece, SetArmor her çalıştığında buffer belleğine 3 karakterlik bir veri yazılacaktır. (abc)

Ve SetArmor fonksiyonu 3.kez çalıştığında buffer belleğinin doluluk oranı 9 olacaktır ve 4.kez bu fonksiyonu çalıştırmaya çalıştığında muhtemelen crash yaşanacaktır. Çünkü bellek yönetimi eksik veya yanlış olduğundan sonuç olarak 3 karakterlik bir veri daha yazılacak tampon bellek kalmamış olacak.

Burada verdiğim örnek sadece anlaşılması içindir. Doğrudan metin2 kodları ile bir bağlantısı yoktur, dolaylı yoldan mantığı anlatmaya çalıştım.

SetArmor veya ChangeArmor içindeki diğer kütüphanelere olan çağrıları ele almanda fayda var. Specular, shape, CAffectFlagContainer, m_GraphicThingInstance gibi nesnelerin peşini koşturabilirsin. Çünkü bunlar daha derinlere uzanan (GameLib/ActorInstance ve EterGrnLib) kütüphanelerle bağlantılı öğelerdir ve bunlarda verdiğim örnekle alakalı veya benzeri bir problem mevcut olabilir.

Ek olarak yanlış bir şekilde veya yanlış bir yerde * ile oluşturulan sınıf örnekleri de benzer sonuçlara sebebiyet verebilir.
(Sadece örnek):

C++:

CItemData * pItemData;

Şeklinde bir örnek oluşturma işlemi, eğer yanlış bir yerde veya bir döngü içinde gibi alanlarda kullanılırsa, ard arda aynı nesneyi oluşturacağı için bellek sorunlarına neden olabilir.

Bu faktörleri göz önüne alarak inceleme yapabilirsin. Veya farklı fileslerle kıyaslama yapabilirsin.

DeadLyEscaPe · Dün 19:04

Kaiser demiş ki:
C++ bazı işlemler için geçici tampon bellek oluşturulur ve işlem bitince bu bellekler kendini yok eder/etmeli.
Eğer bu tampon belleklerle ilgili bir taşma-zorlama veya yanlış yönetim gibi bir durum söz konusu olursa, bu bellekteki verilerin işlenmesi de zorlaşabilir.

Örnek olarak:

C++:

char buffer[10]; strcpy(buffer, "Türkiye'nin başkenti Ankara'dır.");

Burada 10 karakterlik bir bellek ayrılıyor ve içerisine veri yazılmaya çalışılıyor. Bu kod zaten başlı başına hatalı olduğu için çalışmayacaktır çünkü strcpy ile belleğe yazılmaya çalışılan veri 10 karakter sınırını aşıyor.

Aşağıdaki örnekten devam edeyim:

C++:

char buffer[10]; strcpy(buffer, "abc");

Bu kod ise sorunsuz olarak çalışacaktır.
Ancak buradaki kritik nokta şu; burada oluşturulan belleği işlem sonunda yok etmezsem veya doğru bağlamlarda yönetmezsem her kullanımda doluluk oranı artacaktır ve finalde de sorunlar yaşatacaktır.

Daha iyi anlaşılması için bu durumu senin senaryona uyarlayayım:

C++:

void CInstanceBase::SetArmor(DWORD dwArmor) { //ORNEK char buffer[10]; strcpy(buffer, "abc"); //ORNEK [...] }

Burada buffer belleği bir şekilde yok edilmediği veya iyi yönetilmediği sürece, SetArmor her çalıştığında buffer belleğine 3 karakterlik bir veri yazılacaktır. (abc)

Ve SetArmor fonksiyonu 3.kez çalıştığında buffer belleğinin doluluk oranı 9 olacaktır ve 4.kez bu fonksiyonu çalıştırmaya çalıştığında muhtemelen crash yaşanacaktır. Çünkü bellek yönetimi eksik veya yanlış olduğundan sonuç olarak 3 karakterlik bir veri daha yazılacak tampon bellek kalmamış olacak.

Burada verdiğim örnek sadece anlaşılması içindir. Doğrudan metin2 kodları ile bir bağlantısı yoktur, dolaylı yoldan mantığı anlatmaya çalıştım.

SetArmor veya ChangeArmor içindeki diğer kütüphanelere olan çağrıları ele almanda fayda var. Specular, shape, CAffectFlagContainer, m_GraphicThingInstance gibi nesnelerin peşini koşturabilirsin. Çünkü bunlar daha derinlere uzanan (GameLib/ActorInstance ve EterGrnLib) kütüphanelerle bağlantılı öğelerdir ve bunlarda verdiğim örnekle alakalı veya benzeri bir problem mevcut olabilir.

Ek olarak yanlış bir şekilde veya yanlış bir yerde * ile oluşturulan sınıf örnekleri de benzer sonuçlara sebebiyet verebilir.
(Sadece örnek):

C++:

CItemData * pItemData;

Şeklinde bir örnek oluşturma işlemi, eğer yanlış bir yerde veya bir döngü içinde gibi alanlarda kullanılırsa, ard arda aynı nesneyi oluşturacağı için bellek sorunlarına neden olabilir.

Bu faktörleri göz önüne alarak inceleme yapabilirsin. Veya farklı fileslerle kıyaslama yapabilirsin.

Çok teşekkür ederim vakit ayırdığın için. Çok açıklayıcı olmuş. Bunları göz alarak tekrardan inceleyeceğim.

Ara

Yardım Belli bir süre sonra render etkisinin kaybolması

DeadLyEscaPe

Üye

Kaiser

Admin

DeadLyEscaPe

Üye

luigina

Üye

DeadLyEscaPe

Üye

Kaiser

Admin

DeadLyEscaPe

Üye

Kaiser

Admin

DeadLyEscaPe

Üye

Kaiser

Admin

DeadLyEscaPe

Üye

Benzer konular