Esnek Güç

[MD-C]

DirectX için giriş seviyesinde bir dersi incelediğimde herşeyin; nesne tabanlı bir hiyerarşi ile ilerlediğini gördüm. OpenGL'de ise fonksiyonlarla. Bunu göz önünde bulundurursak Nesneye Dayayalı bir alt yapı ile DirectX mi? yoksa Fonksiyonlar ile OpenGL mi daha esnek ve güçlüdür?

Şimdi cevaplar arasında hemen, getirdiği avantajlar sayesinde nesneye dayalı programlama deyip yüzeysel cevaplar yazılabilir! ama böyle yazmayalım ve işin içine girerek, Nesneye dayalı yada Fonksiyolar ile sıkışıp kalınabilecek noktaları düşünerek cevap vermeye çalışalım...

[DoganBir]

Öncelikle şunu söyleyeyim. Nesneye dayalı programlama fonksiyonel olarak programlamanın ardından ortaya çıkmış ve bir çok şeyi daha rahat yapmamıza olanak veren güçlü bir sistemdir. Ve bugün programlama da kullanılan en iyi tekniklerden biridir. Bundan sonra çıkacak kavramdan da sizlere kısa bir bahsetmek isterim. Şu an ortada tam anlamıyla somut bir şeyler bulunmasada Aspect Oriented geliyor. Burada yapay zekayla iç içe geçmeye başlıyor artık. Sınıflarımız kendisi nesnelerini oluşturmaya başlıyor artık. Bundan sonra gideceğimiz nokta yapay zekadır. Artık herşeyi bizim yapmamızın gerekliliği ortadan kalkacak. Biraz uzaklaştım gibi. Kusura bakmayın.
Bu noktadan sonra ben fonksiyonel programlamaya dönmek niyetinde değilim. Object Oriented dan önce kullanırdım. Şimdi bir sınıf yazıp ardından bundan istediğim kadar nesne oluşturuyorum. Ardından gerekiyorsa Ana sınıfımdan alt sınıflar üreterek rahat ve esnek bir yapıya kavuşmuş oluyorum.
Yaşasın Object Oriented (Aspect Oriented gelsin artık.)

[MD-C]

Yazdıkların doğru! heheh dediğim gibi yüzeysel baktık sanki olaya? Adamı sıkıyor bir nesneye bağlı kalıp ondan birşeyler çıkarmak? Hey şey ortada serbestsin Fonksiyonlar ile... Hepsi başıboş geziyor. Ne güzel istediğini al ordan kullan... istediğin an istediğin tanımlamayı yap, yada yapmadan işleme başla....

[ferdemoncel]

> Fonksiyolar ile sıkışıp kalınabilecek noktaları düşünerek ..
Bunu görünce direkt olarak benim aklıma windows programlama ve bunun yanında C fonksiyonlarının C++'nin güçlü nesnesel özelliklerinden faydalanarak kullanılması geliyor.
Şu adreste : http://www.relisoft.com/book/win/index.htm
C fonksiyonlarının C++'nin güçlü nesnesel özellikleri ile kullanılmasına dair örnekler bulmuştum. Sanırım aynı şey OGL fonksiyonları için de düşünülebilir.

Örneğin C++ çeşitli programlama türlerini destekleyen multi-paradigm bir dil olarak bilinir. Eğer elimizdeki program NYP'a yönelik bir çözüm gerektirmiyorsa fazla kasmaya gerek yok Ama ben yine de windows programlama ve OGL için C++'nin NYP destekleyen güçlü özelliklerinden faydalanmak gerekir diye düşünüyorum.

[chfbat]

Tabiki DirectX çok daha güçlüdür.

Çünkü ekli olan özellikler çok fazla ve gerçekten hepsi çok iyi çalışıyor.

DirectFONT
DirectDraw
Direct3D
ses desteği ve daha fazlası...

Ve gerçekten öğrenmek için çok çaba harcadığım dillerden ikici Pixel/Vertex Shader dilleri. Çok rahatça kullanılabiliyor..

Yani directX profesyonel oyun yapımcıları için vazgeçilmezler arasında...


Mesela CAPS adlı struct'ı kullanarak ekran kartının bütün özelliklerini alıp optimizasyon yapabiliyorsunuz.


Eğer OpenGL'de fonksiyonları başlıklar altında sıralasaydı eminim altta kalır yönü olmayacaktı. Vede Ses ve Font desteği eklenirse...

