[MS visual c++ 2008] Debug - działające, Release - błędy

Witam.

Od kilku miesięcy pisze bota do gry.
Bot ma kilka tysięcy linijek kodu. Obsługa całego protokołu gry. Nie odczytuje on danych z pamięci gry, lecz działa na zasadzie proxy, przechwytując pakiety przychodzące do klienta i generując własne informacje np. mapa, lista graczy, ekwipunek.

Natknąłem się na jeden problem.

Bot jest w pliku dll. Gdy kompiluje go w debug działa perfekcyjnie, nie ma żadnych błędów, wszystko jest ok.
Jednak gdy kompiluje go w trybie Release. Też działa, jednak coś jest źle z generowaną mapą z pakietów. Czasami na mapie się przesuwa gracz z danych xyz, a czasami nie. Co ma piernik do wiatraka ?
Dlaczego w Debug wszystko jest ok, a w Release nie. Aplikacja inaczej działa w tych trybach ? To poco jest w takim razie tryb Debug ? Żeby testować aplikacje ? Poco, jak inaczej działa w debug i inaczej Release.

Gdy ludzią chce udostępnić program, muszą tam być zawarte biblioteki Microsoftu.
Wtedy muszę dać Multi-threaded DLL. A może da się to zrobić tylko w trybie debug ? Jakoś wyłączyć optymalizacje, żeby DLL działała tak samo i żeby działała innym ludziom na ich komputerach.

Proszę o pomoc. Co jest nie tak?

Pozdrawiam.

Pewnie synchronizacja jest niedopracowana.
W trybie debug program działa ciut wolniej. Może pewna operacja wymaga dokończenia akcji ze strony gry. W debug zanim ten wymóg nastąpi gra spokojnie nadąża z wykonaniem akcji. W release wymóg pojawia się szybciej i gra nie nadąża. Stawiałbym na to, zwłaszcza, że czasami jest dobrze, a czasami źle.

około 1.5 godziny temu dosłownie przez przypadek w kilku tysiącach linijek kodu znalazłem błąd...
jedna zmienna w konstruktorze nie była wyzerowana.

W debug jakos musialo samo ją wyzerowac, w release nie.

A teraz mam pytanie ?

W takim razie lepiej chyba testować w release ? Tak się ma pewność, że aplikacja będzie działać poprawnie.

Nie. Zwiększ poziom ostrzeżeń, kompilator wtedy powie o niezainicjalizowanej zmiennej.

nie do końca opłaca się release śledzić. w debug masz informacje umożliwiające wykonywanie krok po kroku, przeglądanie stosu wywołań, ogólnie - śledzenie programu. W debug niezainicjalizowane wskaźniki mają magiczną wartość 0xCDCDCD (albo coś takiego...). W debug nie ma optymalizacji - to znaczy kod zachowuje się identycznie, jak tego oczekujesz. W release pewne rzeczy mogą zostać wycięte, jako zbędne, pętle rozwinięte, funkcje zinline'owane - i program będzie dawać te same efekty, ale bardzo trudno byłoby się połapać czasem, jak się kod wykonuje.

niezainicjalizowane zmienne mają to do siebie, że mają wartość losową. Twoja zmienna miała inne wartości w debug/release. Ale jej wartość by się zmieniła również najpewniej, gdybyś po prostu dopisał kilkanaście linijek kodu w zupełnie innym miejscu.

i to wszystko nie zmienia faktu, ze jesli autor jest tym kim mysle, powtarzam to co mowilem Ci na gg: pomysl nad przejsciem na maszyne stanow zamiast obslugiwac kazdy pakiet/wiadomosc w osobnym watku.. Twoj program ma byc w przyszlosci dosc skomplikowany i wcale nie zartuje ze pilnowanie sekwencji wykonywania sie roznych rzeczy tak u Ciebie jak i u wlasciwego klienta gry ktorego proxy'ujesz JEST ISTOTNE.

mozliwe ze obecnie po prostu przypadkiem zniszczyles ich kolejnosc wiadomosci przesylanych do klienta/serwera albo przy wiekszym pechu wrecz wcisnales tresc malej-i-szybciej-przetwarzanej w jakiejs wiekszej-i-wolniej-przetwarzanej..