C++ - Console'dan normal Application a...

quote:

Orijinalden alıntı: AlperXp

Arkadaşlar ben Console ile çok çalışma yaptım zamanında. C++ ta... Artık 2d Oyun yapımı için Win32 Application a geçmek istiyorum ama çok korkuyorum. Yani geçtiğimde herşeye sıfırdan başlamak gibi ve hiçbirşey anlamıyorum, yapamıyorum. Sanki çok fazla geliyor bana. Ya çok hızlı ilerlemeye çalışıyorum ya da bir sorunum var bilmiyorum... Bana ne önerebilirsiniz.

quote:

Orijinalden alıntı: me-er

quote: Orijinalden alıntı: AlperXp Arkadaşlar ben Console ile çok çalışma yaptım zamanında. C++ ta... Artık 2d Oyun yapımı için Win32 Application a geçmek istiyorum ama çok korkuyorum. Yani geçtiğimde herşeye sıfırdan başlamak gibi ve hiçbirşey anlamıyorum, yapamıyorum. Sanki çok fazla geliyor bana. Ya çok hızlı ilerlemeye çalışıyorum ya da bir sorunum var bilmiyorum... Bana ne önerebilirsiniz.

Gerek Win32 API gerekse de MFC ile kod yazmak aşağı seviyeli yapıları bilmeyenler için oldukça zordur. Ki aslına bakılırsa diğer arkadaşımızın da söylediği gibi QT varken bu iki eski araçla ilerlemeye çalışmanın bir anlamı da yoktur.http://qt.nokia.com/downloads kısmından "Go LGPL" buttonuna tıklayın ve karşınıza gelen linklerden Qt SDK for Windows'u indirin. Alışması zaman alsa da QT Creator gibi fena sayılmayacak bir IDE'niz ve QT gibi müthiş bir framework elinizin altında olacaktır. Bu geliştirme ortamı ile çok kolay grafik arayüz içeren uygulamalar geliştirebilirsiniz. Ayrıca QT kütüphanesinin yapılarını dikkate alarak kod yazarsanız nesne yönelimli programlama konusunda seviyenizi ilerleteceğinizi temin edebilirim.

QT'nin içerik olarak yeterince doyurucu yardım dosyaları var. Öğrenmeye oradan başlayabilirsiniz. Eğer yeterli olmazsa internet üzerindeki birçok kaynak ve ebook'tan da yararlanabilirsiniz.

Kolay gelsin.

quote:

Orijinalden alıntı: skoylu

Öncelikle ne yapmak istediğine bir karar vermen lazım.

Eğer niyetiniz GUI programlama teknolojisini öğrenmek ise, o zaman QT'yi filan boş ver. Kendi event loop'unu kur. Onunla çalış. Basitçe bir tek textbox "yapıp" (Şu cevapları vs. yazdığımız GUI elemanı) tamam dediğinizde, olayı bir hayli öğrenmiş olursunuz.

Ama bu "yapıp" kelimesini açmak gerekiyor. Bundan kasıt şu. Gidip bir window handle oluşturacaksınız. Sonra çerçevesini çizecek, çini boyayacaksınız vs. vs. Yani Windows'un hazır (yada QT'Deki vs. hazır olan) Textbox componentini (bileşen) alıp bir forma koyarak değil.

Bu gerçekten çok zaman alacaktır, ama size çok şey katacaktır.

Fakat niyetiniz bu değilde, GUI uygulaması yapmaksa, o zaman bu yoldan gitmek akla ziyandır. QT üzerinden gitmekte gayet akıllıcadır.

QT için herşey pek iyi pek güzel. Fakat bir hususu akılda tutmak gerekir. QT, bir C++ uygulaması değildir. Slot - signal mekanizması ve benzeri diğer bazı meseleleri halletmek üzere, QT, C++ standardı dışında farklı bir sistematik dil kullanır. Bu dil C++ değilde QT dilidir. Bunda tarif edilen metaobject'ler, moc ile C++'ya derlenir. Evet, C++'dan hemen hiç farkı yok gibi. Fakat böyle bir farkın olduğunu akılda tutmak gerekiyor. Bunu iyi kavrayamayınca, mesela bu "emit" neden çalışmıyor gibi kafa kırdıran sorunlarla çokca uğraşmak gerekiyor.

Ama QT, bu yeni C++ aksanını öğrendiğinize değecek kadar kaliteli bir şey. Bunuda belirtmek lazım.

Ha, ilk yoldan giderseniz, QT'yi öğrenmenizde çok sürmez zaten.

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

Öncelikle ne yapmak istediğine bir karar vermen lazım.

Eğer niyetiniz GUI programlama teknolojisini öğrenmek ise, o zaman QT'yi filan boş ver. Kendi event loop'unu kur. Onunla çalış. Basitçe bir tek textbox "yapıp" (Şu cevapları vs. yazdığımız GUI elemanı) tamam dediğinizde, olayı bir hayli öğrenmiş olursunuz.