[mentat]

oncelikle c fonksiyonel degil prosedurel bir dildir. fonksiyonel diller baska bir kavram..

aspect oriented de sanirim biraz ilgisiz kaliyor bu tartismada. sadece bir seminere takildim ve bir giris seviyesinde makale okudum aspect oriented konusunda, ancak benim anladigim, aspect oriented, proje yonetimi, tasarim meselelerine daha yakin. UML, XP, design by contract vs vs gibi yazilim muhendisligi meseleleriyle karsilastirilmali gibi geliyor bana. aspect oriented bir sekilde projenizi tasarlar ve gelistirirken, isterseniz NYP, isterseniz prosedurel paradigmalarla kodmaya devam edebilirsiniz..

gelelim ogl/dx'i NYP ve prosedurel olarak karsilastirmaya. bence gereksiz bir tartisma. ben NYP egilimliyim ve OGL kullaniyorum, ve dogal olarak OGL islemlerini yapan birsuru wrapper (turkcesini uyduramadim) sinifim var kendi yazdigim. kendi yapima monte etmek icin dx olsun gl olsun zaten bir sekilde kendi siniflarimi yazmam dogal. yani gl ile NYP takilabilirsiniz. ayni sekilde dx ile de prosedurel.

tam da bu noktada, pekcok GL'ci DX'i cirkin bulur (ben bulmam), MS'in NYP temellerle gelistirdigi yapiya eger c++'a hakim degilseniz alismak biraz guc. once c ile baslayip c++'a gecmeye karar veren zavalli sanssizlardansaniz bu daha da guc. dx size cok karisik gelir, bulasmak istemezsiniz. ama bu ne dx'in zayifligi, ne gl'in gucu. zaten boyle birsey de yok..

uzatmayayim.. gl ve dx iki API, iki kutuphane. butun dunya icigina cicigina, fanatizmle tartisiyor (az sonra sensei firlayip dx rulez diyebilir), tartismanin pek de bir manasi yok bence. hele nyp'nin bir api'ye ne getirdigi ne goturdugu birsey var, en azindan dx ozelinde..

[mentat]

chfbat: DirectFONT'u yeni duydum. dx10'da falan mi var bu? bi de DirectDraw DX7'den sonra kalkti diye biliyorum. bi de Caps ile kartin ozelliklerini alirsin da optimizasyon kismini anlamadim. gl ile de glGet* ile tum ozelliklere ulasirsin kartin, ve sonra glHint'le falan.. vs vs vs..

shader'lar konusuna ise katiliyorum. HLSL yazilarini bekliyorum (ben de ogrenmeye kasiyorum da).

[chfbat]

Quote:

On 2004-05-01 19:50, mentat wrote: chfbat: DirectFONT'u yeni duydum. dx10'da falan mi var bu? bi de DirectDraw DX7'den sonra kalkti diye biliyorum. bi de Caps ile kartin ozelliklerini alirsin da optimizasyon kismini anlamadim. gl ile de glGet* ile tum ozelliklere ulasirsin kartin, ve sonra glHint'le falan.. vs vs vs.. shader'lar konusuna ise katiliyorum. HLSL yazilarini bekliyorum (ben de ogrenmeye kasiyorum da).

yanlış yazdım yaa kusura bakmayın. oda önceden vardı. eski versiyonlarda farklı bir isimle çağırılıyordu. Visual Basic kullananların bilmesi gerekiyor.

glGet'i biliyorum. optimizasyondan kastımda default olarak ayarlanan başlangıç çözünürlük ayarlarının yazılım tarafından açılışta otomatik olarak şekillenmesi.

p/V shaders gelecek yakında merak etmeyin )

[DG]

En son bildiğim kadarıyla DirectX, Com+ nesne yapısıyla çalışıyordu. DirectX ile prosedürel programlama yapmak biraz kasıntı olur gibi geldi bana.

DirectX ile OpenGL kıyaslanmaz aslında (hangi dil altında ya da hangi programlama teknikleri kullanılmadığına bakılmaksızın). Bu Visual Studio .NET 2003 ile Visual C++ Toolkit i kıyaslamak gibi bir şey. OpenGL açılmış "rendering contex"'in içine birşeyler çizdirmekten başka bir şey yapmaz. DirectX ise oyun yapımına dair her türlü ihtiyacı karşılıyor. Bu bağlamda, Direct3D ile OpenGL'i kıyaslamak bile tam mümkün olmaz çünki Direct3D tümleşik olarak geldiği sistemin gücünü de yanına alıyor (pencere açma, doku işlemleri için stream oluşturma vs..) Olaya bu boyuttan bakıldığında DirectX kıyas götürmeyecek kadar zengin.

