Ashenfall SF | Devlog

mermercan12 demiş ki:

abi bu alt yapı satılık olucakmı keyfimi yapıyorsun

Hepsini görmek için tıklayın...

Kaptan Yosun demiş ki:

32881 eklentisini görüntüle
32882 eklentisini görüntüle
​

[Devlog] Birleşik İkili Harita Formatı (.ashenfallmap): 1.5 Milyon Satır Çöpün Temizliği, Sıfır Gecikmeli Bellek Eşleme ve Deterministik Arazi Hattı​

Ashenfall motorunun dosya sistemi ve arazi hattında, 2004 yılından miras kalan ilkel ve parçalanmış map yükleme/yazma mimarisini tamamen çöpe attım. Klasörler dolusu yüz binlerce başıboş dosyanın ana thread üzerinde senkronize I/O darboğazı oluşturduğu, kamera her hareket ettiğinde diski kilitleyen ve komşu harita sınırlarında dikiş izleri (seam drift) yaratan 20 yıllık eski kafayı projeden söküp attım.
136 harita klasörünü, 10.823 adet başıboş dosyayı ve diskteki 1.5 milyon satırlık metin/veri çöpünü tek hamlede temizledim. Yerine, hem istemcinin hem de WorldEditor'ün sıfır dinamik bellek kopyalamasıyla doğrudan okuyup yazabildiği birleşik ikili kapsayıcı mimarimi (.ashenfallmap) sıfırdan geliştirdim.

Eski Yöntem Neydi ve Neden Terk Edildi?​

Geleneksel harita yapısında tek bir açık dünya haritası; yüzlerce 000000/, 000001/ alt klasörüne bölünmüş height.raw, tile.raw, attr.atr, water.wtr, minimap.dds ve metin tabanlı areadata.txt, setting.txt gibi binlerce başıboş dosyadan oluşuyordu.
Bu ilkel düzen şu devasa problemleri beraberinde getiriyordu:

• Senkronize CPU ve I/O Darboğazı: Karakter haritada yürürken 3×3'lük chunk penceresi her güncellendiğinde ana thread üzerinde onlarca metin dosyası satır satır ayrıştırılıyor (LoadMultipleTextData), LZO ile sıkıştırılmış küçük dosyalar için pack kilitleri (lock) tetikleniyor ve anlık mikro takılmalar (stutter / hitch) kaçınılmaz oluyordu.
• Sınır Kayması (Border Drift) ve Dikiş İzleri: Komşu arazilerin yükseklik sınırları her iki parça tarafından ayrı ayrı saklanıyordu. Yıllar içinde bu veriler birbirinden kopmuştu; örneğin lonca haritasında (guild_war4) iki komşu chunk arasında 50 metrelik uçurumlar ve uyuşmayan 370'in üzerinde kenar noktası mevcuttu.
• Yanlış Klasörlenen Objeler: 46.000'den fazla dünya nesnesinin 549 tanesi üzerinde durduğu arazinin değil, tamamen farklı koordinatlardaki klasörlerin içine yazılmıştı. Bu durum, kameranın görüş açısına göre ağaçların ve binaların aniden havadan belirmesine ya da erken kaybolmasına (pop-in) sebep oluyordu.
• Çapraz Harita Doku Bozulması: Editörde tek bir haritanın zeminini düzenleyip kaydettiğinizde, ortak kullanılan paylaşımlı textureset dosyası ezildiği için alakasız diğer 10 haritanın zemin kaplamaları geri dönülemez şekilde bozuluyordu.

Yeni Sistem Nasıl Çalışıyor? (Teknik & Mimari Altyapı)​

Yeni mimaride artık klasörler, metin dosyaları ve parça parça raw array'ler yok. Harita başına yalnızca tek bir deterministik binary kapsayıcı (.ashenfallmap) bulunuyor.

Kod:

┌────────────────────────────────────────────────────────────────────────┐
│                        .ashenfallmap MİMARİSİ                             │
├───────────────────┬────────────────────────────────────────────────────┤
│ 64-Bayt Header    │ PNG-stili Sihirli Baytlar (Magic), Sürüm, CRC-32   │
│ Section Table        │ 32-Bayt Hizalı Bölüm Başlıkları (Tag, Offset, CRC) │
│ Sabit Katmanlar   │ META (Ayarlar), STRS (Dizgi Havuzu), LAYR, CHNK     │
│ Raster Verileri   │ HGHT (129² uint16), TILE (256²), ATTR, WATR, MINI  │
│ Varlık Tabloları  │ INST (48-Bayt POD), AMBI (24-Bayt POD)             │
└───────────────────┴────────────────────────────────────────────────────┘

1. Sıfır Kopyalamalı Bellek Eşleme (Zero-Copy Memory-Mapped I/O)​

Dosya mimarisi mmap ve doğrudan işaretçi (pointer) aritmetiği için 16-bayt sınırlarına hizalandı. Harita arşivi istemciye EPack32 Type 0 (Stored / Sıkıştırmasız) olarak paketleniyor.
İstemci haritayı açtığında diski belleğe tek bir sanal adres uzayı olarak eşliyor (CEterPack::Get). Pack arşivi açılırken CPU üzerinde hiçbir global kilit (lock) oluşmuyor; sayfalar (pages) belleğe yalnızca dokunuldukça (page fault mantığıyla) işletim sistemi tarafından sıfır gecikmeyle çekiliyor.

2. Katman Bazlı Yükseklik Delta Filtreleme & Blob DEFLATE​

Harita geometrisi ve raster katmanları dosya içinde katı bir determinizmle organize edildi:

