Heja!

[zielok__]

Nitro ja w sumie tez bym zobaczyl

Ja prototypy robie w processingu (http://processing.org/) ale korzystam z tego glownie przy czysto matematycznych efektach i nie w samej wizualizacji efektu. Poprostu sprawdzam obliczenia wykonane w ASM czy zgadzaja sie z wynikami wykonanymi w jezykach wysokiego poziomu. Wizualizacje robilem tylko przy bumpmappingu i plasmie.

[Nitro__]

Prosze bardzo
                   

Cytat:

#include \"stdafx.h\" using namespace::std: map keypressed: bool keyPressed(int key) {   if(keypressed.find(key) == keypressed.end()) keypressed[key] = false:   if(inkeys[key])   {     if(keypressed[key] == false)     {       keypressed[key] = true:       return true:     }   }   else keypressed[key] = false:     return false: } unsigned short *inversion_lut = new unsigned short [57600]: #define FALSE 0 void buildinversionlut(unsigned short *lut, int k, int xc, int yc, int width, int height): #define TICK_INTERVAL    30 static Uint32 next_time: Uint32 time_left(void) {     Uint32 now = SDL_GetTicks():     if(next_time <= now)         return 0:     else         return next_time - now: } Uint32 texture[32][32]: Uint32 buffer[320][200]: int main(int, char *[]) {    screen(320,200,0,\"Distorter Playground\"):    cout.flags(ios::hex):    //Build inversion look-up table    buildinversionlut(inversion_lut, 350, 22, 24, 64, 48 ):    loadBMP(\"texture.bmp\",texture[0],32,32):    float shift = 0:    next_time = SDL_GetTicks() + TICK_INTERVAL:    while(!done())    {       for(int x = 0: x < 64: x++)       for(int y = 0: y < 48: y++)       {          int tex_x = inversion_lut[(y*64+x)] & 0xff:          int tex_y = inversion_lut[(y*64+x)] >> 8:          tex_x %= 32:          tex_y %= 32:          buffer[x*4][y*4] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+1][y*4] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+2][y*4] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+3][y*4] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4][y*4+1] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+1][y*4+1] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+2][y*4+1] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+3][y*4+1] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4][y*4+2] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+1][y*4+2] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+2][y*4+2] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+3][y*4+2] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4][y*4+3] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+1][y*4+3] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+2][y*4+3] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:          buffer[x*4+3][y*4+3] = texture[(int)(tex_x+shift)%32][(int)(tex_y+shift)%32]:       }       drawBuffer(buffer[0]):       redraw():       SDL_Delay(time_left()):         next_time += TICK_INTERVAL:       shift+=0.5:       const int texOne = 0x2400:       if(keyPressed(SDLK_g))       {          char speedCodeCache[0x10000]: //Itp, itd       }    }    return 0: }

Te dlugie write\'y do bufora aby stawiac piksele 4x4 to partyzantka, aktualnie mam dwa bufory i funkcje kopiujaca z jednego na drugi w podanej skali. Jak widac nie jest to zadna rakietowa filozofia, prosty do bolu, brudny kod, kazdy moze sie tego nauczyc w dzien.
Jakby ktos nie rozumial(sorry za posadzenia o niewiedze ) to tabelka LUT ma upakowane dwie 8\'mio bitowe wartosci w jedna 16\'tke, potem przy renderingu sobie je wyluskuje AND\'em(& 0xff) i przesunieciem(>> 8 ).

Korzystam z biblioteki do SDL\'a o nazwie QuickCG, w niej jest wszystko co potrzebne do mazania po ekranie - linie, punkty, bufory, wypisywanie tekstu oraz zmiennych itd.

                   

Cytat:

w processingu

Heh, napisalem wektory w tym i to byl moj pierwszy prototyp efektu. Potem zaczalem przygode z grafika w C++ i nie czuje potrzeby wracac. Znasz C/C++ wiec wydaje mi sie troche dziwne uzywanie processingu, ale kazdy ma swoje gusta Mi sie wspanialy debugger Visual Studio przydal mocno przy jednym parcie, processing chyba pod tym wzgledem kuleje, dobrze pamietam?
A dlaczego wizualizacji nie kodujesz? Przeciez przy kazdym bitmapowym efekcie to formalnosc. Oczywiscie zgadzam sie, ze nie ma sensu odtwarzac EOR-fillera czy tam jakichs trikow sprzetowych w symulacji. Chociaz w tym pierwszym przypadku po prostu mozemy beztrosko maznac linie, potem flood fill czy inny nieoptymalny wynalazek i voila

[c---n]

pozwole sobie zabrac glos w tym temacie
jakis czas temu bawilem sie SDLem (tym co nitro) zeby sprawdzic czy kumam podstawowe efekty z dem. musze powiedziec ze do prototypownia faktycznie sie to swietnie nadaje. api ma latwe, dziala na kazdym systemie, a ze nadaje sie do wiecej niz tylko do testowania dodam, ze narzedzie graficzne grafx2 jest w tym napisane.

[zielok__]

                   

Nitro napisal:

Heh, napisalem wektory w tym i to byl moj pierwszy prototyp efektu. Potem zaczalem przygode z grafika w C++ i nie czuje potrzeby wracac. Znasz C/C++ wiec wydaje mi sie troche dziwne uzywanie processingu, ale kazdy ma swoje gusta Mi sie wspanialy debugger Visual Studio przydal mocno przy jednym parcie, processing chyba pod tym wzgledem kuleje, dobrze pamietam?

Processing uzywam dlatego, ze po prostu wszystko stworze szybciej i latwiej niz w C++. Debugger przy tak prostych rzeczach (od strony PC) nie jest mi zbyt potrzebny a wazna jest dla mnie szybkosc pisania kodu i tu processing IMO wygrywa. Aktualnie zreszta do tworzenia czysto PC\'owych rzeczy uzywam LUA a do wspomagania komodorka uzywam Processingu. Jeszcze dwa lata temu bylem wielkim fanem C++ ale mi przeszlo (tzn. czasem uzyje)
Co do samego SDL to oczywiscie tez z niego korzystalem (zreszta nawet na kilka platform: win, linux, win mobile, gp2x, psp) ale jednak bardziej do specyfiki c64 mi podpasowal Processing.

                   

Nitro napisal:

A dlaczego wizualizacji nie kodujesz? Przeciez przy kazdym bitmapowym efekcie to formalnosc. Oczywiscie zgadzam sie, ze nie ma sensu odtwarzac EOR-fillera czy tam jakichs trikow sprzetowych w symulacji. Chociaz w tym pierwszym przypadku po prostu mozemy beztrosko maznac linie, potem flood fill czy inny nieoptymalny wynalazek i voila

O wlasnie eor filera napisalem w C++ Serio... tzn nie dzialal w 100% jak na c64 (czyli nie pracowalem na 8 hiresowych punktach naraz a na pojedynczych) ale zasada byla mniej wiecej ta sama. Wizualizacji nie robie glownie dlatego, ze wlasnie musialbym bym robic jakies zamienniki w stylu floodfill i nie maja one zbyt duzo wspolnego z c64 a jak efekt wyjdzie to juz mam w glowie:) Owszem czasem pozwolilo by to zastosowac jakies inne parametry lub zaoszczedzic czas i stwierdzic, ze efekt jest do dupy ze wzgledu na zalozenia (czego ostatnio doswiadczylem) ale jakos tak mi wygodniej.

