Heja!

[Digger]

Nie wiem czy powroty na scenę są jeszcze w modzie w 2011, w każdym razie postanowiłem powrócić

Pozdrowienia dla wszystkich!

[Sebaloz/Lepsi.De]

Witamy! Powroty sa zawsze w modzie

[k.]

Hejka, jak znajdziesz czas to najbliższe party to forever C no i nasze SP5.
A tak przy okazji a to falstart w 2010 Color Fade Editor .....?

[comankh]

niektorzy to nawet dema ogladaja nie-na-emulatorach
witaj brachu

[Digger]

A tak przy okazji a to falstart w 2010 Color Fade Editor .....?

Hehe, będzie więcej falstartów w 2011, tak mniej więcej spóźnionych 15 lat. Ale potem już na czasie

niektorzy to nawet dema ogladaja nie-na-emulatorach
witaj brachu

Od niedawna znowu Ebay okazał się niezłym źrodłem zaopatrzenia.

[zielok]

Nie wiem czy powroty na scenę są jeszcze w modzie w 2011, w każdym razie postanowiłem powrócić

Pozdrowienia dla wszystkich!

Jakoś nie jestem zaskoczony bo spodziewałem się tego powrotu. Można było u Ciebie zauważyć pewien wzrost aktywności związanej z c64 czego naturalnym skutkiem jest powrót na scenę. Super!

[Digger]

Jakoś nie jestem zaskoczony bo spodziewałem się tego powrotu. Można było u Ciebie zauważyć pewien wzrost aktywności związanej z c64 czego naturalnym skutkiem jest powrót na scenę. Super!

Hehe, dobra intuicja Mirek. Ja był się tak nie cieszył – spodziewaj się maili z zalewem pytań i męczenia o wytłumaczenie twoich efektów z BSOD

[zielok]

Hehe, dobra intuicja Mirek. Ja był się tak nie cieszył – spodziewaj się maili z zalewem pytań i męczenia o wytłumaczenie twoich efektów z BSOD

Z miła chęcią wytłumaczę:)

[carrion]

digger!!!
zrobie ci .... grafike do dema jak bedziesz cos kodował.
wiedziałem że się w końcu przełamiesz

[Nitro]

Witamy z powrotem na pokładzie Mogę pomóc przy ustawieniu wygodnego środowiska developerskiego i wogóle nowej szkole kodowania

[k.]

nowa szkoła niszczy ducha, siedzenie przy piecu rozleniwia... nie moralna propozycja, Nitro wstydź się

[Digger]

@Carrion: A to mi się podoba, wielkie dzięki! Nowe demo bę∂zie w 100% World Firstem więc logo jak najbardziej w stylu nie widzianym jeszcze na komie.

@Nitro: Bardzo chętnie ale czy to znaczy, że Kick Ass+Makra+.inc już nie wystarcza? To teraz ACME czy CC65 czy jak?

[Nitro]

@Nitro: Bardzo chętnie ale czy to znaczy, że Kick Ass+Makra+.inc już nie wystarcza? To teraz ACME czy CC65 czy jak?

Wystarcza, i o to chodzi Profilaktycznie zaoferowałem pomoc, aby ewentualnie odradzić assemblery powyżej, starego TASS'a czy kodowanie w czymś natywnym pod VICE'm.
CC65 też jest potężnym assemblerem, ale nadaje się raczej do kodowania jakichś dużych wieloczęściowych programów czy narzędzi z powodu posiadania zaawansowanego linkera - modularny loader krill'a jest napisany w CC65.
Funkcjonalność KickAss'a jest głównie zorientowana na dema.
Polecam rzucić okiem na temat loadery IEC, trochę się tam o moim warsztacie naprodukowałem.

[Digger]

@Nitro: widziałem źrodła Krill'a do Artefacts – no szacun taki, że koniec. Dzięki za info o IEC – chętnie rzucę okiem.

Kodowanie na C64 odpada – wiadomo – z racji użyteczności/praktyczności przede wszystkim

[Digger]

@Nitro: chętnie zobaczę też jak robisz prototypy efektów w C++, ja (z racji profesji) używam AS3.

[zielok]

Nitro ja w sumie tez bym zobaczył

