Liczenie ilości okrążeń w grze

Witam, mam problem ze zrobieniem licznika okrążeń w pascalu.
Nie mam pomysłu jak zapisać kiedy pojazd minie linie mety to dodaje 1 okrążenie do licznika.
Próbowałem zrobić to z if pojazd i meta, ale nic nie wymyśliłem.
Proszę o naprowadzenie mnie na rozwiązanie.
Zamieszam kod

function okrazenie : integer;
  begin
      SetColor(white);
      writeln(okrazenie);
      okrazenie:=okrazenie+1;
      str(okrazenie, wynik);
      outtextxy(500,400,wynik);
      if okrazenie=2 then
      begin
        halt;
      end;
  end;;

1.okrazenie:=okrazenie+1; to najpewniej inkrementacja wyniku funkcji; w tym wypadku dodatkowo undefined-behavior (bo wynik nie jest uprzednio zainicjowany).
2.Użyj zmiennej globalnej.

Ale co to ma robić ten kod to ja tego nie rozumiem.

@Patryk27 ucz od razu dobrych nawyków. Zmienne globalne są be :P

1.Pisząc okrazenie := okrazenie+1; inkrementujesz wynik aktualnej funkcji, lecz nigdzie wcześniej tego wyniku nie ustalasz, więc de facto ta zmienna ma nieokreśloną wartość, tak więc dalsze zachowanie programu jest nieprzewidywalne - to jest undefined behavio(u)r.
2.Użycie procedury na pewno będzie rozsądniejsze, natomiast nie rozumiem drugiej części zdania zaczynającej się od "jeżeli".

NrOkrazenia:=1;
while NrOkrazenia<3 do
begin
   NrOkrazenia:=NrOkrazenia+1;
end;

NrOkrazenia:=1;
while NrOkrazenia<3 do
begin
   if PokrywaSieZLine(a,b,c,d) then NrOkrazenia:=NrOkrazenia+1;
end;

Więc poczytaj o kolizji rectangle-line.

Jak Ci się wydaje - w jaki sposób miałoby to niby działać?
Powtórzę siebie: "poczytaj o kolizji line-rectangle".

Przecież to pascal, inicjalizuje wszystko jak leci zerami.

Współczesne kompilatory pascala (np. FPC) zachowują się raczej w taki sposób:

• Wszystkie zmienne globalne są inicjowane zerami (wynika to z konstrukcji PE/EXE - dane są tworzone jako sekcja bez fizycznej zawartości, windows zawsze umieści tam zera)
• Wszystkie pola klasy są zainicjalizowane jeżeli klasa była zaincjalizowana (gorzej jeżeli wskaźnik klasy wskazuje w losowe miejsce).
• Wszystkie zmienne lokalne są niezdefiniowane (jeżeli ktoś zna x86 to wie że robi się to na stosie i większość kompilatorów nie inicjalizuje miejsca, jedynie je przydziela), to samo tyczy się wyniku funkcji, który w zależności od kompilatora i poziomu optymalizacji umieszcza wynik jako pole lokalne albo jako rejestr (np. FPC na najwyższym poziomie optymalizacji często stosuje sam rejestr jako wynik, na niższych tworzy dodatkową zmienną którą na koniec przepisuje do rejestru).

Heh, czyli od błędów mnie zawsze pedantyczność ratowała :D

Niekoniecznie.
Zawartość ramki stosu na startupie jest zerowana, ale potem jest winloader który zużyje ileś dwordów, potem jest sekwencja startowa kompilatora, która również zużyje ileś dwordów. Za większą z tych wartości stos ma same zera które mogą zabezpieczać program przed błędami. Dodatkowo, wcześniejsze procedury mogą zerować stos, co również powoduje 'defined behaviour'.

inkrementujesz wynik aktualnej funkcji, lecz nigdzie wcześniej tego wyniku nie ustalasz, więc de facto ta zmienna ma nieokreśloną wartość, tak więc dalsze zachowanie programu jest nieprzewidywalne - to jest undefined behavio(u)r.

De facto to ta zmienna ma określoną wartość - zawartość za ramką stosu, której zawartości można się domyślać: http://ideone.com/ukPHpG
Mówienie że coś jest undefined jest dla słabych inżynierów Intela którzy sami nie wiedzą co ich procesor produkuje (mimo że cały świat wie). Komputery to maszyny deterministyczne, zawsze można domyśleć się co wyprodukuje o ile nie stosujemy źródeł entropii (zawartość ramki stosu entropią raczej nie jest).

