Ranmus

To napisz czemu Ci się lepiej pracuje, bo ja jakoś nie widzę nic w Dev-C++ co by było wygodniejsze niż w Visualu. ps. http://gdk.thegamecreators.com/ <- Visual C++ 2008 + Dark GDK za darmo i można się zabrać za tworzenie gier. ps2. http://go.microsoft.com/?linkid=7773855

Nie jest zajefajny. Dev C++ to stare, nierozwijane środowisko, któremu brakuje wielu funkcji. Jeżeli kod nie ma być wieloplatformowy, to tylko i wyłącznie Visual C++ (w którym prawie wszystkie profesjonalne gry pod windowsa są kompilowane). W Visualu pisze się nie dość że łatwiej to i przyjemniej. Poza tym masz jeszcze dostęp do biblioteki MSDN wprost z edytora.

Nie trzeba do tego wersji pro. Wystarczy, że za cząsteczki będą służyły obiekty.

Na allegro, to się kupuje hosting od firmy krzaka, która nie ma żadnych gwarancji na jakość usług. Już wolałbym darmowy pewny hosting niż płatny, który po paru miesiącach zwinie interes. Tak trudno wejść na webhostingtalk.pl i poczytać opinie co do firm niż potem płakać, że zostaliście oszukani?

Asus już nie jest taki jak kiedyś. Teraz trzeba patrzeć jak sprawuje się konkretny typ płyty głównej, poza tym zawsze można trafić na jakiś feler. Płytka, którą wymieniłeś jest jak ok i do tego atrakcyjna cenowo. Jeżeli zaś miałbym polegać tylko i wyłącznie na marce, to wybrałbym DFI. :) UPDATE: Na tej płycie da się także kręcić normalnie procki. Co prawda nie tak ekstremalnie, ale jak jest w zestawie e6750 to i tak za dużo nie musi kręcić, a o te 1ghz spokojnie by podbił. Tylko on zapewne nie będzie kręcił.

Za tą cenę to syf (pomijam już fakt, że w tym sklepie nic bym nie kupił, bo witryna biedna i pierwszy raz o nich słyszę). Najgorzej w tej cenie będzie z monitorem bo i tak musi być na matrycy TN, więc można ciąć na nim koszta. :) Obczaj ten zestawik i dodaj do ceny z konfiguratora po prawej dodatkowe 50zł za złożenie (5 dni roboczych - 30zł) oraz testowanie działania pod windowsem xp (20 zł). Dzięki temu masz pewny sprzęt, a przy tym znacznie wydajniejszy od tego co podałeś w linku (tutaj masz trochę silniejszy proc, lepsze ramy oraz znacznie lepszą kartę grafiki!) i to za mniejszą cenę. PS. Nie wiem czemu, ale po kliknięciu w ten link i zaimportowaniu zestawu jak potem przyjrzysz się konfiguracji to tam jest cena 3889zł zamiast 3489zł, jest to spowodowane tym, że przy ramach, procku itd. pojawia się liczba sztuk 2. Popoprawiaj w formularzach wszystko na 1, a potem kliknij na guzik "przelicz". PS 2. A skopiuję zestaw tutaj: Procesor - Intel Core 2 Duo E6750 2.66 GHz 4MB cache s. 775 Box - 575,00 zł Płyta główna - Gigabyte GA-P31-DS3L IP31 s775 - 225,00 zł Pamięć RAM - Patriot DDR2 Dual Chanel 2GB 800 - 149,00 zł Karta graficzna - Gigabyte 8800GT 512MB 256bit TV/2xDVI PCI-e - 985,00 zł Dysk Twardy - Seagate ST3250310AS 250GB sATA II 8MB - 215,00 zł Obudowa - XPower 093 Silver-Black bez zasilacza - 99,00 zł Zasilacz - Chieftec GPS-450AA-101A ATX 450 Watt - 159,00 zł Napęd lub nagrywarka - LiteOn DVDRW+- H-20A4P OEM Black - 79,00 zł Monitor - Samsung 20 SM 205BW silver - 899,00 zł Klawiatura - Logitech 967738-0100 OEM DeLuxe 250 Keyboard USB Black - 35,00 zł Myszka - A4TECH SWOP-3D-4 Opto 013 Black - 19,00 zł razem brutto: 3439,00 zł + 50zl zlozenie i testowanie pod xp Suma: 3489zł

