sunflower

Kod źródłowy obiektu rysującego (alarmy pomijam, bo tylko ustawiają zmienne): Create: GML surf = surface_create(32, 32); //tworzenie surf. dla przypadku 1 surf2 = 0; //zmienna surf. dla przypadku 2 i 3 varyy = false; //zmienna dla tworzenia i narysowania w przypadku 2 alarm[0] = 1; //ustawia varee na true varee = false; //zmienna dla ponownego tworzenia i narysowania alarm[1] = 60; //ustawia varyy na true //rysowanie na surface 1 w tym samym bloku co jego tworzenie surface_set_target(surf); draw_sprite(sprite0, 0, 0, 0); surface_reset_target(); Draw: GML //tworzenie surface 2 i bezzwłoczne rysowanie sprite0 (przypadek 2) if (varyy) { surf2 = surface_create(32, 32); surface_set_target(surf2); draw_sprite(sprite0, 0, 0, 0); surface_reset_target(); varyy = false; } //rysowanie sprite1 na juz istniejacym surface 2 (przypadek 3) if (varee) { surface_set_target(surf2); draw_sprite(sprite1, 0, 0, 0); surface_reset_target(); varee = false; } //sprite0 i porownanie z surface 1 draw_sprite(sprite0, 0, 10, 10); if (surface_exists(surf)) draw_surface(surf, 10, 50); //sprite1 i porownanie z surface 2 draw_sprite(sprite1, 0, 50, 10); if (surface_exists(surf2)) draw_surface(surf2, 50, 50); Wersji 1.1.1076 jeszcze nie mam, prawdopodobnie ze względu na fakt późniejszego pojawiania się nowych wersji na Steamie. >.<

Problem zachodzi dla wersji 1.1044, nie wiem, czy występował w poprzednich. Przypadki są następujące: - tworzę jednego surface'a wraz z tworzeniem obiektu i od razu rysuję sprite0; odpalam Alarm0 i Alarm1 - tworzę drugiego surface'a po Alarm0 i od razu rysuję sprite0 - po Alarm1 rysuję sprite1 na drugim surfacie Niezależnie od przypadku o ile sprite'y rysują się prawidłowo, o tyle surface'y mają dziwną tendencję do zniekształcania tychże. Można to zobaczyć na tym obrazku: http://i42.tinypic.com/35n5xyo.png (na górze sprite0 i sprite1, na dole pierwszy surface i drugi surface, już po Alarm1). Nic mi nie wiadomo na temat tego, żeby w przykładowym projekcie gdzieś zachodziła zmiana jakiegokolwiek rozmiaru (okna, sprite'a, cokolwiek) ani obracanie; nie widzę żadnych rozsądnych przesłanek, dla których sprite rysowany na surfacie nagle ma się rozmazywać. Postarałam się, żeby ten program testowy był raczej prymitywny i nie wprowadzał dodatkowych okazji do zakłóceń. O.o" Jeśli nic nie robię źle i to jest bug GMa, to ktoś mógłby mi podpowiedzieć, jak właściwie mam tego buga zgłosić, żeby w YYG mi zauważyli? Bo przycisk rejestracji na bugs.yoyogames.com przekierowuje do strony na której można napisać raport, a wysłanie raportu z kolei prowadzi do rejestracji na help.yoyogames.com, na które nawet nie wiem czy ktoś zagląda, a na pewno nie wygląda to na stronę poświęconą tylko i wyłącznie błędom. >.<

OK, zadziałało mi to to, i mam już nawet programik białym prostokącikiem latającym po planszy. Jej! Nie do końca wiem, co mam rozumieć przez "średnie" działanie funkcji SetFramerateLimit, u mnie wydaje się działać prawidłowo, przynajmniej na razie. Niemniej jeśli coś dziwnego będzie mi się działo, pewnie zajrzę do tamtego arykułu; dzięki za informację. ^^" Jeśli chodzi o Unity, jakoś niespecjalnie mnie to zachęca; może dlatego, że wydaje się jednak być zrobione z myślą o super efektyowynch grach, być może wykorzystujących również 3D itd. i jeszcze by mnie zalało różnymi opcjami z których ja akurat nie chcę korzystać; poza tym ma znacznie dłuższą licencję użytkowania. O.o"