Ogolnie uwazam, ze wszystko nalezy stosowac zgodnie z zapotrzebowaniem i uzyskaniem maksymalnej wydajnosci pracy i do tego dobierac odpowiednie narzedzia a nie robic cos aby to tylko zrobic.

ps. do nowego dema na kilka efektow tylko jeden mam prototypowany (nawet z wizualizacja). Jednak efekt stworzylem kilka lat temu i tylko dostosowalem go do specyfiki c64. Kolejne trzy nie beda na pewno prototypowane bo korzystaja ze specyfiki sprzetowej c64 a co bedzie dalej to nie wiem:)

[Nitro__]

                   

Cytat:

pozwole sobie zabrac glos w tym temacie   jakis czas temu bawilem sie SDLem (tym co nitro) zeby sprawdzic czy kumam podstawowe efekty z dem. musze powiedziec ze do prototypownia faktycznie sie to swietnie nadaje. api ma latwe, dziala na kazdym systemie, a ze nadaje sie do wiecej niz tylko do testowania dodam, ze narzedzie graficzne grafx2 jest w tym napisane.

Brawo, 120% normy Teraz tylko dzien na nauke ASM\'a 6502, drugi na nauke rejestrow sprzetowych C64 i witamy w klubie koderow.

                   

Cytat:

rocessing uzywam dlatego, ze po prostu wszystko stworze szybciej i latwiej niz w C++. Debugger przy tak prostych rzeczach (od strony PC) nie jest mi zbyt potrzebny a wazna jest dla mnie szybkosc pisania kodu i tu processing IMO wygrywa.

Spoko, ja majac w pamieci doswiadczenia z wektorami w processing mysle, ze C++ plus SDL plus QuickCG jest mniej wiecej rownie wygodne.
                   

Cytat:

LUA

Skryptowy jezyk, a fuj

                   

Cytat:

Ogolnie uwazam, ze wszystko nalezy stosowac zgodnie z zapotrzebowaniem i uzyskaniem maksymalnej wydajnosci pracy i do tego dobierac odpowiednie narzedzia a nie robic cos aby to tylko zrobic.

