gnysek

Pięknie to wygląda, pięknie.

Och, pamiętam te charakterystyczne rendery Ale w sumie w wielu grach lat '90 tak właśnie robiono postaci - 3D, potem render, a potem sprite 2D.

a próbowałeś z move_outside_solid zamiast tego while ? Jak dla mnie, to tam gdzieś jest kolizja z dwoma kamieniami na raz i wtedy kierunek od nie tego jest brany, dlatego ten skok.

A jakby utworzyć te pola javascriptem, to przeglądarka też je uzupełnia?

Tak, ta sama co w GMS - websockety Pytanie jak dużo tych danych i jak często, bo czasem szkoda na nowo koło wynajdywać i się męczyć ze starą technologią, jak znasz inną, nieco gorszą, ale napiszesz kod 10x szybciej.

Babka od fizy w gimbazie tak wyglądała. Tylko miała zeza rozbieżnego dodatkowo i okulary.

Jaka przeglądarka? Mi to akurat na bank działa, wiele razy używałem. https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

Tzn. liczysz, że jak użyjesz szyfrowania (nie hashowania), to dane w MySql będą bezpieczne? Jak ktoś pozna klucz (a będziesz go miał w aplikacji C# zapewne) to dupa zbita. Co do tego, że dane po https są przesyłane jawnie - cóż, przed wysłaniem (w przeglądarce) i po odebraniu (w PHP) owszem są jawne, ale przeglądarka pokazuje dane przed wysłaniem pakietów, a PHP po przetworzeniu przez Apache/Nginx. Co do włamów do bazy MySql - nie udostępniaj bazy z zewnątrz, to ryzyko włamania spadnie niemal do zera. A jak się ktoś włamie na serwer, to wierz mi, że nie trzeba nawet wejść do mysql, można po prostu zrobić loggera przychodzących danych w odpowiednim miejscu i je nawet na mejla wysyłać. Co do danych kart kredytowych - po co je chcesz zapisywać? Nawet jak robisz płatności-subskrypcje, to wystarczy autoryzowanie z bramki płatności i otrzymanie z niej kodu płatności i potem powoływanie się na niego, żeby ściągać kasę (capture). Sam numer karty też najlepiej, gdyby klienci podwali w bramce (payu/dotpay itp) - to jest miliard razy bezpieczniejsze. Zrobiłem w życiu ponad 50 sklepów internetowych i zawsze zalecamy klientom, aby nie wpisywać i nie przechowywać ŻADNYCH danych kart kredytowych na ich stronie i zostawić to bramkom płatności.

Czytałeś manual ? Wpisz -1. Będzie bez tekstury. A najpierw daj draw_set_color(c_white);

https - nie musisz wtedy nic szyfrować, automatycznie pobierze certyfikat z docelowej domeny (o ile tam jest https) i zaszyfruje dane przed wysłaniem. Tak jak przeglądarka.

Napisałem powyżej, że masz zmienić kodowanie pola na utf8_bin - tak przynajmniej zaleca internet

Zapisywanie tekstu, a metoda porównywania z zapytaniem SQL to są dwie różne rzeczy. Powyższe kodowanie przy zapytaniach nie odróżnia wielkości liter, chociaż zapisuje i zwraca je jak chcesz.

O ile pamiętam, instance_number wlicza też dzieci obiektu.

To, czy duże i małe znaki są odróżniane czy nie nie zależy od ustawień PDO, a od ustawienia kodowania danego pola w tabeli mysql. Spróbuj zmienić np. na utf8_bin . A co do haseł jw. mamy co najmniej kilka ustaw które zabraniają trzymania ich w plaintekście. Nawet bez wycieku danych trzymanie czyjegoś hasła jawnie w swojej bazie jest równe ze zhackowaniem tej osoby - bo tak naprawdę masz loggera haseł wtedy.

Jeżeli postać podskakuje na podstawie jakiegoś wzoru i nie masz pomijania klatek, to nie ma za bardzo opcji, aby skoczyła niżej. W takich sytuacjach po prostu pewnie rzeczy trwają dłużej, ale w całej grze i tyle. Kod wykona się tyle razy i tak jak chciałeś, tylko w wolniejszym czasie - to jest jedyny problem jaki można napotkać w GMie. Dlatego jest to problem jedynie przy grach online, gdzie musi być sync między klientami.

Nie no, HTML to jest meta dokument, coś jak XML, dlaczego miałoby to renderować ? Wiadomo, ze tylko parsuje (o ile kod jest poprawny - niedomknięte tagi też mogą popsuć sprawę). Co do wczytywania inaczej - musisz "udać" przeglądarkę, wysłać w nagłówkach user-agenta jakiejś znanej przeglądarki. Np. google zwraca inną stronę jak tego brakuje, uznając, że wchodzisz z jakiejś archaicznej komórki i ograniczając javascript.

Mówiłeś, że chcesz odczytać dokument HTML, a nie parsować i sprawdzać zaaplikowane CSSy. To jest zupełnie inna sprawa, od tego jest cały silnik renderujący w przeglądarce i poza użyciem embedded chromium nic mi więcej nie przychodzi do głowy. Bo sparsowanie samemu i szukanie czy klasa jest do zaaplikowania na danym elemencie to za dużo zabawy przy wszystkich możliwych kombinacjach cssów.

A właśnie, na PGA jej nie widziałem w tym roku, a wcześniej pamiętam, że ekipa była

"Innych silników" - no jak robisz w Unity FPSa i chcesz, żeby leciało klatek ile fabryka dała, to jak wspomniał @Konrad-GM - delta time obowiązkowe, bo musisz utrzymać prędkość postaci i innych elementów względem tego co ekran pokazuje, a jest to zmienna liczba. Ale w GM robi się raczej sztywne ograniczenie (cap) właśnie na 60 FPS i wtedy jeśli to nie jest gra online, to średnio delta jest przydatna. Jak mówie, nie widzę problemu, gdy gra zgubi kilka klatek i zwolni, bo cała gra zwolni i gracz sobie z tym poradzi. Trzeba pamiętać, ze w GM draw i step są w sumie powiązane. A jak zakładasz, że Twoja gra na słabszych sprzętach nie utrzyma 60FPSów w GMie, to znaczy, że przedobrzyłeś z czymś GM to spadał poniżej 60FPSów na komórkach za 800zł w 2012, ale nie dziś.

Podobno fajne jest to: https://html-agility-pack.net/

Ja generalnie nigdy nie stosowałem, bo nie robiłem gier, w których jest to niezbędne, lub które lagują Ogólnie uważam, że delta jest WYMAGANA w grach online, żeby rozwiązać problem lagów. Nie wiem czy jest sens używac jej w platformówce typu mario - jak spadnie FPS to spadnie, postać ruszy się wolniej, chyba lepiej niż gdyby przeskoczyła od razu o 3 klatki animacji bo delta time nadrabia to co gra nie wyrobiła A np. to, gdzie doleci pocisk i sprawdzanie, czy przez jego prędkość nie przeleci przez ścianę (np. jak ściana ma 32 piksele szerokości, a prędkości pocisku wynosi 40, to możliwe, że kolizja nie zajdzie), to do tego bym używał collision_line(x,y,xprevious,yprevious), delta time w ogóle nie rozwiąże sprawy. Jeśli wiec nie robisz gry online czy bijatyki i zakładasz, że nie będzie lagować (a jak będzie, to coś robisz źle, więc napraw powód lagowania), to też uważam, że to zbędny bajer.

Przez 17 lat nigdy mi się to nie zdarzyło. A napisałem już łącznie ponad 50 stron w sieci, niektóre z bazami po 4-5 GB.

Przy takiej liczbie userów jak pewnie byś miał, to nie wiem jakie mogą być problemy z serwerami... zwykły hosting www gdziekolwiek wystarczy.

A bo wszystko takie podobne było Sugerowałem się obrazkiem.

Poprawiłem się.