Ama bu "yapıp" kelimesini açmak gerekiyor. Bundan kasıt şu. Gidip bir window handle oluşturacaksınız. Sonra çerçevesini çizecek, çini boyayacaksınız vs. vs. Yani Windows'un hazır (yada QT'Deki vs. hazır olan) Textbox componentini (bileşen) alıp bir forma koyarak değil.

Bu gerçekten çok zaman alacaktır, ama size çok şey katacaktır.

Fakat niyetiniz bu değilde, GUI uygulaması yapmaksa, o zaman bu yoldan gitmek akla ziyandır. QT üzerinden gitmekte gayet akıllıcadır.

QT için herşey pek iyi pek güzel. Fakat bir hususu akılda tutmak gerekir. QT, bir C++ uygulaması değildir. Slot - signal mekanizması ve benzeri diğer bazı meseleleri halletmek üzere, QT, C++ standardı dışında farklı bir sistematik dil kullanır. Bu dil C++ değilde QT dilidir. Bunda tarif edilen metaobject'ler, moc ile C++'ya derlenir. Evet, C++'dan hemen hiç farkı yok gibi. Fakat böyle bir farkın olduğunu akılda tutmak gerekiyor. Bunu iyi kavrayamayınca, mesela bu "emit" neden çalışmıyor gibi kafa kırdıran sorunlarla çokca uğraşmak gerekiyor.

Ama QT, bu yeni C++ aksanını öğrendiğinize değecek kadar kaliteli bir şey. Bunuda belirtmek lazım.

Ha, ilk yoldan giderseniz, QT'yi öğrenmenizde çok sürmez zaten.

quote:

Orijinalden alıntı: elektro_gadget

Benim bildiğim c++ ta olmayan 3 tane anahtar sözcüğü var. signals, slots ve emit. Başka bir farkı varsa öğrenmek isterim.
Bunların içinde tek kafa karıştırıcı olan emit. Ama zaten ona da çok seyrek ihtiyaç duyuluyor. Bu genişlemeler bence Qt öğrenmenin önüne hiçbir engel çıkarmaz.

Diye yazmıştım ama sonradan aklıma iki fark daha geldi. Birincisi connect yaparken signal slot arası parametre aktarımı, ikincisi nesnelerin kurucularındaki farklı bir sözdizimi.
Bu ikincisinden emin değilim ama ben hiçbir c++ kaynağında böyle bir sözdizimi görmedim.
Ama ne kadar fark olursa olsun %98 i yine c++.

quote:

Orijinalden alıntı: me-er

quote: Orijinalden alıntı: elektro_gadget Benim bildiğim c++ ta olmayan 3 tane anahtar sözcüğü var. signals, slots ve emit. Başka bir farkı varsa öğrenmek isterim. Bunların içinde tek kafa karıştırıcı olan emit. Ama zaten ona da çok seyrek ihtiyaç duyuluyor. Bu genişlemeler bence Qt öğrenmenin önüne hiçbir engel çıkarmaz. Diye yazmıştım ama sonradan aklıma iki fark daha geldi. Birincisi connect yaparken signal slot arası parametre aktarımı, ikincisi nesnelerin kurucularındaki farklı bir sözdizimi. Bu ikincisinden emin değilim ama ben hiçbir c++ kaynağında böyle bir sözdizimi görmedim. Ama ne kadar fark olursa olsun %98 i yine c++.

emit anahtar sözcüğü signal fırlatmanızı sağlar.

Yani,

