PsichiX

sadze ze allegro nie ma takiej funkcji co by raz tablice sprajtow narysowala, wiec mozesz potraktowac particle jako sprajty i wsadzic je w dowolny kontener chociazby liste, i przelatujac ja rysowac kolejno kazdy sprajt. przykladowa struktura: struct PARTICLE_DESC { BITMAP* sprite; // nie znam allegrowskiego sprajta wiec tutaj dasz co trzeba;p int x; int y; int speed; }; // lista particli list<PARTICLE_DESC> particles; // dodanie particla PARTICLE_DESC part; part.sprite=jakis_sobie_sprajt_particla; part.x=rand()%800; // losowa pozycja X part.y=0; part.speed=rand()%10+1; // losowa predkosc particles.push_back(part); // wrzucamy particla do listy // aktualizacja particli for(list<PARTICLE_DESC>::iterator iter=particles.begin();iter!=particles.end();iter++) { iter->y+speed; if(iter->y>600) { iter->x=rand()%800; // losowa pozycja X iter->y=0; iter->speed=rand()%10+1; // losowa predkosc } draw_sprite(sprite,x,y); // tez nie znam funkcji rysujacej sprajta wiec zastapisz to } // a tak skasujesz dowolny element listy list<PARTICLE_DESC>::iterator iter=iterator_listy_particles; // iter=particles.begin() particles.erase(iter); coś takiego ;P

wszystko zależy od tego jakiej biblioteki / silnika renderującego używasz. jeśli masz stałą maksymalną liczbę particli tego samego typu (ta sama tekstura) to możesz wpakować całość do tablicy i renderować za jednym rozmachem, wtedy musisz mieć strukturę która będzie zawierała dane potrzebne bibliotece aby za jednym zamachem wyrenderowała całą tablicę.

uzywales chociazby debuggera w devcpp? brak wygody pracy w devcpp jest nastepstwem wlasnie braku dalszego rozwijania tego IDE

nie tyko dla wygody, a przede wszystkim dla tego ze dev nie jest juz wspierany od lat a brak rozwoju nie jest korzystna przy programowaniu.

co do przykladow kodu niestety musialbys poczekac na premiere PlayGate2 po nowym roku, bo wszystkie musze pod nowa wersje przepisac. 1. na pewno da to przynajmniej tych kilka kaltek wiecej, pracuje tez nad automatycznym odrzucaniem niewidocznej geometrii z kolejki do renderowania oraz swego rodzaju poziom detali. 2. jeszcze w tej chwili nie do konca, ale do premiery beda podmienione wszystkie funkcje graficzne (w tym te ktore wspomniales). Co do pixel shaderow to stara wersja uzywa shadery GPU ARB ktore sa nieco skomplikowane do pisania, w nowej wersji bedzie juz do uzytku jezyk shaderow GLSL (http://en.wikipedia.org/wiki/GLSL) ktory skladniowo przypomina c++ (i GML w pewnym stopniu) a dokumentacje postaram sie umiescic razem z SDK silnika i obszerny opis z przykladem jak je pisac oraz biblioteka kilku podstawowych efektow w tym wlasnie glow i blur ktore z tego co widze Wasza gra najprawdopodobniej uzywa (badz zamierzacie ich uzyc). dynamiczne to takie ktorych wyglad zmienia sie czesto (chociaz by co klatke) a niedynamiczne to takie ktore mozna narysowac raz i dalej sie jej nie modyfikuje. surfacesy w PG sa niczym innym jak dynamicznymi teksturami - teksturą której zawartość możemy zmieniać dowolnie, tak jak to działa przy surfacesach w GM - malować po nich, tak jak po scenie (roomie), dodatkowo używać ich jako tekstur dla sprajtów (czego w GM nie ma) przez co możesz mieć jakiś obiekt któremu będziesz mógł dorysowywać dziury bądź wszelakie inne obrażenia, dosłownie cokolwiek, bez konieczności uzywania sprite_create_from_surface(), ani rysowania surfacesa zamiast sprajta - wystarczy utworzyć surfacesa, pobrać jego teksturę, przypisać ją dowolnym sprajtom i one zawsze będą rysowały to co zawiera surfaces. plusem jest też że surfacesy w PG obsługują kanał alpha bez żadnych zbędnych zabaw z blendingiem - możesz więc spokojnie rysować na nim obiekty półprzezroczyste, bądź ustalać wartosc alpha danego pixela wedle swojego uznania, i dziala to zaskakujaco szybko :) co do ksztaltow: jesli uda mi sie szybko zrobic taki automat to bedzie on dzialal jak particle w PG ze automatycznie beda grupowane w kolejce renderowania wedle tekstury oraz wartosci depth takk by za jednym razem wyswietlac je pogrupowane i jeszcze szybciej, jesli zas nie zdaze to pokaze jak ta metode uzyskac przy nie duzych zmianach w kodzie (same funkcje i ich sklandia sie nie zmienia). Ale i tak postaram sie to zautomatyzowac by nie trzeba bylo sobie tym glowy zawracac. Jak cos to jestem otwarty na kazde dodatkowe pytanie - wiadomo ze na raz nie da sie wszystkiego opisac dokladnie a konkretne pytania ulatwiaja sprawe, jak teraz ;) PS. wybacz ze pol posta jest z ogonkami a reszta bez - pisanie na szybko daje takie rezultaty za co przepraszam jesli utrudnia to czytanie posta

no wlasnie nie jest to takie jak oczekiwales :P

GMowe bounce dziala na zasadzie kolizji masek. sprawdza ksztalt i na jego podstawie wylicza wektor normalny i wektor odbicia. a ze Ty masz obiekty jako kulki to latwo znajdziesz wektor normalny (jest on przedluzeniem promienia, przecinajacym sie z punktem gdzie nastapila kolizja na okregu kulki), wzor na wektor odbicia znajdziesz w sieci, nawet chyba pod pierwszym linkiem w googlach :) sprowadzę Cię na ziemię i powiem - nie ;p

Witam :) 1. z racji iż dostępne przykłady i demka są sprzed około dwóch miesięcy, a w tym czasie sporo się działo w pracach nad silnikiem, w tym wydajność skoczyła gwałtownie, to nie miałem czasu przygotować publicznych testów wydajności, jednak testowałem w trakcie tworzenia i z pewnością jest on szybszy od GMa, nie mniej zbieram się do przygotowania takich testów gdy już skończę podmieniać wszystkie funkcje graficzne. 2. ideą jest używanie silnika dokładnie tak samo jak normalne funkcje, co za tym idzie Twoim jedynym zadaniem było by umieścić obiekt silnika w roomie w którym chcesz go używać, a on zrobi juz za Ciebie wszystko automatycznie - uzywanie go jest nieodczuwalne od strony kodu. 3. domyślnie PG używa tablic wierzchołków dla sprajtów i innych elementów co juz przyspiesza renderowanie. na pewno efekty które wymagają odrysowywania kilka razy lepiej umieścić w pixel shaderze który nam dany efekt uzyska szybciej. Surfacesy proponuję podpiąć bezpośrednio pod jakiegoś sprajta i do niego rysować elementy niedynamiczne raz i uzywac do woli, lub zmieniajac jego zawartosc dowolnie dla dynamicznych tekstur sprajtow (porownam to do malowania sprayem po murze ;p). PG umozliwia tez uzywanie macierzy transformacji (osobne dla wierzcholkow i osobne dla tekstur) i je polecam uzywac zamiast lengthdirow. Wszelkie modele (ksztalty) najlepiej bedzie pakowac w bufor (model; odpowiednik GMowego d3d_model_*()) i rysowac od razu funkcja renderujaca tablice zamiast rysowac to prymitywami. na razie tyle przypominam sobie (troche sporo w silniku siedzi a ciagle zmiany nie pozwalaja wszystkiego pamietac ;p). 4. gm6 dla tego aby mozna bylo uzywac go w obu wersjach 6 i 7 (w niedalekiej przyszlosci tez 8) Jesli masz dalsze pytania jestem gotow udzielic Ci na nie odpowiedzi. Ewentualnie zapraszam na GG: 5745342. Pozdrawiam :)

