hgter

Musisz wejść w global settings i tam w zakładce androida masz możliwość wyboru w jakich ułożeniach ekranu będzie działać (4 do wyboru)

Dzięki za informację zwrotną, dobrze wiedzieć co było nie tak. Jeżeli chodzi o wysokość miała być częścią dalszych opcji - czyli np. możliwości wykupywania ulepszeń, natomiast czas nie pozwolił. Ponadto w trakcie testów przegrana spowodowana 0 wysokością zaczęła mnie lekko irytować. Można było z tym walczyć zgodnie z mechaniką machając mocno skrzydłami także wtedy gdy nie skręcamy, ale to co wydawało się zabawne na papierze nie było takie do końca w faktycznej grze. Stąd też opcja wyłączenia tego. Nie wywaliłem tego całkiem (choć w ostatecznej wersji tak by się pewnie stało) bo byłem ciekaw opinii. Jak pewnie często się to zdarza nie wyrobiłem się z wszystkim. Np. rozważałem mechanizm synchronizacji machnięć skrzydeł (teraz wygląda dziwnie jak się ustawią w antyfazie). Co do innych gier: Jeżeli chodzi o grę H2S04'a to ją zainstalowałem, choć też nie przepadam za tym. Muszę powiedzieć, że jest trudna - takie rozwinięcie idei pokonało moją koordynację. Propozycja hamtarena zdecydowanie mi podeszła (bardziej niż moja co mnie wnerwia:). Bardzo ciekawe rozwinięcie idei.

Ufff. Dodałem moją grę do Ligi. Pierwszy raz. :) Niby nic, a stresujące jednak było. PS Nigdy jeszcze nie pisałem nic docelowo na pc. Mam nadzieję, że będzie działać wszystkim.

Żaby nie było, że się czepiam - nie odbierz proszę spisu błędów w ten sposób. Uznałem, że wolisz wiedzieć o tych rzeczach niż nie wiedzieć. Całość może być całkiem zabawna, ale teraz widać niedobór testowania. Z nexusa 7. Najbardziej irytujące jest przerywanie poruszania co chwilę (próbowałem wyłączyć sieć - bez zmian). Wygląda to tak, że nogi przestają się ruszać na 0.5s (świnia dalej się przesuwa, ale trochę wolniej), całość szarpie a wciśnięty przycisk ruchu miga. Powtarza się to co chwila. Szczególnie jak podejdę do zombie (tak bardzo, że trudno od niego odejść). Raz po zginięciu i wybraniu przycisku powtórz (zawinięta strzałka) całość zawiesiła się na loading z głosami w tle. Zupełnie nie rozumiem związku między zebranymi bekonami a bekonami w podsumowaniu levelu. W pierwszym poziomie zbieram 3 a w podsumowaniu są 2. W drugim poziomie zbieram chyba 10 a w podsumowaniu 0. Jeżeli podsumowanie zależy od czegoś innego to zupełnie nie jest wyjaśnione od czego a użyte bekony wyraźnie sugerują związek. Przechodzę 2 level i dalej nie mogę bo piszę, że muszę mieć chociaż 1 bekon. Czy te bekony z podsumowania służą do czegoś? Czy po prostu trzeba mieć chociaż jeden aby zaliczyć level? Cała kwestia bekonu jest dla mnie nieintuicyjna. Przycisk powrót do listy (ikona zapisanej kartki) sugerowałby raczej powrót do spisu leveli a nie do ekranu głównego. W spisie leveli przydałby się przycisk sklepu (choć jeżeli powrót będzie zawsze do ekranu głównego to bez znaczenia). Podobnie po przejściu levelu brakuje możliwości zakupów. Wybuch beczki nie zawsze rani świnię. Po wskoczeniu na skrzynkę z początku levelu nie mogę podskoczyć, ich ułożenie sugeruje, że da się na nie wejść. Jeżeli ma się nie dać to może ułóż je inaczej? Bo teraz jest szklana ściana. Przyciski ruchu zachowują się niekonsekwentnie. Nie zawsze gdy puszczam przycisk zmienia się na "nie wciśnięty". Skok i strzał tego nie mają. Teraz świnia jest na środku ekranu. Rozważ aby była trochę bardziej przy jego lewej krawędzi bo przecież ważne jest to co z przodu (przez to wolniej reaguje się na zombie). Przejście do Info na głównym ekranie nie jest płynne wygląda to trochę podobnie do ruchu świni z punktu pierwszego. Może to jest po prostu spadek fps? Gdyby była możliwość ich podglądu napisałbym więcej. Ale jeżeli tak to trochę dziwne. Pisząc swoją grę akurat ten tablet traktuję jako mocny przy optymalizacji. Może jeszcze coś wyszperam w wolnej chwili. Pozdrawiam