Suma sumarum, ja nie mówię że macie wszystko tłumaczyć od podszewki pytaczowi ale gdy już się mówi de facto to należy mówić jak jest na prawdę. Mówienie 'undefined behaviour' jest jedynie oznaką niewiedzy.

@3yhewuy4:
Z takim podejściem pojęcie "undefined behavior" nie istnieje, bo nawet x=x++ + ++x; można "niby przewidzieć", więc nie może być undefined, mimo tego, że wynik takiego wyrażenia zależy od kompilatora, poziomu optymalizacji i/lub ułożenia gwiazd na niebie...
Tak dla porównania, na Linuxie 32-bit przy -O2 na FPC 2.6.2, Twój programik zwraca "-29051"

"niby przewidzieć"

To można nawet bardzo łatwo przewidzieć: Sprawdzisz raz i już wiesz że za każdym razem będzie tak samo dla tej samej konfiguracji. Można by tu mówić o błędach które wydają się występować bardzo losowo a mimo to zależą i tak tylko od całkowicie zdefiniowanych warunków. To że czasami jest to trudniejsze do odtworzenia, nie znaczy że nie jest to niemożliwe, a świadczy jedynie o niewiedzy. Jestem przekonany że gdybyś wiedział wszystko o danym kompilatorze to również wiedziałbyś jaki kod on wygeneruje. Ale nie wiesz, więc dla ciebie to undefined behavior. Dla mnie kwestia sprawdzenia.

więc nie może być undefined, mimo tego, że wynik takiego wyrażenia zależy od [...] ułożenia gwiazd na niebie...

Mówiłem już że komputer to maszyna deterministyczna? Dla danej konfiguracji w tym wypadku wynik będzie zależny od platformy, opcji kompilatora i jego wersji. To jeszcze bardzo konkretne warunki.

Tak dla porównania, na Linuxie 32-bit przy -O2 na FPC 2.6.2, Twój programik zwraca "-29051"

Bo wtedy zapewne FPC wrzuca zmienne do rejestrów bezpośrednio. Nawet można usunąć całą funkcję. Tak samo można przerobić stub startowy FPC żeby dla twojego kodu zwrócił 1, 0 czy dowolną, z góry ustaloną wartość. Albo można pobawić się debuggerem i sprawdzić co oznacza wartość którą produkuje twój kod oraz wyznaczyć formułę na twoje 'undefined behavior'.

Z takim podejściem pojęcie "undefined behavior" nie istnieje

Dla inżynierów Intela to co zawsze zwraca 0 to też undefined behavior, bo są zbyt onieśmieleni żeby powiedzieć że instrukcja zamiany kolejności bajtów dla wordów produkuje 0. polecam bswap ax które ustawi ax na 0. Więc idź sobie z nimi i nie próbuj zrozumieć świata, tylko rób sobie 'undefined behavior'. Najprostsza metoda która z rzeczywistością nie ma nic wspólnego. Natomiast jeżeli będziesz mieć podejście rzeczywiste to zrozumiesz że losowość = brak wiedzy.

Więc chyba nie do końca rozumiesz pojęcie "undefined behavior"; na przytoczonym uprzednio przeze mnie przykładzie:
x = x++ + ++x;
Tutaj występuje undefined behavior, ponieważ działanie tego kodu jest bliżej nieokreślone.
Fakt, że na kompilatorze A przy jakichś przełącznikach zwróci 3 nie oznacza, że działanie tego kodu jest nagle zdefiniowane - UB tyczy się "niesprecyzowań" języka, nie kompilatora.

Więc chyba nie do końca rozumiesz pojęcie "undefined behavior";

Nie ja, tylko ty.

Tutaj występuje undefined behavior, ponieważ działanie tego kodu jest bliżej nieokreślone.

Każda implementacja ma określone działanie na ten kod. Zgłoszenie błędu jest również działaniem.

Fakt, że na kompilatorze A przy jakichś przełącznikach zwróci 3 nie oznacza, że działanie tego kodu jest nagle zdefiniowane

Otóż oznacza.

