...ve aklima soyle bir problem geldi. Network'de sadece send_net() degil,
receive_net() de olacak, ve block'lanmamak icin receive_net'in ayri bir
thread'de olmasi gerekecek (di mi?).
Sonra da soyle dusundum. Sadece send ve receive yapan bir thread olsa,
bu thread'in send_buffer ve receive_buffer'i olsa... benim loop'um da
soyle olsa...
Simdi, boyle yapinca render process block'lanmiyor.
1. Soru : yukardaki mantik ise yarar mi?
2. Soru : simdi yukardakini yazarken aklima geldi. iki farkli bilgisayarda
frame rate'ler ayni olmayacak. Birinde 1fps, digerinde 100 fps olabilir,
bu durumda bilgisayarin biri saniyede 1 tane oteki 100 tane send yapacak,
bu olmaz. o zaman soyle birsey desek, mesela her client 40 ms'de bir send
yapar (ve her an receive yapar, nasilsa ayri thread).
Simdi, 100 fps olan makina bir bakiyor ki son send'den beri 42 ms gecmis, ve
artik send yapmasi lazim. bu 42 ms icinde de 3 frame cizdik diyelim (rakamlar
atmasyon oldu pardon). obur client'lara 3 frame'lik sure icindeki tum mouse
ve klavye input'larini gonderdik diyelim..
Eee.. simdi varsayalim 10 tane client var. Bizim client'e 40 ms'de bir 9 farkli
client'in mouse/klavye data'si gelirse, ve bizimki bunlari hesaplamaya
kalkarsa sapitir...Diger 9 player icin collision detection? dusunmek istemiyorum.
Gerci belki de olabilir... olur tabii. niye olmasin? hhahahahaa!!!!
Neyse, ikinci soru da su, yukaridaki mantik mantikli midir?
bende girmek istedimde bir basliyamadim su multiplayer olayina Starcraft oynadigim kadariyla bilg. hangi hizda calistigi degil veri gonderme/alma araligi kontrol ediliyor sanirim bu da ping oluyor bir bilg. 1000 FPS de calistirsa oyunu baglantisi dusuk ve ping i yuksek ise buda bir sorun birinde 30 FPS ama ping i cok dusuk ise o daha hizli veri alip gonderecektir ping ine gore ayarlarsak ..
yani ping degerlerine gore ayarlaniyor bu isler sanirim... (tamda bilmiyorum ama boyle olsa gerek)
Kayıt: Jan 25, 2005 Mesajlar: 40 Nereden: istanbul
Tarih: Sat Mar 19, 2005 6:41 pm Mesaj konusu:
tam iyi bilmemekle birlikte directplay kullanmanizi önerebilirim. Cunku hem p2p hem de client-server tarzi uygulamalarda gayet hizli. Ayrica kendi icindeki orneklerle nasil multiplayer oyun yazilir hakkinda bayagi fikir veriyor. Kolay gelsin.
Kayıt: Nov 02, 2002 Mesajlar: 215 Nereden: Istanbool
Tarih: Sat Mar 19, 2005 7:49 pm Mesaj konusu:
Konunun ping ile alakasi yok. Iki bilgisayarin birbirine cross cable ile baglandigini varsayin. Ikincisi, render islemi cok basit, yani frame rate'i CPU belirliyor, yani bottleneck CPU. Baska, dedicated server olmayacak. Yani uc player varsa, 3 tane pc ve uc tane process var. Oyunu ilk acan kendi capinda server olabilir, ama butun islemleri ona yaptiramayiz (bottleneck : cpu).
Directplay'in getirecegi ekstra yok, cunku network kodu zaten var.
...ve aklima soyle bir problem geldi. Network'de sadece send_net() degil,
receive_net() de olacak, ve block'lanmamak icin receive_net'in ayri bir
thread'de olmasi gerekecek (di mi?).
Bloklanmamanın tek yolu, network işlemlerini ayrı thread içinde yapmak değil. Non-blocking moda alınmış soketlerle de çalışabilirsin...
Kayıt: Nov 02, 2002 Mesajlar: 215 Nereden: Istanbool
Tarih: Sat Mar 19, 2005 8:24 pm Mesaj konusu:
Socket non-blocking olursa, loop'un icinde kontrol ettirmem gerekecek ama, ilk sey'de yazdiim gibi...Varsayalim her paket 1024 byte olacak, her frame 1024 bayt gelmis mi gelmemis mi kontrol ettirmek istemiyorum aslinda. Aslinda ettirilebilir de...
Ama diger thread'den 'merhaba, 1024 byte'lik paketiniz hazirdir, buyrun islenmis halde size sunuyorum' gibi bir mesaj gelmesi daha $Ik sanki. yani loop'un icinde bir wait olmasi (0 delay ile).
uzunlar: gonderdigin link cok guzel, sanirim site'nin muptelasi olucam
Socket non-blocking olursa, loop'un icinde kontrol ettirmem gerekecek ama, ilk sey'de yazdiim gibi...Varsayalim her paket 1024 byte olacak, her frame 1024 bayt gelmis mi gelmemis mi kontrol ettirmek istemiyorum aslinda. Aslinda ettirilebilir de...
Ama diger thread'den 'merhaba, 1024 byte'lik paketiniz hazirdir, buyrun islenmis halde size sunuyorum' gibi bir mesaj gelmesi daha $Ik sanki. yani loop'un icinde bir wait olmasi (0 delay ile).
1024 byte'lık hazır paket mesajlar halinde bir haberleşme sistemi kurmak istiyorsan, TCP yerine UDP paketleriyle haberleşme alternatifini düşünebilirsin.
Kayıt: Nov 02, 2002 Mesajlar: 215 Nereden: Istanbool
Tarih: Sun Mar 20, 2005 2:21 am Mesaj konusu:
fixed paket size dusunmedim, her paketin ilk iki byte'i magic word, sonraki iki byte'da paketin uzunlugu, vb.
ama fixed size olsa bile udp bana nasil bir avantaj saglayacak ki?
Bir de... soyle seyler kolay : player A, player B'nin gorus alanina girer. B, A'yi gorur, A B'yi gormez. A'ya 'bir oyuncu sizi gordu' diye bir warning basilacak. B'den A'ya warning bas diye bi command gonderdik, tamam.
Benim derdim su, Player A bir missile launch etti. missile'yi goren B ve C player'leri var. Missile C'ye dogru geliyor ve C kacmaya basliyor. C ve missile'nin pozisyonlarinin her 3 client'de de ayni olmasi lazim.
Missile ve C'nin pozisyonlarini bir server'e hesaplat, ordadan x,y,z olarak iste desek, olmaz.
sadece missile velocity'yi ve start x,y,z'yi 3 client'e de ayni anda duyursak ve kalanlari kendilerinin hesaplamalarini istesek, olur. Ama bu sefer de soyle bir sey cikiyor: missile-C degil de B-C collision soz konusu ise, B ve C'nin velocity'leri sabit olmadigi icin, her uc client'in de A, B ve C'nin localtion'larini surekli olarak diger client'lardan almalari gerekiyor. Daha dogrusu, her client'in 40 ms'de bir kendi location'unu diger iki client'e gondermesi gerekiyor.... Bir client'in de time server gibi calisip, diger client'lara o andaki time-slot'u bildirmesi gerekiyor ('su anda bilmemkacinci tick'teyiz' gibi, bir tick = 40 ms).
Dusundum de biraz, galiba genel bir 'soyle soyle yapilacak boyle boyle yapilacak' kurali yok. Duruma gore algoritma gelistirmek lazim.
Bi de hep 40 ms yazmisim, aliskanlik (40 ms -> 25 fps = pal)
Kayıt: Jan 29, 2003 Mesajlar: 118 Nereden: Eskişehir
Tarih: Sun Mar 20, 2005 4:14 am Mesaj konusu:
bu arada multiplayer sözü geçmişken RakNet den bahsetmemek olmazdı. kendisi sırf multiplayer oyunlarda ağ iletişimini sağlamak için yazılmış ücretsiz bir kütüphane.
www.rakkarsoft.com
Kayıt: Apr 24, 2003 Mesajlar: 287 Nereden: İstanbul
Tarih: Mon Mar 21, 2005 11:22 am Mesaj konusu:
gerçi çoğunu biliyorsundur, ama yine de hatırlatma babından yazayım diye şeyettim..
1. UDP, TCP ye göre daha lightweight olması hasebiyle daha hızlı çalışıyor. bu sebeple bildiğim kadarıyla genelde oyunlarda UDP tercih ediliyo. (ama bu durumda session olayını kendin implement etmek zorunda kalıyosun)
bir de TCP de paketlerin bütün geleceği garanti oluyo, UDP de parçalanabiliyor falan filan olayları da var galiba. ama bundan çok emin değilim. (unuttum detayları..)
2. Hesaplamaları tek kişinin yapması lazım ve diğerlerinin sadece sonuçları alması lazım. aksi takdirde sürekli sync ihtiyacı doğar. yuvarlama hataları falan yüzünden. eğer server client mantığı olmayacaksa, hesabı yapacak kişi o olayla en ilgili kişi olabilir. Mesela, C bir missile attığı zaman, bunun her frame de konumunu hesaplayıp herkeslere göndermek C nin görevi olur. Diğerleri iki konum arasında interpolasyon falan yapar yada bağlantı hızlı ise ve sorgu aralığı küçükse direk gelen konumu kullanır diyebiliriz.
3. herkes herkeslere konum gönderirse, networkde ~n^2 tane paket gider. ama bir tane serverın olursa, herkes kendi konumunu ona gönderirse, sonra isteyenler de bana deltaX uzaklığındakilerin konumunu gönder gibi komutlarla server a bağlanırsa daha güzel olabilir. Ama server -client yapmayacaksan, herhangi birisinin bu işi üstlenebileceği bir sistem geliştirmek de mantıklı olabilir. (kasmak istersen oylama falan filan işleri olabilir, yada en küçük ip si falan olan direk location server gibi bişey olabilir.) yada client sayısı azsa sürekli broadcast etmek de performansı çok etkilemeyebilir. bilemiyorum. duruma göre değişir galiba..
4. evet, genel bir algoritma yok, ama yine de bazı noktalara dikkat etmek gerekiyo. mesela, network yavaşsa, mümkünce time/space complexity olayının time tarafını uzatıp space i azaltmak gerekiyo.(işi CPU ya yıkmak) ama network hızlı CPU yavaşsa, (mesela gigabit ethernet + pentium 100) bu durumda CPU zaten networkden gelen tüm byteleri işleyebilecek kadar hızlı olmayabilir bile. bu durumda hiç bir işlem yapmadan direk veriyi göndermek lazım..
5. birde network hızına göre 40ms artıp azalabilir. eğer network çok yavaşsa, bu durumda,ilk paketin cevabını almadan diğerini gönderiyo olaibliriz, yada çok hızlı ise boşu boşuna bandwidth ziyan ediyo olabiliriz falan..
Biryerlerden edinebilmeyi başarabilirsen "Advanced 3d game programming with direct x 9" isimli kitaptaki "Chapter 07 - UDP networking" bölümünü okumanı şiddetle tavsiye ederim, gerçekten çok öğretici.. kaynağa ulaşamassan, bana Ö.M ile haber ver..
ayrıca, quake2 network kodu da çok çok başarılı, anlamak için -biraz- kasmak gerekiyor ama sonuçta çok verimli işleyen süper bi network kodu..
Bu forumda yeni konular açamazsınız Bu forumdaki mesajlara cevap veremezsiniz Bu forumdaki mesajlarınızı değiştiremezsiniz Bu forumdaki mesajlarınızı silemezsiniz Bu forumdaki anketlerde oy kullanamazsınız