Chciałbym zauważyć, że Crysisa na full detalach z full fps nie pociągnie aktualnie żadna karta graficzna, więc nie ma się czym przejmować. ;) http://pclab.pl/zdjecia/artykuly/stolarczy...s-1280-aa4x.png Strach pomyśleć jak to chodzi pod panoramą w rozdziałce typu 1680x1050. :|

Sprawowałby się całkiem dobrze, ale nie oczekuj, że będziesz grał w nowe gry na maksymalnych detalach, conajwyżej średnie.

Chciałbym zauważyć, że znalezieni graficy, programiści i muzycy spokojnie się obejdą bez Ciebie. Co chcesz robić w tej grupie?

Nie wiem w sumie co chcesz osiągnąć. Jaką strukturę sieciową ma twoja gra? Układ gwiaździsty czyli serwer, do którego podłączeni są klienci? Jeśli tak, to wszystkie dane z klienta muszą przechodzić przez serwer. Co KLIENT trzyma pod zmienną global.clienttcp? Daj większy kawałek kodu, to co jest przed case lub zdebuguj czy w ogóle case jest wywoływane. Umiesz korzystać z debuggera GM? W SERVER step zamień: case 10: pocisk_x = readshort(); na case 10: show_debug_message( 'wykonywanie case 10' ); pocisk_x = readshort(); Następnie odpal serwer w trybie debuggerskim (czerwony trójkąt) i wybierz z menu TOOLS -> SHOW MESSAGES. Jeżeli nie pojawi się tam "wykonywanie case 10", to znaczy że coś jest nie tak z odczytem pakietu. Jeżeli się pojawi, to zaczniemy myśleć dalej. Pamiętaj by korzystać z debuggera GMa bo to strasznie ułatwia wychwytywanie błędów. Btw. zapisywanie image_speed jako short jest fatalnym pomysłem, ponieważ image_speed to ułamek od 0 do 1, a short to liczba całkowita 0-65535. Zamień to na writedouble i readdouble.

Jeżeli ma to być w javie, to nie lepiej poszukać jakiegoś forum dedykowanemu temu językowi? Tutaj większość zajmuje się GM, a języki programowania, to poboczna sprawa, zwłaszcza java. Przesuwam temat.

Borek, mogłeś dodać jeszcze, że druk będzie profesjonalny, a nie na jakiejś drukarce w domciu. ;)

Najlepiej zacząć tworzenie gier od ... planszowych. Bierzemy karton, brystol czy zwyczajny kawałek papieru i... :P Spytajcie się Borka. On jest mistrz w tworzeniu takich gier. :D

Pardon, rzeczywiście. A tak się zastanawiałem czy u to przypadkiem nie od unsigned, ale z pośpiechu jak patrzyłem na kolumny i przepisywałem liczby, to mi się wiersze pomyliły. ;) Oczywiście masz rację.

Guzik prawda, kompilatorów się już praktycznie nie pisze w assemblerze, bo i po co? Wystarczy, że kod wynikowy będzie w asmie i tyle. Do tego są jeszcze generatory kompilatorów, składni, lexery i inne dupery... Jednak prawda jest taka, że jak nie jesteś PRO w programowaniu, to po prostu zapomnij....

Oj tam głupie pierdzielenie. Kiedyś stworzymy pogromcę WoWa. ;)