W 100% sie zgadzam i stosuje te filozofie.

[zielok__]

                   

Nitro napisal:

Spoko, ja majac w pamieci doswiadczenia z wektorami w processing mysle, ze C++ plus SDL plus QuickCG jest mniej wiecej rownie wygodne.

Jak komu wygodniej:)

                   

Nitro napisal:

Skryptowy jezyk, a fuj

Tez tak kiedys uwazalem ale to naprawde swietne rozwiazanie. Latwosc, szybkosc i przyjemnosc pisania kodu rekompensuje mi zmniejszona wydajnosc ktora i tak jest dla mnie w zupelnosci wystarczajaca.

[c---n]

                   

Nitro napisal:

Brawo, 120% normy Teraz tylko dzien na nauke ASM\'a 6502, drugi na nauke rejestrow sprzetowych C64 i witamy w klubie koderow.

Nitro zapewne nie jestes swiadom ze wujek karjon wie jak sie koduje w ASMie. nawet zaczal pare rzeczy kodowac na swoje potrzeby i moze kiedys to to ujrzy swiatlo dzienne... Kiedys opowiem ci jakie rzeczy pisalo sie drzewiej... (np na studiach informatycznych jak sie zna 6502 to mikrokontroler 8051 to pan pikus).

a w temacie...
to jeszcze przydaje sie nakladka na sdl napisana w Pythonie PyGame (czy jakos tak) api jest smiesznie latwe (jeszcze latwiejsze od golego SDLa) no i python to  jezyk skryptowy... tez latwo sie prototypuje.

[digger]

                   

carrion napisal:

Nitro zapewne nie jestes swiadom ze wujek karjon wie jak sie koduje w ASMie. nawet zaczal pare rzeczy kodowac na swoje potrzeby i moze kiedys to to ujrzy swiatlo dzienne...

Hehe, ano, wujek Kerjon kiedys nawet puszczal mi swojego player\'a do zakow, okolo \'94.

[Nitro__]

                   

Cytat:

Nitro zapewne nie jestes swiadom ze wujek karjon wie jak sie koduje w ASMie. nawet zaczal pare rzeczy kodowac na swoje potrzeby i moze kiedys to to ujrzy swiatlo dzienne... Kiedys opowiem ci jakie rzeczy pisalo sie drzewiej... (np na studiach informatycznych jak sie zna 6502 to mikrokontroler 8051 to pan

Najs, nie wiedzialem, ze mamy tak wielu wszechstronnych ludzi na scenie, ja niestety nie jestem nawet minimalnie uzdolniony w temacie grafiki/muzyki
                   

Cytat:

jezyk skryptowy...

A fuj po raz drugi

[xpo__]

czesc Digger i wszystkim na forum. fajnie znowu zobaczyc wasze nicky, chociaz sie nie znamy (poza Diggerem i Sebalosem). widze, ze komoda oparla sie czasowi i calkiem dobrze sie ma

Digger, robimy jakies demo pod Atlantic?

[Sebaloz]

                   

xpo napisal:

Digger, robimy jakies demo pod Atlantic?

Z tego co pamietam to nie byles w Atlantic? Ty jestes we Fresh a Digger w Agony. Ale demo robcie, jesienia bedzie Silesia Party.

[Kisiel]

Seba malo wiesz a duzy rosniesz.

[digger]

                   

xpo napisal:

Digger, robimy jakies demo pod Atlantic?

Hehe Goner! Milo cie widziec tutaj stary! Komoda sie ma dobrze a nawet lepiej (mam juz chyba z 5). Demo jak najbardziej, chociaz czy pod Atlantic to nie wiem... Dziabnij mi maila na tomek blog2t.net to obgadamy temat.

[xpo__]

czolem Digger
ja tez sie ciesze, ze scena wciaz istnieje, ze ludzie wciaz sa i cos na niej mieszaja, a z tego co widze ciagle rozwijaja swoje talenty. szacun dla Was.
zreszta, ogladalem niedawno remake Desert Dream/Kefrens na c64 i powiem ze rewelacja. efekty,muza,gfx,synchro (to mnie rozwalilo bo ladowanie efektow jest myk-myk, wszysstko sie zgrywa w czasie tak jak powinno), poprostu miodzio. kiedys nie myslalem, ze da sie tak zrobic na naszej maszynce. no coz, ciesze sie ze sie mylilem. nie ma rzeczy niemozliwych i dobrze. teraz mysle ze jedynym ograniczniem bedzie juz tylko i wylacznie wyobraznia tworcow. komoda forever i tyle.
 
ps. reszte napisalem w mailu tak jak chciales.
pozdro dla Ciebie i wszystkich na formu
xpo