Skocz do zawartości

gnysek

Administratorzy
  • Postów

    9 812
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    141

Treść opublikowana przez gnysek

  1. Akurat przypadkiem YAL, jeden z najbardziej kumatych twórców GMa (to ten od GMLIVE) napisał posta na ten temat: https://yal.cc/gamemaker-html5-hdpi-support/
  2. WD40 to jest do smarowania i wypychania wody (water dispenser), a nie do rozpuszczania.
  3. Sprawdź wartości display_get_width i window_get_width. Może być tak, że przegądarka przy wersji mobilnej ze względu na "retinę", zwraca, że okno jest 3-4 razy mniejsze i musisz powiększyć grę nie do window_get_width, a display_get_width. Takie rozmazanie sugeruje właśnie, że "wyjście" kamery/surface (bo nie wiem czy masz application surface) jest ustawione na 3-4x mniejsze, niż faktyczne okno.
  4. To są te takie śmieszne drobne przewody cienkie jak włosy, gdzie w jednym kabelku jest ich kilkadziesiąt ? sensowne wydaje się zrobić jakiś zacisk na koniec i wtedy zlutować i zaizolować.
  5. - to taki problem założyć konto paypal ? wyrób osobną kartę do płatności internetowych (w banku, albo np. Revoluta) którą doładowujesz tylko przed płatnością, jak się boisz wycieku danych i kradzieży pieniędzy - jeśli przy teksturze nie są opisane prawa autorskie, to zakładałbym, ze jest chroniona prawami autorskimi, bądź napisał do właściciela strony. To nie torrent że sie dzielisz czym chcesz. Przypominam też, że w naszym kraju wypada płacić podatek, co najmniej dochodowy (nie trzeba do 8000zł zarobków ŁĄCZNIE z wszystkich źródeł w roku), a przychód (nie dochód) z gry dłużej niż miesiąc powyżej połowy średniej krajowej oznacza, ze trzeba założyć działalność gospodarczą (do połowy najniższej krajowej masz nierejestrowaną działalność - nadal płacisz dochodowy). W przypadku steam trzeba też z tego co kojarzę zgłosić działalność w USA (nie założyć, tylko ich poinformować, że prowadzimy handel z USA).
  6. Przesyłanie danych co klatkę czy jakaś interpolacja/przewidywanie ruchów ?
  7. Wymierzanie, to zabawa alarmami/zmiennymi które je zastąpią.
  8. Można własne paski robić, gdzieś mają tutorial. Sprawdź też, jaki jest rozmiar canvasa na starcie - może trzeba ręcznie edytować plik .html ?
  9. 1) używaj web gl i włącz interpolację 2) z tego co widzę, on nigdy nie skaluje gier w górę, tylko w dół
  10. s_lydka2=s_wer_lyda_pr1; s_lydka2_sub = 2; /// draw draw_sprite(s_lydka2, s_lydka2_sub, x, y);
  11. Ostatni przycisk w okienku z miniaturkami sprite: https://docs.yoyogames.com/source/dadiospice/001_advanced use/more about sprites/editing sprites.html Generalnie, nie ma takiej opcji, żeby był spadek wydajności w GMS 1.4, jeśli gra jest dobrze zrobiona. Za dużo rzeczy tam robiłem, żeby nie stwierdzić, że od GM 8.1 jest wszystko kilka razy szybsze i bardziej zoptymalizowane.
  12. Pre-multilpy alpha zrób na każdym sprite. Przesiadanie się dziś z GM 8 na GMS 1.4 jest jak przesiadanie się z Windowsa XP na 7. I nie rób grafik większych, niż rozmiar tekstury, albo je podziel wtedy na szerokość tekstury właśnie. To wygląda też, jakbyś jakiś tryb na GPU włączył z kodu. Przejrzyj dobrze, czy gdzieś takich rzeczy nie robisz (ustawiani interpolacji, blendingu itp.)
  13. Drugi sposób to zapewne zrobić direction = direction % 360;
  14. gnysek

    Bonfire

    Zgłaszasz do Pixel Awards ? Myślę, że przy takiej jakości gry warto zgarnąć statuetkę, daleko nie masz po odbiór https://www.pixelheavenfest.com/pixel-awards-europe/
  15. Idealnego wyglądu jak chcesz nigdy nie wyklikasz, zawsze wymaga programowania.
  16. Jeśli są dwa obj_wrog, to zawsze zwraca ID tego stworzonego jako pierwszego w tym przypadku, więc gdy kolizja jest z drugim to i tak zapamiętuje pierwszego. Musisz użyć bodaj instance_place() aby dostać konkretne ID, a nie pierwszego stworzonego obj_wrog w roomie. Ja generalnie polecam użyć eventu kolizji, wtedy masz pod other ten obiekt z którym jest kolizja i możesz dać ostatnicel = other.id
  17. 2. Trzeba to zaprogramować Albo poszukać gotowego rozszerzenia
  18. Jak piszą w dokumentacji do polecenia buffer_create - "pamiętaj aby usunąć z pamięci", więc tak, siedzi tam ciągle i nie ma garbage collectora. Garbage collector w GMie jest na instancje z niezaznaczonym persistent i tablice.
  19. Ja myślalem, że ten sklep już powstał, to miało być dwa dni pisania Ale ostatnie zdanie Threefa mówi wszystko w temacie na temat skomplikowania sprawy.
  20. Ale przepraszam, myślisz, ze kto mi zleca zadania, programista? Pfff. Zadania zleca klient, który zaprogramować, to potrafi najwyżej pralkę. I ja wszystko robię tak, jak on chce i jak wg. jego wizji ma to wyglądać, a nie ja wg. mojej wizji. Jak wrzucam 30 różnych skryptów śledzących, obrazków, google tag managerów, facebook pikseli i chuj wie czego jeszcze, to nie dla tego, że programista uważa, że tak jest lepiej, tylko dla tego, ze przyszedł MARKETINGOWIEC i SPECJALISTA OD SPRZEDAŻY i on takie gówna każe wklejać. Także jest dokładnie na odwrót niż myślisz, bo programiści to są leniwe istoty i robią na skróty, a same formularze i proces sprzedaży upraszczaliby jak się da. Dla mnie wystarczą dwa statusy zamówienia - "oczekujące" i "zrealizowane", ale pan właściciel sklepu potrzebuje 50, a potem sam się w tym gubi. A to okienko tutaj, a to newsletter tam, a to bannerek w tym miejscu, a to pierdoła w tamtym. Każdy sklep ma naprawdę inne wymagania i robienie projektu już pod dwa wymaga, żeby pisać modułowo. I tak się to rozrasta potem. Zapytałeś co musisz wiedzieć przed robieniem sklepu, my, z doświadczeniem mówimy, że na takie coś nie ma się co porywać, bo to jest za duży projekt, i to nie dla tego, że piszemy sklepy na gotowcach, tylko dla tego, że w ogóle mamy doświadczenie w programowaniu (którego Ty w ogóle nie masz, skoro mylisz bezpieczeństwo sklepu z używaniem PDO), albo twierdzisz, że coś da się napisać w godzinę, skoro nawet zrobienie HTMLa i CSSa dla niektórych rzeczy zajmie dłużej, żeby coś się prawidłowo wyświetlało. Owszem, jak chcesz to próbuj, ja jednak nadal będę twierdził, że użycie gotowca jest szybsze, niż pisanie samemu. Ja bym się tego nie podjął, bo żeby zrobić coś uniwersalnego, dla więcej niż jednej osoby wiem, że musiałbym spędzić chyba z kilka lat, żeby to napisać. Jeśli jednak ktoś o sklepach mówi CMS, no to w sumie wszystko mówi na temat poziomu rozmowy i tego, ze nie rozumie faktów które przytaczamy. Żaden z systemów sklepowych, Magento, Presta, Sylius, WooCommerce, OpenCart, ZenCard czy X-Card nie jest CMSem. Część z nich posiada moduł CMS, część z nich działa pod CMSami, ale żaden nie jest. Jedyne z czym się zgodzę, to że prowadzenie sklepu niestety jest drogie i fajnie minimalizować koszty, ale właśnie skorzystanie z gotowca kosztuje w sumie 0zł. I naprawdę sporo da się wyklikać, bez programowania i jestem pewien, że jakbyś powiedział czego potrzebujesz, to większość tych funkcji jest bez wtyczek. Martwisz się też co w momencie, gdy sklep ma aktualizacje. No cóż, to patrzysz co zaktualizowali, jeśli trzeba to poprawiasz kod (chociaż jak poprawka dotyczy jedynie bezpieczeństwa, to jeśli musisz coś poprawić to sam miałeś błąd bezpieczeństwa) i tyle. Nie wrzucasz przecież poprawki na żywca na serwer na pałę. A co do argumentów, że znajomi mają mnóstwo malware itp. - no cóż, jak nie potrafią skonfigurować dobrze serwera, to mają. U mnie klienci nigdy nie mieli z tym problemu, bo zawsze chociażby zmieniamy ścieżkę do panelu admina, blokujemy ją pod konkretne IP, dodajemy htpassword czy nawet wymagamy konkretnego ciasteczka w przeglądarce najpierw. I to są akurat rzeczy do zrobienia w godzinę. Jestem też ciekaw tych faktur. Generujesz fakturę, wtedy wysyłasz ją księgowej i jak będzie zła to poprawisz? Coś chyba tutaj jest nie tak, przecież jak user już pobrał fakturę, to po ptakach. A jak ją sobie wpiszę w KPiR to co, potem mi się skarbówka przywali, bo nie umiałeś dobrze faktury wygenerować? Nie mniej, czekam na pierwsze efekty, na pewno podpowiemy co jest źle i ostrzeżemy przed jakimś fatalnym błędem, zanim pakujesz się w maliny. Pamiętaj tylko, że od początku ostrzegaliśmy, że na maliny w ogóle masz nie iść
  21. 10 lat piszę sklepy internetowe, zrobiłem ich ponad 50, piszę czasem sam bramki do nowych systemów, czy systemy dostaw, a ten mi mówi, ze to kilka linijek... to nie jest tak, ze ja je piszę pod jakiś system, dlatego zajmują mnóstwo kodu, to jest tak, że się nie da krócej, bo ja już znam system i wiem gdzie oszukać i czego nie muszę zrobić, byle to działało. Jak mówię - nie masz nawet pojęcia za co się bierzesz, albo w ogóle nie chcesz 90% funkcjonalności sklepu, które są przydatne MARKETINGOWO i dla SPRZEDAWCY a nie dla programisty. Sporo rzeczy przyspiesza prace, jak da się je zobaczyć w panelu admina (status zamówienia, numery paczek, status płatności) ale rozumiem, wolisz je sprawdzać osobno. I bez odpowiedniego flow dla klienta. Pytanie czy robisz prawdziwy sklep, czy tylko mikro-sklepik na dwóch klientów rocznie.
  22. Czy jesteś w stanie zminimalizowac projekt (oczywiście na kopii) do 1-2 obiektów i podesłać go nam, zebysmy sprawdzili (i upewnić się, ze dalej się psuje)? Inaczej chyba na nic nie wpadnę. Czasem usuwając rzeczy okaże się, ze się magicznie naprawia i znajdziesz problem
  23. Ale tylko w momencie tych czynności, czy np. 5 minut później też? Bo ja bym obstawiał, ze mruga, bo się przełączasz i że tak robią wszystkie gry. Co do mrugania między levelami które widziałem, to strzelam, że masz różne rozdzielczości w roomach, dlatego mruga. Sprawdź też, czy gdzieś kodem nie zmieniasz rozdzielczości/rozmiaru view/pozycji okna w step, może dla tego mruga. Ja generalnie nie kojarzę takich problemów w 1.x za czasów gdy pracowałem w YoYoGames.
×
×
  • Dodaj nową pozycję...