Odczyt poziomów z pliku

[Pental Stary]

Odczyt poziomów z pliku mówi samo za siebie, w tym jednak przykładzie zamiast odczytywać poziom z pliku tekstowego, poziom odczytujemy z grafiki, np. bitmapy, gifa itp. Jakie to ma zalety? Hmm... jedyne co to daje, to zmniejsza rozmiar exe'ka i gra szybciej się ładuje, większego sensu raczej to nie ma, no ale kit z tym :P .

 

Jak wygląda taka grafika? Ano, załóżmy, że tak :) :

Została powiększona ośmiokrotnie jakby co. Do odczytu takiego poziomu, wystarczy prosty skrypt load_map:

/* 
   load_map( sciezka, lista1, lista2 )
   sciezka - sciezka do pliku mapy, np. 'mapa.gif'
   lista1 - lista z kolorami
   lista2 - lista z obiektami
   funkcja nie dziala poprawnie w evencie Draw! 
*/

_dir = argument[0];
_col = argument[1];
_obj = argument[2];

var  __temp, __s;

__s = sprite_add( _dir, 0, 0, 0, 0, 0, 0, 0 );   
__w = sprite_get_width( __s );
__h = sprite_get_height( __s );

__temp = surface_create( __w, __h );

surface_set_target( __temp );
draw_sprite( __s, 0, 0, 0 );
surface_reset_target();

for( _i = 0; _i < __w; _i += 1; )
    for( _j = 0; _j < __h; _j += 1; )
    {
        __c = surface_getpixel( __temp, _i, _j );
        __x = _i * ( room_width / __w );
        __y = _j * ( room_height / __h );
        
        for( i = 0; i < ds_list_size( _col ); i += 1; )
        {
            if ( ds_list_find_value( _col, i ) == __c )
            {
                instance_create( __x, __y, ds_list_find_value( _obj, i ) );
                break;
            }
        }
    }
    
surface_free( __temp );

Nie będę objaśniał tego kodu, bo sensu by to nie miało. Jak odczytać planszę? Wystarczy stworzyć dwie listy - jedna z kolorami, druga z obiektami. Wyglądać to może tak:

global._list_col = ds_list_create();
global._list_obj = ds_list_create();

Dodawanie jednak na przemian wartości do pierwszej i drugiej listy byłoby może nieco niewygodne, dlatego też można napisać sobie prostą funkcję ułatwiającą życie o nazwie add_color:

ds_list_add( global._list_col, argument[0] ); 
ds_list_add( global._list_obj, argument[1] );

Funkcje już mamy, teraz do dzieła. Pamiętaj, że:

-kolor zielony (make_color_rgb( 0, 255, 0 )) to obiekt Point

-kolor czerwony (c_red) to obiekt Hero

-zaś kolor czarny (c_black, ew. 0) to obiekt Block

Teraz przygotowujemy obydwie listy do użycia:

load_map( 'mapa.gif', global._list_col, global._list_obj );

Gotowe :) . Jeszcze jedna uwaga: ponieważ grafika ma wymiary 10 x 10, to by uzyskać odpowiedni efekt należy zapamiętać tę o to zasadę:

szerokosc rooma = szerokosc grafiki * szerokosc innych sprite'ow
wysokosc rooma = wysokosc grafiki * wysokosc innych sprite'ow

Czyli w tym wypadku rozmiar rooma, zakładają, że grafiki mają wymiary 32 x 32, to 320 x 320 :) .

 

Tyle ode mnie. Mogę także zarzucić przykładem z dwoma planszami:

https://gmclan.org/up4218_4_Mapy.html

 

Pozdrawiam,

Pental.

[gnysek]

Hmm, ciekawy sposób, ale do większych plansz absolutnie się to nie nadaje.

[Dawidds]

LOL...? Dopiero co napisałem tutaj posta '-.- Dziwne...

 

Ja chciałem napisać, że to ładownie w sumie nie ma zalet :P Jest mniej wydajne niż ładowanie z pliku tekstowego, a i pliki więcej ważą. Zaletą jest niekonieczność tworzenia edytora: w sumie każdemu wystarczy Paint i tylko wskazać mu, jaki kolor co oznacza.

 