• Filtrelenmiş Yükseklik Verisi (Height Delta Planes): 129×129'luk ham yükseklikler komşu piksel delta farklarına ayrılarak düşük ve yüksek bayt düzlemlerine (planes) bölündü. Bu filtreleme, salt DEFLATE sıkıştırmasına kıyasla yükseklik verisinde fazladan %27 boyut tasarrufu sağladı.
• Türetilebilir Verilerin Tasfiyesi: Komşu arazilerin sınır halkaları (rings), yüzey normalleri ve splat haritaları dosyada saklanmıyor; yükleme anında bitişik komşulardan dikişsiz olarak türetiliyor (AssembleHeightRing). Kenar yükseklikleri matematiksel olarak eşitlendi ve drift problemi tamamen ortadan kaldırıldı.
• Gömülü Doku Paleti (LAYR): Her harita kendi zemin katmanlarını ve UV ölçeklerini kendi içinde taşıyor. Editörde bir haritayı düzenlemek artık başka hiçbir haritanın zeminini etkileyemiyor.

3. 48-Bayt Sabit POD Nesne Dizilimi​

Metin tabanlı areadata.txt ayrıştırması tamamen kaldırıldı. Binalar, zindan blokları, ağaçlar ve efektler harita koordinatlarına göre sıralanmış 48 baytlık sabit POD (Plain Old Data) struct'ları olarak saklanıyor. Yanlış klasörlenen 549 nesne matematiksel olarak üzerinde durdukları doğru chunk sınırlarına taşındı.

Performans & Optimizasyon Kazanımları​

Bütün projedeki 136 haritanın (106 bağımsız harita, 30 hafif alias) tamamı yeni formata geçirildiğinde elde edilen net mühendislik verileri:

• 1.5 Milyon Satır ve 10.823 Dosya Çöpe Gitti: +1.321 / -1.502.382 satırlık diff ile kaynak koddan tüm ilkel loader'lar, metin parser'lar ve başıboş klasörler kalıcı olarak kazındı.
• %78 Disk Ayak İzi Küçülmesi: Eski sistemde 313 MB tutan dağınık harita verisi, yeni mimariyle birlikte kayıpsız olarak 67.4 MB boyutuna indi. En büyük 6×6 kar haritasının (map_n_snowm_01) tüm zemin ve nesne geometrisi yalnızca 2.37 MB.
• 26 Milisaniyede 136 Harita: 136 haritanın tamamını açıp başlık ve CRC doğrulamalarını tamamlamak C++ motorunda toplamda yalnızca 26 ms sürdü.
• 0.06 ms Chunk Açılma Hızı: Karakter arazide ilerlerken yeni bir parçanın bellekten çekilip çözülmesi 0.06 milisaniyeye (60 mikrosaniye) düştü. Chunk geçişlerindeki mikro takılmalar, anlık FPS düşüşleri ve disk I/O beklemesi tamamen sıfırlandı.
• Determinizm ve Pre-Commit Güvenliği: Yazılan MapDocument mimarisi sayesinde, harita WorldEditor ile açılıp hiçbir düzenleme yapılmadan kaydedildiğinde bile diskteki dosyanın tek bir baytı dahi kaymıyor; byte-identical determinizm korunuyor. Repoya eski tip harita dosyalarının girmesi ise CI/CD hattına eklediğim pre-commit gate kontrolüyle engellendi.

Gelecekte araziyi doğrudan GPU üzerinde Compute Shader veya Indirect Draw ile tek geçişte çizeceğimiz Full-Map Terrain Renderer mimarisine geçiş için gereken temiz, contigous ve modern veri altyapısını böylece tamamlamış oldum.

Hepsini görmek için tıklayın...

[Devlog] Bölüm II: Sunucu Tarafının Tasfiyesi, Tek Gerçeklik Kaynağı (.ashenfallworld) ve Modern Editör Altyapısı​

Eski Sunucu Mimarisinde Neler Vardı ve Neden Çöpe Gitti?​

1. İki Ayrı Dünyanın Senkronizasyon Çilesi:
   İstemci hangi haritaya ışınlanacağını root/atlasinfo.txt üzerinden metin okuyarak çözerken, sunucu share/locale/.../map/index dosyasını tarıyordu. Yıllar içinde bu iki dosya birbirinden koptuğu için 22 haritaya (season1/..., season2/..., map_a2) oyuncu asla ışınlanamıyor ya da yanlış yere düşüyordu.
2. Kopya Haritaların Veri Yükü:
   Üç maymun zindanı veya lonca köyleri gibi haritalar aynı arazi geometrisine sahip olmasına rağmen, sunucu tarafında her biri için ayrı ayrı server_attr ve metin dosyaları tutuluyordu.
3. 20 Yıllık Ölü Kod ve Verisiz Sistemler:
   Sunucu boot olurken hiçbir haritada bulunmayan hayalet dungeon.txt dosyalarını arıyor, içi boş MonsterAreaInfo yapıları parse ediliyor ve event_flag bağımlı sahte event attribute bitleri için gereksiz CPU döngüsü harcanıyordu.

Yeni Sistem Nasıl Çalışıyor? (Format 1.1 & .ashenfallworld)​

┌────────────────────────────────────────────────────────────────────────┐
│                   BİRLEŞİK SUNUCU/DÜNYA MİMARİSİ                       │
├───────────────────┬────────────────────────────────────────────────────┤
│ maps/world...     │ .ashenfallworld: Global koordinatlar, Server ID,   │
│ (PLCE + STRS)     │ Harita boyutları, çakışma kuralları (Single-Source)│
├───────────────────┼────────────────────────────────────────────────────┤
│ Format 1.1 Ekleri │ TOWN (Doğma/İmparatorluk noktaları, 36-Bayt POD)   │
│ (Opsiyonel)       │ SETS (İsimli spawn setleri: boot, boss, event)     │
│                   │ SPWN (36-Bayt sabit POD spawn kayıtları)           │
└───────────────────┴────────────────────────────────────────────────────┘

