İleride değiştiririm artık onu daArial fonta gıcık olduğum kadar hiçbir şeye gıcık değilim
Sonradan uyarladım:
Kaiser Graphic | Changelog
- Konuyu açan Kaiser
- Açılış Tarihi
- Yanıt 63
- Gösterim 4K
10x daha iyi. Ama yine de mobil oyun havası var. uygun bir font lazım.
orjinal halinde tahoma kullanıyor bence onun dışında başka font pek hoş durmuyor
Güncelleme sonrası ilk aklıma arial geldiği için direkt onu çalıştırmıştım. Şimdi yorumu görünce tahomayı denedim, biraz daha düzgün oldu.
Mobil hava gibi görünmesinin nedeni biraz da eşekten inip ata binmek olsa gerek
Önceki güncellemeye ek:
Yeni metin işleme yapısının pek çok eksiği mevcuttu ve doğal olarak oyunun birçok hassas noktalarında bozukluklar meydana gelmişti.
Fark ettiğim kadarıyla;
Yeni metin işleme yapısının pek çok eksiği mevcuttu ve doğal olarak oyunun birçok hassas noktalarında bozukluklar meydana gelmişti.
Fark ettiğim kadarıyla;
- Quest pencerelerine uyarlandı.
- Premium sistemine uyarlandı.
- MultiTextline sistemine uyarlandı.
- Emoji key sistemine uyarlandı.
- Item yansıtma işlemine uyarlandı.
- Silah evrim sistemine uyarlandı. + Evrimli silahların yansıtılması iyileştirildi.
- Pythondan gönderilen renk kodlarını tanıyacak şekilde düzenlendi.
- Mouse imlecine/UI Shader'a uyarlandı.
Bozulmuş hali
| Sonra
|
Filesi verde azda biz gelistirek kaiser bey .d
Güncelleme:
Sadece bir fikir olarak ileride Directx11 güncelleme gibi düşüncem vardı. Hala var, ancak bu ne kadar mümkün olur emin değilim. Ama her halükarda ön hazırlık ve iyileştirme maksadıyla Directx9'u mümkün olduğunca soyutlamaya çalışıyorum.
Şu ana kadar bu konuda zaten birkaç iyileştirme yapmıştım ve eski dosyaları/kodları ya sildim ya da iyileştirdim.
Şimdi ise Metin2'de DirectX8 ve DirectX9'un kalbi olan GrpDetector.cpp ve GrpDetector.h dosyaları ve bağımlılıkları proje genelinde tamamen kullanımdan kaldırıldı. Bunların yapmış olduğu çok uzun ve karmaşık işlemler artık tek bir modern yapı üzerinden hızlı ve kısa sürede gerçekleştirilir. Cihazın pencere üzerindeki kontrolleri - yönetimi vb. gibi işlemler çok daha basite indirgenip sadeleştirildi.
Özetle; 610 satırın yaptığı işi(GrpDetector) artık 55 satırlık bir yapı yapıyor. Bunun en önemlisi getirisi, gereksiz ve eski karmaşalardan uzak, geleceğe yönelik esnek, hızlı ve yönetilebilir bir işlevselliktir.
Sadece bir fikir olarak ileride Directx11 güncelleme gibi düşüncem vardı. Hala var, ancak bu ne kadar mümkün olur emin değilim. Ama her halükarda ön hazırlık ve iyileştirme maksadıyla Directx9'u mümkün olduğunca soyutlamaya çalışıyorum.
Şu ana kadar bu konuda zaten birkaç iyileştirme yapmıştım ve eski dosyaları/kodları ya sildim ya da iyileştirdim.
Şimdi ise Metin2'de DirectX8 ve DirectX9'un kalbi olan GrpDetector.cpp ve GrpDetector.h dosyaları ve bağımlılıkları proje genelinde tamamen kullanımdan kaldırıldı. Bunların yapmış olduğu çok uzun ve karmaşık işlemler artık tek bir modern yapı üzerinden hızlı ve kısa sürede gerçekleştirilir. Cihazın pencere üzerindeki kontrolleri - yönetimi vb. gibi işlemler çok daha basite indirgenip sadeleştirildi.
Özetle; 610 satırın yaptığı işi(GrpDetector) artık 55 satırlık bir yapı yapıyor. Bunun en önemlisi getirisi, gereksiz ve eski karmaşalardan uzak, geleceğe yönelik esnek, hızlı ve yönetilebilir bir işlevselliktir.
Güncelleme:
Eğer zaman içinde farklı yerlerde farklı sorunlar görmezsem text render güncellemesi tamamlanmıştır demektir.
Aklıma gelebilecek bütün noktaları test ettim.
Yere düşen itemlerin isimleri, chat konuşmaları, questler, tooltip textleri, affectlerin infosu, UI nesneleri vs.. eğer kritik nokta diyebileceğiniz yerler varsa belirtebilirsiniz, onları da kontrol ederim. Ama aklıma başka bir şey gelmedi.
Buna ek olarak; textler için optimizasyon iyileştirmesi uygulandı.
Üstteki görselde 500 adet köpek var ve FPS fotoğrafta görüldüğü gibi 34'dür.
Optimizasyon öncesi değerler:
300 Köpek : 33 FPS
Optimizasyon sonrası değerler:
300 Köpek : 56 FPS
600 Köpek : 34 FPS
Yani sadece textlerden yaklaşık %70 FPS kârımız var.. Tabi bu sonuçları hala olumsuz etkileyen faktörler var.
Bu sadece text öğelerini kapsayan bir optimizasyondur. Bunun haricinde diğer alanlara da aynı işlemleri yapmam gerekecek.
Mesela; şu an 30 adet metin taşı attığımda FPS 35'e düşüyor. Çünkü metin taşı köpekten farklı olarak = efekt + model + text demek.
Bu durumda da sadece text optimizasyonu yetersiz kalıyor ve her halükarda efekt ve model renderları tarafından eziliyor.
Genel olarak hepsini optimize ettiğimde bu değerlerin daha da yükseleceğini düşünüyorum.
Eğer zaman içinde farklı yerlerde farklı sorunlar görmezsem text render güncellemesi tamamlanmıştır demektir.
Aklıma gelebilecek bütün noktaları test ettim.
Yere düşen itemlerin isimleri, chat konuşmaları, questler, tooltip textleri, affectlerin infosu, UI nesneleri vs.. eğer kritik nokta diyebileceğiniz yerler varsa belirtebilirsiniz, onları da kontrol ederim. Ama aklıma başka bir şey gelmedi.
Buna ek olarak; textler için optimizasyon iyileştirmesi uygulandı.
Üstteki görselde 500 adet köpek var ve FPS fotoğrafta görüldüğü gibi 34'dür.
Optimizasyon öncesi değerler:
300 Köpek : 33 FPS
Optimizasyon sonrası değerler:
300 Köpek : 56 FPS
600 Köpek : 34 FPS
Yani sadece textlerden yaklaşık %70 FPS kârımız var.. Tabi bu sonuçları hala olumsuz etkileyen faktörler var.
Bu sadece text öğelerini kapsayan bir optimizasyondur. Bunun haricinde diğer alanlara da aynı işlemleri yapmam gerekecek.
Mesela; şu an 30 adet metin taşı attığımda FPS 35'e düşüyor. Çünkü metin taşı köpekten farklı olarak = efekt + model + text demek.
Bu durumda da sadece text optimizasyonu yetersiz kalıyor ve her halükarda efekt ve model renderları tarafından eziliyor.
Genel olarak hepsini optimize ettiğimde bu değerlerin daha da yükseleceğini düşünüyorum.
Güncelleme:
Dungeon haritalar çok baş ağrıttığı için diğer tüm yapıdan ayrıldı. Bu haritalar için yeni bir dungeon shader hazırlandı ve sadece zindanlarda çalışacak şekilde ayarlandı. Bunu yapmamdaki sebep ise zindanların materyal tipinin çok farklı ve teferruatlı olması. Mevcut material shader ile işin içinden çıkamayınca ayrıştırmaya karar verdim. Bunun yanı sıra şu açıdan iyi oldu; ilerleyen zamanlarda istenilen herhangi bir zindan için özelleştirmeler daha rahat ve esnek şekilde yapılabilir. Örneğin; şeytan kulesinin atmosferini ve aydınlatmasını değiştirme gibi..
Diğer tüm haritalar düzgün çalışırken zindanların ahval;
Son hal:
Dungeon haritalar çok baş ağrıttığı için diğer tüm yapıdan ayrıldı. Bu haritalar için yeni bir dungeon shader hazırlandı ve sadece zindanlarda çalışacak şekilde ayarlandı. Bunu yapmamdaki sebep ise zindanların materyal tipinin çok farklı ve teferruatlı olması. Mevcut material shader ile işin içinden çıkamayınca ayrıştırmaya karar verdim. Bunun yanı sıra şu açıdan iyi oldu; ilerleyen zamanlarda istenilen herhangi bir zindan için özelleştirmeler daha rahat ve esnek şekilde yapılabilir. Örneğin; şeytan kulesinin atmosferini ve aydınlatmasını değiştirme gibi..
Diğer tüm haritalar düzgün çalışırken zindanların ahval;
Son hal:
Güncelleme:
Efektler için çok iyi olmamakla birlikte optimizasyon uygulandı. Önceki mesajımda 30 metin taşı çağırdığımda FPS'in 35'e düştüğünü söylemiştim.
Şu an 30 metin taşı = 45 FPS. En karmaşık mantığa sahip olduğundan henüz materyallere dokunamadım ama şu an için durum böyle. Hala bir miktar darboğaz mevcut, ama ayar vereceğim bir şekilde. Materyalleri de optimize ettiğimde bu değerin bir miktar daha artacağını düşünüyorum.
Ek olarak;
EterLib/TextBar.cpp
EterLib/TextBar.h
EterLib/DibBar.cpp
EterLib/DibBar.h
Bu dosyalar ve bağımlı oldukları diğer eski kodlar tamamen projeden kaldırıldı. Bunların üstlendiği görevler FreeType'a devredildi.
Efektler için çok iyi olmamakla birlikte optimizasyon uygulandı. Önceki mesajımda 30 metin taşı çağırdığımda FPS'in 35'e düştüğünü söylemiştim.
Şu an 30 metin taşı = 45 FPS. En karmaşık mantığa sahip olduğundan henüz materyallere dokunamadım ama şu an için durum böyle. Hala bir miktar darboğaz mevcut, ama ayar vereceğim bir şekilde. Materyalleri de optimize ettiğimde bu değerin bir miktar daha artacağını düşünüyorum.
Ek olarak;
EterLib/TextBar.cpp
EterLib/TextBar.h
EterLib/DibBar.cpp
EterLib/DibBar.h
Bu dosyalar ve bağımlı oldukları diğer eski kodlar tamamen projeden kaldırıldı. Bunların üstlendiği görevler FreeType'a devredildi.
Ne kadar kullanışlı olur emin değilim ama şöyle bir fikir geldi aklıma. Bu tarz moblarin fazla olduğu durumlarda belirli bir radius içindeki moblari gruplayip tek bir text olarak göstermek. Mesela köylerdeki moblara da bu tarife uygulanabilir, tek tek hepsinin ismini yazdırmak yerine grup olduklarından sadece o ismi yazdirmak. Tabi sadece bir fikir tartışmaya açık. Mobların kendi isimleri tabi yine üstlerine tıklayınca görünecek.
Biraz meşakkatli bir yöntem ama işe yarayabilir. Aslında metin2 varsayılanda da tam olarak dediğin mantıkta çalışıyor.
Distance kontrolü ile dışta kalan textleri render listesinden çıkarıyor. Yani altyapı olarak zaten bu özelliğe sahip ancak üzerine gidilip geliştirilebilir elbette. Zaten pek verimli çalıştığını sanmıyorum..
Şuanki yapıda eski render mantığında olduğu gibi her gördüğü pixeli doğrudan çizmek yerine o an işleme alınan textlerin tamamını 2048x2048 boyutunda(değiştirilebilir) atlas dokusu içerisine kodlayıp shadera gönderiyor. Bu da beraberinde ciddi performans kayıplarının önüne geçiyor.
Yani birnevi süzgeç gibi düşünülebilir: Atlasa kodlanmayan text shadera gitmez -> shadera gitmeyen text çizilmez
Fakat şu noktadan itibaren textler de dahil olmak üzere diğer tüm render yapılarını ağırlıklı olarak C++ tarafında iyi bir noktaya ulaşana dek optimize etmek gerekiyor. Çünkü artık shaderların bu noktada yapabileceği bir şey kalmadı. Dolayısıyla görsel güncellemelere biraz ara verip bu alana yöneldim. Ayrıca fikir için teşekkürler, bunu değerlendireceğim.
atlas oluşturma işlemi texturelar içinde uygulanabilir, mevcut halinde her bir mesh materyalini tek tek renderlıyor(ek olarak aynı olsa bile yeniden renderlıyor). 512x512 zemin/terrain ya da materyal texturelarınıda 2048x2048 atlaslar üzerinden yönetebilirsiniz.
efekt'e dönecek olursak benim gördüğüm kadarıyla ana sorun partiküller, yine buradada diğer her yerde olduğu gibi partikülleride tek tek renderlıyor, renderlama mantığını
Linkleri görebilmek için
giriş yap veya kayıt ol.
mantığında düzenlenirse baya faydası olacaktır, her bir partikül yerine her partikül setini renderlar ve yük altığında %20-30 gibi bir fps kazancı sağlar.çok fazla düzenlenmesi gereken şey var hepsine tek tek girmeye gerek yok temel olarak hepsindeki ortak sıkıntı render çağrılarının her bir hedef için tek tek yapılması bu mantıkta renderlanan hedefleri
Linkleri görebilmek için
giriş yap veya kayıt ol.
ile düzenlediği taktirde render kısmındaki sorunun büyük bir kısmı kalkar, geri kalanıda shader üstünden gpu'ya taşıma ki zaten zor kısmıda bitmiş.
Materyallerde dediğin sorunu daha önceden çözmüştüm, şu an aynı olan materyaller dediğin gibi tekrar tekrar rendera(shadera) gitmiyor artık. Yeni bir nesne gibi, tekrar tekrar doku ataması vb. toplara girmiyor. Bunun "oha" dedirtecek bir etkisi olmadı elbette ancak sayısal değerlere bakmadan da gözle görülür etkisi oldu diyebilirim. Materyaller için motor seviyesinde bir batch render uygulamak biraz zor geldi çünkü değişken bir yapıya sahip, farklı vertex structlarını falan kullanıyor ve dediğin gibi materyal type'ına göre materyali işleme mantığı değişiyor vs vs. Text render,effect render falan sonuçta sabit bir nesne üzerine kurulu ama materyaller öyle değil maalesef. Buna en uygun iyileştirme instanced render olacaktır diye düşünüyorum.
Atlas oluşturma işlemini genele yayma fikrini de şu an için erteliyorum çünkü öncesinde çözülmeyi bekleyen pek çok önemli noktalar mevcut hala.
Bahsi geçen optimizasyonlara ek olarak metin2'nin sahip olduğu eski C++98 yapısını da mümkün olduğunca güncelliyorum.
Basit örnekle; std::map gerektirmeyen ama std::map kullanılmış yerleri unerdored_map'e çevirme gibi.. damlaya damlaya göl olur hesabı
Ellerine sağlık takipteyim. AMD’de specular beyaz sorunu ile karşılaştım geçenlerde, ama sadece AMD ekran kartında yapıyor böyle bir şeyi. Senin de başına geldi mi? Bazı skinler bembeyaz duruyor, bunu da specular ayarından yapıyor gibi; mesela item +9'da beyaz görünüyor.
Hayır böyle bir sorun yaşamadım.
Dediğin gibi aynı client her iki markada da farklı şekilde çalışıyorsa sorunun kaynağı çok yüksek ihtimalle shader kodundandır. Çünkü AMD shader kodlarını okuyup işlemede Nvidia'ya göre çok daha katı kurallara sahip. Nvidia bu durumları tolere edip kendisi clamp yapıyor gene değerleri işliyor ama AMD "bana doğru düzgün bir değer, bir sınır göster" mantığıyla çalışıyor biraz.
Doku-alpha-specular (tam olarak hangisinde sorun yaşıyorsan) onun hesaplamasını yaparken min-max aralığını GPU'nun anlayacağı net bir şekilde belirt.
Örneğin;
C:
float specularFactor = pow(dot, specularPower);Ama AMD bunu yapmayacağı için
pow() saturate() vb. sonucu her zaman NaN/bozuk olur.Sorunlu kısmı tespit edip şu mantığı deneyebilirsin, muhtemelen sorununu çözecektir:
C:
// specularPower = clientten gelen specular olsun.
// yeni bir safeSpecularPower ile clientten gelen specularPower'ı belirli bir aralığa sıkıştır.
float safeSpecularPower = max(0.001f, specularPower); // artık NaN üretme ihtimali yok
// pow işleminde güvenli safeSpecularPower değerini kullan >>
float specularFactor = pow(dot, safeSpecularPower);Güncelleme:
Önceki güncelleme mesajlarımdan alıntı olarak:
30 Metin taşı : 45 FPS
600 Köpek : 34 FPS
gibi bir tablo vardı.
Şu an:
100 Metin taşı: 46 FPS
1000 Mob/Actor : 28 FPS
Tabi bu sonuçlara çevresel faktörler de hala eski haliyle çalıştıkları için etki etmekte. (Effect, text vb.)
Efekt ve textlere zaten bir optimizasyon işlemi uygulamıştım ancak beni tatmin etmedi, bu yüzden ilerleyen zamanlarda onları ve diğerlerini de bu yeni render yapısına göre güncelleyeceğim.
Tüm bu süreç biraz zor ve uzun geçecek.
Ek olarak:
- DrawPrimitiveUP kullanımı bırakıldı. DrawPrimitive kullanılacak.
- Projedeki bütün shaderlardan sorumlu olan ShaderManager projesine cache eklendi. Eğer GPU'ya gönderilen bir parametre cache içinde mevcutsa doğrudan dönüş sağlanacak ve onu işleme alacak, tekrar tekrar API çağrısı yapılmayacak.
- Projedeki darboğaz noktalarını tespit edip iyileştirmek yerine, PythonApplication'dan başlayarak bütün render mekanizmalarını yenileme kararı aldım. Doğrudan motor seviyesine çağrı yapmak yerine queue ile render yapılacak ve her proje kendi render yapısını bağımsız işleyecek. Bunu henüz sadece materyallere uyguladım, saatlerimi aldı hala eksik ve uyarlanması gereken noktalar var ancak şu an bile gözle görülür fark etti diyebilirim.
Önceki güncelleme mesajlarımdan alıntı olarak:
30 Metin taşı : 45 FPS
600 Köpek : 34 FPS
gibi bir tablo vardı.
Şu an:
100 Metin taşı: 46 FPS
1000 Mob/Actor : 28 FPS
Tabi bu sonuçlara çevresel faktörler de hala eski haliyle çalıştıkları için etki etmekte. (Effect, text vb.)
Efekt ve textlere zaten bir optimizasyon işlemi uygulamıştım ancak beni tatmin etmedi, bu yüzden ilerleyen zamanlarda onları ve diğerlerini de bu yeni render yapısına göre güncelleyeceğim.
Tüm bu süreç biraz zor ve uzun geçecek.
Ek olarak:
- EterLib/BlockTexture.cpp
- EterLib/BlockTexture.h
- EterLib/GrpFontTexture.cpp
- EterLib/GrpFontTexture.h
- EterLib/GrpText.cpp
- EterLib/GrpText.h
- EterLib/GrpDIB.cpp
- EterLib/GrpDIB.h
- CWebBrowser projesi
- EterLocale projesi
Güncelleme:
Önceki güncellemede bahsettiğim yeni sıralı render yapısına materyallerden sonra:
Artık PythonApplication.cpp dosyasında:
gibi çağrıların pek çoğu doğrudan kullanılmıyor/kullanılamaz. Çünkü bunlar ya artık çizim yapmıyor, ya da içleri tamamen boş.
Efektler ise bu konu çok baş ağrıtıyor, bunun için nasıl bir yol izleyeceğimden emin değilim. Şu an için efektlerde yaptığım tek güncelleme:
Bunları kaldırmanın sonucunda ise client akıllara durgunluk veren bir değişime uğradı:
Ayrıca bu yeni yapıya şu an deneysel gözüyle bakıyorum, eğer bir noktada çıkmaza girersem yedeğe/eskiye döneceğim.
Ek;
Gereklilik doğduğu için src içinden her yerden erişilebilen bir phase yöneticisi kuruldu.
Bu yönetici sayesinde sorgulanan phase anında veya istenilen bir fonksiyon içinde mevcut kod akışı bozulmadan clientin, fonksiyonun veya shaderın davranışı değiştirilir.
Önceki güncellemede bahsettiğim yeni sıralı render yapısına materyallerden sonra:
- Gölgeler
- İtemler
- Su
- Su yansıması
Artık PythonApplication.cpp dosyasında:
C++:
m_kChrMgr.Render();
m_pyItem.Render();Efektler ise bu konu çok baş ağrıtıyor, bunun için nasıl bir yol izleyeceğimden emin değilim. Şu an için efektlerde yaptığım tek güncelleme:
- EffectUpdateDecorator.cpp
- EffectUpdateDecorator.h
Bunları kaldırmanın sonucunda ise client akıllara durgunluk veren bir değişime uğradı:
Ayrıca bu yeni yapıya şu an deneysel gözüyle bakıyorum, eğer bir noktada çıkmaza girersem yedeğe/eskiye döneceğim.
Ek;
Gereklilik doğduğu için src içinden her yerden erişilebilen bir phase yöneticisi kuruldu.
Bu yönetici sayesinde sorgulanan phase anında veya istenilen bir fonksiyon içinde mevcut kod akışı bozulmadan clientin, fonksiyonun veya shaderın davranışı değiştirilir.
Full odak şekilde takip ediyorum
