Ashenfall SF | Devlog

Kaptan Yosun demiş ki:

[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:
Genişlet Daralt Kopyala 
┌────────────────────────────────────────────────────────────────────────┐
│                        .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ı​

İstemci ve WorldEditor tarafında .ashenfallmap formatına geçip disk I/O darboğazını sıfırladıktan sonra masada devasa bir kambur kalmıştı: Sunucu çekirdeği (game).
20 yıldır istemci dosyalarından bağımsız yaşayan, sunucu tarafında yüzlerce klasörde tutulan Setting.txt, Town.txt, LZO sıkıştırmalı server_attr, regen.txt, npc.txt ve boss.txt dosyaları hala hayattaydı. İstemcide olmayan dosyaların sunucuda aranması, sunucuda olan koordinatların istemcideki atlasinfo.txt ile uyuşmaması, büyük/küçük harf tutarsızlıkları (devilsCatacomb, CapeDragonHead) ve monkey dungeon gibi kopya haritaların diskte yüzlerce megabaytlık gereksiz veri tekrarı yaratması tam bir krizdi.
Bu ikinci fazda sunucunun tüm eski harita yükleyicilerini kalıcı olarak projeden kazıdım. Artık istemci, editör ve sunucunun tamamı aynı ikili dosyalardan ve tek bir global dünya tanımından besleniyor.

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)​

Sunucuya .ashenfallmap okuma kabiliyetini doğrudan C++20 standardında ekledim (Shared/Map/MapFile.cpp).
Kod:
Genişlet Daralt Kopyala 
┌────────────────────────────────────────────────────────────────────────┐
│                   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ı:​

Eski atlasinfo.txt ve sunucunun index dosyasını tamamen sildim. Yerine tüm haritaların global dünya üzerindeki $(X, Y)$ taban koordinatlarını, sunucu ID'lerini ve boyutlarını tutan ikili world.ashenfallworld dosyasını getirdim.
  • 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ı (​

Metin tabanlı regen.txt, npc.txt ve boss.txt dosyalarının tamamı ikili formatın içine taşındı:
  • 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.​

Sunucunun harita açılışında okuduğu LZO sıkıştırmalı server_attr dosyalarının tamamı silindi. SECTREE_MANAGER, sectree bloklarını ve çarpışma bitlerini doğrudan .ashenfallmap içerisindeki ATTR raster katmanından derleme anında oluşturuyor (100 birimlik grid 50 birimlik 2x2 sunucu hücrelerine genişletiliyor).

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

Eski MFC/DirectX 9 döneminden kalma, arayüzü kilitleyen ve server_map klasörlerine bağımlı olan MonsterAreaInfo kodlarının tamamı çekirdekten silindi.
  • 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ı.
İstemci, sunucu ve editör artık aynı binary dilden konuşuyor. Yıllardır harita düzenlerken yaşanan "sunucuya ayrı at, istemciye ayrı paketle, atlasinfo ile index'i eşitle" çilesi tamamen bitti; harita hattı profesyonel modern oyun motorları standardında tek kaynak (single source of truth) haline getirildi.
 
​


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

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

Eskiden editörde başka bir haritaya geçmek için dosya listelerinde kayboluyorduk. Hangi bölge neredeydi, haritalar yan yana nasıl duruyordu tam bir muammaydı.
  • 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​

Eski editörü kullananlar bilir: Fırçayı yere 3 kere dokundursan program bellekte şişer, Ctrl+Z bastığında ya objelerin seçimi düşer ya da dokular sapıtırdı.
  • 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.
 
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?
 
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...
Şu anda tam olarak terraine rework atıyordum bunu yazdınız. Bu yazdıklarınızı yapay zekayla taş çatlasın 5 dakika önce tartıştım. Sanki yorumunuzu tam şu an ekranıma bakıp yazmışsınız gibi. Şu anda ufuk çizgisine kadar aralıksız terrain bile çizsek, 1FPS bile zararı dokunmayacak gelişmiş bir terrain sistemi yazıyorum.

1791041659304.webp
 
"great minds think alike" diyelim o zaman hocam :D.

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.
 
Finnael demiş ki:
"great minds think alike" diyelim o zaman hocam :D.

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...
open worldlerin bazılarında pasaj ya da ince geçt gibi yerden player yürürken geçtiği mapi yükleme mantığı koyan oyunlar var
 
fullterrain1.webp

fullterrain2.webp
[Devlog] GPU-Driven CDLOD Arazi Motoru: 20 Yıllık CPU Yama İskelesinin Tasfiyesi, İki Aşamalı Hi-Z Görünürlük ve Sıfır Draw Call Darboğazı
Ashenfall motorunun grafik hattında, Direct3D 8/9 döneminden miras kalan ve açık dünya arazisini CPU üzerinde 3x3'lük chunk pencerelerine hapsederek görünürlüğü 256 metrede bir sis perdesiyle kesen ilkel arazi işleme mimarisini tamamen tarihe gömdüm.
Bir önceki devlog'da temelini attığımız deterministik ikili harita formatının (.ashenfallmap) sunduğu saf contiguous bellek yapısını arkamıza alarak, arazinin seçimini, seviye geçişlerini (LOD) ve görünürlük testlerini doğrudan GPU'ya devrettiğimiz GPU-Driven CDLOD (Continuous Distance-Dependent Level of Detail) ve Two-Phase Hi-Z Occlusion Culling mimarisini tamamladım.
Artık CPU harita arazisi için tek bir vertex veya index kopyalamıyor, tek bir bounding box test etmiyor; tüm harita ufka kadar tekil bir indirect komutla GPU tarafından seçilip çiziliyor.

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

2004 yılından kalan klasik açık dünya arazi motoru, araziyi CPU üzerinde 16x16'lık yamalara (CTerrainPatch) bölüyor ve her karede şu ilkel döngüyü işletiyordu:
  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​

Yeni nesil arazi hattı (RC::Terrain), arazinin tüm geometrisini harita yüklendiği anda GPU belleğinde tekil dokular ve tamponlar halinde (Texture2DArray splat maskeleri, R16_UINT yükseklik ve normal rasters) yerleşik (resident) tutuyor. Çizim süreci ise tamamen compute shader'lar üzerinden yürüyor.
Kod:
Genişlet Daralt Kopyala 
┌────────────────────────────────────────────────────────────────────────┐
│                   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​

Her kare BeginRayScene aşamasında tek bir compute dispatch çalışır. Tüm haritanın quadtree hiyerarşisi GPU üzerinde taranır:
  • 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)​

