gnysek

W Marketplace masz gotowy przykład użycia: https://marketplace.yoyogames.com/assets/10078/google-admob - podstawiasz tylko swoje identyfikatory.

Dlaczego generujesz tyle nowych sprite w locie? Pamięć zapełni się szybko i jest to mega niewydajne, bowiem GM każdy sprite generuje jako osobną teksturę jeśli go tworzysz w grze, do tego trzyma dwie kopie do normalnego rysowania i blendingu, co daje WYSOKOŚĆ * SZEROKOŚĆ * 4 bajty. Obrazek 512x512px to jest 2 MB. Z tego kodu widać też, że faktycznie, nie usuwasz starych sprite'ów, wiec one faktycznie zostają w pamięci - GM nie zwalnia automatycznie zasobów jeśli nie są używane, robi to tylko ze strukturami i z tablicami, resztę trzeba usuwać ręcznie.

Super, jak napisałeś w jednym miejscu, to poczekaj, aż ktoś napisze odpowiedź, nie pisz w drugim...

Nie zapomnij zapisywać surface do bufora, bo jak się włączy wygaszacz, zablokujesz ekran, zmienisz rozdzielczość lub podłączysz monitor, jest duża szansa, że surface pójdzie się... zniknie

Mi to wygląda na... Windows Terminal (nie CMD i nie PowerShell).

20 lecie wypada chyba... 1 listopada, więc imprezę zrobimy jednak nieco szybciej, w jakimś cieplejszym miesiącu (lipiec/sierpień?).

W tym roku jest 20-lecie GMCLANu, także pewnie jakiś najazd na Warszawę zrobimy, ćwiczcie wątroby (Ci, których nie ma na zdjęciu :P).

Bo jak prawidłowo pracujesz z gitem, to takie rzeczy nie są potrzebne

Ok, faktycznie, wygląda, że "git commit -a" robi to samo co "git add -u", a nie to co "git add". Dobrze wiedzieć Ja zwyczajnie wolę zawsze przed commitem sprawdzić co w nim idzie, dlatego bym nigdy nie połączył go z "-a" w żaden sposób.

Zakładam, że teraz pocisk jest rysowany za pomocą lenghtdir, więc prawdopodobnie wystarczy skalować argument length, oraz sam obrazek, bo origin zostaje w tym samym miejscu mimo skalowania (więc wykorzystaj to na swoją korzyść).

Daj w pocisku origin poniżej pocisku, tak jakby miał niewidzialną rekojeść.

Ja korzystam tylko z wizualnej wersji gita w Jetbrainsowych produktach, czasem tylko do tworzenia branchy z terminala daję "git checkout -b nazwabrancha", albo jak trzeba zrobić reset (czego nie potrafie zapamiętać i zawsze kopiuję ze stackoverflow). W sumie do gita za duzo nie trzeba znać, push, fetch, commit i jakoś się żyje

git commit -am zrobi to samo co git add * git commit -m Polecam: https://explainshell.com/explain?cmd=git+commit+-am (chociaż z tamtego opisu akurat nie wynika to co napisałem). No i to akurat nie jest programowanie

Zanim doczytałem post Chella, miałem już w głowie:

Tak tego nie osiągniesz. Jeśli chcesz zostawiać na surface obiekty, które znikają, to jest kilka problemów: - nie możesz czyścić surface - jak przełączysz sie na inną aplikację, zablokujesz komputer, włączy sie wygaszacz lub go uśpisz - surface na 99% zostanie skasowane i stracisz wszystko - jak przesunie się ekran, to bez czyszczenia surface obiekty znikną Rozwiązania widzę takie: - nie kasować obiektów - stworzyć tablicę , która trzyma co masz rysować (elementami tablicy może być struktura z polami sprite, x, y). Wtedy można je rysować w pętli i w sumie nawet nie jest potrzebne suface Na GMCLANie jest kilka osób, które zaraz by przybiegły powiedzieć "panie, ale to jest w *pip* niewydajne" - no więc nie do końca. Sprawdzenie czy dane X/Y mieści się w ekranie (to są cztery porównania) i tak będzie szybsze niż przerysowywanie surface czy przetwarzanie wszystkich eventów obiektów. Poza tym, jeśli tego będzie więcej niż kilkaset można wysilić się w jakieś strefy i przetwarzać tylko tablicę danej strefy. Z kolei dla krwi, ja zawsze szedłem w stronę rozwiązania, że np. na raz może być max 100 plam, więc jak dochodzi 101, usuwam pierwszą i dodaję nową w jej miejsce (albo zmienna globalna która mówi gdzie wstawiamy następną, albo przesunięcie elementów tablicy o -1). Można nawet dla usuwanego elementu stworzyć obiekt, który powoduje zanikanie alphy, żeby dynamicznie zanikał (tak bym zrobił np. dla śladów stóp, czy opon). Jest sporo opcji