Cały dzień zabawy i się udało:) Może komuś się przyda. Kluczem było odpowiednie użycie danych liczonych dla małych roomów. Przy uruchamianiu pierwszego małego roomu wywoływany jest kod z pierwszego posta. Ale po nim dodałem: GML global.ekran_szer=1280+2*abs(offset_x) global.ekran_wys=720+2*abs(offset_y) global.pasek_x=offset_x global.pasek_y=offset_y Co wylicza mi dane potrzebne do wyświetlenia dużego roomu (liczby to wielkość view czyli 1280x720) Przy jego starcie wywołuję: GML view_wview[0]=global.ekran_szer //1280 view_hview[0]=global.ekran_wys //800 view_xview[0]=global.pasek_x //0 view_yview[0]=global.pasek_y //-40 view_wport[0]=device_w //pobieram wcześniej view_hport[0]=device_h Wartości w komentarzach to wartości podczas skalowania view 1280x720 do ekranu 1920x1200 - podane dla przykładu. To powoduje, że jeżeli proporcje ekranu różnią się od mojego pierwotnego view to na ekran idzie też trochę tego co znajduje się poza view (co powoduje, że przy krawędziach wyświetlają się dane spoza roomu). Potem te dodatkowe obszary przysłaniam czarnymi paskami. Mamy natomiast dwa "ale". Po pierwsze, ponieważ wyświetlam także obszary spoza roomu, przestaje poprawnie działać podążanie view za obiektem. To trzeba samemu zakodować. Podobnie jeżeli mamy ręcznie przesuwane view. I po drugie, tym razem nie możemy czarnych pasków narysować tilem, bo te paski muszą się przy przesuwaniu view także przesuwać. Musimy je narysować w odpowiednich miejscach zależnych od view. Całość działa dokładnie tak jak miała. Jeżeli proporcja ekranu się nie zgadza to pojawiają się dodatkowe paski zarówno przy roomach o wielkości view jak i większych. Rozwiązanie banalne, ale zabawy było od groma. PS A miałem grać w Fallouta cały dzień.

Tylko, że to nie działa. Jeżeli nie dam tila to wyświetla się to co teoretycznie jest poza roomem z tłem roomu. Ustawienie koloru roomu nic nie zmienia tutaj. Jeżeli nie dam grafiki na tło to okno przyjmuje ten kolor (także na tym obszarze gdzie normalnie mam paski), ale normalnie wszędzie mam grafikę tła. Myślę, że jest to efekt wyłączonych surface. I dokładnie taki efekt by mnie zadowalał w przypadku dużych roomów (paski sobie dodaję ręcznie i jest ładnie). Ale tam albo mam zapełniony cały ekran normalną treścią roomu (także tam gdzie w małych rumach jest "pustka" która przykrywam czarnym tilem) i nie ma jak dać pasków albo room jest zmniejszony tak, że się cały mieści. Teraz rozwiązałem to tak, że duże roomy wyświetlam na całej powierzchni ekranu bez względu na proporcje (na jednych urządzeniach w danym momencie widać trochę mniej niż na innych) a w przypadku małych tam gdzie były czarne tile mam rozszerzone grafiki stanowiące "ramkę" roomu. W rezultacie to ile tej ramki widać jest zależne od urządzenia. Efekt nie jest zły, ale jednak wolałbym paski.

Witajcie Problem jest pewnie banalny, ale coś poległem. W przypadku roomów o wielkości view korzystam z poniższego kodu wywoływanego na początku wczytywania każdego roomu (to nie jest mój kod, przyznaję): GML if os_type == os_windows { device_w = window_get_width(); device_h = window_get_height(); } else { device_w = display_get_width(); device_h = display_get_height(); } window_set_size(device_w, device_h); game_w = room_width; game_h = room_height; device_aspect = device_w / device_h; game_aspect = game_w / game_h; if device_aspect/game_aspect>=1 { view_wview[0] = game_h * device_aspect; view_hview[0] = game_h; offset_y=0; offset_x = (game_w - view_wview[0])/2; view_xview[0] = offset_x; view_yview[0] = room_height - game_h; } else { view_wview[0] = game_w; view_hview[0] = game_w / device_aspect; offset_x=0; offset_y = (game_h - view_hview[0])/2; view_xview[0] = room_width-game_w; view_yview[0] = offset_y; } view_wport[0] = device_w; view_hport[0] = device_h; idt=tile_add(til_outofscreen, 0, 0, 15, 15, -300, -300, 99999); tile_set_scale(idt, 20, 120); idt=tile_add(til_outofscreen, 0, 0, 15, 15, 1280, -300, 99999); tile_set_scale(idt, 20, 120); idt=tile_add(til_outofscreen, 0, 0, 15, 15, 0, -300, 99999); tile_set_scale(idt, 120, 20); idt=tile_add(til_outofscreen, 0, 0, 15, 15, 0, 720, 99999); tile_set_scale(idt, 120, 20); Celem tego jest dopasowanie roomu do wyświetlacza. Proporcje roomu zostają zachowane a jeżeli wyświetlacz ma inne to wyświetlane są czarne paski (robię to czarnym rozciągniętym tilem na samym końcu - bez tego w miejscu czarnych pasków wyświetla się tło roomu). Problem jest gdy roomy są większe niż view. Tu rzecz w tym, że takie skalowanie dla większych roomów teoretycznie nie ma sensu. Bo nie ma sensu wyświetlać pasków jeżeli room jest większy bo można bez problemu użyć całego wyświetlacza. Tyle, że ja mam roomy o różnej wielkości i chciałbym aby były wyświetlane tak samo - czyli z paskami. Ma ktoś z Was pomysł jak uzyskać dla dużych roomów view o takiej samej proporcji jak dla mniejszych?