Tüm haritayı çizmek devasa bir piksel yükü getirebilirdi; ancak bunu Haar & Aaltonen modeli iki aşamalı donanımsal derinlik piramidiyle tamamen etkisiz hale getirdik:
  • 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​

Klasik çoklu geçişli (multi-pass) zemin boyama çöpe atıldı. Piksel altındaki katmanlar bindless doku dizisinden okunarak tek geçişte harmanlanır (8 katmana kadar sıfır ek maliyet).
Ayrıca her chunk için compute kuyruğunda oluşturulan tam çözünürlüklü statik BLAS (Bottom-Level Acceleration Structure) sayesinde, DXR 1.1 ışın izleme hattımız arazinin en ince kıvrımlarından ve kayalarından kusursuz donanımsal gölgeler üretir.

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

Paylaştığım iki ekran görüntüsü, mimarinin sahadaki somut gücünü sergiliyor:

  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.
Arazinin GPU üzerindeki bu kusursuz ve sınırsız işleyişi tamamlandı. Sırada, arazinin üzerinde duran statik nesneleri, binaları ve ağaçları da aynı GPU Instance & Hi-Z mimarisine bağlayacağımız Unified GPU Scene aşaması var!
 
Son düzenleme:
1791461223126.webp
[Devlog] MapGround Mimarisi: 20 Yıllık 3x3 Chunk Streaming İllüzyonunun Sonu, O(1) Contiguous Zemin Belleği ve CTerrain Tasfiyesi

Önceki devlog'da arazinin ekran kartındaki çizimini GPU-Driven CDLOD ve Hi-Z mimarisine emanet ederek GPU render darboğazını sıfırlamıştık. Ancak motorun derinliklerinde çözülmesi gereken devasa bir "mimari borç" daha vardı:

GPU haritanın tamamını ufka kadar tek seferde çizerken; oyunun CPU fiziği, ayak basma yüksekliği (GetHeight), duvara çarpma engelleri (isAttrOn), tıkla-git ışınları (Pick), balıkçılık sorguları ve hatta mini harita hâlâ 2004 yılından miras kalan ilkel bir 3x3'lük chunk streaming penceresine mahkumdu. Karakter her 128 metre yürüdüğünde ana iş parçacığında (main thread) diskten senkronize arazi yükleniyor, kare hızında mikro donmalar (hitch/stutter) yaşanıyor ve 3x3 pencerenin dışına yapılan tüm sorgular zemini "yok (0)" sanıyordu.

