Zbugowana tablica od efektów

[Exigo]

Witajcie,

kombinuję nad systemem "cząsteczek połączonych" do wizualizacji efektu śladu po silniku. Generalnie chodzi, ale czasami w ciągach występują artefakty których pochodzenia nie mogę odgadnąć. Wygląda to tak:

 

Struktura traila (poszczególne komórki):

x, y, wektor x, wektor y, życie (1-0), oraz adres na do traila z którym jest połączony.

 

Na początku deklarowana jest wartość trzymająca max. ilość cząsteczek.

GML

trail_max = 0;

 

Skrypt dodania traila:

(początek skryptu wyszukuje "pusty" slot na ustawienie na nim traila) (pusty = nieużywany)

GML

var i;

for (i = 0; i < main.trail_max; i += 1) {

if (main.trail[i, 4] == -1) {

break;

}

}

main.trail[i, 0] = argument0;

main.trail[i, 1] = argument1;

main.trail[i, 2] = argument2;

main.trail[i, 3] = argument3;

main.trail[i, 4] = 1;

main.trail[i, 5] = argument4;

if (i == main.trail_max) {

main.trail_max += 1;

}

return i;

 

Skrypt rysujący wszystko:

GML

draw_set_blend_mode(bm_add);

for (i = 0; i < trail_max; i += 1) {

if (trail[i, 4] > 0) {

trail[i, 0] += trail[i, 2];

trail[i, 1] += trail[i, 3];

 

_i = trail[i, 5];

if (_i != -1) {

draw_line_width_color(trail[_i, 0], trail[_i, 1], trail[i, 0], trail[i, 1], 4 + (8 * trail[i, 4]), make_color_hsv(0, 192, trail[_i, 4] * 192), make_color_hsv(0, 192, trail[i, 4] * 192));

}

trail[i, 4] -= .05;

} else {

trail[i, 4] = -1;

}

}

draw_set_blend_mode(bm_normal);

 

Używanie funkcji dodania traila wygląda tak, że jeśli trigger jest "pressed", tzn. pierwszy raz wciśnięty wciśnięty po przerwie, ustawiam:

GML

if _triggler_bool_press {

dev_id.my_trail_last = -1;

}

Można to zinterpretować jako "zamykanie ciągu".

W przeciwnym przypadku, czyli standardowo:

GML

dev_id.my_trail_last = add_trail(_xx, _yy, _vx, _vy, dev_id.my_trail_last);

 

Mówiąc o artefaktach, miałem na myśli to co jest przedstawione na screenie (zapomniałem wyciąć, phi):

Ślad jest poprawny (przerywany). Problemem są jednak te nagłe "skręty" które mają przemieszczenie odwrotne do wektora ciała. Tylko nigdzie nie mogę znaleźć powiązania.

 

Co jest tego przyczyną?

Będę wdzięczny jeśli ktoś wpadnie na jakiś trop. Lub ewentualnie zasugeruje lepsze rozwiązanie (np. na jakimś innej strukturze danych, nie koniecznie tablicach).

[gnysek]

A zamiast trail[i, 5] nie możesz używać trail[ i-1, X] ?

[Exigo]

Każdy trail musi trzymać indeks do następnego. To i-1 miało by to sens, jeśli istniała by tylko jedna wiązka. Ja natomiast korzystam z jednej tablicy dla nieokreślonej liczby wiązek. W takim przypadku, np. trzech wywołań add_trail co klatkę, a silniki były by ułożone szeregowo, ciąg miałby kształt harmonijki (dlatego że odwołuje się do poprzedniego indeksu który utworzył inny silnik).

[gnysek]

Wygląda, że kod jest ok, jedyne co mi przychodzi do głowy, ale raczej nie powinno mieć wpływu na te skręcone elementy:

 

GML

if (_i != -1) {

if (trail[_i,4] > 0){

draw_line_width_color(trail[_i, 0], trail[_i, 1], trail[i, 0], trail[i, 1], 4 + (8 * trail[i, 4]), make_color_hsv(0, 192, trail[_i, 4] * 192), make_color_hsv(0, 192, trail[i, 4] * 192));

}

}

[Exigo]

Dobra, jednak wystarczyło oddzielić pętlę logiki od pętli rysowania. For wykonuje się liniowo od początku do końca a rysowanie potrzebowało elementów "przyszłych" iteracji, których traily nie były <jeszcze> zaktualizowane do nowej pozycji. Stąd te artefakty w postaci przesunięć.

 

Problem można potraktować jako rozwiązany. Dzięki za pomoc. :)

[gnysek]

Aaaa, bo u Ciebie nowy trail nie trafia na koniec tablicy, a może nagle w środek, tego nie uwzględniłem, myślałem że to bardziej taki stos - to teraz sie zgadza, że element poprzedzający mógł być jeszcze nie zaktualizowany, lub już zaktualizowany

[Exigo]

Mimo wszystko wrócę do pytania związanego z metodą. Otóż przy kilkunastu aktywnych generatorach tworzących w sumie maksymalnie z 600 trailów, gra jest bardzo "żerna". Wydaje mi się że problem tkwi w pętli przeszukującej nieaktywne komórki. Jak komuś przyjdzie do głowy alternatywne rozwiązanie, niech pisze. Będę wdzięczny za jakiekolwiek pomysły.

[adam014]

Rysujesz traile w Drawie czy na surface?

[Exigo]

Zwykłe rysowanie co klatkę. Po ustawieniu traile stale zmieniają pozycje co ustalony wektor, tak więc każdorazowo trzeba je przerysowywać. Tip w stylu pakowania traili do surface i stopniowe fade-owanie wszystkiego nie zadziała (właśnie ze względu na konieczność każdorazowego rysowania). Choć powiem szczerze że z początku myślałem o tym.

[gnysek]

600 rzeczy to dużo, tym bardziej w GM 8.1. Jedyne co mi przychodzi do głowy, to jak jakiś trail jest już nieaktywny, to wszystkie następne cofać o 1 i zapamiętywać ile ich jest. Raz, ze jak dodasz nowego to zawsze trafi na koniec i od razu wiesz który element jest pusty, dwa, że wtedy nie przeskakujesz wszystkich elementów. Nie mniej jest ich stanowczo za dużo. No i ja bym spróbował na vertexach i nie tak gęsto.