Ale sposób ciekawy :)

[Pental Stary]

Właśnie, to co napisaliście to prawda. Do większości plansz się nie nadaje, chyba, że do gier pacmano-podobnych. Ew. po kilku zmianach miałoby to zastosowanie, w tworzeniu otoczenia :P . Swoją drogą - jest to także niewydajne, o tyle, że aby pobrać kolor danego piksela, grafika zostaje wyświetlona na tymczasowej powierzchni. Ale to już wina braku funkcji sprite_getpixel() :confused: .

[Konrad-GM]

GMLowe "surface_getpixel" jest do pupy, lepiej by było użyć jakiegoś DLLa z wczytywaniem obrazów, aby mieć pełny dostęp do obrazka :P

[Saus]

for( _i = 0; _i < __w; _i += 1; )
    for( _j = 0; _j < __h; _j += 1; )
    {
        __c = surface_getpixel( __temp, _i, _j );

Te linijki mnie przerazily, przy wiekszych planszach taki piksel po pikselu udusilby kompa :P

[I am Lord]

Jakoś nie widzi mi się tworzenie leveli w tensposób bo każdy ma dostęp do ich edycji. :boxed: Ktoś może sobie haxsnąć gierkę edycją w paintcie.

[Pental Stary]

Saus, ty chyba nie wiesz, co to jest dzisiejszy komputer xD . Zauważ, że tam jest jeszcze jedna pętla :) .

 

HuderLord, e tam, wiele gier mają w "nie-skompresowanych" plikach tekstowych bardzo ważne zasoby i co z tego :P ? Konrad, użycie dll'a wiele lepszym rozwiązaniem by nie było.

[Dawidds]

Byłoby, było. DLL by ci powiedział jaki jest dany pixel bezpośrednio z obrazka. A nie, że najpierw dodajesz sprite, surface, i dopiero z surface'a pobierasz kolor.

 

jedyne co to daje, to zmniejsza rozmiar exe'ka i gra szybciej się ładuje

I to jest, cholera, nieprawda. Plik tekstowy ważyłby dużo mniej, a i ładowałby się nieporównywalnie szybko. Dawałby tez większe możliwości, np. ustawianie "własnego" Creation Code obiektów. No i łatwiej by było zabezpieczyć taki plik tekstowy...

 

Jedyną zaletą tego rozwiązania jest to, że, jak już powiedziałem, user może sobie w łatwy sposób tworzyć własne levele. Jedynie informujesz go, jaki pixel oznacza jaki obiekt. I nie musisz nawet pisać edytora leveli. Każdemu Paint wystarczy...

[Pental Stary]

Aha, 5 - latek tak nie rozumuje :unsure: . Masz rację, gra ładuje się szybciej i exe'k mniej waży, jeśli zamiast jednego rooma, będzie dużo roomów... Człowieku zastanów się co piszesz! Jeśli ładujemy zasoby z zewnętrznych plików exe'k zawsze będzie mniejszy :o . A teraz napiszesz coś innego, proszę, nie rób ze mnie idioty, myśleć chyba umiem i wiem, że a - b, zakładając że b jest większe niż zero, zawsze będzie mniejsze od a :/ . A z dllem byłoby wolniej, gdyż samo odwołanie się do niego obciąża komputer.

[Saus]

Saus, ty chyba nie wiesz, co to jest dzisiejszy komputer xD . Zauważ, że tam jest jeszcze jedna pętla

Jeszcze trzecia trzeba bylo dac :P

Wiem co to dzisiejszy komputer, ale patrze na to oczami GMa, wez obrazek 1024x768 i uzyj tego na nim, ciekawe ile to GMowi zajmie (o ile w ogole).

[Pental Stary]

1024x768? Jeden piksel to nie jeden piksel rooma :D . Ten kod jest dla obiektów statycznych raczej :P ...

[Dawidds]

