Şu an temel şekillerin örneğin nokta, dikdörtgen, çizimi ile ilgili uğraşıyorum. Kodun son hali şu şekilde:

import sdl;

struct Nokta
{
   int x = 0;
   int y = 0;
   Renk renk;

   this (int x, int y, Renk renk = [0x00, 0x00, 0xff, 0x00])
   {
       this.x = x;
       this.y = y;
       this.renk = renk;
   }
}

struct Dikdörtgen
{
   Nokta solÜst;

   int genişlik;
   int yükseklik;

   this(Nokta solÜst, int genişlik, int yükseklik)
   {
       this.solÜst = solÜst;
       this.genişlik = genişlik;
       this.yükseklik = yükseklik;
   }
}

struct Üçgen
{
   Nokta[3] Noktalar;

   this(Nokta bir, Nokta iki, Nokta üç)
   {
       Noktalar = [bir, iki, üç];
   }
}

Burada Renk yapısı şu şekilde:

struct Renk
{
   Uint8 r;
   Uint8 g;
   Uint8 b;
   Uint8 unused;
}

Burada son bileşen alpha (şeffaflık) bilgisi tutuyor.

Şimdi ben henüz bu kodu bitirmedim ama tasarımla ilgili fikirlerinizi alayım dedim. Yapmayı düşündüğüm şeylerin bir kısmını henüz denemedim.

Örneğin renkleri bir enum kullanarak yukarıdaki gibi

enum Renk { mavi, yeşil, kırmızı };

gibi yapabilirmiyiz.

İkincisi aslında bu dikdörtgenin solÜst kısmını bir Vector2 alacak şekilde değiştirmek istiyorum. Bunun nedeni her oyun nesnesi bir dikdörtgen ya da çember gibi temel bir şekile sahip olacak. Daha sonra bu kısımları kullanarak çarpışma algılamasını yapmayı düşünüyorum.

Ama güncelleme metodunda hem oyun nesnesinin konum bilgisini hem de dikdörtgenin konum bilgisini ayrı ayrı güncellemek pek iyi bir çözüm olmadığı için bunları birbirine nasıl bağlı yapabilirim diye düşünüyorum. Örneğin oyun nesnesinin konumu değiştiği zaman oyun nesnesinin sahip olduğu dikdörtgenin konum bilgisi de değişsin. Basitçe '@property' ile olur mu acaba..

Öneri, yorum ve fikirlerinizi bekliyorum! :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Evet en pratik yöntem bu galiba! :)

Yalnız '@property' kullanırsak acaba Dikdörtgen nesnelerini ayrı olarak bağımsız örneğin bir Dikdörtgenle bir Çemberin çarpışma algılamasında kullanabilecekmiyiz. '@property' her ne kadar okumuş olsam da biraz yabancı bir konu. Bakalım kodlayalım görelim :-D

Öneriler için teşekkürler.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (erdem):