Witaj Graficznie bardzo miło to wyszło i otwiera się ładnie pod studio (w przypadku innych Twoich silników patrzyłem wyrywkowo i raczej był kłopot). Co do kodu, to w przypadku serc/prostokątów/mniejszego paska rozwiązanie jest zgrabne. Natomiast w przypadku dużego raczej bym nie poszedł w tym kierunku - tylko użył np. draw_sprite_part. Ale oczywiście Twoje działa i wygląda fajnie. ps Dzięki za zamieszczenie wszystkiego - zawsze chętnie popodglądam cudze rozwiązania

Zgadza się co do draw. Trochę irytujące to jest. I to na tyle, że zaczynam zastanawiać się czy dobrym wyborem do 2D jest GM i czy nie lepiej byłoby pracować na np. Unity. Nie wiem czy słusznie, ale mam odczucie, że w GM bardzo szybko można uzyskać działającą grę, ale jest sporo zabawy żeby działała dobrze. Spotkałem się z opinią, że wiele osób używa GM jedynie do prototypowania. Nie wiem jak to jest w Unity natomiast. PS A fpsy są niskie cały czas (nawet lekko spadają - ale to pewnie przy dalszej optymalizacji zniknie).

Zrobiłem jeszcze trochę testów. Wyniki są dość zaskakujące: 1) Próbowałem jeszcze raz z tilami - nie mogłem uwierzyć, że to też zabierało fps. Potwierdziło się. Dawanie 1 dużego tila nic nie pomaga 2) Po podziale na 4 mniejsze tile nadal bez zmian. 3) No dobra to automatem pokrywam wszystko tilami 30x30 - bez zmian Zacząłem kombinować z background. No bo on jest wielki a nie obniża fps. 4) Funkcja draw_background - wygląda świetnie, ale fpsy lecą w dół bez zmian. 5) I w końcu postanowiłem nie rysować niczego tylko użyć: room_set_background. I to nie powoduje spadku fpsów. Czyli jeżeli background rysuję to spadek jest a jeżeli go ustawiam to nie ma. Wynika z tego, że użycie tilów jest wolne i użycie jakichkolwiek draw też. Kurde trochę bez sensu. Ale tak wyszło. Dla pewności sprawdziłem co będzie jeżeli surface utworzę, ale nie narysuję - i tu zgodnie z oczekiwaniem spadku nie ma. Czyli jeżeli nie chcę zmniejszać wielkości roomu to na słabych urządzeniach muszę zamienić wszystkie grafiki w background i następnie przypisać do roomu. Wadą jest to, że room_set_background nie można użyć na aktywnym roomie oraz to, że nie można tu użyć sprita - można co najwyżej wczytać plik. Mogę teraz zrobić to na dwa sposoby: albo mieć gotowe wcześniej odpowiednie backgroundy dla każdego levelu - ale to spowoduje, że gra będzie wielka albo przy pierwszym uruchomieniu gry konwertować kolejno w każdym roomie wszystkie grafiki wraz tłem na surface, potem zapis do pliku i następnie odczyt do backgrounda. O matko. Jak ktoś zna sposób na bezpośrednią zamianę surfaca/sprita w background to poratujcie.

