Często spotykam się z zakomentowanymi całymi fragmentami kodu ale rozumiem Twój punkt widzenia.
Tu nie chodzi o punkt widzenia – zbędny kod zawsze usuwa się z projektu.
Natomiast jeśli już z jakiegoś powodu decydujemy się na pozostawienie zaremowanych fragmentów lub nawet całych metod, to wypada w komentarzu napisać o co chodzi, tak aby inny użytkownik wiedział czy to backup, czy inny sposób implementacji czy jeszcze coś innego.
Ach ta wygoda zaznaczenia katalogu do archiwum..
Lazarus ma proste narzędzie do ”publikowania” kodu – menu Project, pozycja Publish project.
Tutaj skupiasz się na elementach w odniesieniu do grafiki.
Tak, dlatego że Twój projekt będzie w przyszłości pobierany przez wiele osób i każdy będzie się zastanawiał dlaczego mu ekran tak miga podczas zabawy wężem. Jeśli nie zamierzasz w przyszłości zajmować się grafiką dla okienkowego UI (np. tworzeniem komponentów) to z tych uwag mogą skorzystać odwiedzający ten wątek.
Zauważ, że dla mnie ważniejszy jest sam algorytm działania węża.
Tutaj też mam uwagę – spróbuj implementować tego typu listy w taki sposób, aby wszystkie elementy takiej listy były używane. Obecnie masz to zrobione w ten sposób, że ostatni element listy nie jest w ogóle wyświetlany.
Nie wpadłbym na to, gdybym nie spróbował przeportować tego kodu, wymieniając macierz na generyczną listę. Kod przepisałem i ciągle dziwiłem się dlaczego głowa węża (ostatni segment) jest przyklejona do lewego górnego rogu okna, czyli jeden z punktów ostatniego segmentu cały czas posiada współrzędne 0,0
. Sądziłem, że popełniłem błąd podczas przepisywania kodu i coś pominąłem. A tu okazało się, że wszystko jest w porządku oprócz renderowania – użyłem pętli for in
i renderowałem wszystkie segmenty.
Całe zamieszanie wzięło się z pokrętnej deklaracji macierzy przechowującej segmenty:
const maxParts = 10;
var
arm : array[0..maxParts+1] of TArm;
Jeśli już używasz stałej określającej rozmiar macierzy, to powinna ona przyjmować wartość faktycznie zgodną z liczbą elementów. Twoja stała informuje, że macierz zawiera 10
elementów, tymczasem zawiera ich 12
. Nie chodzi tu o tę jedną zarezerwowaną komórkę (pomijaną podczas renderowania), a o indeksację macierzy od 0
. Jeśliby nie używać tej dodatkowej komórki, to w dalszym ciągu macierz zawierałaby o jedną komórkę za dużo.
Tymczasem schemat jest prosty – stała powinna określać rzeczywisty rozmiar macierzy. Przykład:
const
SEGMENTS_COUNT = 10;
var
Segments: array [0 .. SEGMENTS_COUNT - 1] of TSegment;
Jeśli macierz ma zawierać ten jeden dodatkowy element na końcu (zarezerwowany) to w ten sposób:
var
Segments: array [0 .. SEGMENTS_COUNT] of TSegment;
Aby móc wygodnie odwoływać się do dwóch specjalnych komórek (ostatniej używanej oraz zarezerwowanej) warto zadeklarować sobie dodatkowe stałe z ich indeksami:
const
SEGMENTS_COUNT = 10;
const
SEGMENT_RESERVED = SEGMENTS_COUNT;
SEGMENT_LAST = SEGMENT_RESERVED - 1;
var
Segments: array [0 .. SEGMENTS_COUNT] of TSegment;
Niby to takie pierdoły, ale w szerszej perspektywie właściwa deklaracja zmiennych pozwoli zwiększyć elastyczność kodu i oszczędzić czas. Jeśli trzeba będzie zmienić rozmiar macierzy to wystarczy zmienić wartość jednej stałej, a reszta kodu sama się dostosuje do zmian.
btw, drzewo zrobię w przyszłym tygodniu.
Z tym drzewem to akurat tak się złożyło, że w piątek byłem na małej wycieczce i gapiąc się godzinę za okno samochodu zastanawiałem się nad narzędziem do proceduralnego generowania piksel-artowej roślinności podatnej na odkształcanie (głównie w wyniku działania wirtualnego wiatru).
No i akurat tak się składa, że tego typu drzewka powinny być reprezentowane przez drzewiastą strukturę połączonych ze sobą segmentów, a wyginanie całych gałęzi byłoby niczym innym jak specyficzną implementacją właśnie algorytmu kinematyki odwrotnej. :]