> enum Renk { mavi, yeşil, kırmızı };
> ```

>
> gibi yapabilirmiyiz.

Bildiğim kadarıyla enum'lar perde arkasında herhangi bir türü kullanabiliyorlar. Bu yüzden şunun çalışması gerekiyor:

import std.stdio;
import std.string;

alias ubyte Uint8;

struct Renk
{
Uint8 r;
Uint8 g;
Uint8 b;
Uint8 unused;

int opCmp(const ref Renk sağdaki) const
{
return ((r == sağdaki.r)
? ((g == sağdaki.g)
? b - sağdaki.b
: g - sağdaki.g)
: r - sağdaki.r);
}

string toString()
{
return format("%s,%s,%s", r, g, b);
}
}

enum TemelRenkler : Renk // <-- Renk üzerine kurulu
{
mavi = Renk(0, 0, 255),
yeşil = Renk(0, 255, 0),
kırmızı = Renk(0, 0, 255)
}

void main()
{
writeln(TemelRenkler.mavi);
writeln(TemelRenkler.yeşil);
writeln(TemelRenkler.kırmızı);
}

opCmp()'u derleyici istediği için ekledim. Ama yine de derleyici hataları alıyorum:

'Error: cast(const(Renk))Renk(cast(ubyte)0u,cast(ubyte)0u,cast(ubyte)255u,cast(ubyte)0u) is not an lvalue
..
'

Hatırladığım kadarıyla o bilinen bir hata. Sanırım şu:

 http://d.puremagic.com/issues/show_bug.cgi?id=4423

Onun yerine sabit renk değerlerini evrensel ve tekli enum'lar olarak tanımlayabilirsin:

enum mavi = Renk(0, 0, 255);
enum yeşil = Renk(0, 255, 0);
enum kırmızı = Renk(0, 0, 255);

void main()
{
writeln(mavi);
writeln(yeşil);
writeln(kırmızı);
}

Eğer evrensel alanda isim kirliliğinden çekiniyorsak onları bir struct'ın static üyeleri yapabiliriz (C++'ta namespace'in olmadığı zamanlarda yapıldığı gibi):

struct TemelRenkler
{
static {
enum mavi = Renk(0, 0, 255);
enum yeşil = Renk(0, 255, 0);
enum kırmızı = Renk(0, 0, 255);
}
}

void main()
{
writeln(TemelRenkler.mavi);
writeln(TemelRenkler.yeşil);
writeln(TemelRenkler.kırmızı);
}

Başladığımız noktaya dönmüş olduk. :)

Alıntı:
> Basitçe '@property' ile olur mu acaba..

Anlattıkların bana da onu çağrıştırdı. Dikdörtgen her nesnenin kendi niteliği galiba; yani ayrı bir varlık değil. Gerektiğinde nesnelere sorup edinmek mantıklı.

Ali

-- 
[ Bu gönderi, <http://ddili.org/forum>'dan dönüştürülmüştür. ]

@property, nesneyle ilgili bir değeri işlev parantezleri kullanmadan döndürmekten başka bir şey değil. Ek olarak, ve isteniyorsa, onunla ilgili bir değeri yine işlev parantezleri kullanmadan atama işleci ile değiştirebilmek.

C++ ve başka dillerde yapılan

eskiDeğer = nesne.get_birŞey();
nesne.set_birŞey(yeniDeğer);

yerine

eskiDeğer = nesne.birŞey;
nesne.birŞey = yeniDeğer;

diyebiliyoruz. birŞey sanki bir üye değişken gibi kullanılıyor ama perde arkasında işlev çağrıları oldukları için nesne yönelimli programlama suçu işlememiş oluyoruz. :)

@property'de bundan başka bir karmaşıklık yok.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Yaklaşık 24 saattir SDL dünyasında geziniyorum. Erdem'in yapmış olduğu işler bu dünyada gezinmemi kolaylaştırıyor. Kendi adıma teşekkür ederim..

Özellikle bu renk yapısındaki tanımlar işleri daha da kolaylaştırıyor. Gerekli parametreleri tanımladığınızda şu şekilde oyununuzu oynamaya (istediğiniz zemin rengi ve boyutta) başlıyorsunuz...:)

void main() {
   auto oyun = new Oyun(800, 200);
   oyun.çalıştır(Renk.mavi);  // Mavi gökyüzünde dolanan bir yıldız...
}

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Şimdi de geliştirmeye başladım...

Ama temel öğeler üzerinde fikir birliğine varalım istiyorum. Elbette bir oyunda birden fazla sahne olabilir. Örneğin menü, skorlar ve aksiyon anı gibi. Erdem de bunu düşünmüş olacak ki TemelOyun isminde bir sınıfı Oyun'a miras vermiş. Ben ise farklı düşünmeye başladım. Çünkü ekranı temizlediğinizde ve/veya var olan nesneleri hafızadan bir şekilde attığınızda artık yeni bir oyun veya sahneye sahip olmuş olacaksınız. Öyle değil mi?

Peki biz nesnelerin ortak özelliklerini (w, h, x, y) de içeren bir Nesne sınıfımız olsa ve Sahne'ye aldığımız (sahne sınıfı içinden çağırdığımız) nesneleri tıpkı TemelOyun'da olduğu gibi miras alsak nasıl olur? Yani her nesnenin özelliğine göre başka nesneler (yazı, şekil, resim) hali hazırda tanımlansa, bu durumda bunlar sınıf olurdu ve ortak noktaları da Nesne'den miras alabilirdi diye düşünmekteyim.

Şimdi bu ortak noktaların listesini çıkaracağım, unuttum bir şey varsa ekleyin lütfen:

• int w (nesnenin genişliği)
• int h (nesnenin yüksekliği)
• double x (nesnenin yatay konumu)
• double y (nesnenin dikey konumu)
• bool etkinMi (nesne görünür mü?)
• bool şeffafMı (nesne zemin rengi şeffaf mı?)
• Renk zemin (nesnenin zemin rengi)

Sanırım font ve vector'ler için çizgi rengi de eklenebilir. Ama bu resim veya dördüncü tür bir nesne için geçerli görünmüyor. Ayrıca şeffafMı = true olması durumunda da zemin renginin bir esprisi kalmıyor. Bence bu son iki üyeyi eğrisiyle, doğrusuyla biraz düşünmeliyiz...

Peki genişlik/yükseklik değerlerine ne demeli? Benim anladığım kadarıyla SDL'de, bu bir resim ise maskeleme özelliğinde çalışıyor. Ayrıca SDL imkan veriyorsa offset değeri de eklenebilir. Peki ya size.w/size.y anlamında bir ölçüt olmalı mı? Yine SDL olanaklarıyla ilgili ki eğer nesneyi ölçekleyebiliyorsak ek üyeler yolda görünüyor. Bunu biraz daha araştıracağım...

Teşekkürler...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Aslında oradaki amacım TemelOyun sınıfını başka bir modüle atıp, sınıf detaylarını kullanıcıdan gizlemek. Böylece bir parça da olsun kodun karmaşıklığını azaltmak istemiştim. Şimdi düşününce iki tane sınıf olması bana da uygun gelmedi. Hatta Oyun sınıfının bir nesne olmasına gerek var mı emin değilim.

Alıntı (Salih Dinçer):

Gayet mantıklı. Bir tane temel nesne sınıfı olur. Daha sonra yazı tipi gibi diğer sınıflar bu sınıfın bazı özelliklerini miras alırlar.

Alıntı (Salih Dinçer):

Kod oluşmaya başladıkça uygulama detaylarının daha iyi ortaya çıkacağını düşünüyorum.

Alıntı (Salih Dinçer):

Ben bunun nasıl yapıldığını bilmiyorum. Ama kütüphanenin böyle bir özelliği desteklediğini tahmin ediyorum.

Bir de diğer grafik, oyun kütüphanelerini inceleyebilirsin.

https://github.com/jlnr/gosu

http://create.msdn.com/en-US/education/tutorial/2dgame/getting_started

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (erdem:1344240609):

Katkın için teşekkürler Erdem... Kütüphane aslında çok gelişmiş değil (2.0'nı bilmiyorum, görmedim) ve başka kütüphanelere ihtiyaç bırakıyor. Ancak henüz SDL-D ilintisine eklemediğimiz işlevler var. Örneğin pencere simgesi ve bu çok temel bir şey. Hatta Linux için şunu söylemeliyim (belki Windows'da oluyordur, denemedim) sahne değiştirirken pencere simgesi de gerçek zamanlı değişebiliyor. Bu çok hoş ve bir o kadarda gereksiz sanki...:)

Alıntı (Salih Dinçer:1344212895):

Sanırım bu konuyla ilgili çok az kişi (sadece Erdem mi yoksa?) var; çünkü kimse yukarıdaki liste için fikir belirtmek istemiyor sanki, öyle mi?

Ben herkesin, içerlerde bir yerlerde gizli oyun aşkı olduğuna eminim. En azından iş güç ile bilinçaltına ittiğimiz heveslerimiz var. Bunlar çocuklukta kalmadı ve geri alabilirsiniz...:)

Listeye tek aklıma gelen frame adeti ki oda dün yaptığım FPS denmelerinden çağrışım yapan (şükür!) bir şey. Her ne kadar temel şekilde bu değer 1 olacaksa da oyunun asıl al benisini oluşturan grafik türü animasyondur. Üstelik SDL'de bunu yapmak çok kolaymış. Hani web uygulamalarında tek resim vardır ama CSS ile o resmin bir bölümü maskelenir ya, işte aynı şekilde bunu SDL ile yapabiliyorum. O yüzden bu TemelNesne sınıfımıza uint çerçeve üyesini ekliyorum.

Tam burada bahsetmeyi uygun gördüğüm ve sonra ayrı bir başlıkta dillendireceğim SDL çatısından (framework) fikri var ama ayrıntılar sonra. Çünkü SDL'nin çok basit olsa da yeterli bir basamak olduğunu düşünüyorum. Tıpkı bir puzzle gibi parçaları birleştirerek gelişmiş bir kütüphane yapılabilir. Tabi düşündüğüm modern bir çatı değil ve belki bir deneme. Yine de daha hızlı uygulama geliştirmeyi sağlayabilir. Çünkü SDL'nin şu hali uygulamanıza multimedia dosyaları katıp yansıtmaktan öteye geçemiyor sanki<--- çok mu acımasız bir yorum oldu? Özetle programcıya çok hamallık yüklüyor gibi...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Aynen katılıyorum :)

Alıntı (Salih Dinçer):

Aslında SDL bir grafik kütüphanesi. Grafik, ses, ağ desteği kısaca bir oyun için gerekli tüm bileşenlere sahip olanlar ise oyun motoru olarak geçiyor. Burada oyun motorlarının bir listesini bulabilirsin.

http://en.wikipedia.org/wiki/List_of_game_engines

Ama seninde bahsettiğin gibi bir yapboz'un parçalarını bir araya getirir gibi SDL kullanılarak 2D oyun motoru, oyunlar yapılabileceğini düşünüyorum. Ya da SFML gibi SDL kullanan bir 2D oyun kütüphanesi kullanılabilir. Derelict3 de SFML için D ilintileri var sanırım.

https://github.com/aldacron/Derelict3

Hatta SDL2 için ilintileri de yazmışlar. Ama ben SDL2 konusunda yeterli kaynak bulamadım.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Katkı için teşekkür ederim...

Evet, böyle bir tür uyumsuzluğu (hatta uyumsuzlukları) var. Şöyle ki;

Öncelikle Erdem'in hazırladığı Vector sınıfı her ne kadar farklı veri türleri ile de çalışabilse de alias kullanılarak Vector!float Vector2'ye eşitlenerek kullanılıyor. Yanılmıyorsam SDL ilintisinde de aşağı yukarı her yerde int veri türleri var! İşte bu ilginç...:)

Belki Erdem bu konuda daha açıklayıcı bilgi verecektir. Yani hesapların ondalıklı yapılması SQRT fonksiyonu için mi? Öyle ya SDL tam sayılar ilgileniyor...

Diğer bir uyumsuzluk ise sanki SDL'nin kendi yapıları içinde. Yani işlevler çoğunlukla int üzerinde veri işliyor/döndürüyor. Ama örneğin SDL_Rect yapısında koordinatlar (x, y) short kullanılırken, boyutlar (w, h) ushort kullanılmış:

extern(C) struct SDL_Rect
{
   Sint16 x, y;
   Uint16 w, h;
}

Evet, bunu anlayabiliyorum! Çünkü bir nesnenin boyutu eksi değerli olamaz ve uint32 gibi yüksek bir değer de saçma olur. Çünkü her şey ekranda olup bitiyor. Ama koordinatları (pixel coordinate) pek anlamış değilim. Çünkü eksi değerli bir şey olamaz. Belki vektör toplamları ile ilgili bir pratiklik sağlıyordur. Gerçi ekran sınırları dışına taşan diğer yöne aksediyor. Yani 0,0 noktası sol üst köşeyse ve burada olan bir nesne eksiye yöneldiğinde sağ alt köşede beliriyor. Aynı şekilde sağ sınırı geçen bir nesne solda çıkıyor...:)

Peki bir soru float'dan kurtulabilir miyiz? Çünkü dün FPS'lere bakarken bir tekleme/takılma tespit etmiştim. Meğer 60 FPS'de bile bu oluyormuş. Acaba diyorum, tür dönüşümleri sırasında yukarı/aşağı yuvarlamalardan dolayı mı böyle bir şey oluyor? Yoksa biz her yerde integer kullansak daha çok karmaşa mı olur?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]