a to mój mały hak: https://pastebin.com/G8iYwAPg
planowałem za niego dostać dzisiej pińć plus z grafiuczki na dobry początek wakacji, niestety plany pokrzyżował brak MSVCP120.DLL, failure during conversion to coff file invalid or corrupt i inne wesołe zjawiska znane każdemu, kto hakeruje na systemach małomientkich.
Ale nie w tym rzecz. Rzecz w tym mianowicie, że mój hak nie do końca bangla zgodnie z założeniami. Konkretnie jedną z rzeczy, która nie bangla, jest detekcja kolizji, a jeszcze konkretniej reakcja na kolizje, w funkcji CollisionDetect3(). Piłeczki często zamiast zmieniać kierunek sczepiają się ze sobą i pchają dalej w tym samym kierunku. Wydaje mi się, że po wyliczeniu wszystkiego coś jest nie tak ze zwrotami wektorów. Czy ktoś może potwierdzić/zaprzeczyć/preferowalnie wskazać dokładną przyczynę błędu i znaleźć rozwiązanie? Za pomoc oferuję sowitą nagrodę.

P.S. Jakby komuś się nie kompilatorowało, to tutej binarka.

P.P.S. Mówię Wam, jaką lasencję mamy na uczelni Figura - ideał w każdym nanometrze sześciennym, cycki jak marzenie, normalnie doskonała, wszystko co widzieliście w internetach to jest przy takich widokach jedynie marna imitacja kobiety... Jak zhakuję jej foty, to nie omieszkam podzielić się ze szczęśliwym pomagaczem.

P.P.P.S. Mały hack oczywiście jest jeszcze mocno niedopracowany, w zasadzie są to dopiero podwaliny hacka, bo przy doświadczeniu oscylującym wokół zera do roboty przysiadłem gdzieś w sobotę, jak na przykładnego studenta przystało, i na dobrą sprawę dopiero dziś nad ranem udało mi się dopracować detekcję kolizji (przynajmniej na tyle, żeby piłki przy kontakcie jedna z drugą zachowywały się dość przewidywalnie, a nie zaczynały pop#$%dalać jak głupie po całej planszy). W kolejce czekają jeszcze pikne amigowe teksturki, multiple light sources i inne bajery rowery. No ale na to już mam czas do września, więc luzik arbuzik.

Na kiedy to masz? ;)

4.09.2018. Do tego czasu to pewnie dam radę sklecić z tego jakąś małą gierkę. O ile oczywiście najpierw poradzę sobie z kolizją kulek. :)

Tak, jak pisałem poprzedni post to nie doczytałem, faktycznie do września. Szkoda że nie dałeś znać wcześniej, byśmy powalczyli w porę.

Nie mogę tego u siebie skompilować bo nowe MinGW-w64 nie ma GLUTa. Mógłbym go sobie doinstalować ale tego nie zrobię, bo GLUT jest stary, zbutwiały i powinno się użynać ręce za jego stosowanie. Od takich rzeczy jest GLFW. To rzecz pierwsza.

Druga jest taka, że tego typu rzeczy jak kolizja najłatwiej się debuguje upraszczając sobie testy - z tego co widzę jedziesz tu w full 3d, weź sobie na czas testów zrób przypadki 2D, gdzie jedna oś jest cały czas zerowa. Jak zrobisz na XY to zrób na YZ, potem na ZX. Jak to będzie działać to odpalasz wszystkie 3 osie naraz.

Trzecia jest taka, że Twój kod ma prawie 666 linii kodu (667 ale gdzieś widziałem podwójny enter, który można zastąpić pojedynczym), to plus do hakierstwa. Minus jest taki że kod jest nieczytelny, zaciągnij sobie bibliotekę GLM do macierzy i wektorków. Z kodu:

sphereOBJ1.position.x = 0.0;
	sphereOBJ1.position.y = 0.5;
	sphereOBJ1.position.z = 0.0;
	sphereOBJ1.velocity.x = 0.003;
	sphereOBJ1.velocity.y = 0.0;
	sphereOBJ1.velocity.z = 0.02;
	sphereOBJ1.rotation_angle.x = 0.0;
	sphereOBJ1.rotation_angle.y = 0.0;
	sphereOBJ1.rotation_angle.z = 0.0;
	sphereOBJ1.rotation.x = 0.2;
	sphereOBJ1.rotation.y = 0;
	sphereOBJ1.rotation.z = 0;
	sphereOBJ1.rotation_dir.x = -1;
	sphereOBJ1.rotation_dir.y = 0;
	sphereOBJ1.rotation_dir.z = 0;

Zrobi Ci się:

sphereOBJ1.position = glm::vec3(.0f, .5f, .0f);
sphereOBJ1.velocity = glm::vec3(.003f, .0f, .02f);
sphereOBJ1.rotation_angle = glm::vec3(.0f);
sphereOBJ1.rotation = glm::vec3(.2f, .0f, .0f);
sphereOBJ1.rotation_dir = glm::vec3(-1.0f, .0f, .0f);

Gdzie każdy z wektorów ma oczywiście pola do .x, .y, .z więc mało zmian (jeśli jakiekolwiek) w samych wzorach będzie.

Jak zastosujesz się do powyższych zmian (zwłaszcza GLFW) to będziemy myśleć dalej ;)

dzięki za rady. Od tamtego posta co prawda projekt posunął się już trochę do przodu. :)
GLFW i GLM mam wśród bibliotek, chociaż tego pierwszego nie stosowałem (i nie pamiętam już, do czego ją ściągałem), a to drugie to praktycznie tylko dla M_PI. Co do testowania w 2D czy po jednej osi, to również doszedłem do takiego wniosku, że nie ma co porywać się z motyką na słońce i skoro całość nie działa zgodnie z założeniami, to trzeba sprowadzić układ do jak najprostszej postaci i testować po kolei od najniższego szczebla... Tak więc kule już nie skaczą, tylko się toczą. Zderzenia kul poruszających się wzdłuż jednej osi wyglądają OK, więc przeszedłem do płaszczyzny 2D.
Problemy z "zazębianiem się" kul wynikały z początkowej instrukcji warunkowej if, która porównywała _aktualną_ pozycję kul z sumą ich promieni - w ten sposób kolizja mogła nastąpić dopiero w chwili, gdy kule już na siebie zachodziły i odsunięcie się obydwu o wektor prędkości tego nie zmieniało. Teraz odległość między kulami obliczana jest "krok wprzód". Poza tym w toku dalszych testów wyszedł się też m.in. problem, kiedy kula ustawia się równolegle do ściany - wówczas poruszała się wzdłuż niej i nijak nie dało się jej odbić. Z tym też, zdaje się, jakoś sobie poradziłem (problem ten odkryłem dopiero dziś, więc jeszcze za wcześnie oceniać). Naniosłem też parę zmian w obliczeniach kątów, dzięki czemu kulki po odbiciu poruszają się już bardziej właściwym torem :) (chociaż wydaje mi się, że nadal czasami pojawiają się dość dziwne układy). Dodałem też prowizoryczne ściany i ładną siateczkę na podłogę, żeby te kule nie toczyły się "w powietrzu", do tego opcję przełączania na widok z góry. Ostatni 10-minutowy test nie wykazał większych błędów, chociaż jak zostawiłem te kulki (w liczbie 5) samopas z zamiarem późniejszego sprawdzenia, jak sytuacja wygląda po x minutach - to niestety okazało się, że w końcu trzy kulki się ze sobą sczepiły... Myślę, że problem pojawia się w sytuacji, gdy kulka ma "ciasno", tzn. z jednej strony ściana, z drugiej druga kulka, z trzeciej trzecia - i w efekcie nowy wektor prędkości wpycha ją na inną kulkę.

Niemniej jest już dużo lepiej niż było. Zastosuję się do tego, co piszesz na temat glm i glfw, to później wrzucę poprawiony kod. Na razie robię krótką przerwę.
A co do linijek w liczbie 666, to czysty przypadek ;) (obecnie kod ma 1899, z czego pewnie koło połowy to różne śmiecie do uporządkowania/wyrzucenia).

-edit aha, jeszcze doszedłem do tego, że jest problem z kątami prostymi, ale to już wynika zapewne z faktu liczenia kątów w radianach.

Ostatnia aktualizacja: 02.07.2018 15:53:19 przez snajper

no więc tak oto prezentuje się kot w postaci obecnej, z grubsza uprzątnięty:



klawiszologia:
szczały - poruszanie, z altem - przesuwanie lewo-prawo
s - stop
b - wył./wł. odbijania piłeczek. Przydatne, kiedy ktoś chce sobie pooglądać same kolizje na płaszczyźnie.
1/2/3/4/5/6 - zmiana widoku... W sumie są trzy tryby, + trzy kolejne obrócone o 90 stopni. W tej chwili przy przełączaniu widoku nie jest zapisywana aktualna pozycja obserwatora, współrzędne są przypisane na sztywno do każdego trybu.
ctrl + 1/2/... - wł./wył. świateł (obecnie są 2 światła)
esc - qniec.

