Threef

To mam już lepsze: liczba = 31352 wynik = liczba while(wynik>1) { wynik/=10 }

Jednym z pewnych rozwiązań jest zabawa stringami. Nie mam siły teraz myśleć więc czekam aż ktoś zaproponuje optymalniejsze rozwiązanie. zmienna = real("0."+string(zmienna2))

Z wykorzystaniem trygonometrii i podstawowej matematyki nie trzeba żadnego przykładu. Jeżeli zrobisz 2 nogi postaci i sprawisz żeby jedna noga miała y=ypostaci+sin(czas) a drugaa to samo tylko -sun() to już masz efekt o który chodzi.

U mnie jest to zawsze maszyna stanów. Ruch, pozycja i input gracza ustala stan. Wszystko musi być na tyle przejrzyste żeby wynikiem był jeden konkretny stan na podstawie którego musi narysować konkretną klatę animacji.

Jest draw_sprite_part_ext(). On pozwala narysować fragment z ze sprite. Ale niestety jeżeli chodzi to że klon Minecraft jest prostą rzeczą to nie mogłeś być bardziej w błędzie. Zoptymalizowanie tego by jakkolwiek działało jest prawdziwym wyzwaniem.

Tak. To miałem na myśli. Pora była późna.

if(keyboard_key="A" && wcisnietyalt) { } To chyba będzie działać. Bo GM może rozróżnić a i A wpisywane z klawiatury

Oj bardzo głupio widzę jest to zrobione. Dlaczego nie jest to interpolacja liniowa? Określ minimalny zasię i maksymalny a potem dziel. To wszystko. var _min=350; var _max=400; view_light=lerp(_min,_max,distance_to_object(obj_glr_fire_light)-_min)*4

Średniki są jedynie wymagane przy deklarowaniu zmiennych lokalnych (var) albo przy użyciu globalvar.

Jeżeli rosołem nazywasz wódkę smakową to będzie.

To rozumiem że yy_jump było w zakresach -coś do 0? Skacząc robisz tę wartość na minus? Może coś takiego? var col=instance_place(x+hspd_,y,objBLOK); if col && yy_jump>=col.yy_high // yy jump wysokosc skakania uwzględniająca to gdzie stoimy a yy_high to wysokość bloczku z którym kolidujemy { while !place_meeting(x+sign(hspd_),y,col) { x+=sign(hspd_) } hspd_=0 } else { // funkcja spadania } x+=hspd_;

Bardzo proste. Sprawdzasz z jakim obiektem kolidujesz a potem jeżeli moja H (czy cokolwiek używasz dla wysokości) jest >= wysokości bloku to pozawalasz się poruszać.

To chyba dobrze? Jest więc szansa że się pojawisz

Ja takie rzeczy robię w bardzo prosty sposób. Tak samo jak 3D w GM. Zrób płaską maskę która jest na ziemi i wygląda jak kałuża. Stojąc na ziemi gracz nie może na nią wejść. Teraz ten obiekt ma swoją wysokość np 20. Następnie gracz skacząc manipuluje jakąś zmienną tak? Nazwijmy ją teraz H. Jeżeli H < wysokości obiektu to gracz nie może z nim kolidować. Jeżeli H jest większe to nie bierz pod uwagę kolizji. Ale teraz jeżeli H < wysokości oraz aktualnie spadałeś (coś jak vspeed tylko twój) to ustaw graczowi wartość wysokości obiektu jako aktualną wysokość podłoża i pozwól graczowi się poruszać jakby nie było kolizji z tym obiektem. Ostatnia sprawa to jeżeli wykryjesz ze kolizji znów nie ma to gracz ma znów spaść niżej.

W Poznaniu i tak się spotkamy. A W Szczecinie na coś ogarnę. ?

Używałem tylko betę przez 2 dni więc dużo nie mam ale zdążyłem jej nie polubić. Minusy Tylko wersja 64bitowa Required DirectX11 Interface jest mniej kompaktowy i zajmuje sporo niepotrzebnego miejsca na ekranie Layers (to po części plus bo poprawiło optymalizację draw pipeline) Plusy IDE dla MacOS Działający edytor room

To Box2D czy własna?

O! Nikas zaprasza na domówkę!

Listopad? W sumie jeżeli będę mieć wolny termin to będzie mi pasowało chyba wszędzie byle nie Warszawa. A może by jakieś domki letniskowe? Jeziorko grill te sprawy?

Jeżeli gra spowalnia to znak że trzeba włączyć profiler i sprawdzić gdzie. Oraz to że muszę dokończyć dla was tekst o tym jak profilera używać. https://docs.yoyogames.com/source/dadiospice/001_advanced use/profiling.html Nie możesz próbować szukać rozwiązań problemu jeżeli nie wiesz co go powoduje. - Jeżeli jest za dużo obiektów to możesz spróbować dezaktywować albo ukrywać te które nie są potrzebne. - Jeżeli za często jest sprawdzane czy możesz stworzyć wodę to możesz to ograniczyć - Może elementy tworzą się nie tam gdzie chcesz? Na przykład poza room? Jedno co na pewno możesz zrobić to podejście identyczne jak jest w Minecraftcie. Zrób stan który oznacza że woda się updatuje. Coś takiego create: update=true step: if(update) { if place_free(x,y+32) { instance_create(x,y+32,obj_water) } if place_free(x+32,y) { instance_create(x+32,y,obj_water) } if place_free(x-32,y) { instance_create(x-32,y,obj_water) } update = false } W ten sposób sprawdzenie wykona się tylko raz. Jeżeli chcesz z jakiegoś powodu ponownie wykonać sprawdzenie, bo np zabrałeś wodę, to wystarczy że w którymś obiekcie wody znów zmienisz update=true

A żyje, żyje. Jakoś nie było za bardzo okazji by coś postować bo były zmiany w edytorze map i refactoring. Doszło kilka rzeczy ale postowałem je w Nad czym aktualnie pracujesz i w galerii grafik. Muszę domknąć aktualne zmiany żeby móc dodawać nowe feature.

Nie no, to takich mam i tak już za dużo. O tym się zastanawiałem bo właśnie nie jest ani super fajny ale też nie jest tak płytki jak ten co teraz kończę. Chce dobrze dokończyć kilka mniejszych projektów

Drugi problem wynika z tego że gdy już jest health<=0 to nowo postawiony obiekt również jest niszczony bo spełnia warunek.

Nie mówię o tym żeby się za to teraz zabierać. Mam 3 projekty na najwyższym priorytecie. To pewnie zacząłbym w przyszłym roku. Korci mnie zrobienie jakiegoś twista na shmupa. To mogło by być łatwo rozwijane.

Tak, chociaż tego jest troszkę więcej. Śledzenie kamery. Screenshake. I sterowanie które już mi się nie podoba. To powstało w kamperze jadąc wzdłuż Bałtyku. ?