Bu devlog ile birlikte; zemin ve su hattını birbirinden tamamen kopararak tüm harita arazisini tek parça, biti bitine doğrulanmış bir bellek deposuna (GameLib/MapGround) taşıdık. CTerrain sınıf ailesini, chunk yükleme kuyruklarını ve 3x3 streaming illüzyonunu motor kodundan ebediyen sildik.


Eski Sistemin Mimari Çıkmazları ve Kök Hatalar

Arazi kodunun derinliklerine indiğimizde karşılaştığımız tablo tam bir teknik borç yumağıydı:

  • 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.


Yeni Mimari: MapGround ve Tam Tasfiye

Kod:
Genişlet Daralt Kopyala 
┌────────────────────────────────────────────────────────────────────────┐
│                   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    │
└───────────────────┴────────────────────────────────────────────────────┘

1. Tekil, Harita Çapında Depo (GameLib/MapGround):
Harita açıldığı an tüm haritanın yükseklikleri (HGHT), öznitelikleri/yürüme engelleri (ATTR) ve su katmanları (WATR) harita boyutunda tek parça, contiguous bir belleğe alınır.
Artık GetHeight, isAttrOn ve WaterLevel sorguları 9 slotluk matrislerde chunk aramaz; $O(1)$ matris indeksiyle anında yanıt verir.

2. Çizilen Geometri ile Birebir Köşegen Eşitliği (Rw3):
CPU zemin yüksekliği algoritması, GPU CDLOD ve DXR Ray Tracing BLAS'ın çizdiği üçgen köşegeniyle birebir eşitlendi. Karakterin bastığı nokta ile poligonun eğimi artık pikseli pikseline aynı yüzeydedir.

3. Quadtree Hızlandırmalı Analitik Picking (D3):
Eski kör adımlı ışın döngüsü silindi. Haritanın yükseklik sınırları (Quadtree Bounds) üzerinden çalışan ve Amanatides & Woo grid yürüyüşünü kullanan analitik bir ray-picker yazıldı. Artık haritanın öbür ucundaki 20 kilometrelik bir dağ zirvesine tıkladığınızda bile ışın anında doğru üçgene oturur; mesafe sınırı yoktur.

4. Su Ayrımı ve Perimeter 1/8 Deniz Kuralı (Q1 & D7):
Su yaşam döngüsü araziden tamamen koparıldı (MapWater). Haritanın dışına deniz eteği çizilme şartı, haritanın dış çerçeve hücrelerinin (perimeter) en az 1/8'inin açık deniz seviyesinde olması kuralına bağlandı. Kapalı zindanlar ve iç gölleri olan haritalar sahte okyanuslardan kurtuldu.

5. WorldEditor Entegrasyonu ve Dikiş İzsiz Fırçalar (D5):
Editördeki 20 yıllık CTerrainAccessor silindi. Yeni MapBrushes mimarisi doğrudan MapGround tamponlarına yazar. İki chunk'ın sınırına fırça vurulduğunda artık dikiş hesapları veya kenar eşitleme (ShareEdges) algoritmaları koşturulmaz; zemin tek parça olduğu için doğal olarak kusursuz boyanır.

6. Statik Objelerin (CArea) Tasfiyesi ve glTF Entegrasyonu (W7):
Arazinin özgürleşmesiyle birlikte, araziye bağlı duran binalar, zindan blokları ve SpeedTree ağaçları da eski 3x3 penceresinden ve yapay 768 metre gölge/ışın kesme kısıtlamalarından kurtarılarak glTF / ModelLib sahnesine doğrudan bağlandı. Zemin snapping sorguları doğrudan MapGround'a kenetlendi.


Doğrulama ve Test Süreci

Bu kadar köklü bir omurga ameliyatını güvenle tamamlamak için geçici bir test harness'ı (MapGroundCheck) kurduk:

Test Edilen HaritaTest Noktası SayısıBit-Level UyuşmazlıkRaycast (Pick) Testi
metin2_map_a1~2.6 Milyon021.000 Işın (Kusursuz)
devilscatacomb~2.7 Milyon015.000 Işın (Kusursuz)
battleroyale~5.0 Milyon016.000 Işın (Kusursuz)

Toplamda 10.3 milyondan fazla rastgele koordinatta eski sistem ile yeni MapGround bit-seviyesinde kıyaslandı ve sıfır hata ile doğrulandı.


Büyük Tasfiye (The Purge) ve Sonuç

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

Sonuç olarak: Chunk sınırlarında yaşanan takılmalar bitti, fizik/yükseklik hesapları modern D3D12 BLAS geometrisiyle eşitlendi, bellek kullanımı hafifledi ve zemin mimarimiz modern bir oyun motoruna yakışır sadeliğe kavuştu!
 
Son düzenleme:
Geri
Üst