connect(controller, SIGNAL(removeItems()), archiver, SLOT(removeAllItems());

Bu şekilde controller sınıfının removeItems sinyalini archiver sınıfının removeAllItems slotu ile bağlamış oldunuz. Controller sınıfı ne zaman kendi içerisinde bir iş yapar ve removeItems() sinyalini fırlatırsa akabinde archiver sınıfı için removeAllItems() slotu çalıştırılır.

{
...
//Birşeyler yapıyorum ve sinyalimi fırlatıyorum.
emit removeItems();
//Yukarıdaki bağlama sayesinde archiver sınıfının removeAllItems fonksiyonu da çalıştırılacak
}

Bir sinyale birçok slot bağlatarak tek seferde bir çok yerdeki işi rahatça yaptırabilirsiniz. Ayrıca bir sinyale sinyalde bağlayabilirsiniz.

connect(controller, SIGNAL(func()), controller, SIGNAL(foo());

gibi.

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

iyi güzel, tamamda..

Buradaki sorun, standart C++'ya bir şeyler ekliyor musunuz, eklemiyor musunuz?

Bu noktada söz konusu olan nicelik değil, nitelik meselesi.

C++ felsefe olarak nesnenin iç yapısını tamamen kullanıcıdan izole eder. Fakat bu bahsettiğiniz slot/signal mekanizması, bu kuralı yok edip, C++ seviyesinde nesnenin o kapsülünü kırar. QT Nesneleri C++'nın gerek ve amaçlarında olan veriyi kapsülleme yapısını yok etmiş olur.

Eğer QT seviyesinden bakıyorsanız, o seviyede sonuç aynıdır: Nesne gene kapsüllenmiştir. Fakat eğer C++ seviyesindne bakıyorsanız, o nesne artık size açık bir nesnedir.

Bu slot mekanizmasına daha bir dikkatli bakmak gerekir. QT burada bir tür VTBL yaratır. Bu da açıkca, derleyicinin ABI seviyesindeki çağrı mekanizmasının ihlali anlamına gelir.

Basitçe, bir nesnenin herhangi bir fonksiyonu, bir pointerle ifade edilemez. Fakat burada, tersine bir "hack", bir "atraksiyon" görülmektedir.

Bu meseleyi anlamak ve akılda tutmak önemlidir. Diğer yandan bu satırlar "QT C++'yı igfal ediyor, şöyle vede böyle" babında bir yaklaşım değil. Bu, kendi adıma takdir ettiğim ve güzel olmuş dediğim bir olgu. Bu bilinmesi gereken bir husus, fakat kötü veya çirkin bir husus değil.

QT Güzeldir, kullanmaya değer. Velakin kullandığımız şeyin ne olduğunu bilmekte sayısız faydalar vardır.

Birde küçük bir düzeltme ekleyelim. QT, NOKIA'nın değil, Trolltech'in bir ürünüdür. Linux'un yaygın masaüstü KDE'nin QT ile yazılmış olması, çok geniş bir uygulama sahasının önünü QT'ye açmıştır. Bu noktadan gelen açık kodun itici gücü QT'yi gerçekten çok iyi bir getirdi. Ve bu noktada NOKIA devreye girip, Trolltech'i satın aldı. Fakat QT'nin asıl itici gücü hala open source / GPL tabanından gelmektedir.

QT gerçekten son derece iyi bir tercihtir. Herşeyin başında, GPL olması dileyenin dilediği gibi hack'lemesine vs. imkan verir. Daha güzeli, konuyu öğrenmek isteyene hazır muazzam bir kaynak sağlar.

Diğer yandan şöylede bir şey var. QT, Java, Pascal, PHP, python, C# vs. gibi hemen her dille kullanılabilir. Gerçi bunlar genelde C++ koduna wrapper halindedir ama netice değişmez.

Birde tekrar üzerine basmak gereken bir şey daha var. QT sadece bir GUI widget setinden ibaret değildir. Tipik bir kullanıcı uygulaması için gereken hemen her şeyi, script yorumlayıcı dahil, kapsamaya çalışır.

Kısaca, QT her açıdan makul, mantıklı, güzel bir tercihtir. C++ diline eklemeler yapması tercihte değil, kullanımda dikkate alınacak bir husustur sadece.

quote:

Orijinalden alıntı: me-er

quote: Orijinalden alıntı: skoylu iyi güzel, tamamda.. Buradaki sorun, standart C++'ya bir şeyler ekliyor musunuz, eklemiyor musunuz? Bu noktada söz konusu olan nicelik değil, nitelik meselesi. C++ felsefe olarak nesnenin iç yapısını tamamen kullanıcıdan izole eder. Fakat bu bahsettiğiniz slot/signal mekanizması, bu kuralı yok edip, C++ seviyesinde nesnenin o kapsülünü kırar. QT Nesneleri C++'nın gerek ve amaçlarında olan veriyi kapsülleme yapısını yok etmiş olur. Eğer QT seviyesinden bakıyorsanız, o seviyede sonuç aynıdır: Nesne gene kapsüllenmiştir. Fakat eğer C++ seviyesindne bakıyorsanız, o nesne artık size açık bir nesnedir. Bu slot mekanizmasına daha bir dikkatli bakmak gerekir. QT burada bir tür VTBL yaratır. Bu da açıkca, derleyicinin ABI seviyesindeki çağrı mekanizmasının ihlali anlamına gelir. Basitçe, bir nesnenin herhangi bir fonksiyonu, bir pointerle ifade edilemez. Fakat burada, tersine bir "hack", bir "atraksiyon" görülmektedir. Bu meseleyi anlamak ve akılda tutmak önemlidir. Diğer yandan bu satırlar "QT C++'yı igfal ediyor, şöyle vede böyle" babında bir yaklaşım değil. Bu, kendi adıma takdir ettiğim ve güzel olmuş dediğim bir olgu. Bu bilinmesi gereken bir husus, fakat kötü veya çirkin bir husus değil. QT Güzeldir, kullanmaya değer. Velakin kullandığımız şeyin ne olduğunu bilmekte sayısız faydalar vardır. Birde küçük bir düzeltme ekleyelim. QT, NOKIA'nın değil, Trolltech'in bir ürünüdür. Linux'un yaygın masaüstü KDE'nin QT ile yazılmış olması, çok geniş bir uygulama sahasının önünü QT'ye açmıştır. Bu noktadan gelen açık kodun itici gücü QT'yi gerçekten çok iyi bir getirdi. Ve bu noktada NOKIA devreye girip, Trolltech'i satın aldı. Fakat QT'nin asıl itici gücü hala open source / GPL tabanından gelmektedir. QT gerçekten son derece iyi bir tercihtir. Herşeyin başında, GPL olması dileyenin dilediği gibi hack'lemesine vs. imkan verir. Daha güzeli, konuyu öğrenmek isteyene hazır muazzam bir kaynak sağlar. Diğer yandan şöylede bir şey var. QT, Java, Pascal, PHP, python, C# vs. gibi hemen her dille kullanılabilir. Gerçi bunlar genelde C++ koduna wrapper halindedir ama netice değişmez. Birde tekrar üzerine basmak gereken bir şey daha var. QT sadece bir GUI widget setinden ibaret değildir. Tipik bir kullanıcı uygulaması için gereken hemen her şeyi, script yorumlayıcı dahil, kapsamaya çalışır. Kısaca, QT her açıdan makul, mantıklı, güzel bir tercihtir. C++ diline eklemeler yapması tercihte değil, kullanımda dikkate alınacak bir husustur sadece.

1) Standart C++'a birşeyler eklemiyoruz. Aşağıdaki örnekleri inceleyelim.

a)