Problemy z poruszaniem po płaszczyźnie już nie występują. :) Wynikały głównie z równań wyliczających prędkości składowe kulek po zderzeniu, w których jednym z czynników była prędkość wypadkowa przed kolizją, nie uwzględniająca znaków prędkości na osiach X i Z... Stąd brały się czasami kąty odbicia +/-90 stopni i sklejanie piłek. Ostatni test przy ponad 13000 kolizji nie wykazał błędów. :) Dodałem więc analogicznie ruch "wgórny" - to już wydawało się pestką i jak dotąd nie zauważyłem problemów w skakaniu piłeczek - chociaż w tej chwili piłki z każdą kolizją obniżają pułap, co zapewne wynika już jednak z praw fizyki stosowanych w obliczeniach.

Biblioteki GLFW niestety nie udało mi się dodać do projektu - przy próbach kompilacji występują różne "undefined reference", czy coś w ten deseń - nie mam bladego pojęcia czemu. W każdym razie żeby niepotrzebnie nie przeciągać projektu, dałem sobie z tym spokój i wziąłem się za usuwanie błędów. Za to w tej chwili korzystam z bibliotek SDL, głównie w celu wyeliminowania delaya między wciśnięciem klawisza a powtarzaniem ruchu.

Enyłej... Na dzień dzisiejszy najbliższe plany wyglądają tak:
1. Znalezienie sposobu na ustawianie dowolnego rozmiaru siatki na podłodze. Współrzędne siatki są w tej chwili przechowywane w tablicy, a te, jak wiadomo, muszą mieć z góry określony stały rozmiar. Wykorzystanie do tego wektorów niestety nie wchodzi w grę, bo musi być tutaj stosowana ciągła adresacja... (w każdym razie przy obecnie stosowanej metodzie rysowania siatki)
2. Ograniczanie ruchu obserwatora przez ściany. Na to, zdaje się, już znalazłem rozwiązanie, aczkolwiek nie podchodziłem jeszcze do próby jego zastosowania - opierać by to się miało na jakichś dziwnych obliczeniach z iloczynem wektorowym.
3. Dodanie napisów w rogu - informacje o stanie "gry" typu czas trwania, liczba kolizji, współrzędne obserwatora itp.
4. Taki dynks z kierunkami północ-południe-wschód-zachód, obracający się wraz z ruchem obserwatora.
5. Zapis aktualnej pozycji obserwatora przy przełączaniu trybów widoku
6. Teksturki na ściany itp., ale to już sprawy drugorzędne.
7. Zamiana gl_quadsów na trianglesy.
8. Podobno glShadeModel jest deprecated, więc to też by należało czymś zastąpić...

No i to chyba wsio na razie.

Aha, programik do działania wymaga SDL.dll (preferowana wersja 1.2.15) i freeglut.dll. Może się też pluć o jakieś msvc-cośtam-120.dll w windzie.

Ostatnia aktualizacja: 11.07.2018 00:33:26 przez snajper

Undefined reference masz jak nie dodałeś argumentu -lcośtam do linkera - którejś biblioteki nie dołączasz. Namawiam Cię jednak na zrobienie drugiego podejścia... albo w sumie nie. Jak masz SDLa to nie potrzebujesz GLUTa - on jest tylko do wygodnego tworzenia okna i inputów, a to Ci załatwia SDL. Więcej tu. Jak go wytniesz to obiecuję uruchomić to u sibie. ;)


Co do punktu 8 - chyba czekają Cię shadery. ;) Nie wiem czy kiedykolwiek dawałem Ci ten link ale tu masz bardzo spoko tut do OGL, w tym wytłumaczenie czemu pojawiły się shadery itd. Tu masz o samych shaderach.

GLEW jest spoko do ładowania OpenGL ale ja używam GLAD. Chyba się to teraz robi bardziej popularne, ale w sumie jeden gips.

Ostatnia aktualizacja: 11.07.2018 08:30:19 przez teh_KaiN

bez freegluta W sumie wystarczyło usunąć includa i skomentować dwie linijki. :) Ale przy okazji wywaliłem jeszcze parę zbędnych zmiennych + nagłówków i przeniosłem setup SDL do osobnej funkcji, żeby w main nie było za wiele syfu. Plus parę małych zmian, żeby całość kompilowała się bez problemu z g++.

a tutaj paczuszka z SDL.dll i gotową windzianą binarką skompilowaną pod MinGW32 - ździebko więcej waży, ale to głównie dlatego, że ma statycznie zlinkowanych parę dll-i (do działania na drugim kompie potrzebowało to libwinpthread-1.dll i libstdc++-6.dll). Komenda, którą kompilowałem pod mingw32:

g++ texture_sphere23.cpp -o bounce.exe -I... -L... -lOpenGL32 -lGlU32 -lglew32s -lmingw32 -lSDLmain -lSDL -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread