SimianVirus7

Myślałem myślałem i nie wiem do czego się przyczepić 😁Widzę, że używa Pan Spine. Pytanko takie, czy w spine można ustawić dźwięk i odgrywać go w game maker?

Świetnie to wszystko wygląda. Zmiana graficzna niczym z Rogue Legacy 1 na Rouge Legacy 2, a to wszystko w przeciągu jednego dema 😄 Te wstawki z twoim avatarem i generalnie cała forma prezentacji - no przyjemnie się to ogląda. Szczególnie język polski na + 😄 Dodane do wishlisty, będzie grane, nawet już saldo przygotowane 😁

Ja osobiście zawsze mu dziękuje za wypowiedź, żeby był dla mnie łagodniejszy przy buncie maszyn.

Dziękuje za miły odzew. Zaktualizuje zatem parę rzeczy i wstawię na nowo, na razie z wyświetleń i tak nic nie stracę 😆 No teraz to się trochę zdziwiłem. Już tak z przyzwyczajenia chyba nie zauważyłem tego faktu. Pewnie, że tak. Miałem zamiary zrobić też lektora po polsku, ale nie wiem czy to nie będzie przerost formy nad treścią, może same napisy by jednak wystarczyły. Z drugiej strony taka właśnie forma narracyjna sprawia, że nagranie polskiego głosu nie byłoby trudne.

Postanowiłem zrobić poradnik dość ciekawego efektu destrukcji otoczenia, coś a la wormsy. Nie wiedziałem, że tworzenie poradnika jest takie stresujące i czasochłonne. Zanim opublikuje go na YT chciałbym poznać waszą opinię: - ogólna jakość poradnika - merytoryka - mój angielski którym ostatni raz porozumiewałem się z moją panią od angielskiego w technikum parę lat temu (wymowa typu "egzampul, ziroł, du dis.). Są napisy dla tych którzy wyłączą dźwięk ale nadal chcieliby obejrzeć. (Odkąd usłyszałem swoją wymowę to przestaje się śmiać z hindusów na YT) Po obejrzeniu go zrozumiałem, że to bardziej narracja tego co robię niż typowy poradnik, ale może akurat taka forma wypadnie dobrze. (dorobię polskie napisy jeśli będzie zielone światło)

Dużo napracowanka. Przyznaje, nie kupiłem, ale komentarz zostawiłem. Choć zastanawiam się, bo dużo spójnie narysowanych postaci, a ja w swoich dungeon crawlerze mam wszystko z innej parafii.

Gra faktycznie mocno trudna. Horda przeciwników przenikający przez ściany, mrówki koloru czarnego na czarnym tle strzelające rakietami, no i ten przerażający gość, który ma mnie na strzała: No ale da się odpalić na windows 11, także plus. Trochę uciążliwe jest ciągłe klikanie myszką, ja bym zmienił na zwykłe przytrzymanie.

Zrobiłem surface o wymiarach x4 i przeskalowałem w dół i faktycznie daje to zamierzony efekt. Pytanie jak bardzo wpływa to na wydajność, bo jeden surface ok, ale jak się ma takich kilka? Będę chyba musiał wymyślić coś innego. Próbowałem, to samo 😕 Zrobiłem surface_get_width/height(application_surface) i dało wymiar Viewport Properties (okno wyświetlania gry) czyli 1920x1080, a room i camera ma 960x540 🤔 Czyli faktycznie application_surface ma 2 razy bardziej zagęszczone pixele i pewnie przez to nie przeskakują... taki antyaliasing EDIT: Tak, kiedy zmienię wszystko na jednakową wartość, czyli 1920x1080 i application_surface ma zagęszczenie 1:1 to piksele też przeskakują 🙂

Tak, zapomniałem dodać, że w opcjach mam odhaczoną opcję "Interpolate colours between pixels" ze względu na pixelart. W Twoim przykładzie jest ta sama sytuacja, kiedy ją odhaczę. Gdzieś czytałem, że to ze względu, że application_surface jest rysowana w większej rozdzielczości i skalowana do niższej. Nie wiem na ile to prawda i jak to faktycznie miało by działać i dlaczego akurat w ten sposób. Kod w tym wyjaśnieniu był mniej więcej taki (nie mogę tego teraz znaleźć): draw_surface_ext(application_surface,0,0, 0.5, 0.5,0,c_white,1); - gdzie 0.5 to xscale/ysclae; Zabawnie robi się wtedy, kiedy surface utworze o wymiarach spritu (sprite'u?... duszka? 😄) i obracam całym surface, a nie spritem. Wtedy przeskakiwanie pikseli nie występuje, a zachowuje się tak samo jak na application_surface.

Zrobiłem nowy surface o wymiarach pokoju i rysuje sprite na x/y. Obracając nim pixele przeskakują, gdzie na application surface tego nie robi [gif podglądowy]. Gra startuje w rm_init o właściwościach: Room Settings: 1920x1080 Camera Properties: 1920x1080 Viewport Properties: 1920x1080 Po czym przechodzi na właściwe pokoje o właściwościach: Room Settings: 960x540 Camera Properties: 960x540 Viewport Properties: 1920x1080 Zmiana rm_init na te same wartości co wszystkie pozostałe daje ten sam efekt 😕 Próbowałem coś z aa_display, gpu_set_texfilter ale albo wywalało cały surface, albo rozmazywało wszystkie sprity. (faktycznie dość słaba jakość tego gifa, ale na rękach - niebieskich plamach, widać o co mi chodzi. Po lewej piksele przeskakują, a po prawej nie) Kod surface: //surf = surface_create(room_width, room_height); // -> w create event surface_set_target(surf) draw_clear_alpha(0,0) draw_sprite_ext(sprite_index, image_index, x, y, 1, 1, image_angle, c_white, 1); surface_reset_target(); draw_surface(surf,0,0);

Miałem robić tą grę na konkurs, ale tak mi się nie chciało, że postanowiłem uderzyć w końcu w shadery i trochę się ich poduczyć. To mój trzeci i jak na razie jestem bardzo zadowolony. - można wybrać barwę - próg koloru - próg blendowania / przejścia pomiędzy kolorem a skalą szarości.

Oszem, według mojej wiedzy jest zasobożerne. Ja znalazłem na to dwa rozwiązania w swoim projekcie. a) zmiana collision_circle na collision_rectangle - Wiem, że nie zawsze jest to możliwe, ale np. jeśli robisz pole widzenia przeciwnika, to czy circle czy rectangle, efekt jest bardzo do siebie podobny. ( u mnie przy 100 obiektach to uzyskanie 1000fps więcej... dużo.) b) To co najbardziej zwiększa wydajność, to przerzucenie tej funkcji na ten "konkretny typ obiektu" który ma Ci znaleźć. Przykład: - masz 100 przeciwników którzy patrolują teren i sprawdzają czy widzą obiekt gracza np. oPlayer, a więc masz 100 razy collision_circle. Możesz odwrócić sytuacje i to graczowi dać collision_circle czy widzi przeciwników, jeśli tak, zrób np. oEnemy.widze_gracza = true; Wtedy collision_circle występuje tylko 1 raz; Pamiętaj, że zawsze możesz zrobić rodzica obiektów, np. nie musisz pisać collision_circle_list(x, y, 100, oEnemy1); collision_circle_list(x, y, 100, oEnemy2); collision_circle_list(x, y, 100, oEnemy3); collision_circle_list(x, y, 100, oEnemy4); tylko wrzucić jako child do pustego obiektu, np. oEnemies i wtedy collision_circle_list(x, y, 100, oEnemies); PS: Listę tworzymy w create, jeśli damy to w innym miejscu, step czy draw, będzie się ona tworzyć bez końca aż zapełni całą pamięć RAM. Tworzenie jej w step i od razu niszczenie jej przy pomocy ds_list_destroy(), kiedy już zrobi swoje, też negatywnie wpływa na fps;

Wróciłem do robienia dinozaura z bronią po dłuższej przerwie. Chciałem najpierw zrobić krótkie zestawienie co od tamtej pory zakodowałem, ale dzisiaj zrobiłem możliwość podpalenia dosłownie każdego obiektu w grze i jestem na tyle zadowolony, że się pochwalę (tak, wiem o dropie fpsów) DUG_iseeworlonfire.mp4

tak tak, problem mam z tym, że ja w funkcji nie wiem jaka jest nazwa tej zmiennej w instancji. Niektóre mają sndPlayer a inne inaczej, dlatego chciałbym przesyłać odwołanie do zmiennej. Odwołanie, a nie przypisanie, bo chciałby też wiedzieć kiedy ta zmienna jest wykorzystywana (audio_is_playing). No nie potrafię tłumaczyć albo za dużo wymyślam

O! Bardzo prawdopodobnie, że tego właśnie szukałem. Robiłem też return sound_player zamiast true, ale to nic nie dało. Na razie zrobiłem to po normalnemu, czyli tak jak Gnysek napisał, ale chciałem to sobie zrobić bardziej elastycznie. Prościej mówiąc, chcę uniknąć pisania za każdym razem if(!audio_is_playing(sndPlayer)) a dodatkowo kiedyś też miałem problem właśnie z tym przesyłaniem zmiennych, gdzie zmienna w funkcji i instancji miała być tą samą.