Kurcze na początek dzięki wielkie, że chciało Ci się to wszystko zebrać. 1. Wylaczenie application_surface ktore wylaczyles owszem bardzo pomaga, ale jego wylaczenie nie wylacza korzystania z surface W OGOLE, dlatego mozesz z wlasnych korzystac. Podejrzewałem to, tylko cały czas się boję czy nie będzie z tego artefaktów. Np. nie mogłem zmusić do działania surface_resize - po prostu znikała. 2. Android jest słaby z dużymi surface'ami, dlatego ta 1sza opcja tak bardzo pomogła. Dlatego tez jakikolwiek wlasny surface ktory jest DUŻY zmniejszy wyraźnie wydajność. Szperając byłem tu: http://gmc.yoyogames.com/index.php?showtopic=655565 I po tym zacząłem kombinować z podziałem spritów na mniejsze części. Myślałem czy nie zrobić podobnie na etapie tworzenia surface - czyli np. zamiast jednej dużej dać 4 mniejsze, ale naprawdę nie chcę wbijać w pisanie kodu tego. Generuję obraz na bazie dużej ilości trójkątów i gdybym chciał to w locie dzielić na np. 4 musiałbym w przypadku tych trójkątów, które wchodzą na dwie surface jadnocześnie wyliczać przecięcie i rysować jedną połówkę tu a drugą tu. Już tu mi się odechciewa mocno, a jak pomyślę co z trójkątami które są na 4 surfacach (lub więcej) to odpadam:) Jeszcze teoretycznie mógłbym użyć surface_copy_part do podziału gotowej surface na 4 części, ale jak robiłem podobnie, tyle że dzieląc na 4 sprity to efektu nie było niestety. Chyba sam fakt, że surface była rozwalał fps. Miałem też epizod, w którym wykorzystałem to: http://gmc.yoyogames.com/index.php?showtop...49#entry4734849 Przerobiłem to tak, że na początku gra stopniowo zmniejszała jakość do takiej przy której ilość fpsów była wystarczająca. Ale to był niewypał bo fakt, że do tego surface musi był włączony powodował, że na s3 mini gra szła dopiero przy około 0.2 początkowej wielkości co dawało jakość w której nic nie było widać:) Ale sama idea była fajna. 3. W Androidzie bardzo ważny jest texture swap. Każda grafika jest zapisana na texture page'u. Postaraj się je pogrupować tak aby grafiki były roomami aby jak najmniej stron naraz było aktywne. Ok, dobra idea. Niby to bardzo wstępna wersja, ale mam kupę starych wersji spritów, które niepotrzebnie się ładują. 4. Próbowałeś jednak je rysować na bierząco zamiast trzymać surface/sprite? Może jednak okaże się szybsze? Niestety tak. Danie tego do surface dało prawie 4x wzrostu fps (ale na mocnych urządzeniach - sprawdzę czy na słabym nie zachowa się to inaczej). 4a. Background jest szybszy od sprite bo nie ma maski kolizji ani klatek animacji. No tak tylko, że spróbowałem też podejścia, w którym najpierw wygenerowałem 4 pliki png z ćwiartkami tego surface i następnie w projekcie testowym wstawiłem je jako tile. Tu nie było rysowania surfaceów ani spritów a i tak nie dało to efektu. Byłem tym naprawdę zdziwiony - liczyłem, że w najgorszym razie zrobię to tak, że po rozpoznaniu słabego urządzenia, gra przy pierwszym uruchomieniu wygeneruje sobie odpowiednie tile i to z nich będzie korzystać potem. 5. Co prawda YYC nie pomaga na draw, a na step, ale może Ci zaoszczędzi te kilka FPS Niestety akurat tu różnica była zbyt mała. 6. Rozumiem view_wview/hview jest 1920x1080, ale polecam view_wport/hport zmniejszyć do rozdzielczości wyświetlacza, jeśli tego jeszcze nie robisz Tak właśnie robię. 7. Robię na 720p na Androidzie, bo spadek jakości po rozciągnięciu na 1080p nie jest jakis zly, a kompromisy się przydają. I chyba w tym kierunku pójdę. Ciekawy byłem jakie inni stosują tu wielkości. Tylko właśnie tego rozciągania się bałem. Muszę zrobić sobie jakiś testowy obraz i zobaczyć jak duże są te straty. 8. Room speed mocno wpływa na wydajność na Androidzie. Bywa tak, że na room_speed 30 utrzymuje stałe 30, ale na room_speed 60 trzyma się poniżej 30 tam, gdzie na speed 30 byłoby stabilnie. Wplywa to również nieznacznie na FPSy przez ogólne obciążenie urządzenia. 9. Dodatkowo do przeciwwagi spadków prędkości używaj delty. Nie zwiększy Ci to FPS ale zmniejszy ilość bolących zadków, bo nie będzie spowolnienia gry samej w sobie. Niestety całość gry opieram na fizyce. I te 60 musi być aby miało to sens. 10. Jak masz pewność, że background zapełnia cały ekran, polecam w roomie wyłączyć opcje [settings>>]"Clear Display Buffer with Window Colour" oraz [backgrounds>>] Draw background color Ok, dzięki. 11. Global Game Settings>Android>Graphics>16 bit To tyle co z głowy mogę wyciągnąć apropo optymalizacji. Rozumiem, że pewne rzeczy mogą Cię zniesmaczyć, jak chociażby 16-bitowa grafika, ale pamiętaj, że robisz grę na małe urządzonko trzymane w kieszeni, a nie na komputer. Jesteś przyzwyczajony że 2015 i taka technologia i takie bajery, no ale telefon to telefon. To będzie bardzo prosta gierka - fajerwerków nie będzie tak dużo:). Cała ta zabawa jest, ponieważ chcę maksymalnie ułatwić pracę w edytorze roomów, aby zupełnie bez kodowania i tailowania można było tworzyć "z klocków" kolejne levele. I robię to też trochę "dla sztuki" żeby się nauczyć jak najwięcej na tym projekcie. Stąd wspomniany gdzieś wcześniej przeze mnie mechanizm, w którym obiekty po starcie usuwają się, konwertując przy tym do prymitywów opartych o trójkąty, które z kolei się ładnie teksturują i są wrzucane na surface. Podobnie z fiksturami. W efekcie nie ma różnicy czy w grze jest 10 czy 600 obiektów (muszę w końcu zrobić testy ile maksymalnie tych obiektów wyciągnę). Oczywiście jeżeli obiektów miałoby być 10 na ekranie to to jest idiotyzm na którym więcej tracę niż zyskuję. Edit: Mogę Ci wydajność testnąć jeśli podeślesz APK na PW. Chociaż moje urządzenie to tablet i to całkiem dobry więc może Ci nie dać żadnych interesujących wyników. Na razie urządzeń trochę mam więc dziękuję. Muszę chyba tylko coś słabszego kupić. Jeszcze raz dzięki za odpowiedź!