Dobra, próbowałam coś kombinować z SFMLem, ściągnęłam pliki do .NETa (stąd, wersja 32bit), dodałam pliki z folderu "lib" do References do przykładowego programu, ale nie chce mi dodać bibliotek z "extlibs", które też są chyba wymagane. Błąd przy dodawaniu tych plików: "A reference to [...]\csfml-window-2.dll could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component." Wiesz może, czemu to to nie chce mi działać? O.o"

Witam tutejszych programistów! W ciągu ostatnich paru miesięcy całkiem przyjemnie programowało mi się w C# i chętnie skorzystałabym z jego możliwości przy tworzeniu gier, które dotychczas robiłabym w GMie. Jednak jest parę kluczowych elementów, które GM całkiem ułatwia, a których póki co jeszcze nie odkryłam. W szczególności ułatwienia, które chętnie bym widziała, to: - przechowywanie obrazków w wygodnym miejscu, i to najlepiej tak, żeby te obrazki były wewnątrz programu - możliwość w miarę wydajnego rysowania tych obrazków na ekranie lub jeden na drugim (trochę jak surfaces; prawdopodobnie jest do tego klasa z bitmapami czy coś O.o), uwzględniające lub nie kanały alpha - obsługa i przechowywanie dźwięków (najlepiej modułków, choć *.oggi też powinny działać całkiem nieźle; i może *.wavy dla pojedynczych dźwięków ^^") - obsługa i przechowywanie czcionek? ← niezbyt pilne - prawdopodobnie powyższe "przechowywanie" może zostać zrealizowane przez przechowywanie plików w ogóle - bardzo mile widziana obsługa klatkowości (tj. kod powtarzający się cyklicznie np. 60 razy na sekundę, przeplatany cyklami rysowania) - a tym bardziej z łatwym do odebrania stanem klawisza klawiatury, stanem przycisku myszy i pozycją myszy Myślę, że takie coś by było już w miarę wystarczające, abym na bazie tego mogła skonstruować to co bym chciała. Ktoś zna narzędzie/bibliotekę/zestaw powyższych które by spełniało te funkcje, i opisałby pokrótce/podlinkowałby *przyjazny* poradnik jakbym miała się tym posługiwać? ^_^