Nie wiem jak o to zapytać w googlach po angielsku, więc zapytam na gmclanie po polsku. Jak przesłać odwołanie do adresu zmiennej w pamięci a nie przypisanej wartości do funkcji. np. mam w obiekcie create: sndPlayer = 1; //to ma robić coś w deseń Sound Instance ID step: play_sound(sndSound1, 1, 1, sndPlayer); a w funkcji: function play_sound(snd, gain = 1, pitch = 1, sound_player = -1) { if(sound_player != -1) if(!audio_is_playing(sound_player)) {sound_player = audio_play_sound(snd, 1, false, gain,0, pitch); return true;} } No to i tak odtwarza dźwięk co klatkę, zamiast czekać aż się zakończy, bo pewnie przesyła wartość zmiennej czyli 1. Jak zrobię na sztywno, czyli tak: function play_sound(snd, gain = 1, pitch = 1) { if(!audio_is_playing(sndPlayer)) {sndPlayer = audio_play_sound(snd, 1, false, gain,0, pitch); return true;} } No to działa elegancko. Chyba, że gmlu czegoś takiego nie ma, bo z tego co kojarzę to jakieś pointery to w c++ są Nie chce robić zmiennych globalnych, bo wiele obiektów ma zmienną sndPlayer. Szukam czegoś w stylu get_variable_address(sndPlayer)

draw_set_halign(fa_left) // wypisuje od lewej, nie będzie rozjeżdżania ewentualnie var _offset = string_width(Global.local_question)/2 //pobierz szerokość wypisanego tekstu draw_set_halign(fa_center) draw_text(x + _offset, y, Global.local_question);

Potrząśnie się słabo i zatrzyma. Generalnie miało to tak wyglądać ale teraz wpadłem na pomysł, że w sumie mogę zrobić X na kursorze i uniemożliwić wyrzucenie.

Tzn ja już kolizję mam zrobioną. W pierwszej fazie lotu jej nie ma, tak aby można było przerzucić granat nad ścianami. Dopiero przy pierwszym odbiciu kolizja jest włączona i wtedy granat może odbić się od solidu. (cień nie zrobiony, nie tykałem tego jeszcze, tylko patrzyłem czy ogólnie działa) Untitled Project.mp4

Tak ?Dziękuje bardzo, wszystko działa ?

No witam, a ja znowu z tymi granatami. Zrobiłem lot granatu po zakrzywionej linii, tak jak @Uzjel narysował. Teraz mam zagwozdkę jak zrobić do niego cień. Gdyby to była platformówka, to bym sobie pewnie poradził, ale tu już wchodzi większa matematyka. Kod kiedyś ogarnął mi @Konrad-GM i to jest cała mechanika lotu: CREATE: ghost_x = x; ghost_y = y; target_x = x + lengthdir_x(15+speed, dir) + lengthdir_x(10, dir-90); target_y = y + lengthdir_y(15+speed, dir) + lengthdir_y(10, dir-90); start_distance = point_distance(ghost_x, ghost_y, target_x, target_y); STEP: // poruszamy obiektem w kierunku celu var angle = point_direction(ghost_x, ghost_y, target_x, target_y); var spd = 5; ghost_x += lengthdir_x(spd, angle); ghost_y += lengthdir_y(spd, angle); // liczymy aktualna odleglosc var distance = point_distance(ghost_x, ghost_y, target_x, target_y); var angle90 = angle + 90 * image_yscale; // glowna funkcja przesuniecia var factor = sin((distance / start_distance) * pi); var maxlen = sqr(log2(start_distance)); var offx = lengthdir_x(maxlen * factor, angle90); var offy = lengthdir_y(maxlen * factor, angle90); // dodajemy przesuniecie do realnej pozyci obiektu x = ghost_x + offx; y = ghost_y + offy; Wynik: granade_cien.mp4 Jakieś nakierowania, pomysły? Znam początkową pozycje granatu, miejsce gdzie wyląduje oraz x/y aktualnej pozycji i nie wiem jak to posklejać, żeby cień rysował się mniej więcej tak: Problem mam w tym, że granat może lecieć w 360º a nie tylko na boki, w osi X

