c64scene.pl

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

comankh pisze:niektorzy to nawet dema ogladaja nie-na-emulatorach
witaj brachu

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

Pozdrowienia dla wszystkich!

zielok pisze: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 pisze: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

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

#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;
}

w processingu

Nitro pisze: 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?

Nitro pisze: 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

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.

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.

LUA

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ć.