tr-demoscene
the scene => web linkleri => diğer projeler... => Konuyu başlatan: deneme - 02.07.2008 18:11:08
-
Selam,
SDL kütüphanesinin yapılarına,fonksiyonlarına Java'dan ulaşılmasını sağlayan bir kütüphane yazmayı planlıyorum.
şimdilik "SDL_video.h" ve "SDL_image.h" başlık dosyasına ait fonksiyonları ve yapıları yazmaktayım. Tek kişi olarak bu projeyi yürütmem zor görünüyor.
Ancak http://sdljava.sourceforge.net/ kütüphanesi mevcut diyeceksiniz.
NativeSDL'nin sdljava'dan farkı, sdljava'nın 2005 yılından itibaren artık güncellenmediği ve geliştirilmediğidir. SDL kütüphanesi sürekli güncellenmektedir. Java,C ve JNI'de deneyim sahibi olanlar projeye katılabilir.
http://sourceforge.net/projects/nativesdl/
Sevgiler
-
Java hakim olmadığım bir dil. Bu yüzden bu projeye istesem de destek veremem. Ancak aklıma takılan ilk soru SDL'in Java'nın built-in grafik fonksiyonlarına göre ne avantajı olduğu? Bu soruyu gerçekten bilmediğim için soruyorum, yoksa projenin gerekliliğini sorgulamıyorum.
SDL'in ek libraryleri onun asıl gücünü ortaya koyar ancak sanırım her birini tek tek port etmek gerekecektir. Kısacası SDL'in coreunu port etsek de TTF, müzik v.b. extensionlarını kullanamayacağız. Eğer amaç SDL tabanlı geliştirilmiş projeleri kolayca Java'ya port etmekse SDL core'u bu konuda yeterli olmayabilir düşüncesindeyim. Yani SDL ve sıkça kullanılan librarylerinin tamamını port etmek gerekiyor gibi gözüküyor. Projenin ulaşması hedeflenen nokta bu mu?
-
Aslında SDL'nin, Java'nın built-in grafik fonksiyonlarına ne gibi bir fazlalığı ya da eksikliği olduğunu araştırmadım.
Core SDL kütüphanesinin ve ek kütüphanelerinin(SDL_mixer,SDL_net vb.) ve sdljava'nın desktelemediği kütüphanelerin eklenmesi ile birlikte çözüm sunmayı planlıyorum.
http://sdljava.sourceforge.net/features.html sdljava'nin desteklemediği kütüphanelerinden birkaçı SDL_thread ve SDL_net kütüphaneleri.
Projenin bir sonraki aşaması SDL kütüphanesi ile yazılmış oyunların NativeSDL'ye port edilmesi.
Proje deskek alırsa ilerleyecektir. Destek alma ihtimali düşük olursa projeyi bitirmem zor görünüyor.
Not: Aslında NativeSDL kütüphanesine başlamamın sebebi sdljava'da YUV desteğinin olmaması idi. FFmpeg(NativeFFmpeg) kütüphanesini tasarlıyordum o zamanlar ekranda FFmpeg kütüphanesi ile video çizimlerini gerçekleştirmek için NativeSDL kütüphanesini yazmaya başlamıştım. NativeFFmpeg'de proje göründüğü gibi gitmeyince NativeFFmpeg rafa kaldırıldı. NativeSDL ile ilerliyorum şu an.(NativeFFmpeg, FFmpeg kütüphanesinin Java'dan fonksiyonlarına ve yapılarına ulaşılması)
Sevgiler
-
Sana başarılar diliyorum. Umarım projen başka "Native" prefixli projelere vesile olmaz da muaffak olursun. Özellikle sdl_mixer gibi libraryler epey bir çaba ister gibi geldi bana. Java'dan hep uzak durmuş biri olarak sadece iyi dileklerde bulunabiliyorum.
-
skate hakkaten biz scener tayfasının yıldızı bir türlü barışamadı şu java ile. bildiğim tek javacı scener tesla'dır. ama java ona da 7d5'te bi kazık atmıştı. bkz javabird (http://pouet.net/prod.php?which=19217)
-
Java Bird'i download ettim ancak Native kütüphaneler kullanılmamış. Java Bird'in kaynak koduna ulaşmamız mümkün mü?
Native kütüphanelerden bir tanesi olan, lwjgl kütüphanesi ile yazılmış birkaç projeyi sizlerle paylaşmak istiyorum:
http://lwjgl.org/
http://lwjgl.org/projects.php
@skate
teşekkürler.
-
kaynak kodlar bende yok. tesla'da vardır herhalde. ona bu isteğini iletirim.
bu arada başka bir java projemiz bir mobile demo idi (code yine tesla) : wasted (http://pouet.net/prod.php?which=24215)
Java Bird'i download ettim ancak Native kütüphaneler kullanılmamış. Java Bird'in kaynak koduna ulaşmamız mümkün mü?
-
kaynak kodlar bende yok. tesla'da vardır herhalde. ona bu isteğini iletirim. bu arada başka bir java projemiz bir mobile demo idi (code yine tesla)
şimdilik emulatör kurulu değil sistemde bu sebeple jar dosyasını download etmeme rağmen çalıştıramadım. video dosyasını(*.mov) maalesef download yapamıyoruz.
Video dosyası(*.mov) siteden kaldırılmış mı? http://ftp://www.untergrund.net/users/nightshift/releases/wild_compo/20060304103811_wasted.MOV
Not:En kısa zamanda emulatör yükleyip demo'ya bakacağım.
Hmm, private system diyor sadece üyeler mi download yapabiliyor videoları?
Sevgiler
-
@deneme: Foruma hosgeldin. Oncelikle biraz problemli bir nickname secmissin. Cok gecici bir goruntusu var :) Neyse sen bilirsin
Projenin form faktoru ile ilgili Skate'in sorguladigi noktalara ben de takilmadan edemiyorum. Sonucta zevk olsun diye veya sirf ogrenmek amacli yapmak isteyebilirsin elbette ve buna scene kulturunde de buyuk saygi duyulur zaten. Fakat pratik anlamda cok faydali bir fikirmis gibi gorunmuyor. Yaniliyor olabilirim tabii, ama Open source bir projeye developer attract edebilmek icin projenin iyi bir "faydalilik hikayesi" olmasi gerekir (belki de zaten open source projelerde deneyimlisindir ve bunlari biliyorsundur ve ben kafani utuluyorumdur :) o durumda kusura bakma)
Java zaten platformdan bagimsiz bir ortam ve cok iyi bilmemekle beraber eminim ki kendi kutuphanelerinde SDL'in yapabildigi hersey vardir. SDL Native dilleri kullananlar icin platform bagimsizlik saglamaya calisan baska bir kutuphane. Onu Java classlari ile wrap etmek nasil bir "avantaj" getiriyor onu goremiyorum. Eger ihtiyacin olan tek sey YUV destegi ise ihtimalen ilgili bir Java classini alip ondan kendi YUV destekli class'ini inherit edip implement etsen daha hizli bir cozum olabilir gibi geliyor bana. Ayrica native sdl arayuzlerini javada wrap etmenin mevcut SDL yazilimlarinin Javaya port edilmesini nasil kolaylastiracagini da tam goremiyorum. Sonucta o yazilimlar C/C++ ile yazilmis olacak. Syntax benzese bile yine de bir ton fark var gidip elle degistirilmesi gereken, arti komple memory management modeli farkli.
Dedigim gibi komple yaniliyor olabilirim ama umarim bu yazdiklarimi kendi kendine cevaplarken, ya "dogru ya boyle biseye hakkaten gerek yok", ya da "hayir ama falanca konfigurasyonda cok avantajli" gibi bir sonuca varirsin. Iki sonuc da isine yarayacaktir :)
Kolay gelsin
-
@nightlord:
Internette dolaşırken, SDL kütüphanesinin hem yapısı olsun hem de yan projeleri olsun araştırma yapıyordum. SDL.NET kütüphanesi ile karşılaşmıştım. SDL'nin, .Net binding kütüphanesi.(http://cs-sdl.sourceforge.net/index.php/Main_Page)
Gerçekten, "nightlord" gibi düşünerek içimden şöyle demiştim: "C/C++ ile yazılacak bir projeye neden C# diline gerek duyulsun? Hem de C# dili Java'ya nazaran platforma daha bağımlı ve her ne kadar Linux için mono projesi devam etsede" şeklinde düşünmüştüm. SDL.Net binding yazarak libSDL'yi platforma bağımlı hale getiriliyordu.(win32 için)
sdljava için projelerin pek tutulmadığını gördüm.(SDL.Net ile yazılan projelerin listesi için http://cs-sdl.sourceforge.net/index.php/Projects_using_SDL.NET) Gerçekten, Ivan Ganza'ya(sdljava'nın yazarına) birkaç kere mail gönderdim(sdljava desteklemeye devam edecek mi?) ancak cevap alamadım.
ıstatistiklere bakarak belki bir sonuca varabileceğimizi düşünüyorum: SDL.Net için: http://sourceforge.net/project/showfiles.php?group_id=52340 Proje başladığından itibaren: Dosyalar 53255 kere download yapılmış sdljava için: http://sourceforge.net/project/showfiles.php?group_id=124821 Proje başladığından itibaren: Dosyalar 12042 kere download yapılmış
Bu istatistiklere baktıktan sonra Birkaç sonuç beliriyor aklımda: "1) Java için SDL wrapper kütüphanesine gerek yoktur çünkü Java'nın kütüphaneleri yeterlidir. Bu sebeple download rakamları azdır ?" "2) SDL.NET binding'e gerek vardır çünkü .Net kütüphaneleri yetersizdir. ?" (Burada gerçekten, .Net ile ilgilenen arkadaşlarımızdan düşüncelerini öğrenmek istiyorum SDL.NET hakkında)
Nightlord, iki düşünce arasında kaldım ancak düşüncelerini öğrenmek ile belki de doğru seçimi bulmamı sağlayacaktır. (NativeSDL'ye devam etmek veya etmemek gibi. ıkisi arasında seçim yapacağım ve doğru seçimi yapmalıyım)
Sevgiler
-
http://www.scene.org/file.php?file=%2Fparties%2F2006%2Fnightshift06%2Fwild%2Fwasted.mov&fileinfo
Video dosyası(*.mov) siteden kaldırılmış mı? http://ftp://www.untergrund.net/users/nightshift/releases/wild_compo/20060304103811_wasted.MOV
-
@deneme: .NET'de genellikle GDI/GDI+ kullanılıyor. Ancak eğer daha üst seviye bir proje, örneğin bir oyun v.s. yapılacaksa Direct3D'den faydalanılıyor. Yani benim tahminim Java'nın grafik özelliklerinin .NET'deki karşılığı (tam olarak frameworkün bir parçası olmasa da) GDI+, Java3D'nin karşılığı ise Direct3D. GDI+ ile Java'nın grafik librarysini kıyaslayabilmek için öncelikle Java hakkında bilgi sahibi olmam lazım. Ancak GDI+ ekranda basit bir animasyon göstermek için bile yeterince güçlü değil. Örneğin Java ile ilk uğraştığımda yaptığım örneklerden biri hareket eden ve animasyonlu bir spritedı ve Java Applet olarak gayet temiz, smooth bir biçimde çalışmıştı. Aynısını GDI+'da aynı kalitede yapmak biraz daha zor oluyor. Aslında double buffering birçok problemin önüne geçilebiliyor ancak performans tatmin etmiyor. Hem Java'nın grafik librarysi, hem de GDI+ ekran kartının özelliklerini pek kullanmadığı için bence kıyaslanabilirler ve tahmin ediyorum Java'nın üstünlükleri gözlenebilir. Ancak iş Java3D ve Direct3D'yi kıyaslamaya gelirse Java3D'ye pek şans tanımam. Gerçi bildiğim kadarıyla Java OpenGL kullanabiliyor. Belki Direct3D de kullanılıyordur Windows'a özel olarak. Bu durumda kıyaslamak çok anlamlı olmaz.
-
Java Bird'i download ettim ancak Native kütüphaneler kullanılmamış. Java Bird'in kaynak koduna ulaşmamız mümkün mü?
Tabi mümkün. Java Bird Source (http://unlimited-limits.untergrund.net/tesla/inspire13/files/java_bird/source.zip) . Evet Java Bird'ün her bilgisayarda farklı çalışma gibi bir huyu var. Burda hata %50 benimse %50 Java'nın bence. Eğer Linux'ta çalıştırmayı denediysen oyuna başlarken ekran modunu 1024x768 , 16 bit yapıyor, ama Linux'ta buna izin vermiyor. Kodun o kısmını silip, yerine 1024x786'lik bir pencere açsan yeterli olur. Okuldaki bilgisayarda düzeltilmiş bir hali vardı, onu da bulursam eklerim buraya. Evet Java görüldüğü üzere oldukça cross platform! :) .. Hem o ekran açma kod kısmını java.sun.com'dan almıştım yani kendi uydurmam da değil.
Java Bird'ü yaparken o zaman java 1.4 vardı tamamen onun kütüphanelerini kullanmıştım. Sonra java 1.5 çıkınca en son halini 1.5 ile derlemiştim. Yani ek bir kütüphane kullanmadım.
Bir de bu versiyon değişiklikleri Java'da problem olabiliyor. Mesela Java 1.5 ile "double buffering" yapan applet'lerim. Java 1.6 virtual machine ile artık titreme yapıyor yani "double buffering" yapmaz olmuş. şimdi hepsinin kodunu açıp, Java 1.6 ya göre nası yapılıyormuş ona göre düzenlemek lazım. Java hoş, bi nebze kolay ama böyle de bela işte.
Wasted youtube'da var. keywords: "J2ME Wasted"
-
Ya .Net'te durum Skate'in söylediği gibiyse SDL için bir yer var demektir. Sonuçta SDL kullanımı basit ve 2d işler için gayet yeterli, zaten sanırım 2d için bile direct3d kullanıyor windowsta. Düzgün bir grafik uygulama için Direct3d ile uğraşacağına aynı işi kolayca sdl'de halledebilmek tabi yararlı.
Java'yı pek bilmiyorum ama sdl'sizde bolca oyun vs.si var zaten. Pek faydalı olur mu emin değilim. Yine de bir incelemek lazım tabi, java coder'larının ihtiyaçlarını vs. yi.
-
.NET ile ilgili bir bilgi vereyim, evet C# gibi standart win32 dll'lerinin pointer türü yapılarını "unsafe" olarak nitelendiren diller bir nebze problem yaratıyor ancak C++.NET kullanarak hem .NET'in tüm özelliklerini kullanabilirsiniz, hem de SDL gibi libraryleri zahmetsizce, port etmeden doğrudan kullanabilirsiniz. Yani "SDL'in .NET versiyonu" biraz yanlış bir algı. Ancak SDL'in C# ya da VB.NET'de rahat kullanımı için hazırlanmış bir paket anlam taşıyor. Bu sebepten dolayı artık C++.NET'e geçmiş bulunuyorum zaten. Yeni projelerimde VB.NET ya da C#'ı kullanmamayı tercih ediyorum. Ancak C#'a da sempatim var hala. VB.NET ise .NET platformunda ilk göz ağrımdır. Platformun yapısını hızlıca öğrenmeme faydası olmuştur.
-
ben, sdl'in java uyarlamasının yararlı olacağı görüşündeyim. mesela diyelimki, sdl'e hakimim ama java bilgim yok. elimde sdl ile geliştirilmiş bir projem var. bunu java based bir platforma (mesela mobile ya da applet) aktarmayı isterim açıkçası.
-
.NET icinde 2D ve basit 3D grafik libraryleri var aslinda. Bunlar managed libraryler. GDI/GDI+ native olduklari icin .NET icinde sayilmiyor. .NET'in bahsettigim bu managed grafik API'leri, Windows Presentation Foundation altinda.
http://msdn.microsoft.com/en-us/library/ms752061.aspx
Bunlar Vista ile ciktiklari icin henuz yeniler ve fazla bilinmiyorlar. Ancak kullanimlari msdn sayfasindan gorebileceginiz gibi hayli kolay. Hatta xml tabanli bir dosya tipi olan .xaml dosyalari ile kod bile yazmadan sabit grafikler hazirlanabiliyor. Ustelik de bunlar Hardware accelerated grafik API'leri. Eger .NET kullanip managed code yazacaksaniz, ve olumcul derecede Direct3D performansina ihtiyaciniz yoksa benim tavsiyem WPF kullanmanizdir.
Burada yazilanlardan sonra sanirim deneme arkadasimizin dusundugu projeyi biraz daha iyi anliyorum. Yani Native SDL gibi bir seyin soyle bir avantaji olabilir. Daha onceden C/C++ kullanip SDL ile birseyler yapmis, ardindan .NET veya Java gibi managed bir dile gecmis birisi Native SDL gibi bir api sayesinde WPF gibi yeni bir API ogrenmeden basit 2D isler yapabilir. Sanirim hedeflenen fayda bu ve bu kimi programcilar icin faydali olabilir.
Bu arada dipnot. Ben GDI+'i API tasarimi olarak cok begenirim. Son derece temiz ve yalin bir C++ arayuzu. Keske daha performansli olabilseydi. Ama malesef hw acceleration olmadan, GDI uzerine float koordinat destegi ve anti-aliasing eklenince boyle bir hal olusuyor :)
-
@Nightlord: Verdiğin bilgiler için çok teşekkür ederim. Özellikle henüz development platformumu Vista'ya taşımamış olduğum için haberdar değildim bu yeni grafik librarylerinden.
Bir de sana bir sorum olacak. Bir yerlerde Visual Studio 2008'de artık formlarda olduğu kontrollere de adam gibi opacity propertysi eklenmiş diye okumuştum ve büyük bir hevesle kurdum ama böyle bir özellik göremedim. Acaba Vista only bir özellik falan olabilir mi bu? Bahsettiğim şey üst üste basılan kontrollerin birbiri üzerinde levellı opacity sergilemesi, full transparency ya da form backgroundunu gösterme olayları değil.
-
Windows.Forms konusunda hemen hemen hic bilgim yok. Fakat MSDN forumlarinda su konu basligina rastladim. Sordugun seyin bu oldugundan bile emin degilim gerci (o denli uzagim konuya yani :) )
http://forums.msdn.microsoft.com/zh-CN/vblanguage/thread/bb929012-599f-4a36-bb17-d6eeb88ac56a/
Burada elemanin biri yari seffaf bir Formun ustune yari seffaf bir control basmaya calismis ve olmamis. Bunun uzerine forumda sormus. Oradan bir MS calisani da bunun mumkun olmadigini cunku opacity property'sinin ancak top level formlarda dikkate alindigini soylemis. Yani bir formun komple opacity'si ile oynaniyor ama butun widgetler o formun opacity'sinde ciziliyor galiba.
Bir de yine MSDN'de .NET 3.0 altinda System.Windows.Forms altindaki Control class'inin referans bolumune baktim. Orada da Opacity diye bir property goremedim.
http://msdn.microsoft.com/en-us/library/system.windows.forms.control(VS.85).aspx
PS: Yasasin MSDN ;)
-
ben de bu konuyu saatlerce MSDN'de araştırdım ancak MSDN'deki bazı articlelar Visual Studio 2008 çıkmadan önce yayınlanmış ve forumlarda "bunu artık VS 2008 ile yapabiliyorsunuz" gibi laflar gördüm. Lafın içersinde kontrollere "opacity" propertysi eklendi gibi net birşey de yazmıyordu. Ben de yine bir workaroundla paint, paintbackground v.s. birşeyleri override edip ARGB kullanarak falan hallediliyordur diye düşünmüştüm ancak öyle birşeye de denk gelmedim. şu ortaya laf atıp olayı muallakta bırakan posterların kurbanıyım işte.
-
şu ortaya laf atıp olayı muallakta bırakan posterların kurbanıyım işte.
hahahah :D hakkaten abi ne cok oluyo o olay bu teknoloji forumlarinda arkadas. dedikodu kazani gibi sektor serefsizim :)
-
hahahah :D hakkaten abi ne cok oluyo o olay bu teknoloji forumlarinda arkadas. dedikodu kazani gibi sektor serefsizim :)
microsoft .net'i amiga icin de cikaracakmis. :D
-
@endo: olm gözlerim kan çanağına döndü, google, yahoo, live search engine'i bırakmadım, saatlerdir bakınıyorum. .NET takımındaki MS MVP'lerine telefonla bile ulaşmayı becerdim ama kimse duymamış bu haberi. kafayı yiicem :p