Czyli tak, raczej powinno działać na darmowym GM:S. O ile dobrze pamiętam, jedyne wystąpienia funkcji grida to Create, User Event 1 i Draw (przy czym user event jest stosowane tylko przy zmianie rozmiaru siatki). Zresztą, jak pominiesz którąś funkcję niedarmową, to pewnie od razu GM:S zacznie ci jojczyć przy uruchomieniu. ;) Przy okazji, tam są stosowane zmienne "width" i "height"; teoretycznie powinny odpowiadać rozmiarom grida, ale w tym przypadku chyba najlepiej w ogóle zamienić tworzenie grida i wywołanie User Event 1 na: GML width = /*szerokość*/; height = /*wysokość*/; for (i=0; i<width; i++) { for (j=0; j<height; j++) { source[i, j] = 0; //albo coś } } Mam nadzieję, że przejście od grida na tablicę dwuwymiarową nie sprawi zbyt wielu problemów? ^^'

"DAŁAŚ" :angry2: (tak, dziewczyną jestem) Co do exeka, to też mogę wrzucić, skoro tak bardzo chcecie. ^^' [LINK]

Tytuł: Heksagonalna plansza Krótki opis: Reprezentacja gridem (tablicą dwuwymiarową), rysowanie i znajdowanie pozycji myszki dla planszy heksagonalnej. Wersja: GM:S, zalecany co najmniej Standard* Pliki: Projekt (*.rar zawierający *.gmz, do otwarcia przez "Import Project"; ok. 2,8 MB) Exek (ok. 1,8 MB, na górze po prawej jest FPS i współrzędne obecnego pola, strzałkami ogląda się planszę, pole nad którym jest myszka podświetla się; nie jest to to specjalnie fascynujące) Screen: [LINK] Przykład zawiera następujące elementy: - reprezentacja gridem (tablicą dwuwymiarową): w tym przykładzie oś X przebiega w prawo i w dół (pod kątem 30 stopni), a oś Y w lewo i w dół, co można zauważyć po numerkach współrzędnych; uznałam, że taka konwencja sprawdza się najlepiej (czyt. akurat tak mi się podobało) - rysowanie planszy: tj. rysowanie klatek pewnego sprite'a po wielokroć, która klatka to zależy od wartości pola w planszy; po narysowaniu wszystkich właściwych pól jeszcze jest rysowanie na tym konturów; rysowanie napisano w ten sposób, że wyświetlane są tylko elementy konieczne; nawet dla planszy zawierającej 10000x10000 elementów szybkość rysowania zasadniczo się nie zmienia - przewijanie planszy: można sprawdzić korzystając ze strzałek; nie musisz mieć gigantycznego rooma, żeby wyświetlić wszystko, czego chcesz! (technicznie rzecz biorąc room i tak jest z założenia w miarę nieskończony, ale można to załatwić i w ten sposóB) - znajdowanie pozycji myszki: obiekt rysujący planszę rozpoznaje współrzędne pola, nad którym obecnie jest myszka korzystając z matematyki takiej i owej; aktualna pozycja myszki jest przechowywana w zmiennych fx i fy (nazwanych bodajże po "focus x" i "focus y") i to do nich należy się odwoływać po wykonaniu zdarzenia Step odpowiedniego obiektu Póki co zrobiłam wyżej wymienione elementy mechaniki. Jeśli ktoś jest bardzo zainteresowany bardziej szczegółowym tutorialem ilustrującym jak to działa (i pewnie też tłumaczącym do czego służą poszczególne zmienne w przykładzie :P ) lub nowymi funkcjami, to proszę pisać; nie mam specjalnie ochoty robić nie wiadomo jakich fajerwerków jeśli okaże się, że i tak nie ma na nie zapotrzebowania. ;) *sam przykład korzysta ze struktury "grid" dostępnej tylko w płatnej wersji, natomiast można to podmienić na tablicę dwuwymiarą jak ktoś naprawdę bardzo chce

Dobra, czyli jeśli Chell się nie odezwie w ciągu godziny, to czy możemy przeprowadzić ten pojedynek od jutra (soboty 16 lutego) godz. 6:00 (albo jak najszybsza po tej) do niedzieli 24 lutego godz. 6:00 rano (w sumie 8 dni, temat podobno tygodniowy, ale lepiej, żeby pojedynek skończył się w środku weekendu ^^'). Co na to Huder?

Nie chcę być niecierpliwa, ale... ...co dalej? ^^'

Inna sprawa mnie zastanawia. Jak Chell swoją grę wysyła na PW, to jak ona ma zostać poddana ocenie użytkowników? O.o'

Elevator: a co jeśli ja poddaję się bardziej? Bo w sumie nie zrobiłam specjalnie nic z tamtej gry (chyba te projekty kompletnie zabrały mi siły do robienia czegokolwiek na zadany temat), a w sumie ty oddałeś więcej niż ja. >.< Więc jak? Chcesz grać dalej, czy może jednak uważasz, że to ja mam walczyć z kimkolwiek kto wygra pojedynek Chell vs Huder? ^^'

*korzysta z NOOOO~ buttona w rozszerzeniu Opery* No, ale przynajmniej teraz chyba będę mogła się wziąć wreszcie za ten projekt, bo wcześniej to semestr mi się kończył. >.<

Wnioskuję o przedłużenie terminu na podstawie tego, że coś tam próbuję robić tylko czasu specjalnie nie miałam, a Threef chyba powiedział, że jak będzie coś wyglądało obiecująco, to może przedłużyć z tych 48h. Ogólnie to gra ma być Tower Defensem/Attackiem, w którym do naszego komputera przychodzą wrogie pakiety, i trzeba się przed nimi bronić (wieżyczka po prawej), a w ostatecznym rozrachunku pokonać przeciwnika (szereg shurikenów na dole), produkując swoje pakiety w fabryczce koło naszego węzła. Ogólnie tydzień będę mieć dość narwany (ostatni projekt w semestrze oddaję dopiero w piątek, a nie sądzę, żebym napisała to przed czasem), więc i tak chyba Elevator będzie miał nieco fory. >.< Naprawdę nie miałabym nic przeciwko przedłużeniu nawet o tydzień, zwłaszcza, że historia zna takie przypadki (vide koty), a póki co jeszcze nawet Huder i Chell nic nie zaczęli. Elevator też swojego projektu specjalnie nie skończył, a zaczął, więc mam nadzieję, że nie będzie miał nic przeciwko. ^^' Screen (wyedytowałam, bo w poprzednim screenie nie było wieżyczki) A gra ma się nazywać #Shuriken++. ---EDIT--- Widzę, że Elevator się zgodził na jakiekolwiek przedłużenie! ^^ To jak, tydzień? ;)