Prosedürel programlamayı izlemek çok zor oluyor. Ne kadar açıklama satırı yapılmış ya da "identation" olayına özen gösterilmiş olsa da, oyun gibi büyük işlerde kod çorbaya dönebiliyor (ben Q2'nin kodlarının büyük bir kısmını hala çözemiyorum) Prosedürel programlama ile bir yerlere sıkışıp kalabilirsin ama nesneye dayalı programlama ile öyle bir durum olacağını sanmıyorum (en azından günümüz için)

Konu DirectX'ten açılmışken. DirectX'in içinde gelen shader öğeleri ile NVIDIA'nın CG'si arasında ne fark var? FarCry'nin shaderları CG ile yapılmış (halbuki oyun DX9.0b istiyor), hatta Deus Ex 2'ninkiler de CG ile yapılmış (DX8.1 istiyor).

[cemuzunlar]

>DG
>Konu DirectX'ten açılmışken. DirectX'in içinde gelen shader
>öğeleri ile NVIDIA'nın CG'si arasında ne fark var? FarCry'nin
>shaderları CG ile yapılmış (halbuki oyun DX9.0b istiyor),
>hatta Deus Ex 2'ninkiler de CG ile yapılmış (DX8.1 istiyor).

OpenGL'in de, DirectX'te verteks ve piksel shaderlari, temelde api'ye ozel assembly dilleri uzerine kurulu. Yani hicbir ust seviye dil kullanmadan( HLSL, CG, GLSL ), hem OpenGL'de hem de DirectX'te verteks ve piksel shaderlari kullanmak mumkun.

Ancak bu alt seviye diller ile shader programlamak cok guc oldugundan, bir sure once ust seviye diller'de apilere girdi. Burada bilinmesi gereken nokta su: Iki apide de ust seviye shader dilleri ile yazilan programlar, alt seviye assembly'e cevriliyorlar ve sonrasinda ekran kartinin surucusune gonderiliyorlar. Yani ekran kartinin tek anladigi bu alt seviye programciklar. Etrafta dolasan tum ust seviye shade dilleri bir sekilde kodunuzu derliyor ve alt seviye ciktilari kullaniminiz icin size veriyor. Hatta ust seviye dille yazdiginiz shader programciginin, derlentikten sonra olusan assembly halini bile gormeniz mumkun.

OpenGL'de verteks ve piksel shader'lari kullanmak icin ilk yol, alt seviye assembly ile shader programlayabildiginiz, ARB'nin onayladigi ARB_vertex_shader ve ARB_fragment_shader eklentileri. Bu eklentilerin olmadigi donemde ATI ve NVIDIA'nin,shader yazmaniza olanak veren kendi alt seviye assembly dil eklentileri vardi. Bunlar hala duruyor ama kullanimdan kalktigi soylenebilir. Ust seviye shader dili olarak, OpenGL 2.0 icerisinde yer almasi planlanan OpenGL Shading Language ( GLSL ) halen gelistirme asamasinda. Hatta yavas yavas ATI ve NVidia'nin suruculerinde GL_ARB_shading_language_100 ismiyle gelmeye basladi. GLSL ile yazdiginiz shader programciklari, GLSL derleyicisi tarafindan ARB_vertex_shader ve ARB_fragment_shader programciklarina donusturuluyor ve ekran karti tarafindan kullaniliyor.

DirectX'te alt seviye shader assembly dilleri ve High Level Shading Language ( HLSL ) isimli bir ust seviye shader programlama diline sahip. Burada da durum ayni. HLSL kodlariniz, HLSL derleyicisi tarafindan, assembly'ye cevrilerek surucuye yollaniyor.

CG de bir ust seviye shader programlama dili. Ozelligi hem DirectX hem de OpenGL destegi olmasi. Bu destegi soyle sagliyor. CG ile yazdiginiz ust seviye shader programciklari, CG derleyicisi tarafindan, seciminize bagli olarak,ister DirectX icerisindeki assembly shader programlama diline, isterseniz de OpenGL icerisindeki assembly shader programlama dillerine cevriliyor. Hatta daha da otesini yapabiliyor ama bunlar su an icin onemsiz detaylar. Bu sayede CG ile yazdiginiz shader'lari teorik olarak iki api'de de kullanabiliyorsunuz.

Ben bu yontemlerin tumunu deneyip test ettim. Ne alt seviye dillerin, ne de ust seviye dillerin aralarinda onemli bir fark oldugunu soyleyemem, buyuk olcude aynilar. Her iki api'de de assembly shader dilleri ile programlama yapmak cok zahmetli. Ancak ust seviye dillerde optimize kod yazabilmek ve ekran kartinin gercekte hangi ozellikleri, nasil destekledigini ogrenmek icin incelenmeleri gerekiyor. OpenGL kullandigim icin, GLSL derleyicileri son haline geldiklerinde, ust seviye dil olarak secimim bu olacak. Ancak su anda profesyonel kullanim icin hazir olmadiklari icin uzun suredir CG kullaniyorum. Derleyicisi cok cok saglam. Dokumantasyonu, ornekleri de oldukca iyi. Kullaniminda herhangi bir zorluk cekeceginizi sanmiyorum.

[chfbat]

....

[ Bu mesajı düzenleyen: chfbat _FIL 02-05-2004 12:49 ]

[chfbat]

....

[ Bu mesajı düzenleyen: chfbat _FIL 02-05-2004 12:46 ]

[chfbat]

Evet aynen öyle. Zaten Pixel ve Vertex shader'larda oluşturulan EXE'nin içine kaydedilirken DX9 (veya DX tarafından assembly koduna çevrilip kaydediliyor. Evet dediğimiz gibi Open GL ile Vertex ve pixel shader'larıda kullanmak kesinlikle mümkün fakat nasıl olduğunu çok fazla bilmiorum. mesela 3. Party yazılımlarla yapılabilir bunlar (SoftWire). Softwire pixel shader 2.0 versiyonuna sahip shader komutlarını software olarak derleyebiliyor veya direk olarak gösterebiliyor.
Yada NVASM programı. Nvidia'nın shader derleme programı... Bunu microsoft'da destekliyor...

Kısacası Shader denen texture'nin kabuk görünümü ve şeklini değiştirebilen yapı (Quake shader'ları dışında) bütün grafik programlama dillerinde aynı. Amacı: Ekran kartına gönderilecek assembly programcıklarının kullanıcı düzeyine getirilmesi ve compile edildikten sonra kolayca yapılabilmesi...

Half-life 2'nin filmindeki su efekti'nin Pixel ve Vertex Shader dosyalarına bakıncada çok şaşırdım çünkü vertex shader ile programda belirtilen şeyler birleştirilmiş. yani suya düştüğünüz zaman düştüğünüz yerden itibaren su dalgaları yayılıyor. Buda gerçekten iyi bir matematik zekası isteyen birşey.. Lambda(Lambda=dalga birimi).

adamlar şöyle yapmış:
kodlar içinde bulunan 'worldeye' yapısını shader dilinede '$worldeye' olarak geçirerek kolayca shader tanımlamalarına oyuncunun bulduğu konumu tanımlamış. Bunun işe yarayacağı yer ise suya düştüğü yerden itibaren suyun etrafına belli araklıklarda oluşturacağı dalgacıkların oluşturulması..

Yani çok kasılması gereken birşey....

[mentat]

cem'e kucuk bir ekleme; aslen Cg (nVidia) ve HLSL (DX) tamamen, birebir ayni diller. sadece isim haklari vs yuzunden iki ayri dil seklinde piyasaya sunulmus durumdalar. Yani birinde yazilan kod digerinde de aynen calistiriliyor. Cg'nin HLSL'e gore tek farki, GL destegi de vermesi. Aslen nVidia Cg'yi ARB'a da GL dili olarak onerdi fakat ortalik orada karman corman oldugu icin, ATI'nin 3DLabs'la birlesmesiyle, aslen Cg (ve HLSL)'den daha kotu oldugu iddia edilen su anki GLSL kabul edildi (mis).

[DG]

Bu cevaplar aydınlatıcı oldu. Herkese teşekkür ederim (geribildirim

chfbat: Su olayı Morrowind'de de var. Haliyle biraz ilkel. (oyun 2002 senesinde çıkmıştı sanırım) Yağmur esnasında denizin üstünde küçük dalgacıklar oluşuyor. Suyun üstünde yürürken senin bıraktığın dalgalar belirli bir süre kalıyor sonra yok oluyor.