bool free(unsigned int val)
{
...
return false;
}

------------------------

#define BOS void
#define IKIDURUM bool
#define YANLIS false

typedef unsigned int isaretsiz_tamsayi;

BOS free(isaretsiz_tamsayi val)
{
....
return YANLIS;
}

b)

template <unsigned long N>
struct binary
{
static unsigned const value
= binary<N/10>::value << 1
| N%10;
};

template <>
struct binary<0>
{
static unsigned const value = 0;
};

İlk kısımda yapılanlarla yeni standart C++'a birşeyler eklemiş olmayız sadece görüntüyü tercihimize göre değiştirmiş oluruz. Aynı şekilde ikinci örnek bir hack değil'dir (Basit bir metaprogram örneği. Derleme zamanında 10'luk tabandan 2lik tabana dönüşüm yapmaya yarar.)
C++'ın standart şablon yapısı tarafından desteklenir. Sonuç olarak QT temelde bu tarz "atraksiyonları" kullanır ve bu özellikler ile bir hacki değil frameworkün çalışma tercihini görmüş oluruz.

2) C++ felsefe olarak nesnenin iç yapısını izole etmez. Bunu etse etse "Nesne yönelimli paradigma" ile hakkını vererek yazılmış bir C++ kodu yapar. Bunun haricinde C++ yapısal (structured) ve jenerik (generic) programlamaya imkan tanıyan bir dildir ve bu iki yapıda kullanacağınız mantık ile zaten OOP'in encapsulation yani veri gizleme ilkesini çok rahat ihlal edebilirsiniz.

3) Inanın Application Binary Interface'e kadar inmeye gerek yok. QT standart C++'ın VTBL yapısını kullanır ek olarak standarda kesinlikle aykırı olmayan metaprogramming ve makro tekniklerini kullanırki bu sayede zaten hakkını veren cross-platform bir kütüphanedir. Hatta ve hatta kimi derleyiciler standart exception handling mekanizamasını doğru düzgün implemente edemediği için QT exception mekanizmasını da kullanmayı tercih etmez.

4) Günümüzde artık Trolltech diye bir firma kalmadığına göre netice de Nokia ürünüdür. GPL'den ziyade artık kendisi LGPL olmuştur ve bu durumun arkadasında da tabiki Nokia gibi bir dev vardır.

5) QT ile yazdığım kodlarda hack yaptığımı söyleyebilirim. (Kütüphanenin yapılmasını önermediklerini yapma) Ancak şu hack kelimesini iyi değerlendirmek gerek. Yaptığınız "hack" ile taşınabilirliği her zaman tehlikeye atarsınız. Diğer taraftan hack demek ileriki dönemlerde yaptığınız tercihlerin geçerli olmaması anlamına da çıkacaktır. Lakin QT'nin temelde kullandığı yapı hack değildir ve "ben C++ standardını destekliyorum" diyen tüm derleyicilerde sorunsuz bir şekilde derlenecektir.

6) QT'nin alt yapısına bağlı olmak veya olmamak tamamen kullanıcının/kurumun insiyatifine bağlıdır. Örneğin işyerimde PC için geliştirilen uygulamalar QT altyapısını birebir kullanırken, gömülü cihazlarda aşağı seviyede çalışan ve ürettiğimiz cihazın "kernel"i olarak düşünebileceğimiz birimler (işletim sistemi kernelinden ayrı olarak) tamaman standart C++ ile kodlanmaktadır. Ancak ve ancak cihazların arayüz ve diğer daha yüksek seviyeli birimleri QT'nin bütün yapılarını kullanmaktadır.

Kısacası QT'nin kurduğu yapıyı kullanmakta tamamen tercih/ihtiyaç meselesi.

Alıntıları Göster

quote:

Sonuç olarak QT temelde bu tarz "atraksiyonları" kullanır ve bu özellikler ile bir hacki değil frameworkün çalışma tercihini görmüş oluruz.

quote:

Kısacası QT'nin kurduğu yapıyı kullanmakta tamamen tercih/ihtiyaç meselesi.

quote:

Orijinalden alıntı: skoylu

