Threef

Nice. Ale zdecydowanie powinieneś większe DPI dać i pamietać że warstw nigdy nie za wiele

Pokaż ustawienia. Bo na razie to wygląda na 2 rzeczy. Albo jest tak jak ustawiłeś więc nie ma co się dziwić, albo próbuje ci wyświetlić okno większe niż twoja rozdzielczość (ale ten problem nie występował w GMS 1.4)

Tak, ale ogranicza cię sandbox

Zaznaczyć w apce obsługę WebGL i zrobić to shaderem z podobnym efektem do bm_subtract

To co dzieje się w twoim przykładzie 1 to rozszerzenie okna z zachowaniem aspect ratio. Przykład trzeci to rozciągnięcie bez zachowania aspect ratio To co ty chcesz zrobić z przykładem drugim to zmiana aspect ratio gry i potem rozszerzenie go do okna. Przeczytaj to pogrubione na głos. Jeszcze raz, bo gdy ostatnio ci tłumaczyłem na Discordzie to zapomniałeś. Pobierz wymiary okna Wylicz aspect ratio okna Pomyśl sobie którą krawędź gry możesz zmieniać i przemnóż ją (room_wiidth/height albo camera zależy co używasz) przez aspect ratio okna Rozszerz rozmiar gry do okna z zachowaniem nowego aspect ratio Nie wykonuj poniższego checku bo wykonuje się zawsze. Jest chyba wbudowany event związany ze zmianami okna. Spróbuj go. Jak nie działa i chcesz zrobić mądrze to zapisuj nowe rozmiary okna po każdej zmianie i porównuj z tym if (browser_width != width || browser_height != height)

Najprzyjemniejszy sposób jaki ja znalazłem to: rotspeed = 8 direction += angle_difference( direction, point_direction(x,y,gracz_par.x,gracz_par.y) ) / rotspeed