Aha, 5 - latek tak nie rozumuje unsure.gif . Masz rację, gra ładuje się szybciej i exe'k mniej waży, jeśli zamiast jednego rooma, będzie dużo roomów... Człowieku zastanów się co piszesz! Jeśli ładujemy zasoby z zewnętrznych plików exe'k zawsze będzie mniejszy ohmy.gif . A teraz napiszesz coś innego, proszę, nie rób ze mnie idioty, myśleć chyba umiem i wiem, że a - b, zakładając że b jest większe niż zero, zawsze będzie mniejsze od a :/ . A z dllem byłoby wolniej, gdyż samo odwołanie się do niego obciąża komputer.

Ja pierdziele.

 

Każdy wspomniany idiota wie, że plik lepszy niż room. Ale przeczytaj jeszcze raz mojego posta. Dokładnie. A jak nie odczujesz różnicy to przeczytaj jeszcze raz. Aż dojdziesz do wniosku, że porównywałem twoją metodę do ładowania z pliku tekstowego. Wtedy exec będzie ważył tyle samo, ale level będzie ładować się szybciej, a plik z levelem będzie ważył mniej.

Już rozumiesz, co co mi chodziło? To dobrze...

 

1024x768? Jeden piksel to nie jeden piksel rooma biggrin.gif . Ten kod jest dla obiektów statycznych raczej tongue2.gif ...

Weź sobie grę typu powiedzmy Almora i zobacz, jaka tam jest mapa ;) Akurat Almora to zły przykład :P

 

I podsumujmy to: wskaż mi niepodważalną zaletę tego rozwiązania ładowania map. Jedyną mini-zaletą jest fakt stworzenia prosteg edytora leveli, jak już wspominałem kilka razy.

[Pental Stary]

Ej, no :( .

 

Każdy wspomniany idiota wie, że plik lepszy niż room. Ale przeczytaj jeszcze raz mojego posta. Dokładnie. A jak nie odczujesz różnicy to przeczytaj jeszcze raz. Aż dojdziesz do wniosku, że porównywałem twoją metodę do ładowania z pliku tekstowego. Wtedy exec będzie ważył tyle samo, ale level będzie ładować się szybciej, a plik z levelem będzie ważył mniej.

Już rozumiesz, co co mi chodziło? To dobrze...

Sam przeczytaj, zwróciłeś się do cytatu: "to nie prawda", a jeśli nie, to co ma piernik do wiatraka?

 

A tobie polecam przeczytać pierwszego posta, jeśli to zrobiłeś to wywnioskuj coś z niego :P .

[Dawidds]

Ja cię pierniczę :P

Przeczytaj moje wszystkie posty to dojdziesz do wniosku, że to było porównanie room w pliku tekstowym vs room w obrazku :P

Zresztą jakby ie było, to właśnie miałem na myśli. Więc po co dalsza rozmowa na ten temat..?

 

A DLL mógłby zwrócić wartości kolorów pixeli wszystkich, w jednym stringu. GM by to rozdzielił i objekty potworzył.

Jestem niemal pewny, że to by było szybsze :D

[Konrad-GM]

@Pental: Chyba nie wiesz z czego składa się obrazek, to zwykła dwuwymiarowa tablica przechowująca każdy kolor pixela.

A więc:

double GetPixel( unisnged int _x, unisnged int _y )
{
    return static_cast<double>( Obrazek[ _x ][ _y ] );
}

czyżby nie byłoby szybsze?

[Matthew]

@Up: O wiele szybsze, ale co z pobieraniem koloru? Jak (poza get_pixel) pobrać kolor? Trzeba by było wiedzieć, jak nazywa się tablica...

[Pental Stary]

Konrad, łał, zaszpanowałeś swoją wiedzą, ale samo odnoszenie się do dll'a wcale nie jest szybsze. No i skąd wziąć id obrazka :] ? Trzeba by było napisać od razu całą funkcję do odczytu obrazka z zewnątrz i w programie używać gotowych tablic. A to, może, by już było dobrym rozwiązaniem.