https://forum.gmclan.org/index.php?showtopic=20657

+ SDL net do sieci (http://www.libsdl.org/projects/SDL_net/) Dobrego darmowego silnika mmo nie znajdziesz, to nie GM :P

w opcjach gry (Game Properties) znajduje sie pole "fullscreen" - je trzeba zaznaczyc

pierwszy gitez, brał bym go :)

daj m u jakąś bardziej rozbudowaną animację śmigania, fajke w usta, skóre na klate i będzie cacy :D

cieszy mnie ze tworzysz cos takiego, jednak mam pare uwag i pytan: 1. czyli na chwile obecna uzywa to tylko WinApi do rysowania? sprawdzilem i faktycznie uzywa. 2. w przykladowym kodzie widac juz bardzo zle podejscie co do zarzadzania zasobami 3. tak swoja droga, znasz dziedziczenie i umial bys przystosowac silnik aby mogl obsluzyc obiekty klasy dziedziczacej po Instance? (bez tego nie widac sensu dzialania (chodzi o rozszerzanie klasy Instance o dodatkowe zmienne i metody i traktowanie ich w podobny sposob jak klasy Instance na co pozwala dziedziczenie. ja na przyklad stosuje klase wirtualna aktora jako swego rodzaju baza/"szablon" z ktorego dziedziczac definiujemy dodatkowe elementy oraz podmieniamy metody na wlasne, daje to duza swobode dzialania. pomysl o tym)) zeby nie bylo - w tych kwestiach bywam demotywujacy, ale nie odbierz moich dociekliwych pytan w negatywny sposob :P btw. z ocena powstrzymam sie az bedzie widac wieksze efekty. Tak poza tym, czym kompilowałeś? Widze ze UPXem spakowane, teraz zastanawia mnei co takiego tam jest ze tak duzo zajmuje (~500kb)? :P jednak lepiej będzie jak sie przerzucisz na cos innego niz winapi do rysowania, bo tylko kolejne allegro wyjdzie, taka moja rada

