2 Api de birbirine çok benziyo. Ben artık şu daha zor şu daha kolay diye düşünmüyorum. Düzgün dizayn yapamazsan ikisinin de kullanımı çok zorlaşır , patlar yani. DX e ilk bakan birisi
LPDIRECT3DDEVICE9 device;
yada genel olarak LPHEDEHODO9 tarzı şeyler görünce canı çok sıkılabiliyo. Syntax olarak OpenGL in algılanması daha kolay. Fakat hem dx hem ogl için güzel wrapper lar yazarsanız bu kolaylık zorluk meselesi ortadan kalkıyo yavaş yavaş. Opengl in dezavantajı bi konsorsiyumun elinde bulunması. Opengl de kararlar yavaş alınıyo , sonra extension karmaşası falan var. Esasında buna benzer problemler Dx de de var (CAPS bitleri mesela). Ama DX10 bu konuda çok katı olacak. CAPS bitleri ortadan kalkacak. Bir ekran kartının %100 DX10 destekli olduğunu iddia edebilmesi için microsoft spesifikasyonuna harfi harfi uyması lazım. Mesela bugün gidiyonuz bir ekran kartı alıyonuz. Kutusunda dx9.0c compatible falan yazıyo. Bu kart non power of two texture ları basabiliyo olsun. Fakat aynı iddia da bulunan başka bir kart non - power two texture ları basamıyo olabilir. Programcının ilgili CAPS bitini kontrol edip bundan emin olması lazım. ışte DX10 da bu tarz herşey tam bir standart a bağlanacak. DX10 gerçek manada geliştiricileri rahat ettirecek. Ayrıca DX in D3DX library si çok iyi. Opengl de benzer glu var ama zayıf kalıyo dx inkine göre. Mesela D3DX e MESH fonksiyonları var. Ekran kartının vertex cache ine göre optimize ediyo datayı. Kendin böyle bişeyi s*ksen yazamazsın. OpenGL için NVidia nın Triangle Strip library si var. Belki o kullanılabilinir. Bi de DX in effects framework u güzel. Özellikle shader ların sınıflandırılması çok net. Tüm device statelerini fx dosyalarında set edebiliyosun. Mesela şöyle bişey yapmak iste :
Backface culling yapmıcan
Fixed pipeline lighting de yapmıcan
Hem vertex shader ın 1.1 hemde pixel shader ın 1.1 profiline göre compile edilmesini istiyon ,
technique Hede
{
pass p0
{
Lighting = FALSE;
CullMode = NONE;
VertexShader = compile vs_1_1 VS();
PixelShader = compile ps_1_1 PS();
}
}
Bu HEDE isimli tekniği renderloop unda aktif hale getirdiğin zaman bu tenikle render edilen herşeyde Culling yok , fixed point lighting yok. Ayrıca VS( ) ve PS( ) isimli shader lar render edilecek şeyler üzerinde çalışıyolar.
Opengl de işler karışık bence. ARB fragment programlar var , NVFragment programlar var (bunlar da kendi aralarında ayrılıyo) , sonra CG ve GLSL var. Ben hala GLSL in hangi shader profiline karşılık geldiğini bilmiyorum ( Muhtemelen ps 2.0). Bu bahsettiğim .fx dosyalarının hemen hemen aynısı CG içinde var . CGFX olarak geçiyo. Zaten CG ve HLSL hemen hemen aynı shading dilleri. Fakat CG nin tek dezavantajı NVIDIA donanımına göre optimize edilmesi ve ATI den hiç destek görmemesi. Vaziyet böyle olmasa Opengl + CG + CGFX de gayet güzel bi çözüm olabilir.
Ayrıca DX de PIX diye bişey var. PIX direct3d profiler ı. Profesyonel adamlar bu olmadan yaşayamazlar artık sanırım.
şimdi yazdıklarıma bakınca sanki DX daha iyi gibi gözükebilir. Ama kime göre? Yani bi democu için yada evinde amatör olarak oyun yapmaya kasan bi adam için iki api de aynı bence. Çünkü ben yaptığım şeyden para beklemiyorum..Yani Opengl + CG + CGFX kullanırım demomda, NVIDIA da iyi çalışır ATI de yavaş. Böyle bir lüksüm var. Yok eğer ben bi oyun stüdyosuysam yaptığım yazılımdan sorumluyum. Her yerde problemsiz ve kabul edilebilir hızlarda çalışmasını sağlamak benim görevim olur. işte bu gibi durumlarda PIX gibi yazılımların , .fx framework un ve D3DX gibi şeylerin önemi ortaya çıkıyo.
Bence mesele böyle.