quote: Sonuç olarak QT temelde bu tarz "atraksiyonları" kullanır ve bu özellikler ile bir hacki değil frameworkün çalışma tercihini görmüş oluruz.

İlginç..

İçinde bir QT nesnesi tarif ettiğimiz, xyz.h dosyasını ve implementasyonu olan xyz.cpp dosyasını, "g++ ...." diyerek derleyebiliyor muyuz?

Eğer önce MOC'tan geçirmek gerekiyorsa, bu preprocessor sizin oraya yazdığınız "QOBJECT" vs. makrolarını C++'nın anlamadığı şekilden alıp "tercüme" ediyorsa, bu açıkca, yazdığınız lisan, C++ değil demek olmuyor mu?

Hal böyle iken, örneğin, PHP ile yazılmış bir kodu da bir preprocessor'den geçirip C++ koduna çevirmek bile mümkünken (bkz: HipHop) söylediğiniz şey biraz "Yok, PHP'de C++ ya bir şey eklemez" gibi duruyor.

C++ için bir standart yok. Yani <<ve "ben C++ standardını destekliyorum" diyen tüm derleyicilerde>> diyebilme ihtimalimiz yok. Ama ANSI'nin bir takım draftları var. Herneyse, şu an herhangi bir C++ derleyicisi, MOC kullanmadan, QT Class tariflerini derleyebilir mi?

Verdiğiniz örnekler derlenmek için bir MOC gibi metacompiler veya preprocessor gerektirir mi?

quote: Kısacası QT'nin kurduğu yapıyı kullanmakta tamamen tercih/ihtiyaç meselesi.

Elbette.. Velakin, benim görüşüm QT kullanmak gayet iyi bir tercihtir, elbette her zaman her yerde olmasada.. Ve dahası, bir şeyler öğrenmeye çalışan içinde çok çok iyi bir başlangıç noktasıdır. Yani, QT için söylediklerim "WARNING" değil, "INFORMATION" halindedir. Bu mekanizmaları görmek, bilmek ve bunun nasıl C++ ile implemente edildiğini kavramak seviyeyi iyice yükseltir.

Yorumlarınıza ve katkılarınıza teşekkürler, devamını beklerim..

quote:

Orijinalden alıntı: me-er

quote: Orijinalden alıntı: skoylu quote: Sonuç olarak QT temelde bu tarz "atraksiyonları" kullanır ve bu özellikler ile bir hacki değil frameworkün çalışma tercihini görmüş oluruz. İlginç.. İçinde bir QT nesnesi tarif ettiğimiz, xyz.h dosyasını ve implementasyonu olan xyz.cpp dosyasını, "g++ ...." diyerek derleyebiliyor muyuz? Eğer önce MOC'tan geçirmek gerekiyorsa, bu preprocessor sizin oraya yazdığınız "QOBJECT" vs. makrolarını C++'nın anlamadığı şekilden alıp "tercüme" ediyorsa, bu açıkca, yazdığınız lisan, C++ değil demek olmuyor mu? Hal böyle iken, örneğin, PHP ile yazılmış bir kodu da bir preprocessor'den geçirip C++ koduna çevirmek bile mümkünken (bkz: HipHop) söylediğiniz şey biraz "Yok, PHP'de C++ ya bir şey eklemez" gibi duruyor. C++ için bir standart yok. Yani <<ve "ben C++ standardını destekliyorum" diyen tüm derleyicilerde>> diyebilme ihtimalimiz yok. Ama ANSI'nin bir takım draftları var. Herneyse, şu an herhangi bir C++ derleyicisi, MOC kullanmadan, QT Class tariflerini derleyebilir mi? Verdiğiniz örnekler derlenmek için bir MOC gibi metacompiler veya preprocessor gerektirir mi? quote: Kısacası QT'nin kurduğu yapıyı kullanmakta tamamen tercih/ihtiyaç meselesi. Elbette.. Velakin, benim görüşüm QT kullanmak gayet iyi bir tercihtir, elbette her zaman her yerde olmasada.. Ve dahası, bir şeyler öğrenmeye çalışan içinde çok çok iyi bir başlangıç noktasıdır. Yani, QT için söylediklerim "WARNING" değil, "INFORMATION" halindedir. Bu mekanizmaları görmek, bilmek ve bunun nasıl C++ ile implemente edildiğini kavramak seviyeyi iyice yükseltir. Yorumlarınıza ve katkılarınıza teşekkürler, devamını beklerim..

Tekrardan merhabalar skoylu,

Evet kodladığımız ve QT'ye has yapıları kullandığımız (signal/slot, Q_OBJECT vb.) dosyalar moc tarafından düzenlenir. Ancak yaptığımız bu değişiklik "C++ lisanı olmaz" da denemez.
Sanırım ayrıştığımız nokta şu. Siz "QT Dili" diye bir tabir kullanmışsınız. Bunun yerine "QT eklentisi" denmesi taraftarıyım. Nitekim bu eklentiler de C++'ın izin verdiği ölçülerde vardır ve bir araç sayesinde doğal C++ koduna dönüştürüşür. Akabinde isterseniz GCC, isterseniz ms c++ veyahut Intel C++ Compiler ile bile derlenir. Demek istediğim yapılan bu tarz bir soyutlama yazdığımız kodu C++ kodundan başka birşeye çevirmez.
Kaldı ki QT'nin eklediği yapının C++'ın felsefesine aykırı iş (C++.net gibi)yaptğını düşünmüyorum.