UB tyczy się "niesprecyzowań" języka, nie kompilatora.

Czyli posługujesz się papierkiem który z rzeczywistością nie ma nic wspólnego? Może warto jeszcze dodać że nie może powstać kompilator zgodny ze standardem C z (bodaj) 1999 roku, gdyż ten papierek został skonstruowany w celu wewnętrznej niezgodności z samym sobą? No zobacz, jaki ten twój świat uporządkowany na opak.
Idąc twoim myśleniem bswap ax jest również UB ponieważ tak jest napisane w manualu. A to że na każdym współczesnym procesorze da to wynik ax=0 to nic nie szkodzi.

Można napisać że cały świat to jeden wielki UB, w końcu jeżeli zajdzie jakaś prawidłowość to się powie że to tylko w tym przypadku. Jeszcze raz mówię, że to że ktoś napisał że coś jest UB nic nie znaczy. To jedynie znaczy że brakuje mu wiedzy potrzebnej do opisania danej rzeczy (w przypadku opisu C wygląda na to że komuś brakowało zgodności ze samym sobą i jednoznacznym stwierdzeniem wszystkiego, bynajmniej nie znaczy to że coś jest UB, a jedynie że specyfikacja nie określa zachowania i każde jest poprawne a UB to to jest jedynie dla tego nic nie wartego papierka). Kiedyś UB były pioruny, zgadnij skąd Zeus?

Widzę że jak ja dążę do realizmu, to ty do utopii i tego, co tylko na papierze działa.

Double posts happen...

Tak można bardzo daleko zajść. Ponieważ każda ludzka reakcja jest wynikiem jakichś procesów chemicznych i/lub fizycznych jak również i reakcja całego
pozostałego wszechświata to teoretycznie możemy zapisać prędkość oraz aktualne położenie każdego atomu we wszechświecie i powiedzieć że mamy maszynę deterministyczną czyli nawet ten twój post można było "wyliczyć" jeszcze przed twoim urodzeniem.

Jasne że tak. Miło mi że rozumiesz. I oczywiście podchodzimy tutaj pod filozofię, ale po odpowiednim zminimalizowaniu naszego problemu do komputerów, można zrozumieć o co mi chodzi. De facto oznacza to jak to wygląda w rzeczywistości, nie że coś jest zależne od tego, jak komputerowi się spodoba.

@3yhewuy4, trochę się zapędziłeś.
Skoro nie ma dla ciebie UB to powiedz mi co się stanie jak odpalę taki program:

#include <iostream>
int main()
   {
    int x;
    std::cin>>x;
    std::cin.sync();
    std::cin.get();
    return 0;
   }

i wpiszę:
0<enter>
?

Czyli posługujesz się papierkiem który z rzeczywistością nie ma nic wspólnego?

Czy aby na pewno nie ma nic wspólnego?

Idąc twoim myśleniem bswap ax jest również UB ponieważ tak jest napisane w manualu.

Dokładnie tak - skoro architekt/twórca/wtf zażyczył sobie, by takie coś po prostu nie miało prawa bytu i oznaczył to jako UB, to jest to UB i kropka.

Widzę że jak ja dążę do realizmu, to ty do utopii...

Momentalnie skojarzyło mi się z tym: http://ludzie.4programmers.net/bash/?392
"Bo skoro działa na 'każdym' komputerze z Windowsem 7 z daną konfiguracją, to niech zostanie, niezależnie, że albo nikt o takim ficzerze nie wspomniał, albo jest to undefined-behavior..."

...i tego, co tylko na papierze działa.

A to że na każdym współczesnym procesorze da to wynik ax=0 to nic nie szkodzi.

Masz rację - ja wolę trzymać się tego, że skoro ktoś napisał, że to i to w połączeniu daje undefined-behavior, to tak po prostu jest.
Fakt, że na większości procesorów w ten sposób skonstruowany opcode zeruje rejestr dla mnie nic nie zmienia, ani już tym bardziej nie daje powodu, by korzystać z takich kombinacji w kodzie, bo a nuż np.kolejne procesory Intela będą wywalać wyjątek w takiej sytuacji.

a jedynie że specyfikacja nie określa zachowania i każde jest poprawne a UB to to jest jedynie dla tego nic nie wartego papierka