Zadno z podanych, ja jak zawsze proponuje: Czokobons Studio

Gnysek nie placi bo ma razem z gmclanem ;p

sound_play(choose(hit1,hit2,hit3,hit4))

nie twórz tablicy dynamicznej jeśli musi być nieskończona - do tego są listy o których piszę. Tutaj masz opis list z biblioteki standardowej STL: http://pl.wikibooks.org/wiki/C%2B%2B/Listy ewentualnie wektor który jest swego rodzaju tablicą, będzie mógł być niby nieskończony, ale ma wadę że im więcej elementów tym bardziej muli, a tego przy dużej ilości obiektów nie chcesz.

pakuj obiekty do listy, skoro masz dynamiczne zarzadzanie obiektami. Dalej pozostanie przelecenie listy petla for/foreach (jesli dana lista obsluguje cos takiego) i po problemie

tak czy siak, przedluzylem waznosc serwera u hekko na pol roku, serwer nie mial nigdy powaznej dlugiej awarii, nawet sam zadnej nie zauwazylem, jest tani, wystarcza na moje potrzeby, wiec polecam :)

zrobili grę webową o uniwersum stargate, dodatkowo płatne 'bajery' i nikt twórce nie gania jak dotąd :P

2. GML (global mouse left press) tx=display_mouse_get_x()-window_get_x() ty=display_mouse_get_y()-window_get_y() GML (global mouse left) window_set_position(display_mouse_get_x()-tx,display_mouse_get_y()-ty) 3. Narysowanie do surfacesa i zapis surfacesa do pliku bmp jedynie, potem mozesz jakims konwerterem zamienic na inne formaty 4. jakiego DLLa, do czego?

myslalem ze sam ja napisales ;p mniejsza o to. ShowMessage(const Msg: string); to zobaczylem w dokumentacji. skoro to string to musisz przekonwertowac pchar na stringa i dopiero mu dac jako argument

zapodaj tresc funkcji ShowMessage()

nie zwracasz żadnej wartości, mimo iż masz to zdeklarowane w GMie. musisz zawsze coś zwracać, aby GM nie sypał błędami - jeśli nie zwracasz nic szczególnego, niech zwraca real rowny 1 lub 0, lub konkretna wartosc jesli cos musi zwrocic funkcja. i nie pomyl typow. bo widze ze masz zwracanie stringa zadeklarowane w GMie, wiec albo zamien to na ty_real i zwroc 1, albo zwracaj jakis pusty string w DLLce (pierwsza opcja lepsza) function Wiadomosc(tekst: pchar): real; stdcall; begin ShowMessage(tekst); result:=1; end; GML Message = external_define(global._DLL_Name, "Wiadomosc", dll_stdcall, ty_real, 1, ty_string);