1. Tek Dünya Tanımı:​

• Sıfır Veri Tekrarı (Aliasing): Maymun zindanları ve lonca köyleri artık diskte sadece birer ufak alias dosyasından ibaret. Zemin geometrisi ve çarpışma verisi ana araziden okunuyor; her kopya sadece kendi TOWN ve SPWN verisini saklıyor.
• Yetkili Koordinat Sistemi: Harita dosyaları (.ashenfallmap) artık kendi içinde base koordinatı tutmuyor (her zaman 0). Haritayı dünyanın neresine koyacağına yalnızca dünya dosyası karar veriyor.

2. Sabit 36-Bayt POD Spawn Altyapısı (​

• Spawnlar; türü (m, g, r, s), agresiflik bayrakları, yönü, koordinatları ve süreleri 36 baytlık sabit POD struct'ları olarak dosyada yer alıyor.
• İsimli Setler (SETS): Haritanın açılışta doğuracağı canavarlar (SET_BOOT), zindan fonksiyonlarının tetikleyeceği boss/özel gruplar (instance_regen, npc) isimli setler altında gruplandı. Sunucu artık diskten dosya yolu aramak yerine hafızadaki haritadan ismiyle seti çekiyor (GetSpawnSet("instance_regen")).

3.​

4. WorldEditor: MonsterAreaInfo Tasfiyesi ve Yeni Spawns Katmanı​

• Editöre modern ImGui tabanlı bağımsız bir Spawns paneli inşa edildi.
• Canavar isimleri doğrudan mob_proto ve sunucunun group.txt / group_group.txt hiyerarşisinden okunarak harita üzerinde gerçek isimleriyle ("Yabani Köpek x3" vb.) görselleştirildi.
• Sahne üzerinde kutular, yön okları, kasaba ve 3 imparatorluğun dirilme noktaları (Town/Empire markers) milimetrik ızgarada doğrudan düzenlenebilir, boyutlandırılabilir ve anında haritanın ikili formatına kaydedilebilir hale getirildi.
• 64 adımlık hafif prosedürel bir geri alma (Undo/Redo) mimarisi kuruldu.

Doğrulama ve Net Kazanımlar​

• 680 Sunucu Dosyası Çöpe Gitti: Server/Binary/share/locale/english/map klasörünün tamamı (Setting.txt, Town.txt, server_attr ve metin tabanlı spawnlar dahil 680 dosya) silindi. Sunucu artık tüm harita verilerini tek bir MAP_FOLDER parametresiyle istemcinin ikili paket klasöründen okuyor.
• Tam Determinizm (--verify-maps): Geliştirilen geçici debug doğrulayıcı ile 65 harita, 12.704 sectree, 208 milyon attribute hücresi ve 20.969 spawn kaydı eski metin okuyucularıyla bayt bayt kıyaslandı; bilinen tasarım kararları dışında 0 hata / 0 uyumsuzluk ile doğrulandı. Fuzzing testlerinde üretilen 16.672 bozuk dosya senaryosunun tamamı motor tarafından anında reddedildi.
• Sıfır Uyarı, Sıfır Hata: Hem SV-Debug hem SV-Release derlemeleri 0 hata ve 0 yeni uyarı ile inşa edildi.
• Ölü Kodların Temizliği: Verisi olmayan dungeon.txt ayrıştırıcıları, d.spawn gibi hayalet fonksiyonlar, sahte event attribute taramaları ve mob drop tablolarındaki gizli kalmış tanımsız bellek gölgeleme hataları tamamen ayıklandı.

[Devlog] WorldEditor: Kuşbakışı Dünya Haritası ve Kafayı Yedirtmeyen Undo/Redo!​

1. Globe: Artık Harita İsimleriyle Boğuşmak Yok​

• Yeni Globe sekmesiyle birlikte tüm oyun dünyasını tek bir devasa tuvalde, sunucudaki gerçek koordinatlarıyla kuşbakışı görüyoruz.
• Çift tıkla istediğin haritanın içine anında ışınlanabiliyorsun.
• Bölgeleri ızgara üzerinde cetvel gibi hizalamak artık tek tık.

2. Ctrl+Z Yapınca Çöken Editör Tarih Oldu​

• Hafıza Tüketimi Sıfırlandı: Eskiden her fırça darbesinde etraftaki 9 arazinin kopyasını alıp ram'e yığıyordu (~1.3 MB). Şimdi sadece fırçanın değdiği minik kareyi tutuyor (~2 KB). Yani 700 kat daha hafif.
• Attr ve Su da Artık Geri Alınabiliyor: Yıllardır Attr (blokaj) veya su boyarken hata yapınca geri alma şansımız yoktu, artık ikisi de tıkır tıkır geri alınıyor.
• Objelerin Kafası Karışmıyor: Eskiden toplu ağaç taşıyıp geri aldığında objeler birbirinin yerine geçerdi. Artık her objenin kalıcı bir kimliği (ID) var; 50 tane ağacı aynı anda sağa çekip Ctrl+Z yapsan bile hepsi milimetrik olarak kendi eski yerine oturuyor.

Finnael demiş ki:

Editorler cok guzel ve kullanisli duruyor elinize saglik. Aslinda terrain sistemini de sifirdan yazip ustune Unreal Unity'dekine benzer bi tooling insa edilebilir.

Daha da guzeli birbirinde ayri mapler uzerinden calisan bi oyun yerine tamamen open world bi dunya olurdu. Yani oyuncu hic bir loading screen gormeden mavi bayrak 1.koyden sari bayrak 1.koye yuruyebilse. Gerci gunumuz fileslari goz onune alindiginda hic bi oyuncunun umursamayacagi bir ozellik olurdu muhtemelen.

World Editor gibi item editor, mob editor toolari da aslinda yazilip hepsi tek bir program icerisine gomulse oyun icerigini olusturmak ve yonetmek cok kolay bi hale gelebilir. Ilerisi icin boyle bir dusunce var mi?

Hepsini görmek için tıklayın...

Finnael demiş ki:

"great minds think alike" diyelim o zaman hocam .

Buradaki temel problem client tarafinda cikmaz ama server tarafini boyle bir yapiya gecirmek epey zorlu olabilir. Client kendisi tum haritayi cell'lere ayirip oyuncunun pozisyonuna gore etrafindaki celleri yonetebilir. Statik objeler icin is kolay ama mevzu bahis server tarafindan yonetilen oyunculari yuklemeye geldiginde is biraz daha karisiyo. Server tarafinin da bu cell yapisina hakim olup, client'a "bu cell'in etrafinda bu objeler bulunuyor, bunlari yukle" demesi lazim.

Tabi client tarafinda da bazi zor kisimlar var. Mesela oyuncu bir dagin tepesine cikip ufka baktiginda cok uzaktaki cell'leri gorebilir ama oyuncunun gordugu her cell'in memory'e yuklenmesi performans acisindan inanilmaz sakincali bir durum. Orada da Unreal'in HLOD sistemine benzer sistemler lazim. Burada WoW gibi open world mmo'lar nasil cozmus bu problemleri onlari arastirmak lazim.

Hepsini görmek için tıklayın...

Eski Yöntem Neydi ve Neden Çöpe Atıldı?​

1. CPU Frustum Culling Darboğazı: Kamera her döndüğünde ana thread, yüzlerce yamanın küresel sınırlarını tek tek dolaşıp frustum testi yapıyordu.
2. 3x3 Chunk Sınırı ve Sis Maskesi: CPU ve D3D9 API çağrı maliyetleri yüzünden harita hiçbir zaman bütüncül olarak ekrana verilemiyor; 3x3'lük (veya biraz genişletilmiş) bir pencerenin dışı yapay bir FarPlane ve yoğun sis ile acımasızca kesiliyordu.
3. Parçalanmış Draw Call Patlaması: Her yama ve her katman için CPU'dan GPU'ya sürekli vertex buffer / index buffer set ediliyor, yüzlerce gereksiz API çağrısı (draw call) ile sürücü kilitleniyordu.
4. T-Junction ve Çatlaklar (Cracking): Farklı detay seviyelerine sahip komşu parçalar arasında yükseklik farkları oluştuğundan, kenarlarda siyah çatlaklar beliriyor; bunu gizlemek için CPU'da karmaşık ve pahalı dikiş (stitching) algoritmaları koşturuluyordu.

Yeni Mimari: Tam GPU-Driven CDLOD ve İki Aşamalı Hi-Z​

┌────────────────────────────────────────────────────────────────────────┐
│                   GPU-DRIVEN CDLOD & HI-Z PIPELINE                     │
├───────────────────┬────────────────────────────────────────────────────┤
│ 1. Frame Open     │ GPU'da tekil Indirect Args sıfırlama (Upload ring) │
│ 2. Compute Select │ Dörtlü ağaç seçimi & GPU tabanlı CDLOD             │
│ 3. Phase 1 Cull   │ Önceki karenin Hi-Z derinlik piramidine karşı test │
│ 4. Depth Prepass  │ Görünen parçaların derinliği tekil ExecuteIndirect │
│ 5. Hi-Z Pyramid   │ Prepass sonu derinlikten mip zinciri inşası (Hi-Z) │
│ 6. Phase 2 Cull   │ Elenen parçaları prepass sonu anında kurtarma      │
│ 7. Lit Pass       │ Shading: Tek geçiş splatting, DXR ışınları, 0 over │
└───────────────────┴────────────────────────────────────────────────────┘

1. GPU Compute Selection & Kesintisiz Morfoloji​

• Piksel Başına Hata Hedefi (T): Ekrandaki hiçbir arazi dörtgeninin belirlenen piksel boyutunu (varsayılan T = 8 px) aşmaması garanti edilir.
• Continuous Morphing: İki detay seviyesi (LOD) arasındaki geçiş, vertex shader içinde precise matematiksel morfolojiyle (k = 0.25) pürüzsüzce birbirine bağlanır. Geometride tek bir çatlak, dikiş izi ya da sıçrama (popping) oluşmaz.
• Görüş Alanı (Reverse-Z & Sonsuz Projeksiyon): Matrisimiz _33 = 0 sonsuz ters-Z projeksiyonuna oturtulduğu için arazinin sonu diye bir sınır yoktur; harita en uç sınırına kadar eksiksiz çizilir.

2. Çift Aşamalı Hiyerarşik Derinlik Elemesi (Two-Phase Hi-Z Occlusion Culling)​

• Phase 1 (Geçmiş Kare Hi-Z): Seçilen arazi parçalarının eksen hizalı sınır kutuları (AABB), bir önceki karenin oluşturduğu ekran derinlik piramidine karşı test edilir. Önünde tepe veya dağ olan kilometrelerce arazi daha ilk aşamada GPU tarafından elenir.
• Prepass Sonu Kancası & Phase 2: Depth Prepass tamamlandığı anda güncel ekran derinliğinden hiyerarşik mip piramidi çıkarılır. Kamera aniden döndüğünde (hızlı hareketlerde) Phase 1'in haksız yere elediği parçalar mikro saniyeler içinde kurtarılır (Phase 2 draw) ve sahneye eklenir. Ekranda sıfır yırtılma, sıfır gecikme!
• Doğrulama (Culled Quarters View): Debug paneline eklediğimiz görünüm moduyla, elenen tüm parçalar magenta renkle test edildi; kameranın gördüğü alanda tek bir hatalı eleme olmadığı matematiksel olarak kanıtlandı.

3. Tek Geçişte Premultiplied Splatting & DXR Entegrasyonu​

Ekran Görüntüleri Ne Anlatıyor?​

1. 
   []Tam Harita Görünürlüğü (Görsel 1): Eski motorun 256 metre sonra kestiği tüm vadi ve dağ silsilesi, kameranın açısından haritanın en uç sınırına kadar eksiksiz işleniyor. Ufuk çizgisine kadar hiçbir sis perdesi veya yapay kesilme yok; arazinin tamamı sahnede.
   []CDLOD Seviye Dağılımı - Görselleştirme (Görsel 2):
   Geliştirici arayüzündeki seviye görünümünde arazinin detay ayrımı net bir şekilde görülüyor:
   • Gri (Level 0): Kameraya en yakın, 512 üçgenlik en yüksek detay seviyesi.
   • Yeşil (Level 1): Orta mesafede morfolojik olarak bağlanan ara detay.
   • Kırmızı (Level 2): Ufka doğru uzanan, piksel hatasını T <= 8 px sınırında tutan en optimize seviye.
     Geçişler compute shader tarafından tam dinamik olarak hesaplanıyor, poligon israfı sıfıra indiriliyor.

Performans ve Mühendislik Kazanımları​

• Sıfır CPU Arazi Maliyeti: Harita ne kadar büyük olursa olsun, CPU arazi çizimi için 0.00 ms harcar. CTerrainPatch, yama listeleri ve CPU frustum kontrolleri tamamen silindi.
• Tekil Indirect Çizim (ExecuteIndirect): Bütün dünya tek bir komutla GPU'dan çizdirilir; CPU-GPU komut kuyruğu darboğazı sıfırlanmıştır.
• Yüzde 60'a Varan Geometri Tasarrufu: Engebeli ve kapalı haritalarda (örneğin Devils Catacomb / Zindan haritaları) 42 arazinin 26'sı Hi-Z culling ile daha piksel aşamasına gelmeden doğrudan GPU'da elenir.
• Modern Entegrasyon: Anlık hedef piksel boyutu (T), seviye zorlamaları ve GPU bellek istatistikleri çalışma anında dinamik olarak izlenip ayarlanabilir.

• Chunk Sınırlarında Main-Thread Takılmaları: Oyuncu haritada gezerken her chunk sınırında CPU senkron olarak arazi verisini diskten çözüyor, normal hesaplıyor ve belleğe basıyordu. Bu durum kare zamanında (frame interval) belirgin sıçramalara (spike) neden oluyordu.
• Çift Köşegen Uyuşmazlığı (Görsel ve Fizik Ayrımı): 20 yıldır motorda var olan trajikomik bir geometri hatası: Ekran kartı ve DXR BLAS arazi hücrelerini bir köşegenden ikiye bölerken, CPU tarafındaki GetHeight tam ters köşegenden interpolasyon yapıyordu. Sonuç: Dik yokuşlarda karakterlerin ve yere düşen eşyaların bir ayağının toprağa gömülmesi veya havada asılı kalması!
• Kaba ve Sınırlı Işın Testi (Picking): Fareyle tıkladığınızda arazi 5, 10 ve 100 birimlik kör adımlarla en fazla 1.000 metre taranabiliyordu. Ufuktaki bir dağa tıkladığınızda ışın ya boşluğa düşüyor ya da yanlış noktaya sapıyordu.
• Suni Okyanus Hataları (Water Coupling): Haritadaki su yüzeyleri bağımsız değildi; arazinin ömrüne bağlıydı. İçinde küçük bir gölet veya kuyu olan 20 farklı kapalı harita (Catacomb, Arena, Battle Royale vb.), harita kenarında deniz olmamasına rağmen "en yaygın su seviyesini" okyanus kabul edip haritanın etrafına devasa bir su eteği (skirt) çiziyordu.
• Çift/Üç Kat Dosya Çözme İsrafı: Harita yüklenirken GPU için zemin, CPU için fizik ve su motoru aynı verileri dosyadan tekrar tekrar decompress edip belleği şişiriyordu.

┌────────────────────────────────────────────────────────────────────────┐
│                   MAPGROUND CPU UNIFIED ARCHITECTURE                   │
├───────────────────┬────────────────────────────────────────────────────┤
│ 1. Map Load       │ .ashenfallmap tek seferde MapGround belleğine açılır│
│ 2. Single Decode  │ GPU (TerrainMap) & Su (MapWater) direkt buradan alır│
│ 3. O(1) Queries   │ Yükseklik, Attr, Normal, Su: Slot araması YOK     │
│ 4. Bounds Raycast │ Quadtree hızlandırmalı sınırsız Pick (Amanatides)  │
│ 5. Object Sync    │ Statik objeler & ağaçlar 3x3 pencereden bağımsız    │
└───────────────────┴────────────────────────────────────────────────────┘

• CTerrain, CTerrainImpl, CTerrainAccessor ve TerrainType.h dosyaları tamamen silindi.
• CMapOutdoor içindeki arazi vektörleri, 60 saniyelik silme havuzları (TerrainDeleteVector) söküldü.

Dev-Log: Bir Devrin Sonu: Granny ve SpeedTree'ye Güle Güle — glTF 2.0 Geçişi & Server Single Source of Truth​

• Geometri ve iskelet için .gr2
• Parça/iskelet montajı için .msm
• Her bir animasyon döngüsü ve skill için ayrı ayrı onlarca .msa
• Animasyon ses tetikleyicileri için .mss
• Klasör indeksleri için motlist.txt
• Yüzlerce bağımsız, dağınık doku dosyası

• Mesh, İskelet ve Animasyonlar: Modelin tüm kemik hiyerarşisi, LOD seviyeleri ve animasyon kanalları standart glTF yapısında doğrudan ikili (binary) olarak dosyaya gömülü.
• Materyal ve Dokular: Modern PBR doku standartları doğrudan buffer seviyesinde yapıya dahil.
• Metadata ve Eventler: Animasyonların hangi karesinde hangi sesin çalacağı veya hangi efektin tetikleneceği bilgisini extras JSON düğümleri altında tuttum. Oyun açılırken binlerce minik metin dosyasını diskten okuma ve string parse etme maliyetini sıfırladım.

• Ortak Model Okuyucusu (Shared/Model/ModelGameData): game çekirdeğine, doğrudan fastgltf / simdjson üzerinden çalışan hafif bir model metaveri okuyucusu ekledim.
• Doğrudan Pack'ten Okuma: Tıpkı harita sisteminde (ashenfallmap) yaptığım gibi sunucuya PACK_FOLDER yapılandırmasını getirdim. Sunucu artık canavarların ve karakterlerin tüm verilerini (hareket mesafesi, saldırı süreleri, combo pencereleri, splash etki alanları) diske saçılmış metin dosyalarından değil, istemcinin render ettiği pack/Models ve pack/Actors altındaki .glb modellerinin kendi içinden okuyor.
• Gerçek Root Motion: Sunucunun yürüme/koşma hızlarını eski .msa dosyalarındaki bayat ve elle girilmiş accumulation değerlerinden kurtardım. Sunucu artık istemcinin karaktere gerçekten uyguladığı ölçülmüş rootMotion vektörünü baz alıyor; böylece istemci ile sunucu konumu arasında en ufak bir sapma ihtimali kalmadı.
• Doğrulama (Zero-Tolerance): Yazdığım test harness'ı ile 4.211 farklı animasyon/hareket değerini (64 ırk hareketi, 768 kombo penceresi, 2.098 canavar hareketi, 1.176 normal saldırı ve 105 skill) tek tek doğruladım; tek bir uyumsuzluk kalmadı.

• GPU Bükülme Fiziği (Tiago Sousa / GPU Gems 3): SpeedTree'nin CPU tarafındaki eski dallanma mantığı yerine, Crytek'in Tiago Sousa formülünü doğrudan GPU Compute ve Vertex Shader katmanına bağladım.
• Doğal Ağaç Salınımı: Ağaç gövdeleri ve dallar, global rüzgar yönü ve hızına göre hiyerarşik bir parabolik eğriyle (x²) esniyor. Her ağacın dünya koordinatına bağlı bir faz farkı (dot(worldPos, 1)) bulunduğu için tüm orman senkronize bir robot gibi değil, dalga dalga ve doğal bir salınımla hareket ediyor.
• Canlı Ayar Desteği: Rüzgar kuvveti, dal salınım genliği ve frekans katsayılarını shader koduna çakmadım; RenderDefaults::Wind üzerinden canlı olarak düzenlenebiliyor.

• Yükseklik taşıyan 362 modelin tamamını, bake aşamasında kendi BVH (Bounding Volume Hierarchy) hızlandırma ağacıyla derledim ve doğrudan model dosyasına gömdüm.
• Yaptığım doğrulama testlerinde 16.08 milyon yükseklik sorgusu ve 5.48 milyon ray-pick işlemi koştum; eski sistem ile yeni BVH arasında 0 bit fark ile birebir matematiksel eşleşme sağladım.
• Artık CPU sahnede yükseklik ararken binlerce üçgeni tek tek lineer taramak yerine mikro-saniyeler içinde doğrudan BVH kutularına dallanıyor.

• 43.048 Dosya Silindi: İstemci paketlerindeki 37.453 dosyanın üzerine, sunucu tarafındaki data/monster, data/pc ve data/pc2 dizinlerinde çürüyen 5.595 dosyayı daha kökten temizledim.
• Sunucu Tamamen Arındı: Sunucudaki 5.285 adet .msa, 292 adet motlist.txt, 288 adet .msm ve sunucuya kazara atılmış tüm yetim istemci dosyaları (.mse, dokular vb.) tarihe karıştı.
• ~1.5 GB Veri Tasarrufu: Ölü modelleri, artık kullanılmayan dokuları ve on binlerce metin script'ini silerek toplam proje boyutunu ciddi oranda küçülttüm.
• ~430.000 Satırdan fazla text silindi EterGrnLib, SpeedTreeLib, SpeedTreeRT, eski metin parser'ları, D3D9 arayüzleri ve sunucudaki eski motion text okuyucuları tamamen kalktı.

.msa (Motion Script - Client + Server) : 14,033 adet
.gr2 (Granny Mesh/Skeleton)            : 11,801 adet
Model Dokuları                         :  6,000+ adet
.mss (Motion Sound Script)             :  5,011 adet
.msm (Model/Armor Script)              :  3,805 adet
.mdatr (Collision Data)                :  1,560 adet
motlist.txt (Client + Server)          :  1,009 adet
.spt (SpeedTree Modelleri)             :    118 adet

​

[Devlog] WorldEditor 2.0: Dahili Asset Health Paneli, Otomatik LOD Üretimi ve Karakter Referanslı Metrik Ölçek​

1. Asset Health: 3.600+ Modelin Saniyeler İçinde Denetimi ve Dahili LOD Üretimi​

• Tek Ekranda Tüm Depo Taraması: Projedeki 3.603 modelin tamamını yalnızca 7.1 saniyede tarayarak; hata, uyarı, doku sıkıştırmaları (BC1/DXT1), en büyük primitive boyutları ve poligon sayılarını filtreli bir liste halinde önümüze döküyor.
• Otomatik LOD Üretimi (Make Levels): Artık eksik LOD'ları üretmek için Blender'a dönüp poligon indirip tekrar export etmeye gerek yok. Eksik basamağı olan modelleri listeden seçip "Make levels" butonuna bastığınız anda WorldEditor arka planda `meshoptimizer` ile LOD1, LOD2 ve LOD3 kademelerini kendi içinde otomatik olarak türetiyor ve dosyaya işliyor.

2. Viewport 3D XYZ Yönelim Gizmosu​

3. Scale Reference: Savaşçı Modeli ve Dinamik Metre Cetveli​

• 1:1 Savaşçı Karakter Referansı: Sahneye hemen modelin zemin hizasına gerçek boyutlu savaşçı karakterini yerleştiriyor. Örneğin fotoğraftaki taş kapıyı (`stone_door.glb`) tek başına incelerken boyutunu kestirmek zorken, yanına savaşçıyı koyduğunuz anda kapının heybeti kendini gösteriyor.
• Metrik Boyut Cetveli: Karakterin hemen arkasında modelin net yüksekliğini gösteren bir metre cetveli yükseliyor. Göz kararı tahmin yürütmek yerine kapının tam olarak 8.09 metre olduğunu doğrudan ekranda görüyoruz.

[Devlog] Ashenfall: Dinamik Atlas Motoru, Zindan Haritaları, Zoom/Takip ve Legacy Tasfiyesi​

1. Neydi & Ne Gitti? (Legacy DDS Çöplüğü ve 12.3 MB Tasfiye)​

• Neydi: Haritalar elle çizilmiş/aktarılmış, düşük çözünürlüklü statik _atlas.dds ve .sub dosyalarından okunuyordu. 64 haritanın yalnızca 26'sında atlas vardı; zindanlar ve kat haritaları "Büyük harita gösterilemiyor" uyarısı veriyordu. Üstelik resim boyutları harita ölçeğiyle birebir uyuşmadığı için (örn. 4x5 chunk'lık A1'in 256x256 resme gerilmesi) tıklanan piksel ile dünya koordinatı arasında metrelerce kayma yaşanıyordu.
• Ne Gitti: Pack içerisindeki kullanılmayan ve kopyalanmış tüm varyantlar dahil 304 adet legacy atlas dosyası (12.3 MB) tamamen silindi. WorldEditor'deki eski BMP atlas dışa aktarma (SaveAtlas) kodları çöpe atıldı ve harita kontrol kapısına (check_maps.py) statik atlas girişini yasaklayan kural eklendi.

2. Ne Oldu? (Dinamik GPU MINI Verisi ve 4 Kat Netlik)​

• Canlı Birleştirme: Artık harici hiçbir görsel okunmuyor. Harita açılırken .ashenfallmap dosyalarının içinde gömülü olan chunk MINI (BC1) blokları doğrudan GPU yüzeyinde anlık olarak birleştirilip atlas dokusuna dönüştürülüyor (~30-60 ms).
• 4 Kat Çözünürlük: Eski atlaslara kıyasla 4 kat daha yüksek çözünürlük elde edildi. Harita üzerinde yapılan her zemin/nesne değişikliği atlasta anında güncel kalıyor.
• 64/64 Tam Kapsama (Otomatik Zindan Atlasları): Şeytan Kulesi, Örümcek Zindanı, Katakomb ve arena haritaları dahil oyundaki 64 bölgenin tamamı artık otomatik olarak kristal netliğinde tam ekran haritaya sahip.

3. Ne Eklendi? (Zoom, Pan, Takip Modu ve 1:1 Hassasiyet)​

• Kademeli Zoom (Powers of Two): Fare tekerleğiyle haritayı bulanıklaşma olmadan (25 ile 400 unit/piksel adımlarında) yakınlaştırıp uzaklaştırabiliyoruz.
• Dinamik Çerçeve & Pan Clamping: Atlas penceresi her haritanın en-boy oranına göre açılıyor; etraftaki siyah boşluklar tamamen sıfırlandı. Harita dışına, siyah boşluğa doğru sürükleme (pan) yapılması engellendi.
• "Beni Takip Et" Modu: Alt bara eklenen takip kutusu aktif edildiğinde harita karakteri merkezine alıp koşarken canlı olarak takip ediyor. Haritayı fareyle elle kaydırdığınız anda takip modu kullanıcı girdisine direnmeden kendini kapatıyor.
• 1:1 Matematiksel Doğruluk: 1 texel tam olarak 1 metreye eşitlendi. Atlasta tıklanan bir pikselin dünya koordinat karşılığı ($X, Y$) sıfır sapmayla alınıyor.

​

Eski Yöntem Neydi ve Neden Çöpe Atıldı?​

1. 2D Izgara ve Yükseklik (Z Ekseni) Körlüğü: Harita sadece 100x100 cm'lik düz hücrelerden oluşan 2 boyutlu bir matristi. Motor 3. boyuttan (yükseklik) habersiz olduğu için bir köprünün altından mı geçiyorsunuz yoksa üstünde mi yürüyorsunuz ayırt edemiyordu.
2. Kaba ve Titrek Çarpışmalar: Karakterler organik çevre geometrisi yerine yapay kare kutulara çarpıyor; köşelere sürtünürken takılıyor, titriyor veya iç içe geçiyordu.
3. Harita Boyu Tıkla-Yürü İmkansızlığı: Eski NEW_MoveAlongPath sistemi maksimum 256 poligonluk sığ bir koridora ve 4.096 düğümlük tekil bir A aramasına kilitliydi. Ekranda görünmeyen uzak bir noktaya rota çizmek imkansızdı; zorlandığında ise ana thread'i kitleyip oyunu donduruyordu (frame hitch).

Yeni Mimari: 3D Tiled NavMesh & WorldEditor Entegrasyonu​

┌────────────────────────────────────────────────────────────────────────┐
│                   ASHENFALL 3D NAVIGATION PIPELINE                     │
├───────────────────┬────────────────────────────────────────────────────┤
│ 1. NavBake (WE)   │ Worker thread'lerde arka plan karo (tile) inşası   │
│ 2. .ashenfallmap  │ Deterministic NAVP & NAVT ikili katmanları         │
│ 3. TileCache      │ Dinamik engeller (lonca binaları) için canlı mesh  │
│ 4. Sliced Query   │ Bütçeli (2.048 iterasyon/kare) asenkron A* araması │
│ 5. Funnel Pass    │ Koridordan düzleştirilmiş en kısa köşe noktaları   │
│ 6. Liang-Barsky   │ Atlas vizörüne donanımsal segment kırpma ve çizim  │
│ 7. Path Runner    │ Seri numaralı (m_uPathSerial) güvenli hareket      │
└───────────────────┴────────────────────────────────────────────────────┘

1. WorldEditor Navigation Sekmesi ve Arka Plan Bake​

• Asenkron Karo Üretimi (Tiled Bake): Haritadaki araziler 25.6 metrelik bağımsız karolara (tiles) ayrıldı. WorldEditor, sahneyi dondurmadan arka plandaki worker thread'lerde NavMesh'i otomatik olarak örüyor.
• Deterministik İkili Katman (NAVP & NAVT): Üretilen NavMesh verisi .ashenfallmap ikili dosyasının içine doğrudan gömülüyor. Hash doğrulaması (digest) sayesinde haritada bir taşın yeri değiştiğinde yalnızca o karonun NavMesh'i güncelleniyor.
• TileCache ile Canlı Engeller: Lonca arazilerine sonradan dikilen binalar veya ağaçlar için tüm haritayı yeniden örmüyoruz; Detour TileCache katmanı sayesinde haritanın o karosu oyun anında dinamik olarak kesilip yeniden deliniyor.

2. Atlas Otopilotu: Dilimlenmiş (Sliced) Detour A* Algoritması​

• Sıfır Frame Drop (Sliced Pathfinding): Sohan Dağı gibi devasa bir haritada 2.8 kilometrelik çapraz bir rota aramak 22.000'den fazla poligonun taranmasını gerektirebiliyor. Bunu tek karede hesaplayıp 5-6 ms'lik takılma (stutter) yaratmak yerine, Detour'un dilimlenmiş arama API'sini (initSlicedFindPath, updateSlicedFindPath) kullandık. Arama kare başına 2.048 iterasyon (~0.5 ms) bütçeyle çalışıyor; en uzak rotalar bile 7-8 kare içinde oyuncu fark etmeden pürüzsüzce çözülüyor.
• İzole Sorgu Nesnesi (Isolated Node Pool): Uzun mesafe araması için 65.535 düğümlük bağımsız ikinci bir sorgu nesnesi tahsis ettik. Böylece harita otopilotu hesaplanırken sahnedeki diğer slotların veya karakterlerin anlık hareket sorguları devam eden aramayı bozamıyor.
• Funnel Algoritması & Liang-Barsky Kırpma: Çözülen poligon koridoru düzleştirilerek en kestirme köşe noktaları çıkarılıyor (findStraightPath). Kalan rota atlasta şık bir çizgiyle çizilirken, pencere dışına taşan kısımlar Liang-Barsky algoritmasıyla vizör sınırlarında donanımsal olarak kırpılıyor.

3. Kusursuz Kontrol ve İptal Mekanizmaları​

• Anında Tepki: Karakter koşarken WASD/yön tuşlarına basıldığı, 3D dünyada zemine tıklandığı, bir canavara saldırıldığı veya bir skill basıldığı anda rota anında iptal edilir ve kontrol oyuncuya geçer.
• Darbe ve İtilme Koruması: Slotların karakteri geriye itmesi (pushback), devirmesi (knockdown) veya sersemletmesi (stun) durumunda eski rotanın saçmalaması engellendi; rota anında kendini temizler.
• Akıllı Takılma Koruması (Stall & Re-plan): Önüne aniden bir engel çıkan karakter 1 saniye boyunca 50 cm'den az ilerleme kaydederse bulunduğu noktadan otomatik olarak tek seferlik yeni bir rota dener; yine tıkalıysa oyuncuyu yormadan durur.

Performans ve Mühendislik Kazanımları​

• Takılmasız Asenkron Navigasyon: 2.8 km'lik en ağır rotada bile kare başına harcanan CPU süresi yalnızca 0.74 ms; harita ne kadar büyük olursa olsun tek bir kare kaybı yaşanmıyor.
• Hafıza Tasarrufu & Determinizm: 2D statik sunucu ızgaraları (server_attr) tamamen kaldırıldı; hem sunucu hem istemci tekil ve sıkıştırılmış .ashenfallmap ikili NavMesh katmanından besleniyor.
• Tam 3D Hareket Özgürlüğü: Köprüler, tüneller, dikey zindan katları ve çok katmanlı yapılar artık oyun motoru için doğal birer yürüyüş alanına dönüştü.