Skoro specyfikacja czegoś jawnie nie określa, nie ma to przypisanego zachowania - nie można stwierdzić, że "każde jest poprawne".

@Patryk27 ma rację. Kolejny raz zawodnik o pseudonimie payl omija bana żeby głosić swoje radosne brednie :|

Undefined behaviour to sytuacja w której nie możemy jednoznacznie stwierdzić co stanie z programem w różnych warunkach, przy czym tym warunkiem może być architektura, platforma, czas kompilacji, wersja kompilatora, czy cokolwiek sobie wymarzysz.

Dokładnie tak - skoro architekt/twórca/wtf zażyczył sobie, by takie coś po prostu nie miało prawa bytu i oznaczył to jako UB, to jest to UB i kropka.

Zażyczył sobie? To dokumentacja>praktyka? Ciekawe twierdzenie. To widzę że nikt nie liczy się z bredniami manuala. W końcu to piszą osoby które powinny najlepiej wiedzieć jak to działa.

"Bo skoro działa na 'każdym' komputerze z Windowsem 7 z daną konfiguracją, to niech zostanie, niezależnie, że albo nikt o takim ficzerze nie wspomniał, albo jest to undefined-behavior..."

Ale czy ja mówię cokolwiek o kompatybilności? Zdaję sobie sprawę że sporo z tych rzeczy jest zależna od wielu parametrów. Natomiast raz jeszcze mówiąc o bswap ax to jest to od bodaj od Pentium I do dzisiaj. Dlaczego? Kompatybilność wsteczna zapewne czy inne powody. W każdym razie jak było tak jest.

Masz rację - ja wolę trzymać się tego, że skoro ktoś napisał, że to i to w połączeniu daje undefined-behavior, to tak po prostu jest.

Ok, to teraz do architektury PE/EXE: Masz jakiś plik EXE, chcesz go parsować. Trzymając się dokumentacji M$ dojdziesz do tego że to nie jest poprawny plik PE/EXE, natomiast plik EXE śmiga sobie. Czyżby UB? A może po prostu M$ nie opisał bardziej skomplikowanych zachowań loadera które notabene są od Win95.
Nie mniej rozumiem twoje myślenie i szanuje je, po prostu nie wychodzisz poza utarty szlak.

Fakt, że na większości procesorów w ten sposób skonstruowany opcode zeruje rejestr dla mnie nic nie zmienia, ani już tym bardziej nie daje powodu, by korzystać z takich kombinacji w kodzie, bo a nuż np.kolejne procesory Intela będą wywalać wyjątek w takiej sytuacji.

RE/AntiRE to często jazda po bandzie, taki kod to nic specjalnego. I skoro jest to od Pentium I, to coraz więcej kodu zależy od tego (niezliczona ilość packerów/protectorów). A gdyby Intel zmienił to, to poprawiłbyś kod i już. Nie widzę tragedii. I nie mówię żeby ten kod stosować jako zerowanie rejestrów 16bitowych. To się przydaje tam gdzie nie chcemy aby osoby korzystające z oficjalnej dokumentacji (takie jak Ty) wiedziały co się dzieje.

Skoro specyfikacja czegoś jawnie nie określa, nie ma to przypisanego zachowania - nie można stwierdzić, że "każde jest poprawne".

Jakoś zaimplementować to musisz. Więc skoro specyfikacja nie mówi o tym nic, to jak masz to zaimplementować jak nie tak jak ci się podoba? Już nie mówiąc że specyfikacja do której się odwołujemy jest wewnętrznie niezgodna.

@Patryk27 ma rację. Kolejny raz zawodnik o pseudonimie payl omija bana żeby głosić swoje radosne brednie

Dziękuje za twoją opinię. Nie mniej jakoś nie straszy mnie to że nigdy się ze mną nie zgadzasz.

Undefined behaviour to sytuacja w której nie możemy jednoznacznie stwierdzić co stanie z programem w różnych warunkach

To jak rozdaję program użyszkodnikom, to to jest UB?
Twoja definicja jest ograniczona.

przy czym tym warunkiem może być architektura, platforma, czas kompilacji, wersja kompilatora, czy cokolwiek sobie wymarzysz.

