Warsztat.GDCompo!ProjektyMediaArtykułyQ&AForumOferty pracyPobieranie

Opisz napotkaną sytuację, a redakcja niezwłocznie znajdzie rozwiązanie!

wyślij anuluj

Jak należy pisać aktualizację stanu gry

Tekst został importowany z Warsztatowych artykułów. Jego oryginalnym autorem jest Jacek Złydach - TeMPOraL. Jeżeli został importowany poprawnie, usuń ten szablon!

[[Kategoria:C++]] http://temporal.pr0.pl/devblog/download/arts/fixed_step/fixed_step.pdf http://temporal.pr0.pl/devblog/download/arts/fixed_step/fixed_step.docx http://temporal.pr0.pl/devblog/download/arts/fixed_step/fixed_step_src.zip

Tekst dodał:
Jacek Złydach
17.04.2010 14:22

Ostatnia edycja:
Jacek Złydach
17.04.2010 14:22

Kategorie:

Aby edytować tekst, musisz się zalogować.

# Edytuj Porównaj Czas Autor Rozmiar
#1 edytuj 17.04.2010 14:22 Jacek Złydach 667
Zwykły
Do sprawdzenia
Do akceptacji
  • Igor Ławicki (@Solgar) 17 kwietnia 2010 14:55
    Dobrze prawi. Dać mu wódki!
  • marcin (@noxy) 17 kwietnia 2010 16:01
    Przydatne :) zaraz sprawdze jak sie to ma w praktyce ;)
  • Hubert Rutkowski (@Koshmaar) 17 kwietnia 2010 18:57
    bo przez tą zmienną dt to się gry psujom!
  • Maciej Stefańczyk (@maciekslon) 17 kwietnia 2010 19:15
    Strona 4, 3 linia od dołu - jest: 1/60 sekundy. Powinno być: 1/30 sekundy ;P

    Wracam do czytania, może coś się jeszcze znajdzie..
  • Jacek Złydach (@TeMPOraL) 17 kwietnia 2010 22:43
    Koshmaar: psujom się, żebyś wiedział, że się psujom. :P.

    maciek_slon: kthx, poprawione :).
  • Michał Korman (@dynax) 18 kwietnia 2010 17:35
    eh... Kiedy wyrzucę update inputu poza pętle while(accumulator > TIME_STEP) to gra się zawiesza. To znaczy praktycznie nie reaguje na wciskanie klawiszy.
  • benethorpl (@benethorpl) 18 kwietnia 2010 22:54
    @maciek_slon: Strona 5, pierwszy wiersz: 600/30 to 20, nie 30
  • Maciej Stefańczyk (@maciekslon) 19 kwietnia 2010 06:20
    @up To chyba do autora uwaga, nie do mnie ;P
  • benethorpl (@benethorpl) 19 kwietnia 2010 14:11
    w sumie tak:)
  • Jacek Złydach (@TeMPOraL) 20 kwietnia 2010 02:42
    Hehehe :) Dziękuję za kolejną wyłapaną pomyłkę - spojrzę rano i poprawię ;].

    @Dynax, wszystko zależy od tego, co rozumiesz przez "update inputu" - może nie jest to powiedziane dość jasno w artykule, ale ja przez 'aktualizację wejścia' rozumiem przeczytanie danych (komunikaty, itp.) od systemu operacyjnego i sieci i "dopięcie" ich do gry - sprawdzenia typu "czy wciśnięta jest strzałka w lewo" powinny być robione jednak w tej wewnętrznej pętli.

    Hmmm... tak prawdę mówiąc to nawet ten cały "update inputu" chyba powinien iść do środka wewnętrznej pętli - to pozwala przyjąć jakieś dodatkowe założenia o częstotliwości zmian wejścia. Muszę się nad tym jeszcze zastanowić ;).
  • Michał Skowronek (@skowronkow) 20 kwietnia 2010 18:13
    Stosowałem ten sposób od czasu pewnego projektu flashowego i sprawdzał się naprawdę nieźle(w zasadzie jako jedyny). Fajnie, że powstał artykuł rozpowszechniający tą technikę bo sam przyznam szczerze uważałem ją za bardzo popularną i niewymagającą wspomnienia. Co do samego artykułu - podoba mi się, że podałeś przykłady czemu akurat ten sposób jest lepszy, oraz fakt, że jest to wiedza czysto praktyczna. Na dodatek przelana w zwyczajny i łatwy do przyswojenia sposób. Ogółem - in plus!
  • Kamil Szatkowski (@Netrix) 22 kwietnia 2010 19:42
    Bardzo dobry artykuł i fajnie napisany :)
  • Oijadt (@Oijadt) 23 kwietnia 2010 18:08
    ale tytul na wyrost :P
  • Jacek Złydach (@TeMPOraL) 24 kwietnia 2010 18:08
    Dobra, wrzuciłem już te zaległe poprawki. Thx, benethorpl. Niestety, trzeba było zmienić przykład, bo nie pasował już do nowych danych ;).

    @Oijadt: dlaczego? :)
  • Oijadt (@Oijadt) 28 kwietnia 2010 16:11
    hmm czy ja wiem. chyba mialem gorszy dzien jak to pisalem :P

    moze chodzilo mi o to ze ta modyfikacja sprowadza sie wlasciwie do petli for(;timer<getTime();timer+=20){} i posiada wady takie ze petla wywola sie w czasie 20 ms + czas nadmiarowy logiki (w twoim przykladzie +/- czas nadmiarowy/2), ktory jest zmienny. Wiec w efekcie mamy minimalne rwania plynnosci.

    Co nie zmienia faktu ze jest to lepsza metoda niz zmiennokrokowosc ;) takze przyczepilem sie z rozpedu.
  • Jacek Złydach (@TeMPOraL) 01 maja 2010 17:55
    I see :). "Czas nadmiarowy" logiki zbiera się i jest kompensowany w kolejnym obiegu ;). Ta metoda "nadgania" czas rzeczywisty, ale w sposób (teoretycznie) niezauważalny dla użytkownika.

    Kojarzysz jakieś lepsze rozwiązanie?
  • Xion (@Xion) 03 maja 2010 15:45
    Stabilność fizyki jest dobrym argumentem za stosowaniem stałego kroku (o ile nasza fizyka jest tego warta, tj. ma coś więcej niż ruch ze stałą prędkością/przyspieszeniem). Natomiast detekcja kolizji już niespecjalnie. Jeśli nasze obiekty poruszają się na tyle szybko, że należy "pod nie" dopasować czas kroku, to trzeba raczej rozważyć ciągłą detekcję kolizji. Inaczej będziemy np. 10 razy za często liczyć całą fizykę (i ryzykować błędy numeryczne przy zbyt małym kroku) tylko po to, by ultraszybki pocisk nie przelatywał nam przez ściany.
  • Minus (@Minus) 12 czerwca 2010 16:34
    Pocisk raczej nie będzie leciał szybciej niż obliczenie kolizji mesha z rayem ;p
  • Bartłomiej (@Vxx2) 17 czerwca 2010 11:33
    Świetnie napisana rzecz - prosto i czytelnie. Wielkie podziękowania dla autora, który naprawił mi fizykę - przy większym FPS i mniejszym deltaTime lub odwrotnie działy się nieciekawe rzeczy z kolizjami i obrotami obiektów. Teraz wszystko działa jak należy.
  • Shlizer (@Shlizer) 03 lipca 2010 13:46
    Cały mój światopogląd na temat głównej pętli gry legł w gruzach =p choć tak naprawdę jeszcze nie potrzebowałem jakiejś wymyślnej fizyki do swoich projektów to wiedza z artykułu na pewno się przyda =) ode mnie spory +
  • Minertorus (@Minertorus) 10 sierpnia 2010 00:58
    Trzeba by dodać coś o inpucie, alebowiem ludek sprawdzający wejście w "danej chwili", bez żadnego buforu, kolejki, z prostym "readem" może mieć problemy z odlagowaniem tego, zwłaszcza jeśli silnik fizyki daje duży narzut...
  • Xevaquor (@Xevaquor) 01 lutego 2012 14:54
    Linki zdechły
  • Napisz komentarz:
    Aby dodać swój komentarz, musisz się zalogować.
Licencja Creative Commons

Warsztat używa plików cookies. | Copyright © 2006-2017 Warsztat · Kontakt · Regulamin i polityka prywatności
build #ff080b4740 (Tue Mar 25 11:39:28 CET 2014)