Witajcie Walczę sobie z wydajnością na androidzie. Na nexusie 7 i xperii Z jest w pełni ok. Natomiast po uruchomieniu na Samsungu s3 mini jest marnie. Srednio mam poniżej 60 fps. W razultacie grafika tnie. Roomy mają 1920x1200 co jest ręcznie (mam wyłączone surface) skalowane do odpowiednich proporcji z wykorzystaniem czarnych pasków jeżeli proporcja ekranu jest inna. Tło też jest obrazkiem o takiej wielkości (sprawdzałem z skalowaniem mniejszego, ale to nie zmienia nic). I teraz chcę wyświetlić sporo elementów (prymitywy) w roomie - te elementy są zawsze w tych samych miejscach i ich każdorazowe oddzielne wyświetlanie jest nieszczególnym pomysłem. Teraz robię to tak, że tworzę raz surface (mam wyłączone surface - mimo to da się je tworzyć) i potem ten surface wyświetlam. Na szybkich jest ok, ale na wolniejszym urządzeniu schodzi to poniżej 60 fps. Jeżeli wyłączę fragment kodu odpowiedzialny za generowanie surface wydajność bardzo rośnie (no ale nie mam grafiki:). No to sobie pomyślałem, że ten surface po utworzeniu przerzucę do sprita a surface usunę. Nic się nie zmieniło. Ok no to testowo zapisałem surface na dysku i w testowej wersji dałem jego wyświetlanie jako sprita. Jak było źle tak jest, chociaż kodu z surface nie ma wcale. Skoro tak, to chyba to duże jest (ale co z tłem które też jest takie duże a nie wpływa na wydajność?). Pociąłem na 4 oddzielne sprity. Nadal kicha. Tak samo jak ustawię to jako tiles. Ech. Co mogę z tym zrobić? Dlaczego tło roomu nie zwalnia całości a tak samo duży surface/sprite/tiles już tak? Wiem, że mogę zmniejszyć room np. do 960x600 i to rozwiązuje problem (sprawdzone). Ale chciałbym aby na urządzeniach z wysoką rozdzielczością dobrze się wyświetlało. Jakie Wy wykorzystujecie wielkości roomów?

Działa dokładnie tak jak powinno. Dzięki wielkie.

Witajcie Wykorzystuję surface. Ponieważ przy minimalizacji itp. są one automatycznie usuwane, wykrywam to i reaguję: GML if surface_exists(global.surf_triangle) { draw_surface(global.surf_triangle, 0, 0); } else { scr_primitives_surface() //skrypt generujący określone surface draw_surface(global.surf_triangle, 0, 0); } I na PC działa świetnie. Wykrywa, że surface zniknęło i odtwarza ją. Ale na androdzie to zupełnie nie działa. Gdy zminimalizuję apkę i ją przywrócę zawartość surface znika, ale surface_exists i tak zwraca true. Chyba nie tylko ja mam z tym problem: http://bugs.yoyogames.com/view.php?id=15485 Czy ktoś z Was jakoś sobie już radził z tym problemem? Jakieś obejście? Jak wykryć na androdzie, że apka się zminimalizowała?

Dzięki, widziałem to wtedy:) - ale jednak chciałem mieć swoje rozwiązanie. Fajnie to tam wyszło. Jest to mocno rozbudowane, bo u mnie tylko obiekty o stale zdefiniowanym kształcie są wypełniane teksturą, ale można je dowolnie skalować i obracać na etapie tworzenia poziomu. Chodzi o to aby łatwo można było budować z klocków levele z ich automatycznym teksturowaniem. Reszta to tylko kwestia tego, że chciałem mieć możliwość użycia dużej ilości różnych obiektów przy zachowaniu znośnej wydajności. Sorry, że niezrozumiale to opisałem. PS Dzięki Uzjelu za poprawę formatowania kodu w poście - będę tak robił.