No to wracając do nieśmiertelnego bswap ax to zakładając że ktoś nie uruchomi tego na 486, to to nie jest UB i tutaj różnisz się od Patryka bo dla niego manual jest święty.
Traktując sprawę w drugą stronę to 99,9% współczesnych programów to jeden wielki UB, ponieważ zakładają istnienie instrukcji których dany (archaiczny) procesor może nie posiadać.

Ja bym raczej powiedział, że to wasze UB, to raczej zachowanie którego nie można przewidzieć (tłumacząc z ang.). Natomiast ja się z tym nie zgadzam, bo moim zdaniem wszystko można przewidzieć jeżeli ma się odpowiednią wiedzę.

Widzę że tylko jeden jedyny 13 smok zrozumiał o co mi chodzi. Reszta zapewne jest zbyt ustawiona na swój tor, który każe ograniczać się. Natomiast moja 'zasada' jest prosta: Undefined Behavior to tylko brak wiedzy/danych aby mieć pełen pomiar, nie żadne działanie którego nie można zrozumieć. W teorii można wszystko zmierzyć więc UB nie istnieje. Są tylko ograniczone przyrządy i... ograniczone osoby, mam nadzieję że nie wy.

A tak w ogóle to nie dyskutuj z terrorystami.

Zdetonuję wam bombę w siedzibie. A nie, zapomniałem, wy nie macie siedziby.
https://pl.wikipedia.org/wiki/Terroryzm
Nie wydaje mi się abym wymuszał na was jakiekolwiek działanie tym postem (no może poza wolnością wypowiedzi). Staram się was też nie bić, więc chyba jest ok.

I tak najzabawniejsze jest to że o ile wasze opinie mają prawo bytu, tak moje, alternatywne, nie mają. Jestem tępiony także za swoje alternatywne poglądy, których nie jesteście w stanie zrozumieć. To jest oczywiste cenzurowanie 'niepoprawnych' poglądów. Także wasze wypowiedzi są nic nie warte bez mojej możliwości odpowiedzi, bo przedstawiają sprawy w jednym świetle.

geraltt napisał(a):

Witam, mam problem ze zrobieniem licznika okrążeń w pascalu.
Nie mam pomysłu jak zapisać kiedy pojazd minie linie mety to dodaje 1 okrążenie do licznika

248gj4owtj32 napisał(a):

Ok, to teraz do architektury PE/EXE: Masz jakiś plik EXE, chcesz go parsować. Trzymając się dokumentacji M$ dojdziesz do tego że to nie jest poprawny plik PE/EXE, natomiast plik EXE śmiga sobie. Czyżby UB? A może po prostu M$ nie opisał bardziej skomplikowanych zachowań loadera które notabene są od Win95.

To dokumentacja>praktyka?

Oba są równie ważne, lecz niektóre rzeczy - np.UB - po prostu istnieją i należy się z tym pogodzić.

Ok, to teraz do architektury PE/EXE: Masz jakiś plik EXE, chcesz go parsować. Trzymając się dokumentacji M$ dojdziesz do tego że to nie jest poprawny plik PE/EXE, natomiast plik EXE śmiga sobie. Czyżby UB?

To nie jest UB - zacytuję siebie: "skoro architekt/twórca/wtf zażyczył sobie, by takie coś po prostu nie miało prawa bytu i oznaczył to jako UB, to jest to UB i kropka."
Więc jeżeli:
a) coś w tym pliku PE/EXE zostało oznaczone jako UB w dokumentacji (np.jakiś bajt ustawiony na konkretną wartość, brak jakiejś sekcji or something), wtedy mamy UB (i plik może np.nie uruchomić się po wydaniu jakiejś łatki od M$ lub czegokolwiek).
b) jeżeli plik jest z pozoru nieprawidłowy, lecz działa - cóż, zapewne przez przypadek, ale na reversowaniu aplikacji znam się tyle, coby zmienić jnz na jmp, więc tutaj ciężko mi coś konkretniejszego powiedzieć :P

po prostu nie wychodzisz poza utarty szlak.

Po prostu nie chce się przejechać na skorzystaniu z UB bądź innych rzeczy, które po prostu działają, ale nikt nie wie dlaczego.

W teorii można wszystko zmierzyć więc UB nie istnieje.

Cytując Wikipedię:

In computer programming, undefined behavior refers to computer code whose behavior is unpredictable.