Ja prototypy robię w processingu (http://processing.org/) ale korzystam z tego głównie przy czysto matematycznych efektach i nie w samej wizualizacji efektu. Poprostu sprawdzam obliczenia wykonane w ASM czy zgadzają się z wynikami wykonanymi w językach wysokiego poziomu. Wizualizacje robiłem tylko przy bumpmappingu i plasmie.

[Nitro]

Proszę bardzo

#include "stdafx.h"
using namespace::std;

map<int, bool> 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 długie write'y do bufora aby stawiać piksele 4x4 to partyzantka, aktualnie mam dwa bufory i funkcje kopiującą z jednego na drugi w podanej skali. Jak widać nie jest to żadna rakietowa filozofia, prosty do bólu, brudny kod, każdy może się tego nauczyć w dzień.
Jakby ktoś nie rozumiał(sorry za posądzenia o niewiedze ) to tabelka LUT ma upakowane dwie 8'mio bitowe wartości w jedną 16'tke, potem przy renderingu sobie je wyłuskuje AND'em(& 0xff) i przesunięciem(>> 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.

w processingu

Heh, napisałem wektory w tym i to był mój pierwszy prototyp efektu. Potem zacząłem przygodę z grafiką w C++ i nie czuję potrzeby wracać. Znasz C/C++ więc wydaje mi się trochę dziwne używanie processingu, ale każdy ma swoje gusta Mi się wspaniały debugger Visual Studio przydał mocno przy jednym parcie, processing chyba pod tym względem kuleje, dobrze pamiętam?
A dlaczego wizualizacji nie kodujesz? Przecież przy każdym bitmapowym efekcie to formalność. Oczywiście zgadzam się, że nie ma sensu odtwarzać EOR-fillera czy tam jakichś trików sprzętowych w symulacji. Chociaż w tym pierwszym przypadku po prostu możemy beztrosko maznąć linie, potem flood fill czy inny nieoptymalny wynalazek i voila

[carrion]

pozwolę sobie zabrać głoś w tym temacie
jakiś czas temu bawiłem się SDLem (tym co nitro) żeby sprawdzić czy kumam podstawowe efekty z dem. musze powiedzieć że do prototypownia faktycznie się to świetnie nadaje. api ma łatwe, działa na każdym systemie, a że nadaję się do więcej niż tylko do testowania dodam, że narzędzie graficzne grafx2 jest w tym napisane.

[zielok]

Heh, napisałem wektory w tym i to był mój pierwszy prototyp efektu. Potem zacząłem przygodę z grafiką w C++ i nie czuję potrzeby wracać. Znasz C/C++ więc wydaje mi się trochę dziwne używanie processingu, ale każdy ma swoje gusta Mi się wspaniały debugger Visual Studio przydał mocno przy jednym parcie, processing chyba pod tym względem kuleje, dobrze pamiętam?

Processing używam dlatego, że po prostu wszystko stworzę szybciej i łatwiej niż w C++. Debugger przy tak prostych rzeczach (od strony PC) nie jest mi zbyt potrzebny a ważna jest dla mnie szybkość pisania kodu i tu processing IMO wygrywa. Aktualnie zresztą do tworzenia czysto PC'owych rzeczy używam LUA a do wspomagania komodorka używam Processingu. Jeszcze dwa lata temu byłem wielkim fanem C++ ale mi przeszło (tzn. czasem użyje)
Co do samego SDL to oczywiście tez z niego korzystałem (zresztą nawet na kilka platform: win, linux, win mobile, gp2x, psp) ale jednak bardziej do specyfiki c64 mi podpasował Processing.

A dlaczego wizualizacji nie kodujesz? Przecież przy każdym bitmapowym efekcie to formalność. Oczywiście zgadzam się, że nie ma sensu odtwarzać EOR-fillera czy tam jakichś trików sprzętowych w symulacji. Chociaż w tym pierwszym przypadku po prostu możemy beztrosko maznąć linie, potem flood fill czy inny nieoptymalny wynalazek i voila

O właśnie eor filera napisałem w C++:) Serio... tzn nie działał w 100% jak na c64 (czyli nie pracowałem na 8 hiresowych punktach naraz a na pojedynczych) ale zasada była mniej więcej ta sama. Wizualizacji nie robię głównie dlatego, że właśnie musiałbym bym robić jakieś zamienniki w stylu floodfill i nie mają one zbyt dużo wspólnego z c64 a jak efekt wyjdzie to już mam w głowie:) Owszem czasem pozwoliło by to zastosować jakieś inne parametry lub zaoszczędzić czas i stwierdzić, że efekt jest do dupy ze względu na założenia (czego ostatnio doświadczyłem) ale jakoś tak mi wygodniej.

Ogólnie uważam, że wszystko należy stosować zgodnie z zapotrzebowaniem i uzyskaniem maksymalnej wydajności pracy i do tego dobierać odpowiednie narzędzia a nie robić cos aby to tylko zrobić.

ps. do nowego dema na kilka efektów tylko jeden mam prototypowany (nawet z wizualizacja). Jednak efekt stworzyłem kilka lat temu i tylko dostosowałem go do specyfiki c64. Kolejne trzy nie będą na pewno prototypowane bo korzystają ze specyfiki sprzętowej c64 a co będzie dalej to nie wiem:)

[Nitro]

pozwolę sobie zabrać głoś w tym temacie
jakiś czas temu bawiłem się SDLem (tym co nitro) żeby sprawdzić czy kumam podstawowe efekty z dem. musze powiedzieć że do prototypownia faktycznie się to świetnie nadaje. api ma łatwe, działa na każdym systemie, a że nadaję się do więcej niż tylko do testowania dodam, że narzędzie graficzne grafx2 jest w tym napisane.

Brawo, 120% normy Teraz tylko dzień na naukę ASM'a 6502, drugi na naukę rejestrów sprzętowych C64 i witamy w klubie koderów.

rocessing używam dlatego, że po prostu wszystko stworzę szybciej i łatwiej niż w C++. Debugger przy tak prostych rzeczach (od strony PC) nie jest mi zbyt potrzebny a ważna jest dla mnie szybkość pisania kodu i tu processing IMO wygrywa.

Spoko, ja mając w pamięci doświadczenia z wektorami w processing myślę, że C++ plus SDL plus QuickCG jest mniej więcej równie wygodne.

LUA

Skryptowy język, a fuj

Ogólnie uważam, że wszystko należy stosować zgodnie z zapotrzebowaniem i uzyskaniem maksymalnej wydajności pracy i do tego dobierać odpowiednie narzędzia a nie robić cos aby to tylko zrobić.

W 100% się zgadzam i stosuję tę filozofię.