Witajcie Wybaczcie długi wstęp, ale po pierwsze chcę, aby było wiadomo skąd się bierze wszystko to z czym jest kłopot, a po drugie może robię coś niepotrzebnie a da się dużo prościej: Pracuję nad prościutką gierką zręcznościową, w której będzie bardzo dużo poziomów (znaczy w teorii:). Całość wykorzystuje fizykę. Do projektowania poziomów wstępnie użyłem standardowej metody. Czyli z pomocą rozciąganych obiektów tworzę szkielet poziomu (ściany, platformy itp.), a w drugim etapie ręcznie pokrywam te rozciągnięte obiekty ładnymi tilesami. I to działa. Obiektów jest mało i całość chodzi szybko. ALE Poziomów ma być dużo i niespecjalnie miło widzę to całe ręczne pokrywanie szkieletu. Chciałbym żeby obiekty (wstępnie w formie trójkątów prostokątnych) same pokrywały się grafiką, ale z zachowaniem tego, że są skalowane i obracane. Robię to tak: mam duży plik z tłem (wielkości okna) z jakąś tam teksturą. Etap wyliczania wierzchołków każdego obiektu z uwzględnieniem skalowania i obrotu poszedł bez problemu. Następnie wykorzystując Primitives (tilesów nie, bo tam może być chyba tylko kwadratowy fragment?) wyświetlam odpowiednie fragmenty tekstury w miejscu obiektu. Mógłbym to tak zostawić bo w sumie już działa. Ale chciałbym mieć możliwość stworzenia tych obiektów bardzo dużo. Czyli chciałbym mieć ciastko i zjeść ciastko: "samotailsujące" się obiekty, których może być bardzo dużo. Wymyśliłem tak: niech każda instancja obiektu na początku przekazuje wyliczone własne trzy wierzchołki do zbiorczej tablicy a potem sama się usuwa. I to też działa (na chwilę obecną zajmuję się tylko wyświetleniem, ale dla fizyki zrobię podobnie, też przypiszę wiele fixtures do jednego obiektu). Uzyskuję jeden obiekt, który ma zarządzać wyświetlaniem. Ale tu pojawia się problem. Póki instancji trójkątów jest mało to całość działa, ale jak zwiększyłem ich ilość to po przekroczeniu pewnej granicy (dokładnie 333) wywala się wyświetlanie wszystkiego. Mam artefakty, inne obiekty niezależne się wyświetlają źle albo zupełnie nie. Robię to tak: Ten kod wrzucony jest bezpośrednio w draw obiektu zarządzającego: GML draw_set_colour(c_white); var tex = background_get_texture(tlo); draw_primitive_begin_texture(pr_trianglelist, tex); for (licz1 = 0; licz1 < global.ilosc_tiles; licz1 += 1) { c_x=global.tiles[licz1,1] c_y=global.tiles[licz1,2] w1_x=global.tiles[licz1,3] w1_y=global.tiles[licz1,4] w2_x=global.tiles[licz1,5] w2_y=global.tiles[licz1,6] draw_vertex_texture(c_x, c_y, c_x/1920, c_y/1200); draw_vertex_texture(w1_x, w1_y, w1_x/1920, w1_y/1200); draw_vertex_texture(w2_x, w2_y, w2_x/1920, w2_y/1200); } draw_primitive_end(); Tablica global.tiles przechowuje wcześniej wyliczone wierzchołki wszystkich obiektów. Jak rozumiem jeżeli obiektów jest więcej niż 333 to kod w draw nie daje rady się wykonać? Zdaję sobie sprawę, że każdorazowe liczenie tego primitywu składającego się z tylu trójkątów jest głupotą - tym bardziej, że nic się nie zmienia. To są nieruchome obiekty czyli wystarczyłoby tylko raz opracować i potem wyświetlać. Tylko jak? Jak zrobić coś takiego: zbiorczy_prymityw=blablabla i w draw tylko: GML draw(zbiorczy_prymityw) Będę zobowiązany za wskazówki. PS Nie wiem czy to będzie istotne, ale ponieważ gra ma być na androida to mam application_surface_enable(false) - sam sobie zarządzam skalowaniem PPS Walcząc z tym problemem póki co rozwiązałem to tak, że stworzyłem dwa zbiorcze obiekty. Jeden wyświetla tekstury dla instancji 1-300 a drugi 300-600 (można dodać kolejne) i to działa ok. Ale to straszna prowizorka - poza tym nadal jest bez sensu że w każdym stepie od zera rysuję całą scenę zamiast tylko wyświetlić wcześniej stworzoną. Ehh liczę na Was bo nie wiem jak to ugryźć a ta metoda ma sens. Przyrost wydajności w porównaniu do wyświetlania się każdego obiektu oddzielnie jest mniej więcej czterokrotny. PPPS Kurde tak podejrzewałem, że surface będzie rozwiązaniem: http://forums.tigsource.com/index.php?topic=7441.0 (post 3). ROZWIĄZANIE: Mimo application_surface_enable(false) daje się wyświetlić stworzony surface (myślałem, że się wywali dlatego nie szedłem w tym kierunku). Co ciekawe limit 333 instancji pozostał. Myślę, że to chodzi o to, że mam 3 punkty na każdą z 333 instancji czyli primitives może się składać z max 1000 punktów - ale nie mogę tego potwierdzić nigdzie. W każdym razie muszę tworzyć więcej primitives niż 1 jeżeli mam więcej obiektów niż 333. I o dziwo działa a wydajność na androidzie jest kosmiczna - kolejne 4-5 razy w porównaniu do rozwiązania z dwoma kontrolnymi obiektami (a na pc znowu odwrotnie - ale może to jakiś artefakt). Czyli ponad 16x! lepiej niż jeżeli po prostu wyświetlam primitives w każdej instancji oddzielnie! Jedyny problem jest na androidzie bo zablokowaniu i odblokowaniu ekranu moja piękna surface znika. Ale to pewnie do rozwiązania jest. W sumie ponieważ sam sobie rozwiązałem problem (nadal po partyzancku, ale działa) to chyba powinienem usunąć cały wątek? Ale może komuś się przyda? Używaj tagów [ gml ], aby kod był czytelny - Uzjel

