Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

[c++][visual studio 2013] Przycinanie się programu w trybie release

Ostatnio zmodyfikowano 2018-12-25 19:58
Autor Wiadomość
Wicon
Temat założony przez niniejszego użytkownika
[c++][visual studio 2013] Przycinanie się programu w trybie release
» 2018-12-10 22:20:10
Witam. Napisałem grę RPG 2D w SFML. Zajęło mi to parę lat, napisałem sporo kodu, wszystko działało bez zarzutu, cały czas stabilne 60fps, przynajmniej gdy kompilowałem kod w trybie debug. Problemy się zaczęły, gdy postanowiłem skompilować go w trybie release.

Pierwszy problem jaki się pojawił był taki, że w trybie release wyskakiwał błąd uniemożliwiający kompilacje:
Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(607,5): error MSB6006: "link.exe" exited with code -1073741819.

Visual studio zaczął kompilowac kod, stopniowo zwiększając zużycie RAM aż do 4GB, po czym zużycie RAMu przez niego spadło znów do 300MB i wtedy wywalił się ten błąd. Nie jest to raczej wina zbyt małej ilości pamięci (mam 32GB).

Tymczasowo rozwiązałem ten problem zmieniając właściwości projektu: C/C++->Optimization->Optimization z Maximize Speed na Disable.
Program się skompilował, przerzuciłem wszystkie pliki do folderu Release, odpaliłem. I gra co prawda działa, ale zaczęła się przycinać.
Ilość fps sprawdzałem frapsem oraz programem MSI Afterburner. W trybie Debug jest cały czas 60fps, licznik nawet nie drgnie. W trybie release licznik cały czas skacze w granicach 57-60 fps i momentami pojawiają się przeskoki. Np. ruszam myszką ruszam i nagle kursor zamiast płynnie się przesuwać przeskakuje z jednego miejsca ekranu do drugiego. Przemieszczam swoją postać przemieszczam i tak samo, nagle postać przeskakuje tak jakby program złapał freeza i po chwili się odwiesił. Nie sądzę aby to była wina optymalizacji, skoro w trybie debug działa normalnie, chociaż pewności nie mam. Zużycie procka jest na poziomie 15%, z czego na jednym wątku oscyluje od 50% do 100% (60fps). Reszta rozkłada się na inne wątki po 0-15%. W programie wykorzystałem wątki do wczytywania świata w czasie rzeczywistym (duży świat), do wyświetlania loading screenów, do wczytywania plików dubbingu oraz do zmieniania muzyki między walką a swobodnym przemierzaniem świata. Myślałem, że może główny wątek jest słabo zoptymalizowany, ale freezy są nawet w menu, gdzie żadne funkcje obsługujące świat nie są wykonywane. Co więcej, po wyłączeniu sync. pionowej program działa w 200fps a w menu nawet 3000-4000 fps, a mimo to nawet przy tej ilości klatek są freezy. (w programie korzystałem z funkcji sf::sleep, ale nie w wątku głównym , tylko żeby uśpić pozostałe wątki, które nie muszą wykonywać żadnej pracy). Myślę więc, że to musi być przez ustawienia we właściwościach projektu, ale nie mam pojęcia co tam może być nie tak. Próbowałem włączać/wyłączać różne właściwości optymalizacji, próbowałem ustawiać wszystko jak w trybie debug (zmieniałem ręcznie, może coś pominąłem), nic nie pomogło. Jeśli nie to, to co może być przyczyną takiego stanu rzeczy? Chcę skompilować program w release żeby program działał na komputerach na których nie ma zainstalowanego programu visual studio, może da się to osiągnąć w inny sposób?
P-173187
Wicon
Temat założony przez niniejszego użytkownika
» 2018-12-17 11:35:45
Póki co problem wydaje się być rozwiązany choć nie w 100%, bo błąd z zaznaczoną opcją optymalizacji Maximize_Speed nadal występuje, ale kompiluje się z wyłączoną optymalizacją, w trybie Release i już się nie przycina, więc mój cel został osiągnięty. Napiszę więc co zrobiłem, choć nie było tego tak naprawdę wiele.

Otóż utworzyłem nowy projekt i tam na nowo utworzyłem wszystkie pliki projektu i przekopiowałem do nich kod ze starego projektu. Pobrałem również nową wersję bibliotek SFML-a (2.5.1), wcześniej korzystałem z (2.4.2). Nie wiem czy to była kwestia utworzenia nowego projektu czy pobrania nowej wersji bibliotek, w każdym razie wykonanie tych dwóch czynności pomogło i mam stabilne 60fps. Co więcej przejście na nową wersję bibliotek sprawiło, że wszystkie pliki wczytują się o wiele szybciej, ekrany ładowania znikają po sekundzie, przy starcie programu pliki zamiast ładować się jak wcześniej 20-30 sekund ładują się poniżej 5 sekund.

(Póki co nie zamykam tematu, jeśli uda mi się skompilować kod z włączoną optymalizacją we właściwościach projektu to dam znać co było nie tak)
P-173275
pekfos
» 2018-12-17 12:40:01
Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(607,5): error MSB6006: "link.exe" exited with code -1073741819.
Masz najnowsze patche zainstalowane? 2013 było 5 lat temu, najlepiej przesiądź się na 2017, albo chociaż jego toolset, jeśli można go pobrać osobno do 2013.

Nie sądzę aby to była wina optymalizacji, skoro w trybie debug działa normalnie, chociaż pewności nie mam.
Jeśli winne są optymalizacje, to zwykle oznacza błąd w kodzie.
P-173276
Wicon
Temat założony przez niniejszego użytkownika
» 2018-12-17 13:26:41
Próbowałem chyba już kiedyś na 2017 się przesiadać ale wywalało mi tam błędy związane z includowaniem plików projektu. Może też właśnie to jest teraz problem. Sprawdzałem dla testu na osobnym projekcie w 2017 i zrobiłem plik main.cpp i 2 pliki .hpp. I jak includowałem je tylko w main to się kompilował a jak jeden plik .hpp includowałem w drugim pliku .hpp i do tego obydwa w main to już się nie kompilował. Jak będę miał trochę czasu to coś z tym pokombinuje, może to przez to.

EDIT: Najprawdopodobniej źle podzieliłem kod na pliki. Nie tworzyłem plików .cpp dla każdego z plików .hpp tylko cały kod waliłem w plikach .hpp. Najprawdopodobniej również w zły sposób mam zadeklarowane zmienne globalne. Deklarowałem je w utworzonym pliku GLOBAL.hpp i includowałem go we wszystkich innych plikach .hpp oraz w main.cpp. Dokształcam się właśnie jak to powinno wyglądać. Powinienem utworzyć zmienne globalne i przypisywać im początkową wartość (jeśli posiadają) pomiędzy includowanymi plikami a funkcją main, a w pliku GLOBAL.hpp utworzyć je ze słowem kluczowym extern bez przypisywania wartości? Resztę plików podzielić na .hpp (deklaracje) i .cpp (definicje) a jeden plik źródłowy dołączać do drugiego pomiędzy
#ifndef #define
 a
#endif
, tak? Dobrze to rozumuję? Sprawdzałem na testowym programie i działało, przerobienie kodu gry w ten sposób zajmie mi trochę czasu.
P-173277
pekfos
» 2018-12-20 23:44:22
Plik .cpp ma zawierać rzeczy, które nie mogą się powtarzać, a .hpp rzeczy które mogą, lub muszą się powtarzać.
CPPHPP
  • Definicje funkcji
  • Definicje zmiennych
  • Deklaracje funkcji
  • Deklaracje zmiennych (extern)
  • Definicje typów
  • Definicje funkcji inline/szablonowych
Pamiętaj, że pliki nagłówkowe są wyłącznie po to, by nie kopiować kodu. Możesz mieć wiele plików cpp i ani jednego hpp.
P-173293
Wicon
Temat założony przez niniejszego użytkownika
» 2018-12-23 21:38:37
Poprawiłem cały kod. W plikach .hpp deklaracje funkcji, zmienne globalne w pliku GLOBAL.hpp (extern) oraz w pliku main.hpp z nadanymi wartościami początkowymi. Wszystko między
#ifndef #define
 a
#endif
. W plikach .cpp definicje funkcji. Niestety błąd nadal się pokazuje z włączoną optymalizacją. Jeśli wyłączę optymalizację program kompiluje się bez przeszkód i działa jak trzeba(cały czas mowa o release). Zaktualizowałem visual studio 2013, próbowałem kompilować na visual studio 2017, również zaktualizowanym i wygląda to identycznie. Pytanie, czy koniecznie muszę kompilować kod z tą optymalizacją? Bo nie mam już pojęcia co może być nie tak.
P-173307
pekfos
» 2018-12-23 22:12:03
Byłbym bardzo zaskoczony, gdyby to coś dało. Problem jest w kodzie i nie objawi się błędem kompilacji. Możesz spróbować zwiększyć poziom ostrzeżeń i sprawdzić czy nic ciekawego się nie pojawi.
P-173308
Wicon
Temat założony przez niniejszego użytkownika
» 2018-12-24 00:51:22
Na W4 przewijały się tylko:
- possible loss of data
- signed/unsigned mismatch
- i coś tam, że mam nieużywane zmienne, przy okazji je sobie usunąłem

Gdy dałem AllWarning pojawiły się jeszcze takie:
- C4710 przykładowy:
1>E:\Programy\MSV Studio 2010\VC\include\xlocmon(232): warning C4710: 'std::string std::numpunct<char>::grouping(void) const' : function not inlined
                 E:\Programy\MSV Studio 2010\VC\include\xlocnum(92) : see declaration of 'std::numpunct<char>::grouping'
- C4820 przykładowy:
warning C4820: 'Riddle' : '3' bytes padding added after data member 'Riddle::RiddleQuest'

- C4350 przykładowy:
1>E:\Programy\MSV Studio 2010\VC\include\vector(1566): warning C4350: behavior change: 'std::_Wrap_alloc<std::allocator<_Ty>>::_Wrap_alloc(const std::_Wrap_alloc<std::allocator<_Ty>> &) throw()' called instead of 'std::_Wrap_alloc<std::allocator<_Ty>>::_Wrap_alloc<std::_Wrap_alloc<std::allocator<_Ty>>>(_Other &) throw()'
                 with
                 [
                     _Ty=CONDITION
                 ]
                 E:\Programy\MSV Studio 2010\VC\include\xmemory0(809) : see declaration of 'std::_Wrap_alloc<std::allocator<_Ty>>::_Wrap_alloc'
                 with
                 [
                     _Ty=CONDITION
                 ]
                 E:\Programy\MSV Studio 2010\VC\include\xmemory0(821) : see declaration of 'std::_Wrap_alloc<std::allocator<_Ty>>::_Wrap_alloc'
                 with
                 [
                     _Ty=CONDITION
                 ]
                 A non-const reference may only be bound to an lvalue
                 E:\Programy\MSV Studio 2010\VC\include\vector(1565) : while compiling class template member function 'void std::vector<CONDITION,std::allocator<_Ty>>::_Destroy(CONDITION *,CONDITION *)'
                 with
                 [
                     _Ty=CONDITION
                 ]
                 E:\Programy\MSV Studio 2010\VC\include\vector(967) : see reference to function template instantiation 'void std::vector<CONDITION,std::allocator<_Ty>>::_Destroy(CONDITION *,CONDITION *)' being compiled
                 with
                 [
                     _Ty=CONDITION
                 ]
                 e:\projekty\legenda rojo\projekt\legenda rojo\legenda rojo\Structurs.hpp(477) : see reference to class template instantiation 'std::vector<CONDITION,std::allocator<_Ty>>' being compiled
                 with
                 [
                     _Ty=CONDITION
                 ]

Pierwsze 3 raczej nie mają nic wspólnego z moim problemem, co do kolejnych 3 to nie wiem o co im chodzi.
P-173309
« 1 » 2 3 4
  Strona 1 z 4 Następna strona