Istotne jest tutaj słowo "unpredictable", a nie "immeasurable":
UB jest wtedy, gdy nie możesz przewidzieć tego, co uczyni kod, a nie sprawdzić wyniki jego działań.
Nie możesz przewidzieć jak zachowa się taki kod: x = x++ + ++x;, ale możesz sprawdzić jego wynik i zapamiętać, że na tym-a-tym kompilatorze przy takich-a-takich ustawieniach zwraca 3, lecz wciąż jest to UB.

Jakoś zaimplementować to musisz. Więc skoro specyfikacja nie mówi o tym nic, to jak masz to zaimplementować jak nie tak jak ci się podoba?

Skoro specyfikacja o czymś nie mówi, nie muszę tego implementować.

A czy ktoś w tym wątku ma zamiar powrócić do tematu stricte liczenia okrążeń..?
Już jest niezły OT, a jak tak dalej pójdzie to rozpocznie się dyskusja o teorii bran i UFO nad Phoenix...

Podany jest kod, jednak na jego podstawie ciężko cokolwiek wywnioskować; Wnioskuję by pytacz zaprezentował najlepiej cały kod gry lub chociaż samą procedurę wyścigu (czy jak to nazwać), wtedy będzie można zorientować się w jaki sposób odbywa się przemieszczanie po torze, sprawdzanie jego pozycji i ewentualnych kolizji; Tego typu informacje (czyt. kod) byłby bardzo pomocny;

Ogólnie to powinieneś checkpointy rozłożone na torze w niedużych odstępach; Podczas przemieszczania się po torze i najechaniu na jeden z punktów ustala się jego położenie względem poprzedniego punktu i dzięki temu można określić kierunek ruchu; Jeśli kierunek jest prawidłowy to dodaje się punkt do jakiejś listy i jedzie dalej; Jeśli kierowca pomylił kierunki punkt nie zostaje dopisany i np. wyświetlona zostaje ikonka błędnego kierunku; Można to wzbogacić o pewną funkcjonalność, mianowicie jeśli uzbiera się np. 10 kolejnych punktów w odwrotnym kierunku niż ustalony, ruch zostaje wstrzymany i pojazd odwrócony w poprawnym kierunku (lub pojazd znika i pojawia się w ostatnim poprawnym punkcie); I tak licząc te punkty dochodzimy do momentu aż pojazd znajduje się na linii mety - wtedy jeśli kierunek jest poprawny (lub wszystkie punkty na trasie są zaliczone) inkrementuje się licznik okrążeń i zeruje listę punktów; Przy inkrementowaniu licznika okrążeń sprawdza się czy wszystkie okrążenia są wykonane i jeśli tak - koniec wyścigu;

Zamiast punktów można wykorzystać bramki (czyli zespół dwóch punktów pomiędzy którymi sprawdzana jest pozycja i kierunek ruchu) - to już kwestia zaangażowania; Ja to tak widzę i tak bym to wykonał.

Dzięki za pomoc. Szkoda tylko, że z pascala doszliśmy do c++
Niekiedy na najprostsze rozwiązania początkującemu programiście trudno wpaść.
Zrobiłem to w taki sposób, że sprawdza czy Y linii mety się zgada z początkiem pojazdu, ale przez to liczy też w połowie okrążenia na górze toru, przez to nie jest idiotoodporny.

A mógłbyś mniej więcej napisać jakby to wyglądało w języku programowania? Jeśli będzie dla mnie za trudne to dam sobie na razie spokój, ale chciałbym chociaż spróbować wpisać to do mojego programu.

Jeżeli:
((Ax-Px)*(By-Py)-(Bx-Px)*(Ay-Py)<0) <> ((Ax-Qx)*(By-Qy)-(Bx-Qx)*(Ay-Qy)<=0)
to punkty P i Q znajdują się po różnych stronach odcinka A-B.
Można jeszcze sprawdzić czy odległości |AP|, |BP|, |AQ|, |BQ| wszystkie naraz lub jedna z nich znajdują się w dopuszczalnych granicach.

Wyobraź sobie, że to poniżej to mapa pikseli (jeśli ma być w trybie tekstowym - mapa znaków):