Że się tak wtrącę: byłoby super:) Ze swojej strony jeszcze może pytanie: jak z rozliczaniem się w kwestii podatków? Bo z tego co czytałem w IOS jest łatwiej, bo to oni sprzedają grę, ale pod Androidem to chyba trzeba firmę założyć? Spotkałem się z informacją, że jeżeli tylko reklamy to nie trzeba, ale przy sprzedaży i mikropłatnościach już tak. I jak to jest teraz od stycznia z tym cholernym vetem i płaceniem go w kraju kupującego (Jezu mam nadzieję, że coś pokręciłem i nie zrozumiałem). Jak sobie z tym wszystkim radzicie?

Najzabawniejsze, że nawet mi to przez myśl nie przeszło:) Jestem nieprzyzwyczajony do posiadania "wsparcia". Teraz, skoro i tak mam moduł exportu, problem sam się rozwiązał. Ale pewnie gdyby nie to, rzeczywiście musiałbym do nich pisać.

Dzięki za odpowiedzi. Wybaczcie, że reaguję z opóźnieniem, ale choroba nie wybiera. Zrobiłem jak radziliście, ale niestety nic to nie zmieniło. W konsoli wyglądało to tak jakby GM wysyłał kod aplikacji (i po sprawdzeniu był on na urządzeniu), ale nie instalował nowego yoyo.runnera (jego nie było). Tak czy siak zakupiłem właśnie export na androida i po zaktualizowaniu licencji GM się zrestartował, dociągnął coś z sieci i po starcie.... bezproblemowo jednym kliknięciem uruchomiłem apkę na tablecie. Czyli problem był jednak nie w sdk tylko w samym GM. Teraz jest mi to co prawda obojętne, bo i tak mam ten export, ale muszę powiedzieć, że to naprawdę niefajne. Teoretycznie kupując Pro mogłem testować apki na urządzeniach (i działało to bez problemu) a tu nagle w którejś wersji wycięli. Mam nadzieję, że to był po prostu błąd, a nie celowe zagranie - bo jak tak to mocno kijowe z ich strony. Nie dość, że ceny poszły w górę to jeszcze takie coś.

Witajcie Sprawa dotyczy GM:Studio 1.4 Professional BEZ eksportu na Androida. Wcześniej wyglądało to tak, że mogłem bez jakiegokolwiek problemu sprawdzać działanie projektów na urządzeniach z androidem podpiętych kablem. Po ustawieniu Targetu na Androida program był przerzucany na urządzenie, yoyo.runner był instalowany i po chwili wszystko ruszało. Natomiast po aktualizacji do najnowszej wersji już niestety nie działa (po odinstalowaniu i czystej instalacji tak samo). Znaczy program jest kopiowany na urządzenie (które na 100% jest rozpoznane), ale na tym koniec. Nigdzie w konsoli nie widzę wydanego polecenia kopiowania i instalacji yoyo.runnera. Stary nie działa (sprawdzone na jednym urządzeniu) a nowy się nie pojawia (sprawdzone na drugim). Grzebię, grzebię i kurczę nic. Znalazłem coś takiego: http://bugs.yoyogames.com/print_bug_page.php?bug_id=16725 ale tam twierdzą, że w najnowszej wersji powinno być ok. A właśnie w najnowszej wersji jest problem. Po odinstalowaniu wszystkiego i zainstalowaniu starszej wersji jest ok (bez jakichkolwiek zmian z mojej strony - po prostu się uruchomiło). Może ktoś ma jakiś pomysł w jakim kierunku pójść?