Diğer taraftan QT'nin bu kullandığı "replace" özelliği tamamen statik durum eylemidir. Arka planda herhangi bir yapay(VFPTABLE taklidi) mekanizma gerçeklemez.

C++'ın standardı vardır. İlk standart ISO/IEC 14882:1998 adıyla 1998 yılında yayınlanmıştır. Ayrıca bu standardın düzenlemeleri 2003 yılında tamamlanmış ve ISO/IEC 14882:2003 olarak yayınlanmıştır. Şuan ise C++0x olarak bilinen ve technical reportları yayınlanmış standart üzerinde çalışmalar devam etmektedir. Ve "ben Standart C++'ı destekliyorum" diyen her derleyici ile de standarda uygun yazdığınız kodu derlersiniz. (export anahtar kelimesi gibi istisnalar dışında. Bildiğim kadarıyla bu özelliği implemente eden sadece Comeau derleyicisi var. Ama son durum nedir pek haberim yok.)

Son cümlenize katılıyorum. Aşağıda dönen mekanizamaları bilmek her geliştirici için büyük bir artıdır. Ancak bilmek istemeyen de pek ala hazır yapıları kullanıp işini halledebilir. Örneğin oyun yazacak bir adam gidip daha ziyade bilgisayar grafikleri konusunda bilgisini geliştirebilir yada bilimsel hesaplar yapan bir uygulamanın geliştiricisi kullandığı yapının detaylarını irdelemek yerine daha hızlı sayısal metodlar üzerine araştırma yapabilir. Bu da olarak tercih meselesi.

Katılımınız için ben de teşekkür ederim.

İyi çalışmalar.

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

Yazınızda katılmadığım demeyeyim de, açıklamak gereği duyduğum bir nokta önemli. Diğer kısımları için hemfikir olmasamda, paralel fikirde olduğumu söyleyebilirim.

ISO/IEC 14882:1998, bir C++ standardı tarif etme girişimidir. Maalesef başarılı değildir. Çünkü C++ özellikle ABI bazında sorunlu bir yapıdır, standart olarak. Basitçe, bir fonksiyonun tek ve iki parametreli halleri, sembol olarak nasıl gösterilecektir, bu pek belirli değildir.

Bu standardın çuvallamış olmasının önemli sebeplerinden biri bu. Elbette tek sebep bu değil. bahsettiğiniz gibi bir takım source seviyesi uyumsuzluklarda söz konusu. Sonuç: C++ için -maalesef- bir standartttan bahsetmek pek mümkün değil. ANSI draft olarak bir şeyler yayınladı, bakalım bekliyoruz, bir şeyler çıkacak mı?

Basitçe elinize aldığınız her C derleyicisi ANSI C uyumludur (temelde). Fakat C++ için derleyicilerin hemen hiç biri IEC14882 uyumlu olmaz maalesef.

Her neyse. Defacto standart, yani şu anki güncel haliyle hemen her derleyicinin desteklediği C++ hali zaten hemen her şeye yetecek halde. Fakat, "bunun standardı bu, bu böyle olmalı" diyemiyoruz maalesef.

Alıntıları Göster

quote:

Orijinalden alıntı: Draglino

Ön Not : Ne zaman konu açsam ateşli tartışmalara konu oluyor :D

Benim amacım Bilg. Müh. okuyup, ardından imkanım olursa yurtdışındaki, olmazsa METU-TECH ATOM da Oyun Prog. üzerine master yapmak ve bu işte çalışmak. Amacım C++ temeli atıp, ileride de üzerine eklemek üzerine başlangıcım olmasyıdı. Sonuçta C++ öğrenip, indie game tipi tek başıma oyun yapabileceğimi sanmıyorum çünkü oldukça zor bir iş. Bu yüzden programlamaya giriş noktam olan AS 3.0 a döndüm. Flash oyunlar ile hem AS 3.0 bilgileirmi genişletip hem de oyun programlama işine başlamış olucam. Fakat aynı zamanda C++ ve Direct3D de öğrenmek istiyorum. En azından mantığımı oturttuktan sonra, gerisini zaten öğreneceğime inanıyorum. Fakat konsoldan normale geçiş arasında çok şaşkın kalıyorum işte. Birşey yapamıyorum... Yani ekranı açıyoruz, message loop'u DirectX'e göre düzenliyoruz. Ondan sonra oyunun nasıl bu sisteme OOP şekilde external classlar ile oturtulacağını anlayamıyorum. O kısım gelmiyor yani... Çünkü Direct3D tutoriallerine baktığımda polygon yaptırıyorlar, nokta vb. şeyleri yaptırıyorlar. Sonra doğrudan bitmap yüklemeye falan geçiyorlar ve ben orada kopuyorum resmen. Bana DirectX i kökten aşırı detaylar ile değil, oyun programlamaya gereken kısımlarla öğretecek bir kitap lazım. Çünkü ana yapıyı oturtup, aklımda birşeyler kurabildikten sonra, ben o detayları zaten teker teker öğreniyorum ve böyle gelişiyorum. Ama hangi kitaba baktıysam. 4-5 adet fonksiyon çıkartıp sonra bu fonksiyonların aldığı değerlere yazılabilecek 10-15 değeri tablo şeklinde yapıştırıyorlar. Resmen 4-5 fonksiyona 10-15 sayfa okuyorum resmen ve bu beni çok sıkıyor çünkü bunları doğrudan öğrenmek zorundaymışım gibi istiyorum, aşırı fazlalıktan bunalıyorum ve kitabı kapatıyorum, öğrenemiyorum. Bunu nasıl yeneceğimi ise gerçekten bilmiyorum işte...

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