Yyyyy eee noooo... Akurat to są podstawy działania 39dll, które Borek doskonale rozumie. Musisz jeszcze się nauczyć jak kodować i dekodować pakiety, jak zrobić efektywne przemieszczanie obiektów (dead reckoning itp.), wyliczyć ile pakietów i w jakich odstępach czasu wysyłać, które częściej, które mniej, jak ustalać limity transferu na klienta itd. Niektórzy to nawet prace inżynierskie piszą na ten temat: https://dip.felk.cvut.cz/browse/pdfcache/ha...m1_2006bach.pdf

Prace nad aktualną wersją silnika Almory są już definitywnie zakończone, czy to tak trudno zrozumieć? Jednak nie tyczy się to samej gry, bo kiedyś zapewne wyjdzie odświeżona wersja, może z numerkiem 2, ale nie nastąpi to wcześniej niż przed paroma innymi projektami, a już na pewno nie przed Infernal Warriors...

Nie odświeżaj półtorarocznych tematów. Polecam zaznajomić sie z regulaminem.

Weźcie pod uwagę to, że ja nawet nie sprawdzałem swojego posta, więc prócz błędów rzeczowych są także błędy stylistyczne itd. Bez solidnego przepisania i korekty się nie obejdzie. ;)

Oj Konrad, jemu to za dużo nie wyjaśni. Trzeba wszystko wytłumaczyć od początku... W grach sieciowych jest ten kłopot, że jeżeli na komputerze lokalnym stworzysz jakiś obiekt, to tenże obiekt nie pojawi się automatycznie na innych komputerach podłączonych do twojego. Weźmy jako przykład wystrzelony pocisk na komputerze A - co zrobić by pocisk pojawił się również na komputerze B. Otóż musisz wysłać stosowane dane do drugiego komputera, na podstawie których to zostanie utworzony odpowiedni pocisk, na określonej pozycji, w określonym kierunku i szybkości. Wróćmy teraz do transferu danych pomiędzy komputerami. Jak wysłać odpowiednie zmienne? Otóż dane wysyłane są pakietami czyli w jednym pakiecie mieści się tyle i tyle danych. W pakietach grupowane są zmienne powiązane ze sobą w jakiś sposób i żadne inne! Pakiety nie mogą być zbyt krótkie (w przypadku TCP) lub też zbyt długie. Zbyt krótkie dlatego, że w protokole TCP prócz informacji właściwych, których wysyłasz, narzucane są jeszcze inne dane do synchronizacji itd. czyli im więcej osobnych pakietów, tym więcej danych pobocznych - większe obciążenie łącza - potrzebna jest większa przepustowość. Pakiety danych nie mogą być też zbyt długie, ponieważ jeden pakiet jest odczytywany w całości, więc jeśli w danym pakiecie jest za dużo informacji, to jego odczyt wydłuży się zbytnio w czasie... Jak wysyłać dane? 39dll oferuje wysyłanie tekstu oraz liczb. Oczywście mógłbyś komponować odpowiedni tekst, a potem dekodować na komputerze klienckim, np.: "pocisk|x:10|y:100|dir:340|speed:50". Następnie byś odczytywał kolejne literki itd. uzyskując odpowiednie informacje. Jednak jest to bezsensowne rozwiązanie, gdyż wysyłasz dużo zbędnych danych. Lepiej zapisać tak: "12|10|100|340|50" Od razu lepiej, prawda? A ile znaków zaoszczędziłeś! Pierwsza liczba (12) to będzie zmienna, która symbolizuje co chcesz przekazać drugiemu komputerowi, jaką akcję. W tym celu musisz sam sobie ustalić własną strukturę protokołu, którą następnie będziesz odczytywał. Załóżmy, że pierwsza liczba w pakiecie będzie nas informowała co to za akcja i jakie dane są wysyłane. Załóżmy, że kody będą wyglądać tak: 1 - poruszanie się obiektu. Będą potrzebne zmienne id obiektu, x oraz y. Pakiet będzie wyglądał przykładowo tak: "1|1312|100|100". 2 - tworzenie obiektu. Potrzebne będą dane typ obiektu (jego indeks w GM), x i y. Pakiet będzie wyglądał tak "2|12|100|100". (tworzymy obiekt typu ... o indeksie 12 w pozycji 100,100. 3 - niszczenie obiektu. Potrzebne będą dane id obiektu. "3|13124" Widzisz, musisz stworzyć całą taką strukturę protokołu, gdzie pierwsza liczba to typ komendy, a kolejne to dane dodatkowe, które będziesz zawsze wiedział w jakiej są kolejności, więc nie będziesz miał kłopotu z ich odczytem. Teraz wrócmy do twojego przykładowego skryptu z początku tematu. To powinno Ci nieco rozjaśnić sytuację. Funkcja clearbuffer służy do czyszczenia bufora (przestrzeni) pakietu danych. Przed wysłaniem pakietu zawsze wywołuj tą komendę. Kolejna funkcja, writebyte zapisuję liczbę 2. Oho! To musi być właśnie jakiś identyfikator komendy, która jest wysyłana. Zobaczmy co jeszcze jest zapisywane. ID obiektu, x, y, indeks spritu itd. Czyli 2 symbolizuje w tym przypadku ogólny stan obiektu - uaktualnienie jego danych na komputerze klienckim. Po prostu teraz musisz odczytać te zmienne i jesteś w domu. Tylko jak? Wrócmy do naszego sposobu zapisu: "12|10|100|340|50" Tak naprawdę jest to niewydajny sposób, gdyż musisz parsować ten tekst (zabijesz gmla) a w dodatku wciąż za dużo zajmuje. Pamiętaj, że pakietów wysyłanych w trakcie gry, w czasie jednej sekundy, jest od groma, do tego dodaj wielu graczy i wyjdzie na to, że twoja gra będzie wymagać łącza 5Mbit. :) Jak temu zaradzić? Prosta sprawa, wysyłać dane w formie liczb i to nie dziesiętnych a heksadecymalnych (czyli w systemie szesnastkowym). A czemu tak? Ponieważ komputer operuje właśnie na liczbach w formie szesnastkowej czyli cyfry są takie: 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f. Przykładowe liczby w formie dziesiętnej i szesnastkowej: 7 -> 7 9 - 9 10 - a 12 - c 15 - f 16 - 10 17 - 11 18 - 12 29 - 1d 255 - ff Ty akurat nie musisz znać przelicznika. Musisz tylko wiedzieć, że jeden bajt to liczby od 0 do 255 (0-ff w trybie hex). Teraz jak sobie spojrzysz w oferty usługodawców w internetu, to oni podają szybkość w bitach, podziel tą szybkość na 8 i masz szybkość właśnie w bajtach czyli ile łącze może wysłać bajtów - liczb od 0 do 255. 1Mbit/s to 128Kbit/s czyli 128000 liczb typu bajt (0-255). Okej, możesz tyle danych wysłać, ale co z liczbami większymi. Jak masz np. planszę 4000x4000 i chcesz wysłać x i y, to bajt do określenia liczby nie wystarczy. :( Dlatego też w informatyce ludzie poszli po rozum do głowy i wymyślili parę dodatkowych typów zmiennych. Kliknij w poniższy link: http://www.zive.cz/Files/Obrazky/2004/12/vbnet1902.gif Zwróć uwagę na kolumnę numer 3 (byte, short, int) - prawda że znajome nazwy! Dokładnie takie nazewnictwo masz w funkcjach przez siebie używanych! Zwróć teraz uwagę na kolumnę numer 6 - tam masz napisane ile dany typ zajmuje bajtów, a w kolumnie 7 masz natomiast podany zakres liczby w formie dziesiętnej jaką dany typ może przechowywać. Z powyższej tabelki dowiadujemy się, że bajt to liczba 0-255 zajmująca jednego bajta. Short to liczba 0 - 65535 zajmująca już 2 bajty! Int zajmuje 4 bajty, a double aż 8! Czemu to jest ważne? Ano dlatego, że im więcej bajtów tym.... tak, większe obciążenie łącza. Dlatego Ty sam musisz ustalić do jakiego typu danych użyjesz jakiego formatu, czy byte czy short czy co tam jeszcze. Przykładowo pierwsza liczba w pakiecie, która będzie odzwierciedlała rodzaj pakietu czyli jakie dane wysyłasz / jaka komenda, to może być byte czyli liczba od 0 do 255, bo chyba nie wymyślisz więcej niż 255 rodzajów zdarzeń, prawda? I tyle starczy. Lećmy dalej, x i y? Jeżeli plansza będzie o wielkości maksimum 4000x4000, to już bajt nie starszy, ale nie musisz zaraz stosować int, wystarczy short, ponieważ 4000 mieści się w zakresie 0-65535. Jeżeli zastosowałbyś int, to byłbyś 2 bajty w plecy, a tak to oszczędzisz trochę łącza. Widzisz? Dla każdego rodzaju liczby musisz ustalić jak je wyślesz! Uważaj tylko na liczby ujemne, jeżeli chcesz je stosować, to w tym celu masz w 39dll specjalne funkcje. Np. zamiast writeshort( liczba od 0-65535 ), masz writeushort ( liczba od -32767 do 32767). typy z przedrostkiem "u" to po prostu liczby przesunięte o połowę "w tył", czyli byte: 0-255, a ubyte: -128-127. Wróćmy teraz do twojego skryptu. Jak się przypatrzysz na nazwy funkcji, to już wiesz jak są dane wysyłane, w jakim formacie określone liczby. Tylko nasuwa się pytanie czemu jednak nie w formacie dziesiętnym, lub jakoś bardziej luźnie. Ano z prostej przyczyny, ponieważ między liczbą 2 a 21 jest zasadnicza różnica - długości jednego znaku, dlatego musiałbyś jakoś te liczby rozdzielać i wróciłbyś do punktu wyjscia. Stosując natomiast liczby w formie byte, short itd., zawsze wiesz jaką długość mają te liczby, np. int to liczby od 0000 do ffff - widzisz, zawsze są cztery znaki. Dla komputera jest to łatwiejsze do odczytania a przy okazji jaka oszczędność, bo int w trybi dziesiętnym to parę milionów czyli 2 razy więcej znaków. Wrócmy teraz do naszego zapisu sprzed paru akapitów: "1|1312|100|100" Taki pakiet danych oznacza: przesunięcie obiektu (1), id obiektu (1312), x (100), y (100). Zamiast parsować ten tekst ustalmy inny format danych, za pomocą liczb typu byte, short, short, short. Byte to będzie komenda na wstępie, bo więcej takowych komend niż 255 nie wymyślimy, rpg nie robisz. :) Short dla id obiektu starczy (0-65535), tylko pamiętaj, że to nie to samo co ID obiektu w gm! x i y też będą shortami, bo zakładamy, że te zmienne nie będą ujemne, oraz zawsze mieszczą się w przedziale 0-65535 (plansza jest 4000x4000). Jak będzie wyglądać przykładowy powyższy pakiet danych? Ano tak: 01052000640064 Rozłóżmy to na czynniki pierwsze: byte: 01 (nasza komenda), short: 0520 (id obiektu), short: 0064 (x), short 0064 (y) Przykładowo 1312, to w zapisie hex 520, ale wiemy, że short to 4 znaki, więc jeżeli liczba jest zbyt krótka (o jeden znak), to komputer dodaje 0 od lewej strony. Aby konwertować z dec na hex i hed na dec, możesz użyć windowsowego kalkulatora, widok w trybie zaawansowanym i tam masz przełączniki. W powyższym przypadku oba formaty danych zajmują 4 znaków. Nic nie zaoszczędziliśmy? Pozornie. Weźmy maksymalne liczby (sytuacja hipotetyczna): dec jako tekst z rozdzielnikami: "255|65535|65535|65535" - 21 znaków hex: ffffffffffffff - 14 znaków Widzisz? w drugim przypadku już zaoszczędziliśmy 7 znaków. Podsumowując: 1) W grach sieciowych wysyłasz pakiety danych o ZNANEJ TOBIE STRUKTURZE, którą sam wymyślasz. 2) Do odpowiednich zmiennych dobierasz odpowiednie formy liczb: byte, ubyte, short itd. tak by jak najmniej obciążyć łącze. 3) Pierwsza liczba w każdym pakiecie odpowiadać będzie za rozpoznanie pakietu i z góry ustalasz jaki to ma być typ liczby. Najlepiej by każdy pakiet zaczynał się liczbą typu byte. 4) Odczytywanie pakietu rozpoczynasz od pierwszej liczby (w formie byte), a następnie przepuszczasz przez instrukcję warunkową switch i w zależności od zmiennej, odczytujesz resztę liczby według ZNANEJ CI KOLEJNOŚCI, bo sam zaprojektowałeś dany pakiet. Ostateczny przykład wysyłu np. komendy przesunięcia obiektu na nowe x i y: Komputer A (wysyła): clearbuffer(); // Czyścimy bufor pakietu danych writebyte(1); // Jest to nasz identyfikator pakietu danych writebyte(global.myid); // Zapisujemy id gracza jako liczba byte writeshort(x); // Zapisujemy pozycje X writeshort(y); // Zapisujemy pozycje Y sendmessage(global.clienttcp); // Wysyłamy dane do innego komputera Komputer B (odbiera): pakiet = receivemessage( global.innykomp ); //Pobieramy dane z odpowiedniego połączenia if ( pakiet < 0 ) break; // Jeżeli pakietu nie ma, to przerywamy skrypt akcja = readbyte(); // odczytujemy pierwszą liczbę w formie byte (zapisaną poprzez writebyte) switch( akcja) { case 1: // Oho! Akcja o numerze 1 czyli przesuw obiektu! obiekt = readbyte(); // odczytujemy 2 liczbe xx = readshort(); // odycztujemy kolejne liczby zapisane jako writeshort, więc stosujemy readshort yy = readshort(); break; } Tym sposobem odczytałeś rodzaj pakietu (ustaliliśmy, że 1 to pakiet odpowiadający za przesuw obiektu, który posiada zmienne w odpowiedniej kolejności: byte, short, short) oraz dane i zapisałeś je do zmiennych obiekt, xx i yy. ------------------------------------------ W temacie pytałeś się o direction gracza. Nic prostszego, po prostu przed funkcją sendmessage dopisz funkcję writeshort! Tak, short to 0-65535 a direction w GM może przyjmować ułamki, bo w GM każda zmienna to zmienna typu double. Jednak jeżeli będziesz wysyłał wszystko jako double, to łącze obciążone będzie strasznie, więc polecam byś zaokrąglał direction, wtedy wyjdzie Ci liczb od 0 do 360. W byte się nie zmieści, ale w short już tak. Po prostu dopisz: writeshort( floor( direction ) ); A w odczycie na samym końcu: direction = readshort(); Pamiętaj, że kolejność odczytu danych jak i ich rodzaj są bardzo ważne, bo gdy coś źle zapiszesz, to po prostu inni gracze będą otrzymywali złe dane.

Od biedy wystarczą tagi <center>tutaj treść</center>. Jeśli natomiast strona ma być w XHTML, to w tagu body dopisać atrybut style="text-align: center", a potem warstwa potomna <div style="text-align: left; margin-left: auto; margin-right: auto">tutaj treść</div>. btw. Fajny mangowy styl graficzny. Przypomniały mi się gry z serii Nekketsu cośtam na NESa. :) Tylko zmień tą obleśną czcionkę.

Wośrodkować stronę możesz poprzez html i css. Javascript w tym przypadku jest niepotrzebne.

Zoptymalizuj grę i powinno być dobrze.

Utwórz zmienną adres no-ip