1. CO? Subimage to subimage. Wykorzystujesz go przy samym rysowaniu. Jeżeli chciałbyś jakość łatwo wskazać na inny sprite który jest po kolei to dam fajny tip: Jak masz w drzewku po sobie sprite: s_wer_lyda_pr1 i s_wer_lyda_pr2 to do tego drugiego możesz się odnosić jako var sprite = s_wer_lyda_pr1 +1 Bo tak na prawdę nazwy assetów to też zmienne trzymające ID w kolejności z drzewka 2. Najlepiej jest sprawić że tworzony pocisk będzie miał w sobie zmienną z typem. Więc w createpocisku pistoletowego dajesz "type = 0", dla karabinowego "type = 1", etc. Potem w kolizji sprawdzasz zwyczajnie if(other.type == 0) { //Jestem pistoletowy } if(other.type == 1) { //Jestem karabinowy }

8192x8192 to trochę brzmi jak problem. Przez takie ustawienie pewnie większość tekstur leci na ten texturepage... a twoja karta graficzna nie może go obsłużyć i skaluje go wewnętrznie. Gdzieś tam masz przycisk w ustawieniach projektu by podejrzeć texturepage. Zobacz czy wszystkie zdeformowane grafiki nie są przypadkiem na jednym wspólnym

OK sporo widzę już. Zobacz swoje fonty. Musisz dodać brakujące znaki. Rozpixelowane sprite mogą być z wielu powodów. Albo są za duże i musiały być zeskalowane w dól by texturepage mieścił się w rozmarze. Albo masz jakiś dziwny rozmiar okna/view. Albo zapisujesz je na surface i tu problemów moze być jeszcze więcej (np rozmiar nie 2^x) Albo masz po prostu wygładzanie krawędzi

W nowszych GM (chyba od 8.1) możesz zastąpić if dir > direction - (max_angle/2) && dir < direction + (max_angle/2) przez if angle_difference(dir, direction) < max_angle To powinno rozwiązać problemy z "dziwnymi" wartościami direction I pamietaj aby najpierw sprawdzać direction a dopiero potem collision_line(), bo ten drugi jest "cięższy dla procesora" więc chcesz go sprawdzać tylko gdy pierwszy warunek już jest spełniony

Przykład był pisany 14 lat temu. Sporo się pozmieniało i jak pozostałe przykłady służy do nauki nie jest gotowym rozwiązaniem. Zadaj konkretne pytanie jaki jest problem

1. To edycja template. Chyba że to menu to moduł. Wtedy albo jest konfigurowany i musisz zerknąć do konfiguracji modułu, albo jak nie jest konfigurowany to edytować template modułu.

Twoje podejście w tym momencie to: "Jakoś się zrobi", "przecież to tylko podpięcie", "damy radę", "wiem jak". Ale wszystko wskazuje, że nie masz pojęcia jak. Jest to naiwne myśleć, że każdy może siąść i zaplanować, a co więcej napisać sklep internetowy. Samochód też ma 4 koła, drzwi, karoserię, i silnik, który jeździ na paliwo. Paliwo trzeba podawać i działa. Jak ktoś chce to można radyjko zamontować... xD

Dalej nie zrozumiałeś. Siądź sam i przemyśl co ma mieć twój sklep. Mając taką listę możesz wrócić z konkretnymi pytaniami. GDPR widzę że już nie rozumiesz. Nie jest "dane mają być bezpieczne" bezpieczne mają być w każdym serwisie który operuje na danych. GDPR ma pozwalać użytkownikowi na wgląd w swoje dane, możliwość ich edycji oraz usunięcia. I to nie jest zwykłe "usuń z MySQL". Jeżeli chcesz dalej próbować to droga wolna. Ale systemy jak Presta i Magento powstały właśnie po to aby uniknąć 80% tych problemów. Nie łatwo się się je konfiguruje ale też nie robi się tego samemu.

Nie rozumiesz. Stoisz twardo przy swoim pytając jakie możesz napotkać problemy, podczas gdy jest ich setka. Siądź chwilę i rozpisz sobie co jest ci potrzebne do twojego sklepu. Samo wyświetlanie produktów z bazy to nic. Pomyśl o procedurze sprzedaży. Wystawiania faktur, pilnowaniu czy produkty są "in stock". Procedurach bramek płatnościowych. Przechowywaniu danych usera. GDPR. Rozliczaniu płatników z poza polski. Nie będę wymieniał już. To ty twierdzisz że "programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta" więc chyba wiesz czego potrzebuje twój sklep. Jak będziesz miał taką listę to możesz zacząć gdybać ile czasu by ci to zajęło. I to powinien być twój punkt wyjścia. W tym momencie tylko marnujesz siły próbując pytać o szczegóły.

Dlatego nikt nie zabiera się za pisanie sklepu od podstaw (pomijając brak wiedzy) tylko od razu uderza się do agencji która zrobi to w krótkim czasie i bez komplikacji. Bazując na doświadczeniu i zaufanym teamie. Chcesz sobie zacząć już to pisać? Zacznij od generowania PDF faktury. Po 2 tygodniach pracy nad tym przemyśl ponownie co chciałeś zrobić. Tylko nie ośmieszaj się, że nie wiesz co ma być na fakturze. Zapytaj specjalisty od sprzedaży. On na 100% będzie wiedział.

Jeżeli sam nie znalazłeś to nie ma. Język polski nie jest językiem powszechnie technicznym. Jeżeli coś jest po polsku to znaczy, że jakiś amator przetłumaczył z Angielskiego.

Na Discordzie sobie wspominaliśmy ludzi

No hej. Ostatnio nawet o tobie wspominaliśmy Prace na poziomie

No nie. Zazwyczaj autor wtyczki o to dba. Większość będzie nie udokumenowana aby nikt samemu sobie nie dopisywał funkcjonalności i zapłacił za nową

Pliki ini są plikami konfiguracyjnymi. Nie nadają się do przechowywania danych. Możesz tam trzymać ustawienie dźwieku ale nie dane gracza. A jeżeli już chcesz trzymać dane, a szczególnie te o zakupach to trzymanie ich lokalnie na urządzeniu to zły pomysł. Takie rzeczy powinny być server-side. I pobierane przy logowaniu. A logować usera możesz np przed ID z Google Play Services

1. Tak 2. Tak 3. Tak 1. Nie w GM 2. Nie w GM 3. Nie w GM Sam musiałbyś dopisać sobie

Każdą aplikację można odpalić na współdzielonym ekranie. Lepiej czy gorzej. Dopisać obsługę trzeba by działała w tle gdy focus ma druga aplikacja. Sam interfejs się zeskaluje odpowiednio źle w zależności jak ustawisz

Drugie rozwiązanie to aby jedni mieli więcej widoczności niż drudzy :| Tam gdzie wchodzi w grę ratio urządzenia tam będą takie problemy. Rozwiązaniem jest niestety projektowanie gier w taki sposób aby zasięg widzenia nie grał istotnej roli. Ach chciałem tylko przypomnieć że dziwne ratio to nie wszystkie problemy Są też notche które wymagają "save zone" bo inaczej gra może rysować elementy tam gdzie jest akurat notch kamery, albo zaokrąglone boki Na to rozwiązanie jest jedynie designować tak aby nic nie było przy krawędziach (lol) albo zerkać na konkretną nazwę device i obsługiwać je specjalnie Edit: A niektóre telefony pozwalają na uruchomienie 2 aplikacji na podzielonym ekranie gdzie można regulować rozmiar. Wiec apka może mieć dowolne ratio xD

fyi aktualnym standardem ratio od 2019 roku jest 19,5:9 i takie ratio mają już prawie wszyscy producenci