Pobaw sie z camera_apply(), który automatycznie zmienia offset surface do obecnej kamery, więc nie trzeba odejmować pozycji view od x i y obiektów. Inaczej mówiąc - normlanie na surface wszystko rysuje się tak, że lewy górny róg to 0,0, po użyciu camera_apply, lewy górny róg surface to jest lewy górny róg obecnego view Jeszcze taka podpowiedź: jak rysujesz na surface, to rób to w jednym obiekcie, np. with(granaty) { draw_self(); } with(krew) { draw_self(); } // i jeszcze inne rzeczy Tak, żeby, optymalnie jedno surface tylko raz miało surface_set_target

To jest jakiś problem z kanałami alpha w takim razie. Spróbuj albo zaznaczyć opcję "premultiply alpha" lub "edge filtering". Ja np. mam problem z obrazkami robionymi w Affinity Designer, bo jak je skalujesz (bez względu na tryby), to dostają czarnej obwódki i "edge filtering" je naprawia.

Jeśli chcesz ją odczytać, użyj "image_blend". Mało logiczne, bo nigdzie indziej tego nie nazywają "blend" tylko właśnie color xD

Może mój laptop ma gorszy ekran, ale ja nie widzę tam żadnych problemów graficznych

Ne bardzo rozumiem problem - moim zdaniem wygląda ok. Jeśli jednak jest jakiś problem, no to musisz poprawić ten gradient, tak, żeby tam gdzie się zdaje, że on się kończy, faktycznie się kończył, a nie miał jeszcze z 30-40 pikseli. Z matematycznego punktu widzenia zdaje się, że wyświetla się ok.

Przy zderzeniu samochody raczej nie przyspieszają, więc to bym odrzucił. Co do wpływania na pozycję - faktycznie, tutaj jest problem, bo nawet jak serwer sprawdza kto pierwszy faktycznie dojechał do mety, to i tak da się oszukać. Ale wiesz - tak szczerze, to ile osób będzie w ten sposób oszukiwać? Naprawdę jest sens dla jednej może osoby, która będzie się bawić, myśleć o rozwiązaniach, które dla setek innych w ogóle nie są potrzebne? Ja bym ten temat olał. Oszustów i tak nie wyeliminujesz i czasem szkoda na nich marnować czasu. Zwykły ban na IP wystarczy

Sprawdź wcześniej lokalnie, w trakcie testów Przecież wiesz jaka jest max. prędkość. Zresztą, skoro to gra wyścigowa, to jak ktoś skoczy nagle o 500px to nie wierzę, zeby mu się udało sterować takim pojazdem i żeby w ogóle w cokolwiek trafił Wpadł mi do głowy inny pomysł. Każdy pojazd ma pewnie jakieś swoje statystyki, typu przyspieszenie, kąt skrętu, max prędkość itp. które właśnie można by przestawiać narzędziem do cheatów. Może właśnie te dane podsyłaj co jakiś czas do sprawdzenia, czy zgadzają się między serwerem a klientem? Jak ktoś chce oszukiwać i jechać szybciej, to musi którąś z nich przestawić, więc jak ją wyślesz do serwera i będzie błędna to można go wywalić - one zapewne są stałe dla każdego pojazdu. Odtwarzania fizyki na serwerze i tak nie zrobisz, bo przez pingi itp. na serwerze nigdy nie będzie 100% tego samego stanu fizycznego obiektów i fizyka może działać znacznie inaczej. Coś będzie miało właściwość o 0.001 inną i już będzie problem.

2. Wiedząc, że pojazd porusza się z prędkością N pikseli na step automatycznie wiesz, że jak ruszy się drugie tyle, to coś jest nie tak. Może uczyć cheata, dlatego serwer powinien znać max prędkość pojazdów, żeby to właśnie wykryć. Generalnie jednak to jest właśnie problem stary jak świat, a obliczanie fizyki na serwerze naprawdę źle się kończy, bo GM nie działa asynchronicznie (jak wyślesz dane, to nawet przy idealnym pingu dostaniesz je w kolejnym stepie). 3. Da się, są jakieś przykłady, ale oczywiście to jest mnóstwo roboty. Kiedyś mają to zmienić, ale wiadomo jak to z YYG.

Podglądu raczej nie ma, ale może da się skontaktować z twórcą, żeby nagrał jakieś wideo? Na Windowsie 10 to jest dziecinnie proste za pomocą Xbox Game Bara. 2.: Obliczałbym po stronie klienta, bo inaczej będą lagi. Oczywiście serwer kontroluje czy ktoś nie poleciał za daleko w jednym kroku, a pozostali klienci interpolują otrzymane dane. Tak to działa nawet w wielkich wyścigówkach (gdzie samochody lubią driftować na prostej, bo zgubiły info, że ktoś o 30cm się przesunął w lewo czy w prawo). 3.: Nie, opcji headless wciąż nie ma.

Nigdy nie podejmowałem tematu, ale wydaje mi się, że to co mówisz, to może... siła odśrodkowa lub przeciążenia?