• zielony - piksele bandy,
• szary - pole, po którym może poruszać się pojazd,
• biały - punkt mety
• żółty - punkt kontrolny na torze,
• błękitny - przestrzeń pomiędzy punkatmi kontrolnymi;
  Podczas jazdy co jakiś czas (nie podałeś jaki) pobierasz współrzędne pojazdu służące do malowania go - wtedy sprawdzaj aktualne współrzędne pojazdu i porównuj z odległością pomiędzy dwoma punktami kontrolnymi, między którymi aktualnie znajduje się pojazd; Sprawdzaj czy pojazd zbliża się do kolejnego punktu kontrolnego (czyli jedzie w dobrą stronę), czy oddala (czyli w przeciwną); Jeśli jest to ruch poziomy na ekranie - oblicz pozycję X na ekranie według aktualnej pozycji i porównaj ją z poprzednią; Jeśli to rych pionowy - porównuj tak samo, tyle że pozycję Y;

Możesz też podzielić sobie tor na sekcje, w których określisz czy to ma być ruch poziomy czy pionowy, oraz w którą stronę (czy z lewa na prawo, z prawa na lewo, z góry na dół czy z dołu do góry); Możesz też dodać ruch ukośny dla zakrętów - obliczanie odległości między punktami to prosta arytmetyka; W niektórych grach 2D (widok z góry) tor jazdy w edytorze posiada podobne punkty, tyle że nie są jedynie idealnie pionowe i poziome, bo służą także jako tor jazdy dla pojazdów sterowanych przez komputer, dlatego są rozmieszczone w różnych miejscach - z reguły blisko wewnętrznej części toru, a po zakręcie wyjście na zewnętrzną by nie tracić nadmiernie prędkości; To tylko informacja, której jak na razie nie wykorzystuj u siebie póki nie bardzo rozumiesz o co chodzi;

Podałem jedynie przykład implementacji - możesz to zrobić na wiele innych sposobów, jednak to pierwszy jaki wpadł mi do głowy; Ekspertem nie jestem, jednak gdybym miał sam taką grę napisać to zrobiłbym właśnie coś w ten deseń;

Ty natomiast mógłbyś zrobić zrzut ekranu z tej gry - wtedy możnaby coś więcej napisać stricte dla Twojej gry; No i przydałoby się więcej kodu.

I tak najzabawniejsze jest to że o ile wasze opinie mają prawo bytu, tak moje, alternatywne, nie mają. Jestem tępiony także za swoje alternatywne poglądy, których nie jesteście w stanie zrozumieć. To jest oczywiste cenzurowanie 'niepoprawnych' poglądów. Także wasze wypowiedzi są nic nie warte bez mojej możliwości odpowiedzi, bo przedstawiają sprawy w jednym świetle.

Cóż jak widać wiedziałem co się stanie. Nie mam zamiaru ponownie postować swoich odpowiedzi.

I słusznie @payl, mamy nadzieję że na dobre oszczędzisz nam swoich złotych rad.

Dziękuję za te słowa otuchy. Wierzę że biegną one prosto z głębi duszy :).

Przesadziłeś z offtopem to posty zaczęły wylatywać.

Hahaha, to moje posty były offtopem, twoje nie? Wolne żarty.

Z drugiej strony: nikogo nie obchodzą Twoje filozofie, tego typu pojęcia definiuje się rozpatrując je pod kątem użytkowników kompilatora, więc ludzi, a nie jakiś istot wszechwiedzących.

No to właśnie wróć do tego, od czego ja zacząłem brak istnienia UB. Wcale nie od kompilatorów. Tylko Patryk przeniósł ten temat na kompilatory, gdzie to ma mniejszy i bardziej ogólny sens. Ja nie mam żadnych filozofii, to wy mnie zmuszacie do z bardzo konkretnej sprawy zrobienia filozofii którą potem krytykujecie że jest zbyt ogólna. Gdybyście nie odbiegali od mojej początkowej myśli to wcale żadnych filozofii by nie było. Także przeczytaj początek tej myśli jeszcze raz.

@38yj9a23k5y: twoje poglądy są niepoprawne, bo pochwalasz pisanie wadliwych programów. nikt nie mówi że ub to przejaw boskiej interwencji niepojęty dla śmiertelników.

No tak, bo dla was istnieją tylko dobrze napisane programy. Napisz swój EXE protector, pogadamy czy nie używałeś UB żeby był lepszy. No chyba że dla ciebie jedyny "protector" to UPX...