Eğer oyun yapmak istiyorsan, doğru yer C++ değil. O devir geçti artık.

Bugün oyun hazırlamak için özel uygulamalar, kütüphaneler vs. mevcut.

Fakat, oyun dediğinde işin zor tarafı C++ değil, polygon hesapları, yapay zeka vs. gibi cidden karmaşık konularda değil, karakterleri CGI olarak işlemek, dekorları oluşturmak gibi programlamadan ziyade sanatçılık gerektiren işler olacaktır.

Zamanında olay basitti. Ekrana bir kare koyup işi bitiriyordunuz. Hele sprite vs. tekniklerini kaptıysanız, sizden iyisi yoktu. O zamanların en meşhur oyunlaır olan, Raid over moscow vs. sanatçılıktan ziyade programcı arıyordu. 40-50K RAM içinde çalışacak 6-7 stage oyun yazmak cidden zor işti.

Buügnse, donanımlar öyle güçlendi ve mevcut oyunlar öyle alıp başını gittiler ki, oyun kodu artık bir real-time hayat simülatörü gibi filan bir şey oldu. Bu ise ortaya aslen son derece ağır ama bu amaca yönelik frameworkler ile nispeten kolaylaşan yazılımcılık durumuna karşın çok çok daha karmaşık sanatçılık gereğini ortaya koyuyor. İşin %90'ı sanatçılık, stüdyo çalışması. Geri kalanı ise kodlama oldu artık.

Sen okulunu bitirene kadar, büyük ihtimalle, oyun üretne firmalarda çalışan bir bilgisayar mühendisi bile kalmayabilir.

Basitçe şunu bir incele: Massive..

http://www.massivesoftware.com/

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

Ha, birde şöyle bir durum var.

Eğer niyetin buysa, o zaman QT'yi filan boş ver. Daha önce söylediğim gibi kendi event loop'unu kurup doğrudan ekrana çizerek bir şeyler yapmaya çalış. Bu amacına yönelik olarak sana daha fazla şey kazandırır.

Alıntıları Göster

quote:

Orijinalden alıntı: Guest-BF8E9B238

@skoylu
Yazdıkların benim bile içimi kararttı. Arkadaş artık bu diyarlardan çekip gitmiştir.

Gerçektende artık bir oyun projesinde programcı ihtiyacının eskisi kadar olmaması doğru bir tespit. Mesela elinizin altında şöyle bir oyun motoru varsa zaten kodlamanın büyük kısmı halledilmiş demektir.
http://www.dailymotion.com/video/xat83i_cryengine-3-trailer_videogames

Ama bence oyunlardaki yapay zeka konusunda alınacak daha çok yol var. Yani bu konuda çalışma yapılabilir.

Peki bana, programlama adına daha emekleme döneminde olan, şu anki algoritma ve donanımla gerçeklenmesinin zor olduğu ve daha kat edilecek yolu olan problemler varsa aklınızda bahsedermisiniz.
Benim aklımda yapay zeka ve görüntü işleme var. Bu ikisi hakkında aklıma bazen çılgınca fikirler gelebiliyor.

Alıntıları Göster

quote:

1- Bu açtığın konudan programlama hakkında bilgin olmadığı anlaşılıyor. Kodlama bilmeyen ama biz böyle bir işe kalkışıyoruz diyen kimseyle,
2- Sitesine başka bir oyun motorundan görüntüler koyup bakın bunu biz yaptık diyenle,
3- Daha işin başındayken 200 dolar verip oyun motoru satın alanla,
4- Kariyer bölümü açıp çalıştıracağı elemanların ücretini ne ile ödeyeceğini düşünmeyenle,
5- Yapacağı motorun önce gui tasarımını yapıp, programlama öğrendikten içini dolduracağını düşünenle,
(ve daha bir sürü sebep) dalga geçilmezde ne yapılır sen söyle.

http://forum.donanimhaber.com/m_40401620/tm.htm

quote:

Orijinalden alıntı: skoylu

Burada temel bir yanılgı sözkonusu. Buda aslında, olayın tarihini bilmemekten kaynaklanıyor.

