piotrdz - 19-03-2012, 17:37 Temat postu: Bugi, nieprzenośny kod, dziwne rzeczy w kodzie Jak pisałem już w moim poprzednim wątku, zobaczyłem jak wygląda sprawa z kompilacją kodu pod GCC. Znalazłem przy tym wiele dziwnych konstrukcji, potencjalnych bugów i przykładów nieprzenośnego kodu. Piszę o tym tutaj, żeby potem to gdzieś nie zaginęło, bo warto z tym rozprawić się już na początku, niż żeby kiedyś potem wyszło to jeszcze raz. Są to głównie rzeczy na których wykrzacza się GCC, ale też kilka rzeczy, które ogólnie rzuciły mi się w oczy. #0 Brakujące #include'y, wielkość liter w nazwach plików - tym już się zająłem. #1 Klasy dziedziczące po CAuto mają podwójnie wywoływane konstruktory. Przykład:
Nie wiem, czy to celowe działanie, czy błąd. #2 Klasy pochodne mają w destruktorze jawnie wywoływany destruktor klasy bazowej (być może też powoduje to podwójne wywołanie jak konstruktorów).
Na tym w ogóle wywala się GCC, bo nie pozwala na taką składnię. Trzeba by wszystkie destruktory zamienić na wirtualne i pozbyć się tego. #3 W robotmain.cpp: #include "classfile.cpp" Hmmm... #4 Są dwa moduły z funkcją WinMain(): d3dapp.cpp i winmain.cpp. Chyba tylko ten pierwszy jest linkowany? Do czego jest ten drugi? #5 Copie de taskgoto.cpp, restext-old.cpp - zgaduję, że można się tego pozbyć? #6 object.cpp, kilka innych miejsc - niestandardowe użycie struktur DirectX np. operator * na najzwyklejszej strukturze D3DMATRIX. Nie ma tego w nagłówkach libwine, MSDN o nich też nic nie wspomina, nie mam pojęcia skąd to wytrzasnęli. #7 math3d.h i math3d.cpp - funkcje są typu extern inline - nie ma czegoś takiego w standardzie C++ (chociaż jest w niektórych odmianach C). Na tym wywala błąd linker GCC. #8 sound.cpp funkcja GetCurrentDir() i prawdopodobnie inne miejsca - bezpośrednie operacje na ścieżkach (parsowanie po backslashach), użycie niestandardowego _prgname - do poprawienia od razu. Jeszcze pewnie parę mi się przypomni. Od strony organizacyjnej można by pomyśleć o postawieniu np. Bugzilli czy czegoś podobnego, ewentualnie wykorzystać sam system issues Githuba. Raptor - 19-03-2012, 20:06 Co do bugów, rzeczywiście. Mogę dodać co najwyżej jeszcze jeden, bardzo niepokojący: #9 Po kompilacji i uruchomieniu gra działa na gołe oko sprawnie, jednak każda próba zapisania stanu gry (np. w swobodnej) kończy się kompletnym crash'em całej gry. Niedobrze... Widocznie modyfikacje, mające na celu zbudowanie CeeBot'ów na podstawie CoLoBoT'a spowodowały, że obecny kod jest bardzo niespójny. Bardzo niedobrze... krzys_h - 19-03-2012, 20:26
Myślałem, że to celowe działanie, ale słabo znam się na dziedziczeniu klas, więc mogę się mylić.
Patrz wyżej.
Natknąłem się na to dzisiaj, sprawdzając czy kod z GitHuba się kompiluje. Może nie chcieli z jakiegoś powodu trzymać tego w jednym pliku. Powinni na to dać jakąś oddzielną klasę z plikiem classfile.h, a nie bezpośrednio includować. Do poprawki.
Tego nie widziałem. Sprawdziłem i "winmain.cpp" nie jest linkowany (za to "winmain.rc" jest), jego rolę pewnie przejął "d3dapp.cpp" a tego zapomnieli usunąć.
Zgadłeś.
Nie znam się na tym, więc nie odpowiem.
Sam to zauważyłem i zapomniałem o tym napisać. Pokombinuję nad tym.
Ja jestem za issues, ale róbcie jak chcecie. PS. Przekopiować błędy z tego tematu do issues? (oczywiście po przetłumaczeniu na angielski) [ Dodano: 19-03-2012, 20:53 ] Ten zapis crashuje się gdzieś w "float CMainMap::RetZoomMap()", tyle udało mi się znaleść. piotrdz - 19-03-2012, 22:21
Na razie możemy używać tych issues. Tylko z czasem nam się rozrośnie ta lista i może stać to się niewygodnie - dlatego proponowałem bugzillę. A, jeszcze jeden błąd znalazłem: #10 W CBotDll.h i CBotVar.cpp. Konstruktor kopiujący:
zamienić na:
Na tym się też wykrzaczył GCC. Być może więcej tego typu błędów się znajdzie. //Coś ci to cytowanie nie wyszło  Poprawiłem. - krzys_h
krzys_h - 20-03-2012, 13:14 Skończone: https://github.com/adiblol/colobot/issues Kolejne błędy proszę zgłaszać w issues. piotrdz - 20-03-2012, 15:50
Hmm, opisy trzeba poprawić, bo nie brzmią dobrze po angielsku. krzys_h - 20-03-2012, 16:00 Wiem. Nie jestem najlepszy z angielskiego 
piotrdz - 20-03-2012, 16:20
To dodajcie mnie do projektu na githubie (mój login to też piotrdz), to poprawię to. Malcolm - 22-03-2012, 12:22 Temat postu: Re: Bugi, nieprzenośny kod, dziwne rzeczy w kodzie piotrdz: ad. 0 Na starszych msvc nie było różnicy, ponieważ na windows i tak nie możesz mieć plików o tej samej nazwie ale różniących się wielkością liter. ad. 1 oraz 2 Długo się zastanawiałem co autorzy mieli na myśli pisząc to, ale za każdym razem dochodzę do tego samego wniosku. Brak dostatecznej znajomości c++ Tak jak pisałeś, w klasie bazowej destruktor nie jest virtualny a powinien być, bo inaczej nie zostanie wywołany. Wygląda mi na to, że gościom po prostu się nie odpalał to dopisali ręcznie (lol), powiem więcej, wygląda na to, że z rozpędu dodali także ręczne odpalanie konstruktorów. Ogólnie taki kod aż prosi się o to żeby nie działać. Ręczne odpalanie konstruktorów stanowczo trzeba wywalić i dodać virtualny destruktor w klasie bazowej. P.S. Nie zmieniaj wszystkich destruktorów na virtualne! Trzeba dodać virtualne destruktory wszędzie tam, gdzie są używane virtualne metody. Znając życie to po takich zmianach i przy takiej wielkości projektu pewnie ujawnią się jakieś bugi. ad. 3 WTF? 
ad. 4 Wygląda na to, że pierwszą wersją było winmain.cpp, po zmianach zapomnieli wywalić. ad. 5 Wywal ad. 6 W którym miejscu masz tam operator? Tego nie rozumiem, chodzi ci o wskaźniki na strukturę? ad. 7 Racja, ktoś się uczył C i zabrał się za C++ 
Z drugiej strony mają dodane to http://msdn.microsoft.com...1(v=vs.85).aspx aby pozbyć się błędów kompilacji. Makabra. ad. 8 Mistrz. Kolejny dowód na brak doświadczenia i znajomości api. ad. 9 Debugger i jazda
krzys_h - 22-03-2012, 12:37 Temat postu: Re: Bugi, nieprzenośny kod, dziwne rzeczy w kodzie Jakby ktoś nie zauważył to niepotrzebnych plików już się pozbyłem. piotrdz - 22-03-2012, 14:19 Temat postu: Re: Bugi, nieprzenośny kod, dziwne rzeczy w kodzie
object.cpp i funkcja CObject::UpdateTransformObject() masz mnożenie D3DMATRIX za pomocą operatora *. Co ciekawe, mają do tego specjalnie napisaną funkcję w d3dmath.h/cpp: D3DMath_MatrixMultiply(). PS. @Adiblol, co z tym dostępem do repo? Edit: OK, dzięki Adiblol. Poprawiłem opisy. Jak będę miał więcej czasu, to zajmę się już niektórymi poprawkami. lukas_j - 24-03-2012, 21:29 Coś czuje ze będziemy musieli się nieźle namęczyć z tym kodem zeby skompilować to pod gcc... piotrdz - 25-03-2012, 14:50
No właśnie po moich poprawkach skompiluje się. Już wstawiłem część poprawek. Programerusie tłumaczy pliki alfabetycznie, więc na razie jest poprawione od autobase.cpp do list.h. Na razie czekam, aż skończy z pozostałymi plikami, to też wrzucę poprawki. Po tym wszystkim, napiszę CMakeLists.txt i sprawdzę kompilację pod mingw i powinno wszystko grać
adiblol - 25-03-2012, 15:59
piotrdz - 26-03-2012, 14:20 Jak pisałem wcześniej, z libwine są problemy. Na razie jako pierwszy cel proponuję właśnie udaną kompilację pod windowsem z cmake i mingw. lukas_j - 28-03-2012, 15:24 Dokladnie... nie ma co się bawić póki nie udało się nam tego skompilować... Najpierw spróbujmy to skompilować - potem przerabiajmy gdy wiemy, że to się kompiluje... piotrdz - 06-04-2012, 17:07 Mogę ogłosić pierwszy sukces - udało mi się skompilować i zlinkować cały kod pod CMake i MinGW
Niestety, są dwa problemy: - nie udało mi się zlinować bezpośrednio z plikami *.lib z DirectX SDK, tylko z innymi bibliotekami dla MinGW, co prawdopodobnie powoduje problemy z grafiką (efekt podobny jak na screenach w temacie o kompilacji kodu), próbowałem różnych konfiguracji z językiem i oryginalnymi plikami *.dat, ale nic nie pomaga, - żeby w ogóle udała się kompilacja, musiałem w paru miejscach zakomentować lub zmienić kod, tak, że mogą być efekty uboczne, chociaż myślę, że nic poważnego nie zepsułem. Z tego też powodu, na razie nie wrzucam moich zmian. Jak chcecie, to wrzucę to jako nową gałąź do repozytorium. Programerus - 06-04-2012, 17:55 Mówiłem, żeby zmienić urządzenie wyświetlające grafikę w ustawieniach, bo też tak miałem i pomogło. piotrdz - 06-04-2012, 18:38 Jak wybieram DirectX to jest, jak mówiłem. Jak wybiorę emulację RGB to jest niby OK, ale oczywiście nie da się grać, bo tnie się niesamowicie. Na tych samych ustawieniach działa dobrze wersja skompilowana MSVC, stąd moim zdaniem to wina tych bibliotek, których użyłem i (nie)kompatybilności DirectX. Programerus - 06-04-2012, 18:52 A nie masz trzech urządzeń? Bo ja mam Direct3D HAL i Direct3D T&L HAL, i na tym pierwszym działa źle, a na tym drugim dobrze. krzys_h - 06-04-2012, 21:36
Wrzucaj jako nową gałąź, potestuje, czy nie ma jakichś błędów ubocznych i spróbuję uporać się z problemem z grafiką. [ Dodano: 06-04-2012, 21:40 ] A ja mam jeszcze jakieś inne urządzenie: "Intel(R) HD Graphics Fa..." I dalej jest uciete bo za dluga nazwa piotrdz - 06-04-2012, 23:21 @Programerus: W obu przypadkach jest to samo. Dokładniej, teraz już wiem w czym tkwi problem i tyczy się to samego SDK DirectX, a nie tych bibliotek do MinGW. Według projektu visuala, powinno się linkować z plikiem d3dx.lib. Tylko tutaj linker MinGW wywala błędy: undefined reference to _CxxThrowException i kilka innych. Można za to zlinkować z innymi plikami np. d3d8.lib, tylko wtedy grafika wygląda tak, jak mówiłem. Z tego co czytałem na forach, to niestety ten plik d3dx.lib współpracuje tylko z MSVC. W każdym razie, wrzucę jako nową gałąź - może komuś się uda rozwiązać ten problem. Raptor - 06-04-2012, 23:43 Przyklejam. Temat ważny. piotrdz - 14-04-2012, 13:13 Widzę, że nikt nie zainteresował się tematem, a gałąź mingw już dodałem tydzień temu. Ale trzeba się za to wziąć i wyjaśnić ostatecznie ten problem grafiki. Dodałem teraz poprawki tak, że kompiluje się wszystko zarówno pod MinGW, jak i VisualStudio 2010. Dodałem też pliki projektu MSVC i instrukcję jak skompilować i uruchomić program. Potrzebuję, żeby ktoś skompilował u siebie tą gałąź (pod MinGW albo MSVC, nieważne) i sprawdził, jak działa grafika. U mnie wygląda to tak: oryginalny projet1.exe i ten skompilowany, który ktoś wstawiał na forum działa dobrze. Natomiast nie mogę u siebie skompilować i uruchomić dobrze kodu i nie wiem, czy to w końcu wina kompilatora, czy wersji DXSDK jakiej używam, czy może jakoś źle ustawiam language.h. Programerus - 14-04-2012, 16:55 Niestety grafika się psuje. piotrdz, po której poprawce zaczęło się tak dziać? piotrdz - 14-04-2012, 17:14 No właśnie, jak mówiłem, nie udało mi się jeszcze skompilować kodu, nawet oryginalnego tak, żeby grafika dobrze działała. Myślałem, że psuje się, bo jest jakaś niezgodność z DirectX czy źle ustawiałem coś w language.h. Ale to w ogóle nie powinno się dziać, bo przecież nie zmieniałem niczego w kodzie grafiki. Kompilowałeś pod MinGW czy MSVC? I zmieniałeś coś w language.h? Programerus - 14-04-2012, 17:41 Kompilowałem pod MSVC. I kombinowałem z różnymi ustawieniami language.h i plików .dat piotrdz - 14-04-2012, 21:49 Sprawa już częściowo wyjaśniona. Na chwilę obecną wygląda to tak: Kod kompiluje się i grafika działa pod MS VC6. Kod kompiluje się, ale grafika nie działa pod VisualStudio 2008, 2010 i MinGW. W takim razie, przerzucam zmiany do głównej gałęzi. |
