Wadliwa pamięć, czyli dlaczego wspomnienia o Windows Vista to stek bzdur

Doprawdy, fascynującym narządem jest ludzki mózg. Natura obdarzyła go w przydatny lub też nie, mechanizm wypierania traumy, przykrych wspomnień czy też innych nieprzyjemnych dla człowieka informacji z życia. O ciekawostce tej przypomniałem sobie w chwili czytania komentarzy wspominkowych o systemie Windows Vista. Nie dość że przykre wspomnienia zostały wyparte to w ich miejsce pojawił się obraz, absolutnie nie mający, z rzeczywistością, nic wspólnego.

Programistyczne niechlujstwo

System Microsoftu w chwili premiery miał sztucznie zaniżone wymagania sprzętowe.

Wszystko szczelne, czyli wykrywamy wycieki do pamięci w aplikacji C++ w systemach Microsoft Windows

Praca z językiem C/C++ daje spore możliwości w kwestii alokowania pamięci. Niestety, jak to zawsze w życiu bywa, w parze z dużą władzą idzie również spora odpowiedzialność. Najlepszą praktyką unikania błędów jest pisanie kodu, który ich nie zawiera – oczywiście jest to czysty truizm gdyż nie myli się ten kto nic nie robi. Pozostaje więc pytanie: jak żyć z alokowaniem pamięci na stercie?

W systemach GNU/Linuks programista ma do swojej dyspozycji wygodne i popularne narzędzie: Valgrind.

Notatki programisty: integracja edytora z rdzeniem aplikacji SFML/Box2D

Słowem wstępu: jest to już piętnasty wpis z serii „Notatki programisty”. Przez ostatnie czternaście wpisów kod rozrósł się do dość pokaźnych rozmiarów. Według SourceMonitora kod zbliża się do granicy 4 tysięcy linii kodu, czy to dużo czy mało. Trudno mi powiedzieć. Mimo wszystko: uznałem że jest to doskonały moment do publikacji całego prezentowanego projektu w ramach artykułów. Przy prezentowaniu kodu, niestety, nie obyło się bez drobnych potknięć. Opublikowany kod posiada naniesione poprawki do błędów wykrytych przy integracji kodu.

Notatki programisty: Modelowanie świata i modyfikacje edytora dema technologicznego SFML/Box2D

W poprzednim wpisie zaprezentowane zostały podstawy funkcjonowania edytora siatkowego do naszego dema. W niniejszym wpisie wprowadzimy do niego kilka kluczowych zmian. Co więcej przygotujemy rdzeń naszej aplikacji pod przyszłą obsługe modelu mapy. Zapraszam do lektury.

Jeśli coś to tam ktoś, jeśli ble to mi się chce

W poprzednim wpisie została przedstawiona prosta klasa do rysowania mapy. Niestety, główna funkcja rysująca opierała się o szereg warunków które decydowały o tym jak będzie wyglądać rysowany obiekt.

Notatki programisty: deska kreślarska jako podstawa projektowania, czyli piszemy edytor mapy siatkowej

W poprzednich wpisach omówiłem pokrótce zasadę działania rdzenia, gier platformowych 2D, wykorzystującego zaawansowaną fizykę. Jak mogliśmy zauważyć w poprzednich przykładach, proces tworzenia obiektów był dość "kodochłonny". W niniejszym tekście zaprezentuje pierwszy krok, który w przyszłości zapewni nam dużo łatwiejsze projektowanie poziomów naszego dema.

Grunt to model

Zacznijmy od konceptu, mianowicie nasza mapa siatkowa będzie prostą dynamiczną tablicą dwuwymiarową zasymulowaną w kodzie wektorami.

Notatki programisty: Czuj się Disneyem, czyli o animacji słów kilka

Niniejszy wpis zaczniemy od omówienia tego jak działają animowane sprite’y w grach. Przechodząc do sedna sprawy: mechanizm animacji w prostych grach 2D polega na tym samym co i w kreskówkach. Cały sekret i magia. ;) Mamy animacje która podzielona jest na pojedyncze klatki które zmieniane są co określony przedział czasowy. W przypadku aplikacji, animację przeważnie zapisujemy do tekstury która później w kodzie jest odpowiednio obsługiwana. W niniejszym wpisie zaprezentuje jak będzie wyglądać nasza klasa do obsługi takiej tekstury.

Notatki programisty: Dobra zmiana, czyli restrukturyzacja aplikacji Box2D/SFML

Czasem aby zrobić dwa kroki do przodu, trzeba zrobić jeden w tył. Ta myśl zawitała w mojej głowie gdy zastanawiałem się nad tematem kolejnego wpisu z serii. W poniższym tekście poprawimy część założeń projektowych, rozwiniemy istniejące mechanizmy i wzbogacimy aplikację o nowe funkcje. Zapraszam do lektury.

Kroki w przód, kroki w tył

Przeglądając kod zaprezentowany w poprzednim wpisie doszedłem do wniosku że trochę się zapędziłem z „ewolucją” klas. Dotychczas prezentowała się ona następująco:

b2Body › DrawablePolygonBody › MovableBody

Notatki programisty: zawód? Magazynier, czyli piszemy menadżer zasobów w aplikacji SFML/Box2D

W miarę jak rozrasta się nasz projekt, ilość zasobów z jakich jesteśmy zmuszeni skorzystać niebywale rośnie. W niniejszym wpisie przedstawię swój patent na zarządzanie zasobami. Co więcej, uporządkujemy sekcje kodu odpowiedzialną za zachowanie przeciwnika. Zapraszam do lektury.

Dekorujemy poczwarę

W poprzednim wpisie, argumentowałem oddzielenie kodu odpowiedzialnego za sprawdzanie czy przeciwnik widzi gracza od kodu odpowiedzialnego za kolizję tym że w przyszłości ten niewydajny podział ułatwi nam napisanie klasy dekorującej dla obiektów przeciwnika.

Notatki programisty: im nas więcej tym weselej, czyli porządkujemy kod i tworzymy grupę niezależnych przeciwników

W poprzednich przykładach, nasz gracz miał do czynienia tylko z jednym przeciwnikiem. W niniejszym wpisie chciałbym zaprezentować dość schludny, moim zdaniem, sposób zarządzania większą ilością obiektów na ekranie a także rozwiniemy istniejące rozwiązania do wyższych abstrakcji. Zapraszam do lektury.

Zaczyna się od porządku, jak w wojsku

Już w poprzednim wpisie pominąłem znaczną część kodu funkcji głównej ze względu na jego niezmienność i „klocowatość”.

Notatki programisty: czyje to zwłoki? Czyli identyfikujemy ciała biorące udział w kolizji

W poprzednich przykładach korzystaliśmy z systemu wykrywania kolizji który pozwalał jedynie na odczytanie informacji jakiegoś typu zdarzenie miało miejsce. Rozwiązanie jednak jest nie wystarczające w sytuacji w której to chcemy pobrać informację o ciałach które biorą udział w zdarzeniu lub policzeniu ile razy jednocześnie dane wydarzenie miało miejsce. W poniższym wpisie zaprezentuje nowy mechanizm który da nam większą kontrolę na tym co się dzieje na naszym podwórku. Zapraszam do lektury.