Birileri bir şeyler icat ediyor, adına bilgisayar deniyor. Birileri onun için kodlar vs. yazıp geliyor. Bu sürecede birileri sonradan dahil olmaya çalışıyor.

Bu mekanizmada ters olan şey şu. O kod yazan vs. birileri kendi bildiklerinin herkesçe bilindiğini farzediyor.

İşin daha kötü tarafı ise, birilerinin belli bir temel bilgi birikimi olmadan bu işlerin kotarılabileceğini sanmaları.

Kısaca, önce en temel konuları öğrenmek gerekiyor. Zor mu, hayır. Ama bunları bilmek gerekiyor. O yüzden tavsiyem, olaya en temelden başlamanız. Gidin C öğrenin. Bu alet ne iştir, ne iş yapar, nasıl yapar bunları öğrenin. Arkası çorap söküğü gibi gelir.

Fakat nedense herkesin aklındaki günü kurtarmak. "Amanda C ile uğraşılırmı hiç.. Ne güzel C# var yahu..." gibi triplere muhatap oluyoruz. Sonuçta insanların maalesef aynı yerde dönüp durduklarını görüyoruz. Olay basit. İşin temelini öğrenmeden, özetiyle hangi seviyeye varabilirsiniz?

Geçenlerde burada bir inci sözlük saldırısı oldu. İnci sözlük ne iştir? Biri 3-5 satır bir şey anlatırsa, "özet geç lan ...." denen ve seviyeyi yükseltmeye çalışana küfür edilen bir yerdir orası. Ama görüyoruz ki, her yer aslında öyle. Birisi seviyeyi yükseltmeye çalışır, işin detaylarına dikkat çekerse "Özet geç lan..." ve "Seviyeyi yükseltme i..." tepkisini alıyor sürekli.

Bu meselede de, öyle aslında. İşin alt detaylarını öğrenmeniz gerekiyor. Bundan kaçtıkça, şu olmaya devam edecek:

quote: 1- Bu açtığın konudan programlama hakkında bilgin olmadığı anlaşılıyor. Kodlama bilmeyen ama biz böyle bir işe kalkışıyoruz diyen kimseyle, 2- Sitesine başka bir oyun motorundan görüntüler koyup bakın bunu biz yaptık diyenle, 3- Daha işin başındayken 200 dolar verip oyun motoru satın alanla, 4- Kariyer bölümü açıp çalıştıracağı elemanların ücretini ne ile ödeyeceğini düşünmeyenle, 5- Yapacağı motorun önce gui tasarımını yapıp, programlama öğrendikten içini dolduracağını düşünenle, (ve daha bir sürü sebep) dalga geçilmezde ne yapılır sen söyle. http://forum.donanimhaber.com/m_40401620/tm.htm

Herneyse, ben gidip kendi işime bakayım, neyime benim herşeyi bilen adamların olduğu yerde laf etmek?

Alıntıları Göster

quote:

Orijinalden alıntı: Guest-BF8E9B238

Sevgili skoylu üstadım;
Şu son mesajındakileri ne için ve kime yazdığını, benim başka bir konudaki yazımdan niçin alıntı yaptığını ve altında niçin iğneleyici bir laf koyduğunu inanki hiç anlamış değilim. Bir yanlış anlama veya anlatma varsa lütfen söylede bilelim.

Alıntıları Göster

quote:

Orijinalden alıntı: skoylu

Eğer oyun yapmak istiyorsan, doğru yer C++ değil. O devir geçti artık.

Bugün oyun hazırlamak için özel uygulamalar, kütüphaneler vs. mevcut.

Fakat, oyun dediğinde işin zor tarafı C++ değil, polygon hesapları, yapay zeka vs. gibi cidden karmaşık konularda değil, karakterleri CGI olarak işlemek, dekorları oluşturmak gibi programlamadan ziyade sanatçılık gerektiren işler olacaktır.

Zamanında olay basitti. Ekrana bir kare koyup işi bitiriyordunuz. Hele sprite vs. tekniklerini kaptıysanız, sizden iyisi yoktu. O zamanların en meşhur oyunlaır olan, Raid over moscow vs. sanatçılıktan ziyade programcı arıyordu. 40-50K RAM içinde çalışacak 6-7 stage oyun yazmak cidden zor işti.

Buügnse, donanımlar öyle güçlendi ve mevcut oyunlar öyle alıp başını gittiler ki, oyun kodu artık bir real-time hayat simülatörü gibi filan bir şey oldu. Bu ise ortaya aslen son derece ağır ama bu amaca yönelik frameworkler ile nispeten kolaylaşan yazılımcılık durumuna karşın çok çok daha karmaşık sanatçılık gereğini ortaya koyuyor. İşin %90'ı sanatçılık, stüdyo çalışması. Geri kalanı ise kodlama oldu artık.

Sen okulunu bitirene kadar, büyük ihtimalle, oyun üreten firmalarda çalışan bir bilgisayar mühendisi bile kalmayabilir.

Basitçe şunu bir incele: Massive..

http://www.massivesoftware.com/