Wykrywane były poprzez bbox prostokątny, dlatego czasem strzelając w jedno miejsce, kolizja występowała ale ściana i tak była za daleko, żeby cokolwiek się "oderwało" - już naprawione. Em, co robić? ? Są jakieś funkcje do tego, czy tu chodzi o "buffer_create" itp? Checked ✓ oh, stop it you ? Dźwięków jeszcze nie dawałem, no i nie wiem jak zrobić, żeby rzucanie granatu było bardziej... fajne. Untitled Project.mp4 (Mam nadzieje, że te posty nie będą brane jako spam)

nie nie nie, nie tak. Tutaj tworzysz spritea o wymiarach pokoju, a ja mówiłem o surface. Hymm... czyli coś takiego, nie pamiętam dokładnie Osobny obiekt dla ścian, np. oWallController Create: surface_wall = surface_create(room_width, room_height); i teraz w bloku ściany, coś takiego: Draw: draw_self(); if(HIT) { surface_set_target(oWallController.surface_wall); //Ustaw surface do edycji draw_sprite(sprite_index, image_index, x, y) //narysuj obiekt który oberwał od pocisku gpu_set_blendmode(bm_subtract) //zmień tryb na wycinanie draw_set_color(c_white) //c_white wycina sprite (u Ciebie to może być c_black, to chyba spowodowane niedawnym przejściem kolorów na rgb w gms) draw_rectangle(damage_x -8, damage_y -8, damage_x +7, damage_y +7, false); //wytnij kawałek bloku gpu_set_blendmode(bm_normal)// ustaw tryb na normalny surface_reset_target(); // wróć na domyślny surface //Odświerz sprite sprite_delete(sprite) sprite = sprite_create_from_surface(oWallController.surface_wall, x, y, 32, 32, false, true, 0, 0) //utwórz nowy sprite z pozycji x/y obiektu trafionego, o wymiarach 32x32 sprite_collision_mask(sprite, 1, 0, 0, 0, 0, 0, bboxkind_precise, 0) //tu bboxkind_rectangle może być w twoim przypadku, tak myślę. sprite_index = sprite; //podmień stary sprite na nowy HIT = false; } Mniej więcej coś takiego, choć może będziesz to nadal musiał dopasować do siebie. Pamiętaj, że jak robisz surface o małych wymiarach np. 32x32 i umieszczasz je w pokoju na współrzędnych x/y, to poruszając się po niej, zaczynasz od x: 0 y: 0 a nie po x/y pokoju.

Ten kod musisz dopasować do swojego, podałem Ci tylko część odpowiedzialną za główną funkcję. Czyli jeszcze gdzieś musisz mieć choćby draw_self() oraz co ważniejsze dopasować tą linijkę sprite = sprite_create_from_surface(oGame.surface_wall, x, y, 32, 32, false, true, 0, 0) //przypisuje nowy sprite z surface Z tego co widzę, kolosalną różnicą jest to, że Ty robisz surface dopasowany do wysokości/szerokości sprite'a i tak dla każdego bloku jest osobny surface. Ja natomiast mam jeden o wielkości room'u, a wszystkie moje bloki ściany odwołują się do tego jednego surface i tylko wycinam odpowiednie fragmenty z których tworzę nowe sprite'y

Swoją destrukcję ścian robię w bardzo podobny sposób i też zauważyłem, że zjada mi to ramu. Na początku się tym nie przejmowałem, bo to 1mb na odświeżenie ale w końcu musiałem to ogarnąć. Po mozolnym klepaniu doszedłem do ładu i robię to w następujący sposób. Create: sprite = sprite_duplicate(sprite_index); //duplikuje przypisany sprite, aby na nim przeprowadzać operacje. Ważne! (dlatego, że nie przypisuje ścieżki do pamięci, tylko tworzę osobny sprite, tak, żeby każdy obiekt miał swój własny, a przy restartowaniu gry, nie pokazuje błędu o nieistniejącym zasobie. Draw: sprite_delete(sprite) //usuwam aktualny sprite z pamięci sprite = sprite_create_from_surface(oGame.surface_wall, x, y, 32, 32, false, true, 0, 0) //przypisuje nowy sprite z surface sprite_collision_mask(sprite, 1, 0, 0, 0, 0, 0, bboxkind_precise, 0) //tworzę do niego maskę sprite_index = sprite; //przypisuje ścieżkę do sprite_index - nie muszę pamiętać, żeby pisać sprite zamiast sprite_index w reszcie kodu. Bardzo długo próbowałem to skrócić, tak, żeby nie musieć tworzyć nowej zmiennej sprite, ale zawsze było jakieś "ale". (zwiększający się stopniowo RAM, są wywołane przez tworzenie pocisków a nie tą sytuacją z surface) Untitled Project.mp4