Witaj Jeżeli chodzi Ci tylko o uproszczenie samego zapisu to można np. tak: if (opcja=1) {draw_text_color(128,256,'New Game',c_red, c_red, c_red, c_red,1)} else {draw_text_color(128,256,'New Game',c_white, c_white, c_white, c_white,1)}; if (opcja=2) {draw_text_color(128,256+32,'Load',c_red, c_red, c_red, c_red,1)} else {draw_text_color(128,256+32,'Load',c_white, c_white, c_white, c_white,1)}; if (opcja=3) {draw_text_color(128,256+64,'Options',c_red, c_red, c_red, c_red,1)} else {draw_text_color(128,256+64,'Options',c_white, c_white, c_white, c_white,1)}; if (opcja=4) {draw_text_color(128,256+64+32,'Bonus',c_red, c_red, c_red, c_red,1)} else {draw_text_color(128,256+64+32,'Bonus',c_white, c_white, c_white, c_white,1)}; if (opcja=5) {draw_text_color(128,256+64+64,'Quit',c_red, c_red, c_red, c_red,1)} else {draw_text_color(128,256+64+64,'Quit',c_white, c_white, c_white, c_white,1)}; A jeżeli dodatkowo nie zależy Ci na gradiencie to: if (opcja=1) {draw_set_color(c_red)} else {draw_set_color(c_white)}; draw_text(128,256,'New Game') if (opcja=2) {draw_set_color(c_red)} else {draw_set_color(c_white)}; draw_text(128,256+32,'Load') if (opcja=3) {draw_set_color(c_red)} else {draw_set_color(c_white)}; draw_text(128,256+64,'Options') if (opcja=4) {draw_set_color(c_red)} else {draw_set_color(c_white)}; draw_text(128,256+64+32,'Bonus') if (opcja=5) {draw_set_color(c_red)} else {draw_set_color(c_white)}; draw_text(128,256+64+64,'Quit') Pozdrawiam

physics_joint_revolute_create(id,i, x-32, y-32, 0, 0, true, 0, 0, 0, 0); w efekcie udarza w ścianę, wysięgnik się wbija w pojazd i potem wysuwa (czyli jakby zawieszenie wyszło). DOdatkowo mimo ogarniczenia jest odgnięcie na boki. physics_joint_prismatic_create i physics_joint_weld_create próbowałem wszystkich możliwych ustawień - jak wyżej. Jednym słowem połączenia zachowują się całkiem ok do momentu, w którym całość nie wali w ścianę. Wtedy połączenie odkształca się jakby było z gumy. Obszedłem problem rozciągając maskę pojazdu tak aby objęła też dodatki, ale to nie jest czyste rozwiązanie i wygeneruje multum pracy (chcąc dodawać moduły o różnej wielkości będę musiał za każdym razem ręcznie korygować maskę). Aż mi się nie chce wierzyć, że nie ma najprostszego możliwego połączenia. Na pewno gdzieś coś mam źle ustawione, ale naprawdę nie mam pomysłu gdzie.

Ponieważ to mój pierwszy post, to na początek witam Wszystkich :) Zaczynam od problemu, z którym walczę i nie bardzo mam pomysł jak to ugryźć. Wykorzystuję fizykę. Chciałbym uzyskać sztywne połączenie między dwoma obiektami (pojazdem i doczepianym cosiem). Sztywne czyli takie, aby potem w fizyce całość była traktowana jako jedna sztywna bryła. Po przejrzeniu dostępnych jointsów wyszło, mi że takiego bezpośredniego nie ma. Próbowałem to obejść wykorzystując np. physics_joint_revolute_create z zakresami obrotu na od 0 do 0 oraz prismatic z 0 zakresem ruchu. Próbowałem też distance do dwóch punktów. I kurczę za każdym razem to nie jest to czego oczekuję. Niby wszystko jest ok, ale jak całość wali w ścianę to te doczepiane cosie przesuwają się na różne sposoby (np. mimo ustawionych kolizji między obiektami "wnikają" w siebie - jak to jest w ogóle możliwe - może mam jakiś parametr źle - ale jaki?). Co robię nie tak? Da się to jakoś obejść? Będę zobowiązany za wszelkie sugestie.