Az élet kódjai

A munkahelyemen sajnos én vagyok az, aki észreveszi azokat a hibákat, amelyek felett mások átsiklanak. Ez azért rossz, mert unalmas tesztelési munkákat is kell végeznem. Így történt, hogy egy bioinformatikai program tesztelése során furcsa anomáliára figyeltem fel. A program több szálon futott, számtalan ideiglenes állományt írt és olvasott. Ezalatt felzabált 100GB helyet, majd eredményül visszaadott 2GB-ot.

A hiba nem hagyott nyugodni, ezért megnéztem a forráskódot is. Mivel bioinformatikus vagyok, a programozók általában úgy tekintenek rám, mint valami Szkript Kölyökre, aki csak Perl-ben tud turkálni. Emberhiány esetén adnak programozós feladatot, de az is elég marginális, mintha félnének, hogy összedöntöm a verzió-követő rendszert. A nyár és a szabadságok ideje viszont megnyitotta az utat előttem, hogy megmutassam, mit tudok.

A hibát sikerült visszavezetnem egy fájl másoló metódusra, ahol NIO-t használtak. Emlékeztem is rá egy megbeszélésből, ahol a programozók bőszen magyarázták az előnyeit. A forráskódban viszont találtam egy tutorial kódot. A változók más néven szerepeltek, de egyébként kínos hasonlóságot mutatott ezze. Az egyetlen probléma, hogy a kód csak 2GB alatti fájloknál működik. Korrekt formája ez lenne:

import java.io.*;
import java.nio.channels.FileChannel;

public class niotest {
   public static void main(String[] args){
      File sfile = new File(args[0]);
      File dfile = new File(args[1]);

      try{
         dfile.createNewFile();
      }
      catch(Exception e){
         e.printStackTrace();
      }

      FileChannel from = null;
      FileChannel to   = null;

      try{
         from = new FileInputStream(sfile).getChannel();
         to   = new FileOutputStream(dfile).getChannel();
         System.out.printf("File size: %d\n", from.size());
         long written = 0;
         while(written < from.size()){
            written += to.transferFrom(from, written, from.size() - written);
         }
         System.out.printf("Written: %d\n", written);

         from.close();
         to.close();
      }
      catch(Exception e){
         e.printStackTrace();
      }
   }
}Mert el kell olvasni a dokumentációt is, nem csak kimásolni a kódot.

A 3.1-es verzió óta az OpenGL nem tartalmazza a forgatással, eltolással kapcsolatos rutinokat. A profik azt írják, hogy ez egy jó ötlet volt, mert nem zárja korlátok közé a programozót. Egy API-nak viszont az a feladata, hogy megkönnyítse egy programozó életét. Ha egy alapvető funkcionalitás hiányzik az API-ból, akkor programozók tömegét kényszerítjük arra, hogy ugyan azt a feladatot elkészítse.

Aki nem akar saját maga bajlódni a mátrixok számolásával, az használhatja a glm-et, vagy egy korábbi posztomban említett Nopper úr GLUS könyvtárát. Én viszont egy merészet gondoltam, és úgy döntöttem, megírom saját rutinjaimat. Azért nevezem merésznek az ötletet, mert nem sokat konyítok a matematikához. Igyekeztem faék egyszerűségű kódot írni, amitől lehet, hogy a kód használhatósága nehézkes lesz. A megértést viszont biztosan nem fogja gátolni.

Az első és legfontosabb megemlíteni, hogy az OpenGL oszlopfolytonosan várja a mátrixokat, ami a Wikipédiában fellelhető mátrixok transzponáltja. Érthetően fogalmazva:

0 4 8 12
1 5 9 13
2 6 10 14
3 7 11 15

 Legyenen az indexek. Az általam használt kódban minden mátrix egy 16 elemű tömb lesz.

Egységmátrix

A legalapvetőbb mátrix a 3D grafikában. Az átló mentén 1-t tartalmaz. Erre azért van szükség, mert a mátrixok szorzása alkalmával nem fogja egyik mátrix a másikat kinullázni. Minden további mátrix ebből indul ki, külön nem fogom leírni.

Perspektíva

A perspektíva viszonylag egyszerű. A képernyő oldalaránya és a látószög beállítása mellett kiszámítja a mátrix értékeit. Két további paramétere a közeli és távoli vágási távolság.

void perspectiveMatrix(float *m, float fov, float aspect, float near, float far){
  float range;

  range = tan(fov * M_PI/360.0) * near;
  memset(m, 0, sizeof(float) * 16);
  m[0] = (2.0 * near) / ((range * aspect) - (-range * aspect));
  m[5] = (2.0 * near) / (2.0 * range);
  m[10] = -(far + near) / (far - near);
  m[11] = -1.0;
  m[14] = -(2.0 * far * near) / (far - near);
}


Kamera pozíció

Egy demóban, megkockáztatom ez az egyik legfontosabb mátrix. Segítségével megadhatjuk, hogy honnan nézzük a jelenetet. Ennek megfelelően bonyolult, mert több vektorműveletet kell végezni.

void lookAt(float *m, float *eye, float *target, float *up){
   int i;
   float n[3];
   float u[3];
   float v[3];
   float d[3];

   for(i = 0; i < 3; i++) n[i] = eye[i] - target[i];
   crossproduct3v(up, n, u);
   crossproduct3v(n, u, v);
   normalize(u, 3);
   d[0] = dotproduct(eye, u, 3) * -1.0;
   normalize(v, 3);
   d[1] = dotproduct(eye, v, 3) * -1.0;
   normalize(n, 3);
   d[2] = dotproduct(eye, n, 3) * -1.0;

   m[0]  = u[0];
   m[4]  = u[1];
   m[8]  = u[2];
   m[12] = d[0];
   m[1]  = v[0];
   m[5]  = v[1];
   m[9]  = v[2];
   m[13] = d[1];
   m[2]  = n[0];
   m[6]  = n[1];
   m[10] = n[2];
   m[14] = d[2];
   m[3]  = 0.0;
   m[7]  = 0.0;
   m[11] = 0.0;
   m[15] = 1.0;
}


Pozíció

A pozíció mátrix a legegyszerűbb. Gyakorlatilag a mátrix három elemét helyettesítjük a koordinátákkal.

void translate(float *m, float x, float y, float z){
   int i;

   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   m[12] = x;
   m[13] = y;
   m[14] = z;
}


Forgatás

A forgatás néz ki a legijesztőbben. A legtöbb példaprogram külön veszi a tengelyek mentén történő forgatásokat, majd mátrix szorzásokkal egy forgatási mátrixot képez. Szerencsére lehet találni olyan leírást, ami leírja, hogyan néz ki az a mátrix, amiben elvégezték a mátrix szorzást. A kód ilyesztő, de csak egyszer kell megírni.

 void rotate(float *m, float rx, float ry, float rz){
   int i;
   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   /* General rotation */
   m[0]  =  cosf(ry) * cosf(rz);
   m[4]  = -cosf(rx) * sinf(rz) + sinf(rx) * sinf(ry) * cosf(rz);
   m[8]  =  sinf(rx) * sinf(rz) + cosf(rx) * sinf(ry) * cosf(rz);
   m[12] =  0.0;
   m[1]  =  cosf(ry) * sinf(rz);
   m[5]  =  cosf(rx) * cosf(rz) + sinf(rx) * sinf(ry) * sinf(rz);
   m[9]  = -sinf(rx) * cosf(rz) + cosf(rx) * sinf(ry) * sinf(rz);
   m[13] =  0.0;
   m[2]  = -sinf(ry);
   m[6]  =  sinf(rx) * cosf(ry);
   m[10] =  cosf(rx) * cosf(ry);
   m[14] =  0.0;
   m[3]  =  0.0;
   m[7]  =  0.0;
   m[11] =  0.0;
   m[15] =  1.0;

}


Egyéb mátrix műveletek

Most pedig jöjjenek az egyéb nyalánkságok. A kamera pozíciójánál a kódban ilyen függvények láthatóak, mint crossproduct meg dotproduct. Mik ezek? Az első a vektoriális szorzat, aminek érdekessége, hogy csak 3 dimenzióban értelmezik.

void crossproduct3v(float *a, float *b, float *result){
   result[0] = a[1] * b[2] - a[2] * b[1];
   result[1] = a[2] * b[0] - a[0] * b[2];
   result[2] = a[0] * b[1] - a[1] * b[0];
}


A másik a skaláris szorzat, ami meglepő módon egy számot ad vissza. A hossz arányos a két vektor által bezárt szöggel, ezért a fények programozásánál is sokszor előkerül.
float dotproduct(float *a, float *b, int size){
   int i;
   float result = 0.0;

   for(i = 0; i < size; i++) result += a[i] * b[i];
   return(result);
}
Ha programunkban egy térhálós modellt elhelyezünk, forgatunk, és még a kamerát is mozgatjuk, több mátrixot kapunk, de hogyan készítsünk egy mátrixot? A válasz a mátrix szorzás. A mátrix szorzásnál a tagok sorrendje nem felcserélhető. Ezt mindenki ki is próbálhatja, hogy mi történik, ha a modellnél az eltolási mátrixot szorozza a forgatásival, vagy fordítva.

A szorzás sorrendje a következő: perspektíva * forgatás * eltolás * kamera. A szorzást a következő kód valósítja meg:

void matrixMultiply4x4(float *a, float *b, float *c){
   int i,x,y;

   for(i = 0; i < 16; i++){
      x = i & 12;
      y = i % 4;
      c[i] = a[x + 0] * b[y + 0] +
             a[x + 1] * b[y + 4] +
             a[x + 2] * b[y + 8] +
             a[x + 3] * b[y + 12];
   }
}


Mondtam, hogy egyszerű lesz, mint a faék. Hozzáértők a kommentekben mindenféle optimalizációt küldhetnek.

Mátrix betöltése shaderbe

A shaderben a mátrix uniform mat4 deklarációval szerepel. Kódunkban a glGetUniformLocation(shader, változónév) segítségével megkapjuk az erőforrás leíróját (egy egész szám), majd ezt felhasználva a glUniformMatrix4fv(leíró, 1, GL_FALSE, matrixpointer) segítségével beállítjuk azt.

Források

http://en.wikipedia.org/wiki/Transformation_matrix

http://en.wikipedia.org/wiki/Rotation_matrix#General_rotations

http://www.songho.ca/opengl/gl_transform.html

A Blendert mindig is egy fekete báránynak tekintettem a 3D programok között, amolyan szegény ember modellezőjének. A különböző demó produkciók elkészítésénél ki is próbáltam néhány programot, hogy megismerjem erősségüket, gyengeségüket. Végül az ízlésemnek leginkább a 3D Studio felelt meg. Ebben kezdtem el tanulgatni a modellezés alapelemeit.

Az eltelt két-három évben ha nem is lettem profi, egyszerűbb modelleket össze tudtam rakni. Aki nagyon kíváncsi, miket is alkottam, az megnézheti az Aeronautism-ban a léghajót, a 2010-ben az Amigát és az EVA pod-ot. Ahogy egyre ügyesebb lettem 3D Studioban, annál inkább mellőztem a Blendert, pedig telepítve van a Linuxos gépemre.

Ahogy a demóink is egyre fejlődnek (még ha ezt a nézők el sem hiszik :-) ) újabb és újabb igényeink lettek, amit alapvetően kétféle módon oldhatunk meg:

1. A speciális igényeinkhez valamilyen demóeszközt írok
2. Mások demóeszközeit használjuk saját célunkra
3. Egy meglévő eszközt ruházunk fel bővítmények segítségével

Demóeszközt eddig is írtam, de mind nagyon speciális volt, főleg különböző formátum konverziókat hajtottak végre. Egy interaktív eszköz elkészítésén is gondolkodtam, de egyrészt sok idő, másrészt olyan egyszerű problémákra sem találtam kielégítő megoldást, mint amilyen a keresztplatformos futtatás.

Mások egyközeivel is kísérleteztünk. Ezek sajnos kevéssé dokumentáltak, főleg saját használatra lettek tervezve, amitől a kezelésük egyéni logikán alapul.

A bővítmény készítés sem volt egyszerű. Először is a legtöbb 3D program Windows alatt fut (1. rossz pont), C++-ban kell hozzájuk fejleszteni (2. rossz pont). Ennek ellenére elkezdtem tanulmányozni a bővítmények dokumentációit.

Így jutottam el ismét a Blenderhez. Python. Ezt a nyelvet sem szeretem jobban, mint a C++-t. Ráadásul még kevésbé ismerem. Viszont amikor négy sorból megkaptam a kamera pozícióját, mindezt a Blenderen belül, akkor úgy döntöttem, hogy érdemes foglalkozni a programmal. A nyelv mélyebb ismerete nélkül pár nap alatt hozzáfértem egy csontváz elemeihez és megkaptam mely csúcspontok tartoznak a csonthoz.

De nézzünk néhány példát! A Blender elindítása után az ablak típusát változtassuk Script Window-ra. A Scripts -> System -> Interactive Python Console menüponttal megkapjuk az konzolt, ahol egyből be is írhatjuk a parancsokat. Arra ügyeljünk, hogy csak akkor tudunk beírni ebbe az ablakba, ha az egérmutató fölötte van. Gyorsan gépelők ne lepődjenek meg: A shift + szóköz billentyű teljes képernyőssé varázsolja az ablakot.

Objektumok:

Az objektumok listája a következő módon érhető el:

for object in bpy.data.scenes.active.objects:
  print object.type

Aki más 3D programban ennél egyszerűbben meg tudja ezt csinálni, az azonnal tudassa velem! Az objektumok helyzetét és forgásszögeit a következő metódusokkal, tagváltozókkal lehet lekérdezni:

object.getLocation() # Az objektum helyzete
object.getEuler()    # A forgásszögek radiánban
object.LocX          # Csak az X pozíció
object.RotX          # X tengely körüli forgatás szöge (fok)
A legszebb az egészben, hogy bármikor segítséget kérhetünk magától a rendszertől!

dir(object)          # Kilistázza a metódusokat és tagváltozókat
help(object)         # Rövid segítség

Az objektumokat is azonnal módosíthatjuk scripteken keresztül. Például forgassuk meg az első alakzatot, ami a kezünk ügyébe kerül:

for o in bpy.data.scenes.active.objects:
   if o.type == 'Mesh':
      mesh = o
      break;
for rad in range(0,360):
   mesh.RotX = rad
   Blender.Redraw()
Az egyik alakzat őrült forgásba fog kezdeni. Remélem sikerült felkeltenem az érdeklődést ez iránt a program iránt. Habár modellezni még jó ideig nem fogok benne, a jelenetek összeállításában biztosan ki fogom használni a képességeit.

A Velencei-tó mellett töltött nyaralás alkalmából megtekintettük a Madárdal tanösvényt. A túra Dinnyésről indul, de az idegenforgalmi kiadványokkal ellentétben nem egészen onnan kell indulni, ahol a térképek jelzik. A térkép szerint ugyanis azt mutatja, hogy a Gárdonyi Géza utcán kelet felé tartva a Kossuth utca után kell letérni. Ez nem igaz, a Kossuth utcán kell menni, egészen addig, amíg egy kis díszes tábla nem jelzi, hogy hol kell elhagyni a civilizációt.

Maga a tanösvény szépen rendezett, kiépített, ismeretterjesztő táblákkal van ellátva. Elhelyezkedése is igen szerencsés, mert végig egy szegélytársulás mentén halad. A szegélytársulások két eltérő élőhely határán fordulnak elő, és jellemző rájuk az ott élő állatok keveredése. Tehát egyszerre lehet látni a lápi és mezei madarakat.

Az egyetem alatt az ökológia professzorom azt mondta, hogy déli napsütésben épeszű ember nem keres madarat, mert azok elbújnak a hőség elől. (Mondta mindezt egy nyári terepgyakorlaton 12 órakor) Ennek ellenére most is elkövettük ezt a hibát, mert nem volt kedvünk hajnalban felkelni. Még így is meglepően sok madarat sikerült észlelni. (Igaz, némelyiket csak hang alapján tudtuk beazonosítani)

Egy kilátót is építettek a nádas szélére, ahonnan egy jobb távcsővel be lehetett látni a nyílt vízre, ahol a gázló és vízi madarak kolóniáját láthattuk. Az elkészült képekért elnézést kérek, nem támasztottam le eléggé a gépet.

 A gólyáknak nagyon melegük volt.

 Repülő nagy kócsag

Nagy kócsag felszállása

 Ilyen és ehhez hasonló táblák nyújtottak felvilágosítást

A madarak azt hitték senki nem látja őket

Daniel Blankenberg: NGS best practices through Galaxy: Cloudbased variant discovery with visual analytics

Ebben az előadásban a Galaxy rendszert ismerhették meg a hallgatók. A program előnye, hogy ingyenes, felhő alapú megoldást nyújt (természetesen az Amazon használatáért fizetni kell). Az egyetlen szűk keresztmetszet az adatok feljuttatása. Az előadó FTP szervert javasol, mert a kézi feltöltés nagyon sok időt vesz igénybe. A program egyébként ismert eljárásokat tartalmaz, például a variációk megtalálására a GATK-t. Személy szerint úgy gondolom, hogy a Pipeline Pilot felhasználóbarátabb. A húzd és vidd módszerrel összeállított munkafolyamat helyett itt egy webes menü-masszából kell kiválasztani a szükséges lépéseket és az sem segít a helyzeten, hogy rendszeresen átugrik egy olyan ablakra, ahol az eddigi lépések szöveges felsorolása szerepel. Az ablakok elrendezése is elég ijesztő, de az előadó gyakorlott mozdulatai miatt ez nem volt feltűnő. Ha viszont elrejti előlem a GATK összes nyűgjét a különböző formátum konverziókkal együtt, akkor egy próbát megér.

Mivel nem tervezem, hogy több előadásra bemegyek, ezért röviden az általam érdekesebbnek ítélt poszterekről írok egy-két sort.

Jalview 2.7: Nyílt forrású, Java alapú genom nézegető.

Mutalyzer 2.0: Improved sequence variant descriptions from next generation sequencing data and locus-specific mutation databases: www.mutalyzer.nl

SNP4Disease: SNP-betegség adatbázis. http://snp4disease.mpi-bn.mpg.de

UCSC Cancer Genome Browser: Az UCSC-ben immár nem csak "átlagos" genomokat böngészhetünk, hanem rákos genomokat is.

SARUMAN - Using GPU programming for short read mapping: GPU alapú short read mapper Cikk, amire hivatkozik: Exact and complete short read alignment to unihal genome using graphics processing unit (Bioinformatics)

Multi-Image Genome Viewer (MIG): mig.molbiol.ox.ac.uk/mig Bevallom, ez csak a neve miatt tetszett meg. A pószter is egy vadászgépet ábrázolt.

SNPeffect 4.0: molecular and structural phenotyping of human SNPs and disease mutations: Adatbázis, ami SNP-hez rendeli a különböző fehérjeváltozásokat.

SNPsyn: detection and exploration of SNP-SNP interactions: Több SNP egymásra hatását próbálja meg szemléltetni és megkeresni.

GARM - Genome assembly, reconciliation and merging: Szekvencia összeszerelő program, ami hibrid módszert használ.

GenomeView: Egy újabb genom böngésző http://genomview.org

Sequence assembly in the clouds: Búza genomot szereltek össze. Míg sokan azt hiszik, hogy az ember a legnagyobb kihívás a maga 3GB-os genomjával, addig a búzánál 15GB-al kell megbírkózni. Ehhez elosztott rendszer kell.

Chipster genome browser: A Chipsterről meghallgattam az előadást is. Igazából meg kell nézni, mert a poszter arról szól, hogy ők a legjobbak.

Earmark graph approach to de-novo genome assembly: Az oroszok megint kitaláltak valamit. A de-Brujin gráf összeszerelő programok helyett ők az Earmark gráfot javasolják, mert kevesebb memória kell neki és jobb eredményt ad repetitív szakaszokon.

The SMALT software for the efficient and accurate alignment of DNA sequence reads: Újabb mappelő program. http://sanger.ac.uk/software/smalt Olyan gyors, mint a BWA, olyan érzékeny, mint a Stampy, de ahol mégsem olyan érzékeny, ott természetesen elhanyagolható a különbség.

KILAPE - Automated scaffolding and finishing of large, highly repetitive genomes: Ez csak nagyobb darabokat illeszt össze, nem csinál teljes de-novot, de bármilyen de-novo programmal összeeresztve sokkal jobb eredményt kapunk, mintha csak egyedül használnánk a programot.

Inproved in silico regulatory SNP detection facilitates large scale SNP scanning: Megállapítja, hogy az SNP szabályozó régióba esik-e és ez kihat-e a fehérje átírására. http://genomics.csse.unideb.edu.au/is-rSNP

Improving SNV calling sensitivity by combining SNVs reported by different calling tools: Ha SNP-ket akar keresni az ember, akkor legjobb, ha több módszert használ, és a közös variációkat szedi ki. De melyik módszer a legjobb? Azt nem tudják. Próbálják megállapítani, hogy mennyire vegyék figyelembe az egyes programok eredményeit. Azt ők is megerősítik, hogy a GATK újraillesztési lépése megnöveli a megtalálható SNP-k számát, de az új SNP felfedezésében a SAMTools programja jár az élen, még akkor is, ha több fals pozitív eredménye van.

Comparison of short read aligners for ABI Solid platform: Több mappelő programot hasonlítottak össze és az jött ki, hogy a BWA a legjobb, a PerM pedig a legrosszabb.

Két pószterben is benne voltam, nem csak egyben, mint ahogy korábban hittem. Ez több feladatot rótt rám, mert én voltam az egyedüli jelenlévő előadó mindkettőben. A kollégáktól próbáltam segítséget kérni, csak annyira, hogy küldjék hozzám az érdeklődőket. Ezt meg is ígérték, de nem tették. Igen, kiérdemeltem a balek négyzet plecsnit. Ezért egyszer itt álltam, egyszer ott. Elég sok embert érdekelt, aminek örülök. Röviden leírom őket:

Az első pószter arról szól, hogy a legtöbb mappelő program illesztését felhasználva a GATK nem képes olyan polimorfizmusokat megtalálni, ahol a két nukleotid változás közvetlenül egymás mellett van. A második pedig arról szólt, hogy egy kodon alapú mappelő algoritmus jobban teljesít exomok esetén, míg a hagyományos, nukleotid alapú jobban boldogul homopolimer szakaszokon.

Rengeteg könyvkiadó cég is képviseltette magát és a konferencia alatt 20%-al olcsóbban lehetett megvenni sok könyvet. Azt hiszem könyvre bármennyi pénzt el tudok költeni, ezért szerencse, hogy nem volt nálam elég pénz, mert romlásba döntöttem volna a családi kasszát.

Összességében elmondható, hogy a legtöbb kiállító a gyorsaságra helyezte a hangsúlyt. Két kiállító FPGA gyorsítást ajánlott. Megtekinthettünk egy PCI foglalatba illeszthető FPGA gyorsító kártyát. Az előadások is arról szóltak, melyik algoritmus gyorsabb. Még tőlem is megkérdezték, hogy milyen a kodonos illesztő sebessége.

Végezetül egy kis poén. Az egyik kiállító ingyen pólókat osztogatott. Az érdekes az egészben az volt, hogy a cég logója nagyon kicsi volt, viszont egy hatalmas "Blast the unknown" és "Altschul et. al 1337" felirat volt az elején és a hátulján. Mondanom sem kell, vitték, mint a cukrot. Ekkor a cégünktől valaki megkérdezte, hogy ez milyen cikkre hivatkozik. (A válasz: Blast) Körülbelül olyan volt, mintha egy Forma 1 nagydíjon valaki megkérdezi, ki is az a Schumacher?

A második nap először a posztereket néztem át reggel. A poszter szekció is két részre volt osztva, ezért azokról egy külön részben fogok beszámolni. A mai nap nagy dilemmában voltam, mert több előadásra is szívesen mentem (lógtam) volna, amelyek egy időben voltak.

Scott Markel, Ruth Dunn: Analyzing next gen sequencing data with Pipeline Pilot

Ez egy viszonylag hosszabb előadás volt, ahol a Pipeline Pilot nevű keretrendszert mutatták be. A többi bioinformatikai keretrendszertől eltérően ez egy elosztott megközelítést használ, ahol a lokális adatok a feldolozási lépések során egy távoli szerverre kerülnek, majd a további elemzések ott folytatódnak, csökkentve a saját gép terheit. Azért kíváncsi lennék, hogy egy 300GB-os humán short read adat mennyi idő alatt mászik fel a szerverre és hogyan kezelik a feltöltés során fellépő hálózati problémákat. A bemutató során csak pici teszt adatokkal játszottak az előadók, ahol természetesen minden tökéletesen ment.

A másik nagyon szimpatikus megközelítés a munkafolyamatok összeállításának lehetősége. Gyakorlatilag képzeljünk el, hogy a különböző programok be és kimeneteit összekapcsoljuk egy grafikus felületen. Az előadás végén megkérdeztem, hogy segít-e a program a hibás adatok felderítésében, amire azt a választ kaptam, hogy igen. Erről azért a gyakorlatban is szívesen megbizonyosodnék, mert a Bioscope tapasztalatom kétkedésre int.

Az előadásnak volt egy másik érdekes eseménye is. Mellettem egy ember tollal, papírra jegyzetelt!

Susan Gottesman: RNA structure: Bacterial small RNAs in regulatory networks.

Részletes és mélyreható bemutatót láthattunk az E. coli rpoS gén kisRNS-en keresztül történő szabályozásáról. A kisRNS-ek különböző stresszhelyzetben aktíválódnak és bonyolult szabályozási folyamatokon keresztül aktiválják vagy represszálják a géneket. Egy kisRNS több gént is szabályozhat és több kisRNS szabályozhat egy gént.

Peter Rice: EMBOSS: New developments and extended data access

Az EMBOSS egy olyan programcsomag, ami sokszor kihúzott a bioinformatikai slamasztikából. Ennyit megérdemelnek, hogy megnézzem az előadásukat. Az új fejlesztés az adatbázisokhoz való kapcsolódás. Beépített adatbázisok is vannak. Van natív Windows-os verziója is, amit alig tesztelnek, úgyhogy el lehet felejteni a cygwin-t. Az új generációs szekvencia adatok támogatása későbbre tolódott. Szomorú hír, hogy az EMBOSS-nak otthont adó EBI ez év december végétől csak tárhely formájában támogatja a programot. Az előadó még nem tudja, mit fognak tenni.

Eric Tannier: Mapping ancestral genomes with massive gene loss: a matrix sandwich problem

Ősi genomokat próbálnak előállítani a mai leszármazottakból, a gének módosulásait figyelve. A probléma akkor van, amikor a két leszármazott más-más géneket tartalmaz. Nem tudni, hogy melyiket örökölte és melyik keletkezett újonan. Az előadó mátrixokat olvasott fel az előadás nagy részében, amitől nagyon unalmas volt.

Eija Korpelainen: Chipster 2.0: User-friendl NGS data analysis software with interactive genome browser

Egy újabb világmegváltó programcsomag. Elsősorban microarray adatok feldolgozására tervezték, de időközben kapott EMBOSS integrációt, és most a 2.0 verzióban újgenerációs adatokat is képes feldolgozni. Tartalmaz felhő alapú modult is, a Hadoop-BAM-ot, ami egy BAM fájlt darabol, hogy mapreduce-os környezetben fel lehessen dolgozni. Egy genom böngészőt is tartalmaz, ami kevés memória mellett is rendezi a BAM fájl rekordjait a könnyű megjelenítés végett. Az előadás külön érdekesssége volt, hogy a Windows-os laptop nem érte el a Wi-Fi hálózatot, ami miatt egy Machintosnak kellett megmentenie az előadást.

Paul Horton: Next-generation genome alignment with LAST

A Blast a múltté. Az adaptív seed technikának köszönhetően készítettek egy olyan lokális illesztőt, ami gyorsabb és érzékenyebb, minat a BLAST, miközben a repetitív szakaszokon jobban teljesít, mint a nagy előd. Másképp kezeli az indexet, mint a Blast. Egy suffix tömböt használ, ami kevesebb tárhelyet emészt fel, mint egy hash alapú index. Állítólag két gerinces genomot néhány óra alatt illeszt egy átlagos PC-n 2GB memóriával. Egy próbát megér: http://last.cbrc.jp/

Ma is álltam és vártam, hogy az embereknek elmondhassam cégem profilját. Senkivel nem kellett beszélnem. Arra a pár emberre, aki jött, lecsaptak a főnökök, én meg nem tiltakoztam. A munkatársaim pósztere mellett is ácsorogtam, mert ők nem akartak olyan sokat ácsorogni a saját pószterük mellett, úgyhogy megkaphatom a balek plecsnit. Annak ellenére, hogy a nevem nem szerepel rajta és a nullához közelítő mennyiséget dolgoztam vele, elég jól elmondtam annak a három embernek, akik odatévedtek. Ez igen rossz arány egy több ezres nemzetközi konferencián.

Vicces volt, ahogy a háromból kettő kínai kutató volt, akik minden kérdésre adott válaszomat hatalmas "hoo"-val kísértek. Mikor azt mondtam nekik, hogy a short readek referenciához illesztésére saját fejlesztésű programot használtunk, kitört belőlük egy "AHHHHH" mély torokhangon, mintha puszta kézzel vágtunk volna ki egy fát.

Este részt vehettem egy céges munka vacsorán is. A két cég főnökei jól elvoltak a repülőgépes, szállodás történetekkel. Hiába, egy kozmopolita életben ezek az események. Én egyfolytában arra gondoltam, mennyivel hasznosabban tölthetném ezt az időt.

A mai poszt egy bécsi bioinformatikai konferenciáról érkezik. A cég, ahol dolgozom kiállít és előadást tart, én személy szerint poszterrel is jelen vagyok. A bécsi konferencia központban van a rendezvény, ami egy hatalmas épület, felszerelve minden technikával, amivel egy konferenciaközpont fel lehet szerelve. A legutóbbi konferencia óta, ahol voltam, sok minden változott. Régen még a regisztrált tagok tollat és jegyzetfüzetet kaptak. Ma már kevésbé trendi bioinformatikusok laptoppal, a trendik tablettel rohangálnak és jegyzik fel az előadáson elhangzott értékes mondatokat.

Apropó előadások. Sajnos csak kiállítói regisztrációm volt, ami nem tette lehetővé, hogy az előadásokat is megtekintsem, legalábbis elméletileg. Gyakorlatilag a kártyámat megfordítottam, hogy ne lássák rajta a nagy vörös betűkkel kiírt "Exhibitor only" feliratot, szépen mosolyogtam az ajtóknál álló emberekre és máris bent voltam.

A következő előadásokat tekintettem meg:

Andre Altman: vipR: Variant identification in pooled DNA using R

Az előadás lényege az volt, hogy a vizsgálatok során, ahelyett, hogy egyenként klón könyvtárakat készítenének a vizsgálat populációkból, ami idő és erőforrás igényes feladat, a mintákat összekeverik, és a kevert mintából készítenek könyvtárat. Elvesztik az egyéni különbségeket, de cserébe a genetikai variációk jobban csoportosíthatóak. Az előadó azt a példát hozta, hogy egy fehérje diszfunkciójához különböző mutációk vezethetnek, amelyek nem feltétlenül egy helyen alakulnak ki. Az előadás többi része arról szólt, hogy az ő megoldásuk természetesen a legjobb, leggyorsabb.

Samuel Flores: A structural and dynamical model of human telomerase

Bevallom, ebből az előadásból nem értettem semmit. Először azt hittem rossz helyen vagyok, mert az előadó az RNS másodlagos szerkezetéről beszélt, majd a fehérjék szerkezetéről. Az előadás egy hatalmas termet kapott, amit nem sikerült halgatósággal megtölteni, akik végigszenvedték, azok kérdés nélkül távoztak. Lehet, hogy nem voltam egyedül az értetlenségemmel?

Benoit Ballester: Five vertebrate ChIP-seq reveals the evolutionary dynamics of transcription factor binding

Szerintem a legjobb előadás volt ezen a napon, az általam látottakból. Öt gerinces faj kromatin immunpercipitációs vizsgálatával figyeltek konzerválódott transzkripciós faktor kötőhelyeket. Megállapították, hogy milyen mutációk vezettek ahhoz, hogy a transzkripciós faktor egyes fajokban működésképtelen legyen. Figyelték azt is, hogyan változnak bizonyos transzkripciós faktorok más fajokban. Eredményeik még publikálatlanok, de biztosan érdekes cikk fog születni belőle.

Attila Bérces: Cloud computing for computational biology

Magyar előadó is volt, már csak ezért is meg kellett nézni. Arról szólt, hogy nincs mese, a felhő jelenti a megoldást a bioinformatika minden problémájára, mert olcsó, nagyobb teljesítményű. Bármikor leakaszthatunk egy 64GB RAM-al ellátott virtuális gépet, ha szükségünk van rá. Egy hallgató megjegyezte, hogy neki páciensek adataival kell dolgozni, a felhő alapú megoldások milyen biztonságot garantálnak neki? A válasz az volt, hogy még semmilyet.

Attila Bérces: Accurate genome variant detection

A második előadást is meghallgattam. Egy olyan programot mutatottak be, ami mindennél jobban illeszti az újgenerációs szekvenciákat referencia genomhoz. Eddig SOLID platformhoz volt használható, de már készül az Illumina platformhoz szánt változat is. Szokásos táblázatok, hogy ez a jó, minden más semmit sem ér.

George Vacek: Efficient graph based assembly of short-read sequences on a hybrid core architecture

Az előadás a felhő alapú szolgáltatásokkal ellentétben a brutális gépi megoldást preferálja. Egy FPGA foglalatos gépről van szó, ami egyesíti egy PC hatalmas memóriáját és egy FPGA sokmagos gyorsaságát. A cég elsősorban ezen gépek értékesítésével foglalkozik, a szekvenciák összeszerelésére Velvetet használnak, amit kiegészítettek egy saját programmal, hogy a Velvet memória éhségét csökkentsék. Implementálnak más algoritmusokat is eme szörnyeteg alá.

Paul Medvedev: Error correction of high-throughput sequencing datasets with non-uniform coverage

Nagyon sokan nézték ezt az előadást. A teremben az állóhelyek is elfogytak. Egy élelmes kutató kinyitotta a szomszédos termet, majd vigyorogva leült, de mikor az ajtót is elállták előle, biztos arcára fagyott a mosoly. Az előadás lényege, hogy a readeket a fedettség függvényében csoportokba rendezik és nézik, hogy az egy csoportba tartozó readek milyen eltéréseket mutatnak és ezeket a többi read (és nem a referencia alapján) korrigálják. Az számomra továbbra sem tiszta, hogy a heterozigóta SNP-ket hogyan nem javítják ki.

Egyéb látnivalók

A regisztrációs kártya nyakba akasztható volt. Az egyéb információkat (valaki előadást tart, csak egy napra váltott jegyet) kis matricákkal oldották meg, amelyek lelógnak a kártya alatt. Erre egy lapáttal rátett az egyik kiállító is, aki pont ilyen matricákat osztogat azoknak, akik náluk publikálták egy cikküket. El lehet képzelni, hogy milyen hosszú élettörténetet viselhetnek egyesek a nyakukban.

Egy kisebb kiállítás is volt, ahol biológiával kapcsolatos művészi alkotásokat lehetett megtekinteni. Az egyik festményen fehérje térszerkezetek körvonalai voltak kiegészítve arra, amire leginkább hasonlítottak. Volt egy BioBlender nevű programmal készített ioncsatorna és sugárkövetéssel előállított fehérje másodlagos szerkezet.

Közben a cég kiállított standján is beszéltem az emberekkel. A nyomulós, mi vagyunk a legjobbak szöveg helyett inkább azt próbáltam mondani, hogy van akadémiai liszensz, a termékünk kipróbálható. Ezzel az emberek saját maguk eldönthetik, hogy a programunk jó-e vagy nem.

Holnap lesz a második nap, és újabb bejegyzés.

A filmekben a ragasztószalag amolyan univerzális javító alapanyag. Bármilyen javítási feladatot meg tudnak oldani vele. Nekem is van olyan anyagom, amivel bármit megjavítok. Ez pedig a két komponensű epoxi gyanta.

Előnye, hogy bármilyen külön álló darabokat végérvényesen egybe lehet forrasztani vele, ami azután hő, fagy, sav és még ki tudja mennyi hatásnak ellenáll. A fotós állványom egy éjszakai bevetés során megrongálódott, aminek hatására az egyik teleszkópos lábát nem lehetett semmilyen magasságban rögzíteni.

Az ismerőseim mind azt tanácsolták, hogy vegyek újat, de szükségtelennek tartottam, hiszen még volt két jó lába.

Abban biztos voltam, hogy ha egy csavart bele tudnék operálni, akkor azzal megszoríthatnám a lábat. A terv az volt, hogy fúrok egy lyukat, amibe egy anya csavart rögzítek epoxi gyantával. Így sikerült:

 Arra kellett csak vigyáznom, hogy a gyanta bele ne folyjon az anyába és az állvány lábához, mert akkor örökre fix hosszúságú lesz. Ezt kis papírdarabokkal oldottam meg.

Nem tagadom, hogy a mindennapi világ történései alól kivonom magam. Legalábbis megpróbálom. Ezért én csak utólag hallok vulkánkitörésekről, meteorokról, árvízekről, Amerikában tevékenykedő orosz kémekről vagy esetleg járványokról.

A mostani eset sem azért jutott tudomásomra, mert a napi sajtót olvasom, hanem mert egy igen érdekes jelenség tűnt fel vele kapcsolatban.

Mint az ismeretes, Németországban járvány tört ki, a fertőzést egy Escherichia coli nevű baktérium egyik törzse okozta. A kínai BGI saját állítása szerint három nap alatt megszekvenálta a baktériumot és a Twitteren keresztül azonnal szétkürtölték a világban. Annyira siettek, hogy a szekvenciát nem is a nagy genom adatbázisokba töltötték fel először, ahogy türelmes kutatókhoz illik, hanem saját FTP oldalukra.

Feltételezem nem sokat aludtak, mert mindjárt szekvencia analízisnek vetették alá a nyers szekvenciákat. Június 2-án már fel is rakták oldalukra, mit találtak. Az eredmények alapján elkezdtek kiteket gyártani, hogy megkönnyítsék a baktérium detektálását.

Június 7-én már készen volt az a PCR gyors teszt protokolja, amivel 2-3 óra alatt ki lehet mutatni, hogy a veszélyes kórokozóról van-e szó. Számítógéppel leellenőriztek 4547 törzset, ami nem nagy szám, tekintve, hogy az E. coli genomja igen kicsi, kitömörítve 5MB helyet foglal. Ha le is töltötték az összes genomot, akkor is kb. 22 GB helyet foglalt. Viszont kísérletesen 93 törzset is megnéztek. Egy kisebb PCR készülékben 25 cső fér el, a nagyobbakba, ha mikroplate-ba rakják a mintát, akkor 96. Futtatáskor egy csőbe csak reakcióelegyet is tesznek, minta nélkül, hogy megnézzék, történt-e szennyezés. Akkor is két üres hely maradna egy plate-en. Nem hiszem, hogy üresen hagyták volna. Azt tudom elképzelni, hogy azok a minták nem adtak eredményt, vagy valamit elrontott, aki összemérte az oldatokat :-) (Bár külföldi laborokban nem ritka a pipettázó robot) Természetesen az is lehet, hogy ott egyéb kontroll oldatok voltak. Akár hogy is történt, akkor is csak egy PCR-t használtak, mert azt nem tartom valószínűnek, hogy ne legyen 93-nál több E. coli mintájuk.

Visszatérve a történetünkhöz. Június 16-án elkészült a teljes összeillesztés. Itt valószínűleg már nem rohantak, mert egy baktérium genom összeszerelése nem tart 9 napig egy kellően erős számítógéppel. Itt valószínűleg a minőségre mentek rá.

Ugyanakkor létrehoztak a Githubon egy csomópontot, ahol gyorsan meg lehet osztani a további eredményeket.

 Csak, hogy érezzük, milyen gyorsan jöttek ezek az eredmények. Mikor nekem E. colit kellett szekvenálnom (2004), akkor kb. 500 bázispár távolságra "láttunk el". Ezt kb. egy hét alatt kaptuk meg a szekvenáló cégtől. Mivel spóroltunk, ezért a szekvenálási hibákat kézzel javítottuk (mert a PhD-s olcsóbb, mint újból megszekvenálni a hibás részeket). Akkor már megvolt az E. coli egyik törzsének a genomja, tehát ha az alapján tervezem meg a primereket, akkor kb. 11 ezer szekvenálásra lett volna szükség. (Ebbe nem számítottam bele a palazmidokat) Ha nem is lett volna egy hét minden egyes szekvenálás, hanem csak egy óra, akkor is egy évig kellett volna dolgoznunk rajta.

Egyes hírek azt sugallják, hogy ezt csak a kínaiak tudják megtenni, mert ők sokan vannak, jól felszereltek és nagyon akarnak, de nem erről van szó. A felszerelésük tényleg jó és minden bizonnyal nagyon akartak, de a nagy ember mennyiségről nem vagyok meggyőződve. A szekvenáláshoz használt Ion Torrent készüléket egyetlen embernek kell kezelni. A PCR szintén egy emberes készülék. A de novo szekvencia összeépítést leszámítva az összes bioinformatikai munkát el lehet végezni egy közepes PC-n. Ehhez is csak egy ember kell. De ha az Amazonon bérelnek egy sok memóriás gépet, akkor egy laptop is elég a munkához.

Nyilván azért is siettek, mert sok beteg emberről van szó, de észrevehetjük, hogy nem a szokványos tudományos publikálást választották. Ha Nature cikket írtak volna (mint ahogy egészen biztos vagyok benne, hogy fognak), annak a megjelenése több hónap is lehet. Annyi idő elteltével nem lenne a gyorsaságuknak hírértéke. Gyorsan lecsaptak egy aktuális eseményre és nagyon ügyesen meglovagolták a sikert. Hiszen az már egyik hírcsatorna sem említi, hogy miután kihozták a szekvenciákat június 2-án, azóta párszor még frissítették azokat. A gyorsaság miatt még arra sem jutott idejük, hogy a honlapjukon a legalapvetőbb szóelválasztási hibákat kijavítsák.

Tehát egyfelől ott a tény, hogy gyorsan el kell juttatni az információkat azokhoz, akik dolgozni tudnak vele (az első eredmények megmutatták, hogy felesleges bizonyos antibiotikumok alkalmazása, a kórokozóban található rezisztencia gének jelenléte miatt), valamint jelezni kell, a többi kutatólaboratóriumnak, hogy mi már itt tartunk, ti ne ezzel foglalkozzatok. Másfelől egy Github miként tudja garantálni, hogy BGI csomópontjához csatlakozók mindegyike szakember-e?

Én személy szerint örülök, hogy egy okostelefon segítségével a Twitteren keresztül bárhol értesülhetek egy tudományos eredmény születéséről. Azt is szeretem, hogy bár nem vagyok az akadémiai szféra tagja, mégis közel mehetek az eredményekhez, mintha csak egy látogatóknak felállított üvegfalon keresztül nézném a laboratóriumban dolgozókat. De azon is elgondolkodom, hogy hol jobb kutatni? Egy vásártér kellős közepén, ahol a kofa hangosan ecseteli, hogy mit pipettázik a kutató, vagy egy laboratórium magányában? Ezzel a nagy nyíltsággal nem vesztünk-e el valamit?

A Mozilla Labs böngészőben futó demóknak szervez partit. A nevezett alkotásoknak a cég legújabb böngészőjén kell futnia. Öt kategóriát állítottak fel:

• Animált GIF. Ez egyfajta grafikai kategóriának felel meg.
• Egy effektes compo: Ez párhuzamot mutat egy introval.
• CSS3 Compo: Ezt nem tudom minek megfeleltetni. A lényeg, hogy csak CSS3 manipulálást engedélyeznek?
• Audio demo: A compo zenei kategóriája. Lehet generált zenével is indulni, mintha csak executable music compo lenne.
• Full Demo: Ahol csak a képzelet szab határt.

Ha valakinek megtetszett a kiírás és úgy érzi nem tudja hol álljon neki, az látogassa meg ezt a blogot.

Azt hiszem jó hatással vagyok a mukatársaimra. Eddig könnyedén kijelentettek dolgokat, majd mindenféle ellenőrzés nélkül elterjesztették, amit később mások igaznak fogadtak el. Ilyen kijelentés például, hogy az Amazonon a programok futását az I/O műveletek visszafogják. Ilyenkor én mindig megkérdeztem, hogy mire alapozzák a kijelentésüket, van-e bizonyítél, esetleg megmérték-e valamilyen módszerrel.

Szép lassan eljutottunk oda, hogy validálunk, ellenőrzünk, és nem csak valami homályos látomás alapján teszünk kijelentéseket, hanem tények birtokában.

De én továbbra is csak egy kis morzsa vagyok a gépezetben. Még nincs doktorim sem. Mi történik, ha két különböző ember elméletileg hasonló mérése nem egyezik meg? Mi történik, ha egy híres, külföldön tanító professzor egyszerű vizsgálatát megismétlem, és különböző eredményt kapok? Ez a professzor pedig nagyon híres. Egy zseni, egy művész. Olyan gondolatok megálmodója, amire mások képtelenek.

Vele szemben én egy senki vagyok. A proffal már találkoztam, de annak ellenére, hogy többé-kevésbé egy témán dolgozunk, a nevemet sem tudja.

Ilyenkor az a reakció, hogy bizonyára én szúrtam el a vizsgálatot. Ennek megfelelően leellenőriztem a vizsgálat menetét és megismételtem azt. A különbség megmaradt. Hibakeresés, hiba megtalálása. Az eredmények megváltoztak, de a különbség továbbra is megmaradt. Végül eljutottam oda, hogy minden apró hibát kijavítottam, amit csak találtam, de a különbség megmaradt.

Ezek után kénytelen voltam levonni a következtetést, hogy a sztárprofesszor megoldása a hibás. Csakhogy hiába mondom, hogy többszöri ellenőrzés után is ott a különbség. A főnököm, aki rá sem nézett az adatokra, sem a vizsgálat menetére, egészen biztos benne, hogy csakis én szúrhattam el valamilyen lépést. A professzort nem lehet megkérni, hogy egy ilyen bagatel hiba felderítésében segítsen, pláne nem lehet feltételezni, hogy ő elronthat valamit. Helyette egy másik ember, tőlem függetlenül megismétli a vizsgálatokat. Majd utána kiderül, hogy merjük-e zavarni a nagy embert.

Szerkesztés: A megoldás roppant egyszerű volt, nem ugyan azokat a paramétereket használtuk, tehát mindenkinek igaza volt.

Már elég idő eltelt a 2010-es Function óta. Azt hiszem eléggé feldolgoztam a sokkot, hogy kiírjam magamból az ott történteket. Amikor a repülőgépes katasztrófákat felderítik, akkor legtöbbször megállapítják, hogy olyan sorozatos hibákat követtek el, ami külön-külön orvosolható lett volna, de abban a kombinációban olyan halálos elegyet alkotott, hogy a gép nem élhette túl. Körülbelül az én esetem is ilyen volt.

Egy szeptemberi hétvégén volt a Function nevű demoshow. Már jó ideje készültem rá, hogy végre megmutathassam, hogy nem
csak windows alatt lehet jó demót készíteni. Szombaton érkeztem a parti helyére, még időben, hogy
leadhassam Grass kézi rajzát és feltöltsem a demót. A demó rengeteg nagy méretű textúrát tartalmazott,
több részletes poligonnal, ezért nem meglepő, hogy bizony a mérete 39 MB-ra rúgott.

Szerencsére 64mb volt a mérethatár, így ez nem okozott gondot. Ez volt az első demóm, ahol nem a jól
ismert SDL könyvtár képezte a keretrendszert, hanem alacsony szintű függvényhívások: libpng a textúráknak,
vorbis a zene dekódolásának, alsa a hang lejátszásához, X11 az ablakkezeléshez. OpenGL tudásomat is
fejlesztettem, ezért már shaderek is voltak a demó egyes jeleneteiben, ami megakadályozta, hogy
a céges laptopon futtassam.

A parti előtt két nappal gyakorlatilag kész voltam a teljes demóval. Annyit elárulok, hogy Slackware 13.0-n
fejlesztettem, méghozzá 64 bites rendszeren. Ekkor még nem volt semmi információm arról, hogy milyen
Linuxon akarják majd levetíteni a demót, de a tavalyi tapasztalatok alapján abból a feltételezésből
indultam ki, hogy egy 32 bites Ubuntu lesz a compógép.

Telepítetem az Ubuntut, lefordítottam a demót és láss csodát, nem volt hang. Tulajdonképpen nem
lepett meg, hiszen itt PulsAudio van, aminek az Alsa-s emulációja nem teljes. Példának okáért
hiányzik az aszinkron hanglejátszás. Mondanom sem kell, hogy természetesen én azt implementáltam.

Gyorsan felvettem egy új függvényt a cg_audio.c-be, ami láss csodát, tökéletesen működött. Csak nem
Slackware alatt. Itt kellett volna még tovább finomítani a rendszert, hogy mindkét rendszer alatt
tökéletesen menjen, de ezt nem tettem, pedig Richard Marchinko is megmondta: "Soha ne feltételezz!".
Én feltételeztem. Mégpedig azt, hogy Ubuntu alatt fogják lejátszani.

A parti nagy fordulópontja az volt, mikor találkoztam Gargajjal, az egyik szervezővel. Megkérdeztem
tőle, volt-e bármilyen probléma a demóm lejátszásával.
- Ha nem Linuxos, akkor nincs vele gond - válaszolta.
- De Linuxos.
- Itt van a laptopod?
- Itt, de azon nem megy. Kell neki OpenGL 2.0.
Rövid kutakodás után találtunk valakit, akinek szintén volt egy Linuxos laptopja. Rövid próbálgatás után
azt is kiderítettük, hogy ugyancsak Intel GMA-val van felszerelve, nem megy rajta a demóm.

Láttam, hogy a helyzet kezd menthetetlen lenni. Latolgattam, hogyan jutok haza, hogy elhozzam
a saját gépemet. Charlie segített. Képes volt miattam levezetni megközelítőleg 100km-t, hogy
elhozzuk azt a gépet, amin fejlesztettem a demót. Átadtam a szervezőknek és megnyugodtam,
hogy most már semmi baj nem történhet. Ez volt a második hiba.

Az intrók után Gargaj szólt, hogy itt az ideje, hogy beüzemeljem a gépet. Kaptam áramot, hangcsatlakozót,
videó kimenetet. Egy profinak ennyi is biztosan elég lenne, de én azért kértem egy billentyűzetet is.
Hátam mögött a kíváncsi tömeggel nekiáltam az óriás kivetítőn beizzítani a rendszert. A Slackware szép
komótosan indult. Mikor az X11-et indítottam, akkor már láttam, hogy baj van. A gép 640x480 felbontásban volt. Rövid billentyűn
keresztül történő matatás után észrevettem, hogy az NVidia beállítópanel sem ismer nagyobb felbontást,
mint 640x480. Most mi legyen? Kértem egy egeret, amivel kicsit gyorsabban folytattam a matatást.

Mögöttem már kezdett zúgolódni a tömeg. Elindítottam a demót, hátha az majd belövi a felbontást, de nem így történt. A demó bal felső sarka látszott csak.
Végül megnyitottam a forráskódot és átírtam, hogy 640x480-ban fusson le. Ez már nagyon nem tetszett a
nézőknek, hogy ott írom át a kódot. Fordítás sikeres volt, rövid teszt, működik, leállítottam, és szépen hátra
kullogtam.

- Nyomd le az entert! - hangzott fel. Visszafutottam és elindítottam a demót. Ismét hátra kullogtam. A terembe már nem mertem bemenni, csak a folyosóról hallgatóztam és a hangokból próbáltam kitalálni, hogy milyen a demó fogadtatása.

Valami nem stimmel. Miért nem hangosítják fel? Miért nincs hang? Ezt mások is megkérdezték, de nekem akkor nem
esett le. Semmit ötletem nem volt. Közben a demó szépen ment hang nélkül. Emlékeztem, hogy az elején, a teszt alatt még volt. Az első teszt alatt! A
fordítás után már nem! Akkor megértettem. Azt a kódot fordítottam le, ami Ubuntu alatt ment, de Slackware alatt
nem. A demónak a fele akkor már lement. Hallva a bekiabálásokat úgy döntöttem, hagyom így. Úgysem tetszik nekik,
akkor minek fárasszam a nézőket még zenével is? Ennek megfelelően utolsó lett, de akkor már nem foglalkoztam a
dologgal.

Minden esetre megtanultam, hogy atombiztos demót kell írni. Különösen Linux alatt. A másik, ha valami gond van
vele, inkább nem szabad hagyni, hogy lejátszák.

Később visszagondolva több módon is elkerülhettem volna a problémát. Először is, a gépemen volta Ubuntu is. Elindíthattam volna azt is. Normálisan megírhattam volna a kódot (csak egy snd_pcm_recover függvény hiányzott). Nem hagyom, hogy a két kódbázis összekeveredjen. Ehelyett egy olyan elegyet főztem, ami megpecsételte a demó sorsát.

Mivel soha életemben nem foglalkoztam kémiai informatikával
és soha nem installáltam több processzoros gépre semmit, ezért
itt volt az ideje, hogy mind a kettőt kiadják nekem feladatnak.

Az Amazon rendszerén van lehetőség egy 16 processzoros, processzoronként
4 magos gép igénylésére. Erre kellett felvarázsolnom az ADF nevű
programot. Lehetőleg úgy, hogy azt a gépre bejelentkező potenciális
ügyfelek ne tudják ellopni.

Egyszerre csak helyzetet tudok kezelni, ezért az installálással kezdtem.
A program igényel egy MPI implementációt. Ha 64 bites Linuxra szeretné
telepíteni az ember, akkor két lehetőség közül választhat: HP-MPI, vagy
Intel-MPI. Az Intel mellett döntöttem, még akkor is, ha ezzel az Amigás
társadalom mély megvetésére számíthatok.

Az Intel-MPI telepítése nem igényel különösebb leírást, az elavult
telepítési útmutató több-kevésbé lefedi a lépéseket. Pl. Nem kell
liszensz fájl, mint ahogy írják. Az ingyenes futtató környezet
letöltése igaz, regisztrációt igényel, amit csak nagy vonakodva voltam
hajlandó elvégezni.

Az ADF telepítése, még ennél is könnyebb. Egyszerűen kicsomagolja magát
az aktuális könyvtárba, és nesze, használd. Egy liszensz fájlt kell
az ADF könyvtárába másolni, és már készen is áll a kémia titkainak
feltárására. Már ekkor sejtettem, hogy ebből gond lesz. Milyen jogosultságot
tudok adni neki, hogy elrejtsem ezt a felhasználó elől? Ha nincs
olvasási joga a liszensz fájlra, akkor nem indul a program. Ha van,
el tudja lopni. Ezt a problémát későbbre halasztottam és megnéztem, mit
tud a program.

Az ADF Fortran nyelven írt alkalmazás, ami laikusként annyit csinál, hogy
szöveg fájlokat olvas be és szöveg fájlokat ír ki. A bemeneti állományok
atomokat, távolságokat és szögeket tartalmaznak, a kimenet bő beszédű
leírásokat.

A rendszer rész még egy teljes értékű Python értelmező is, ami a körülbelül
180 MB-os programból 120MB-ot foglal el, valamint egy Tcl/Tk is helyet kapott.

A teszt adatok között keresgélve találtam egy érdekeset. Azt elindítottam,
az eredményt összehasonlítottam a példa eredménnyel. Nagyjából megegyezett,
ezért úgy gondoltam, készen is vagyok.

A láthatóság problémáját sodu-val oldottuk meg. Így minden egyes parancsot
sudo-val lesz kénytelen futtatni a felhasználó, de cserébe nem látja még
a könyvtár szerkezetet sem. Hátránya, hogy az eredmény fájlok más
felhasználó alatt (soduer) jelennek meg. Ez még további finomítást igényel.

A gondok itt nem értek véget. Kaptam egy másik teszt adatot, amivel szintén
ki kellett próbálni az ADF-t. Indítás után rögtön azt kaptam a képembe, hogy
nincs host. Hűha! Eddig nem kellett. Gyorsan megnéztem a régi teszt adatokat.
Bizony ott is kellett, csak valami csoda folytán túlélte a program és lefutott,
de most nem. Rövid keresgélés után kiderült, hogy kell egy mpd.hosts fájl.
Rendben, hozzuk létre. De hova? Betettem az /etc-be, a telepítés helyére, de
egyik sem tetszett neki. Végső elkeseredésemben a munkakönyvtárba helyeztem.
Az tetszett neki. Később kiderült, hogy a dokumentáció (nem a getting started,
mert az túl nyilvánvaló lett volna) egy helyen leírta, hogy az mpd.hosts
bizony csak az aktuális munkakönyvtárban helyezhető el. Érdekes! Miért
nem jó az /etc vagy a felhasználó könyvtára?

A következő probléma, hogy nem volt hajlandó egy hoston futni. Tizenhat
processzor van a gépen, de neki nem volt elég, mert csak egy hostot látott.
Beírtam neki tizenhatszor ugyan azt a hostot, de az sem segített. Végül egy trükkhöz folyamodtam.
Az Amazonon minden gépe kap egy nevet. Beírtam azt, és a localhostot. Ez
segített. Viszont nem tudott kapcsolódni saját magához.

Tehát meg kell oldanom, hogy rsh-val a számítógép önmagához kapcsolódjon.
Ez nevetséges. Kell, hogy legyen valami más megoldás. Közben kiderült, hogy
amit én a tesztek idején úgy értelmeztem, hogy lefutott, az valójában nem futott le.
Ugyan az a hibajelenség volt ott is, mint itt.

A megoldás pedig olyan egyszerű volt! Letöltöttem a HP-MPI-s verziót, és
futott minden szépen.

Unatkozik hétvégenként? A számítástechnika túl átlátható? Méretezze át NTFS partícióját!

A céges laptopomon Windows van, de úgy éreztem, hogy Linuxot kell rá telepítenem, anélkül, hogy a Windows törlésre kerülne. Az ok egyszerû: a doktorimat LaTeX alatt készítem, és kell egy olyan megoldás, amivel a akkumulátor barát módon tudom szerkeszteni azt. Erre a legegyszerûbb megoldás a Linux konzol. Konzol alatt sok olyan felaadtot el lehet látni, ami nem igényli a grafikus felületet. Az egyik ilyen a szövegszerkesztés (itt most a szöveges állományok módosítását értem, nem a kiadványszerkesztést).

Ahelyett, hogy valami kereskedelmi programot használtam volna erre, mindezt ingyenes, nyílt forráskódú programokkal akartam megoldani. Azt rögtön sejtettem, hogy a Windows partíció átméretezéséhez elõször defragmentálni kell a fájlrendszert. A rendszer saját programját használtam erre, pedig, mint késõbb megtudtam, ezt a lépést is megcsinálhattam volna Linux alatt. A program finoman szólva is nem hozza a kívánt színvonalt. Többször egymás után el kellett indítani, hogy képes legyen kitölteni a réseket a használat alatt álló blokkok között.

Olvastam, hogy Knoppix alatt megvan minden szükséges program, amivel a Windows partíciókat átméretezzem. A Knoppix egy CD-rõl vagy DVD-rõl futó Linux disztribúció, telepítés nélkül is mûködõképes. Fõleg adminisztrációs célokra használom, tehát nem volt ismeretlen számomra, de csak a 2001-es verzió volt meg. Letöltöttem a legújabb, 6.2-es verziót és nekiláttam a munkának. Gyorsan meg is találtam az NTFS resize programot. A súgó javasolta, hogy ha nem vagyunk biztosak magunkban (én nem voltam), akkor használjuk valamelyik klikkelõs keretrendszert, például a GParted-et. Klikkelõs, egyszerû, bolond biztos. Ez kell nekem! Játszottam az egérrel, húztam-vontam a csúszkákat és a Windows partíció összement. Gondoltam, ha már itt vagyok, elkészítem a Linuxos partíciókat is. Azok elkészítése is gyorsan ment. Végül következett a változtatások kiírása. Ellenõriztem, hogy minden rendben van-e, majd kiadtam a parancsot: írd ki a változtatásokat.

A program jelezte, hogy az NTFS partícióval gond van. A volume mérete nagyobb, mint a drive mérete. Gondoltam, majd átmegyek Windows alá és a chkdsk segítségével orvosolom a dolgot. Itt jött az elsõ fekete leves. Nem tudtam átmenni Win alá. Sem csökkentett módban, sem parancssorban, sehogy. Természetesen semmilyen biztonsági mentést nem csináltam a partíciós tábláról, aminek segítségével könnyedén visszaállíthattam volna a régi állapotot. Eszembe jutott, hogy van Norton Systemworkom, ami annak idején sokszor kihúzott a slamasztikából. Emlékeztem arra is, hogy a CD képes bootolni. Nincs más dologm, mint elõkeresni a CD-t kiírni, majd megoldani ezt a kis malõrt. Nem oldotta meg. Ez egy 2003-as verzió volt, ráadásul egyedül a virus irto indult csak el, amikor bootoltam a CD-vel.

Már láttam magam elõtt, amint a cég rendszergazdája kérdezi, mi történt a laptoppal. Mit mondjak? Leejtettem? Csak Linuxot akartam rá telepíteni és tönkretettem a Win partícióját? Esetleg forduljak a jó öreg kifogáshoz: Nem tudom, egyszer mûködött, de a következõ pillanatban ezt csinálta. Azt tudtam, hogy a fájlok megvannak rajta. Azt is tudtam, hogy ezt vissza lehet hozni. Csak azt nem tudtam, hogyan.

Ekkor léptem meg azt, amit már jóval korábban kellett volna. Rákerestem a Google-n. Kiderült, hogy a GParted rosszul állítja be az NTFS fájlrendszer méretét. Ugyanis annak egy szektorral kevesebbnek kell lennie, mint amennyi rendelkezésre áll. A fórumon egy segítõkész ember a neki elküldött partíciós táblákat javította. Ugy gondoltam, ezt én is meg tudom csinálni. Elõször is a jó öreg dd paranccsal lementettem a partíciós táblát, majd hexeditorral megnyitottam. A második sorban volt a méret letárolva. Kiolvastam a GParted hibanaplójából a méretet, kivontam belõle egyet, a méretet hexadecimálisba alakítottam. Itt egy kicsit tanácstalan voltam, hogy milyen bájtsorrendet kell használni, ezért a fórumban leírt méretek és hexa értékek alapján kisakkoztam. dd-vel visszaírtam a partíciós táblát és különbözõ voodoo szertartások közepette újraindítottam. Múködött! A Linux telepítése ehhez képest már semmi nem volt.

Van egy célom. Szeretnék egy kézzel húzódzkodni. Ehhez nagyon sok húzódzkodást kell csinálni. A házunk előtt van egy szőnyeg poroló, télen viszont nagyon hideg a vascső. A kesztyű nem jó alternatíva, mert nehezíti a fogást. A hideg egyébként is növeli a sérülés veszélyt a gyorsabb kihülés miatt. De az igazi indok, hogy lusta vagyok hidegbe kimenni.

Többször gondolkodtam rajta, milyen megoldást lehet találni a problémára. Végül egy ajtókeretbe feszíthető rúd látszott a legjobb megoldásnak, amit egy ismerősöm lakásában láttam. Azonnal megtetszett a szerkezet egyszerűsége és praktikussága. Szimpatikus volt az is, hogy bármikor eltávolíthatom, anélkül, hogy maradandó károsodást okoznék a lakáson.

Rövid kutakodás után találtam egy hegymászóknak szóló blogot, ahol a hozzászólások között írták, hogy vigyázni kell, mert a rúd talpai benyomódhatnak az ajtókeretbe, célszerű valamilyen talpat használni. Megörültem a hasznos tanácsnak. Igen, erre nem is gondoltam! Szerencsére van néhány használaton kívüli laminált padló, majd abból vágok magamnak megfelelő talpat.

Szépen le is vágtam a padlót a megfelelő méretre, majd ügyesen egyensúlyoztam, hogy miközben csavartam ki a rúd talpait, azok egyenlő távolságra legyenek, valamint a padlóból vágott darabok is az ajtókeret és a talpak között maradjanak mindeközben.

Mikor már a gravitációnak ellenállt a szerkezet, elengedtem a talpakat és tovább tekertem a rudat, hogy jól beleszoruljon a helyére. Már masszívan állt, de én tartva, hogy esetleg mégis kicsúszik, még tekertem rajta. Azután még egy kicsit, csak hogy egészen biztos legyek a dolgomban. Ekkor reccsent egy nagyot az ajtófélfa. Egy hatalmas repedés keletkezett a felső sarkában. Pár hónapja festettem és javítottam le. Szörnyű volt látni, hogyan pusztítottam el a munkámat.

Csak ezután jutott eszembe, hogy van egy másik ajtófélfa is a lakásban, amit nemsokára úgyis ki is fogunk cserélni...

Talán mondanom sem kell, hogy ott semmilyen sérülés nem keletkezett a felszerelés során.

A hazai Amigás közösség legnagyobb összejövetele az AmiCon. Lázi ilyenkor vendégül látja ennek a különleges gépnek a rajongóit, a résztvevők pedig bemutatják, megbeszélik az amigás világ legfrissebb történéseit.

Én friss tagja vagyok a közösségnek, ez volt az első alkalom, hogy részt vettem  az AmiCon-on. Többen is megjegyezték, hogy idén kimagaslóan sokan jöttek el. Ülni csak a korán érkezőknek sikerült.

Az első érdekesség a Hollywood Designer bemutatása volt. Ezt a programot egyetlen Amigás fanatikus fejleszti. Ha a program képességeit le akarnám degradálni, azt mondhatnám, hogy egy Amigás Flash alkalmazásról van szó. Bemutatókat, prezentációkat készíthetünk vele. Interaktív tartalmakat hozhatunk létre segítségével.

Az Amigás közönség alaposan szétforgácsolódott, ahogy egyre újabb és egymással alig-alig kompatibilis rendszer jelent meg. A Hollywood Designer igyekszik minden platformon ugyan azt a felhasználói élményt nyújtani. A Windows és Mac felhasználók sem panaszkodhatnak. A program képes futtatható állományt készíteni a bemutatókról ezekre a platformokra is.

Akik előnybe részesítik a programozást a vizuális szerkesztők helyett, azok a Hollywood beépített szkriptnyelvét használhatják. A bemutatón az is elhangzott, hogy a jövőben C nyelven írt bővítményeket is lehet majd használni.

A másik nagy bejelentés egy új Amigás újság megjelenése volt. A szerzők célja, hogy elsősorban a klasszikus rendszerről jelenítsen meg minél több hasznos információt. A PDF-ben terjesztett verzió ingyenes, a nyomtatott változatért értelemszerűen fizetni kell.

A megjelenésnek természetesen mindenki nagyon örült. Reméljük a szerkesztőknek lesz elég idejük és lelkesedésük is, hogy folytathassák a munkát.

Hallottam egy jópofa történetet is, igaz C64-ről, nem Amigáról. A történet főhőse Ratman, akit egy nap felhívtak, hogy nem megy a program.

- Milyen program? - kérdezte.
- A nyilvántartó program - ekkor kezdett el derengeni neki, miről is lehet szó.

Kiment a helyszínre, ahol talált egy C64-t, egy nyomtatót és egy floppy egységet. Ratman megkérdezte, hogy kivették-e bármikor is a lemezt. Azt mondták nem. Óvatosan kivette a lemezt, amit az idő és a fejmozgás papír vékonyságúra koptatott. Már olvashatatlan volt. Reménykedve megfordította és fellélegzett. Ott volt a forráskód!

Otthon rövid debuggolás után kiderült, hogy mi volt a hiba. A program, ami a kilencvenes évek közepén készült, simán túlélte a PC-s világot fenyegető Y2K-t, de  2008-t már nem. Kijavította a hibát és visszaküldte a programot.

Én még arra voltam kíváncsi, hogy annak idején hogyan tanultak meg kódolni az emberek. Manapság elég megnyitni kedvenc keresőprogramunkat és máris tanulhatjuk a kódolás minden csínját-binját. De ez annak idején lehetetlen volt.

Mint megtudtam, az első lépés, hogy warez forrásból kellett szerezni egy fordító programot. A második lépés, hogy a szükséges dokumentációt (ami legtöbb esetben hibás volt) fénymásolt lapokon be kellett szerezni. Ezt legtöbbször egy lelkes illető lefordította angolról, további hibákat és elírásokat vétve. Végül a programozó palánta beírta és lefagyasztotta vele a gépét.

A tanulás második lépése pedig az volt, hogy ki kellett kísérletezni, mi az, ami működik és mi az, ami nem. Tehát a tudás megszerzése inkább egyfajta felfedezés volt.

GNU/Linux rendszeren sokféle módja van annak, hogy hangot csiholjunk ki a gépből. Itt is megfigyelhető az a tendencia, hogy az eszközök egymásra épülnek és mindegyik célja az, hogy elfedjék szegény programozók elől a problémás részeket.

Ha viszont a lehető leghordozhatóbb megoldásra van szükségünk, akkor célszerű átvágni magunkat az API-k dzsungelén, hogy megleljük a tiszta forrást. Ez nem más, mint az ALSA. Az ALSA segítségével előállíthatunk bármilyen hangot. Szerény véleményem szerint nem olyan bonyolult a használata. Ez azonban nem jelenti azt, hogy nem érhetnek minket meglepetések. Erről majd egy következő bejegyzésben részletesen is írok.

A zenét mi Ogg/Vorbisban tároljuk, ezért a példaprogramban a vorbis könyvtárat is használni fogjuk.

Inicializálás

Első lépés, hogy beállítsuk a kívánt paramétereket. Milyen eszközön, milyen típusú puffert használunk és milyen minőségű hangot kívánunk megszólaltatni.

snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);
Minden parancs snd_pcm-el kezdődik. Ezt könnyű lesz megjegyezni. Először meg kell nyitni az eszközt. Az eszköz nevét egy sztring határozza meg. Ha több hangkártya is van a gépbe, akkor explicite megadhatjuk, hogy melyik eszközt használjuk. Ha hordozható megoldásra vágyunk, akkor legyen "default".

A második sorban lefoglaljuk a memóriát a paramétereknek, majd beállítjuk azokat. A dokumentáció részletesen leírja, hogy melyik mit jelent. Ezek a beállítások függetlenek a lejátszani kívánt zenétől.

music_file = fopen(argv[i+1], "r");
ov_open(music_file, &music, NULL, 0);
music_info = ov_info(&music, -1);

A zenefájl megnyitása ennyi. A zene jellemzői a music_info struktúrába kerülnek. Ezt fogjuk felhasználni, hogy beállítsuk az ALSA-nak a hangjellemzőket.

snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 4;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);
Ez már kellően elrettentő. A lényege röviden, hogy mi nem adhatjuk meg pontosan a paramétereket, mert az egyes hangkártyák esetleg nem ismerik azt a beállítást. Ezért mi csak annyit mondunk, hogy körül-belül ilyen beállításokat akarunk (snd_pcm_hw_params_set_period_size_near), majd a meghajtóprogram kiválasztja azt, ami a legközelebb esik hozzá, amivel mi már beállíthatjuk a kívánt paramétert (snd_pcm_hw_params_set_period_size). Beállítjuk továbbá a hangpuffer jellemzőit is.

A size = frames * 4 sor egy kis magyarázatot igényel. Az ALSA a pufferben két adatot vár, mivel sztereóban játszunk le. De a másik kettő honnan jön? Azt nem tudom. Bármilyen más értékre átírom, a mintavételezés olyan rossz lesz, hogy élvezhetetlenné válik a zene.

sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
ret = snd_pcm_writei(playback_handle, buffer, frames);

Gyakorlatilag ennyi a további kód. Az ov_read segítségével kiolvassuk a következő puffernyi adatot, majd az snd_pcm_writei-vel lejátszuk.

A teljes kód:

#include <vorbis/vorbisfile.h>
#include <vorbis/codec.h>
#include <alsa/asoundlib.h>
#include <math.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

/*
   This program is try to play an ogg-vorbis file. This version
   is working with only in 1 bitstream files.
*/

int main(int argc, char *argv[]){
   int i;
   FILE *music_file;
   OggVorbis_File music;
   vorbis_info *music_info;
   snd_pcm_uframes_t frames = 128;
   snd_pcm_sframes_t ret;
   long sample_length;
   char *buffer;
   int size;
   int bitstream;
   int playing = 1;
   int bytes_needed;
   int pcm_index;
   int dir;

   snd_pcm_hw_params_t *hw_params;
   snd_pcm_t *playback_handle;

   for(i = 1; i < argc; i++){
      if(!strcmp(argv[i], "-f")) music_file = fopen(argv[i+1], "r");
   }

   /* Alsa initialization */
   snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);

   /* Open the music*/
   ov_open(music_file, &music, NULL, 0);

   /* Get the sample rate information from vorbis file */
   music_info = ov_info(&music, -1);

   /* Set the alsa channels and rate */
   snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 2;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);

  
   while( playing ){
      bytes_needed = size;
      pcm_index = 0;

      while(bytes_needed > 0){
         sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
         switch(sample_length){
            case 0:
               playing = 0;
               bytes_needed = 0;
               break;
            default:
               pcm_index    += sample_length;
               bytes_needed -= sample_length;
         }
      }
      ret = snd_pcm_writei(playback_handle, buffer, frames);
      if(ret < 0){
         ret = snd_pcm_recover(playback_handle, ret, 0);
         printf("Recover\n");
      }
      if(ret < 0){
         printf("Underrun: %s\n", snd_strerror(ret));
      }
   }

   snd_pcm_close(playback_handle);
   ov_clear(&music);
   return(EXIT_SUCCESS);
}

A demók elkészítése során számos segédeszközt használunk. Az elkészített tartalmakat (zenék, képek, stb) lehetőleg minél kevesebb munkával szeretnénk a demó részévé tenni, ezért a gondosan megválasztott fájlformátumoknak nagy szerepe van. Az intrók esetében ilyen probléma nincs, mert minden tartalmat a program állít elő.

Platform

A demó platformja nagymértékben meghatározza, hogy milyen fájlformátummal tudunk dolgozni. Egy Amigán futó program értelem szerűen nem mp3-ban tárolja a zenét. De PC-n és főleg GNU/Linux rendszerben, ahol a csapat demói készülnek, szintén számítani lehet korlátozásokra. Fedora alatt például alapértelmezetten nincs mp3 codec.

Zene

Mi Ogg/Vorbis formátumban tároljuk a demó hanganyagát. Könnyű hozzá a legelterjedtebb platformokon lejátszó könyvtárat találni. Az SDL_Music például minimális energiabefektetéssel lejátsza. A kezdetek óta használjuk. Valamennyi demónkban Ogg/Vorbis formátumban vannak a zenéink. Egyetlen alkalommal sem okozott problémát a használata, pedig Linux mellett AmigaOS4 és MorphOS alatt is használtam.

Textúrák/Képek

Ez sem nehéz választás. A PNG és JPEG egyaránt elterjedt és népszerű formátum. OpenGL példaprogramok mellett előszeretettel találunk TIFF betöltőket, ezért ha nem akarjuk a képet tömöríteni, akkor ez is egy alkalmazható módszer. Mi PNG-t használunk, mert ebben van alfa csatorna. A libpng-t valamennyi Linux disztribúció tartalmazza. Windows esetén állítólag csak egy DLL kell. Elhiszem. Az összes bitkép szerkesztő program tudja exportálni ebbe a formátumba, de ha mégsem tudna, akkor az ImageMagic ezt is megoldja. (Igen, parancssorban szoktam képeket konvertálni)

3d modellek

Poligon centrikus demók esetén fontos, hogy a különböző térbeli alakzatokat, miután elkészítettük egy modellező program segítségével, szintén minimális energia ráfordítással illeszthessük alkotásunkba. Itt már akadhatnak problémák. Először is, kevés azoknak a fájlformátumoknak a száma, amit a legtöbb modellező program exportálni tud. A másik probléma, hogy az egyes programok ugyanazon formátum különböző dialektusait beszélik. Ezért bármilyen modellt is kapok Grasstól, az első, hogy azonnal tudni akarom, hogy megfelel-e a demó keretrendszere által elvárt formának (ez egyébként valamennyi fájlra igaz).

Így jutottam el a Wavefront OBJ formátumáig. Ez egy szöveges állomány, ezért parancssor segítségével azonnal fel tudom térképezni. Pl:

grep -v "^#" modell.obj | awk '{print $1}' | sort | uniq

Ez a parancs megmondja, hogy mely mezők fordulnak elő a fájlban. A ZBrush például kihagyja a normál vektorokat.

awk '/f/{print NF}' modell.obj | sort | uniq

Ezzel pedig azt ellenőrzöm, hogy minden poligon ugyanannyi csúcspontból áll-e. A Cinema4d ugyanis néha háromnál több csúcsot tartalmazhat.

A másik nagy előnye a szöveges állományoknak, hogy könnyű módosítani őket Perl szkriptekkel. Előfordult ugyanis, hogy az egyik program egy módosítás alkalmával eltolta valamelyik tengely irányába az egész modellt. Mivel én kézzel szoktam pozícionálni a demóban, egy ilyen után meglepődve tapasztaltam, hogy a modell eltűnt. A koordináták gyors ellenőrzése segítségével viszont gyorsan kiderítettem, mi a gond.

Vektorgrafika

Most kellene azt mondanom, hogy SVG. Sajnos nem. Az SVG egy olyan formátum, ami már kétszer is megkeserítette az életemet. Az első demóm alkalmával egy saját vektoros formátumot használtam, de mivel még nem volt grafikus a csapatban, ezért a grafikákat Illustratorban (igen, ez egy Windowsos program) és Karbon14-ben (ez pedig Linuxos) készítettem. Sajnos nem volt elég tapasztalatom egyik program használatában sem, ezért mindkettővel egy részfeladatot végeztem csak el. Abban az időben sokat indítottam újra a gépet.

Ami viszont az újraindításokon túl gondot okozott, az a szabványok támogatásának hiánya. Sajnos az Illustrator, aminek elméletileg kenni-vágnia kellett volna az SVG szabványt, bizony sokszor hibázott. A Karbon14, amit valószínűleg felhasználók visszajelzései nélkül fejlesztettek és fejlesztenek mind a mai napig, viszont remekül boldogult többféle SVG dialektussal is. Ezért, ha véletlenül Karbon14-ből mentett SVG-t akartam betölteni Illustratorba, akkor volt egy kis konvertáló scriptem, ami SVG-t konvertált SVG-be.

Most, így utólag visszaolvasva, nekem is hihetetlennek tűnik, hogy mikre voltam képes. Azt még nem is említettem, hogy az SVG-k csak vonalakat tartalmaztak, egyetlen színnel. Bele sem merek gondolni, hogy mi történt volna, ha bonyolultabb alakzatokat használok.

Sajnos az SVG-től nem sikerült megszabadulnom. Az Etch-a-sketch című demónknál is kísértett szelleme. Itt is saját formátumba készítettük a vektorgrafikát. Okulva a korábbi kudarcból, készítettem egy szerkesztő programot, ami rögtön saját formátumba mentett. Legalábbis ez volt az elmélet. A gyakorlat az volt, hogy sok időt felemésztett a szerkesztő program kifejlesztése, ami nálam működött, Grassnál nem. Közeledett a party, de én ahelyett, hogy a demót programoztam volna, a szerkesztő bugjait javítottam. Grass közben nem tudott dolgozni, az idő meg telt.

Ekkor nagy levegőt vettem és azt mondta, használjunk SVG-t. Két kikötésem volt: Csak vonalat tartalmazhatott és csak egy általa választott program egy bizonyos verziójában készülhetett. Azt gondoltam a konvertáló szkript ennyivel meg fog birkózni.

Mondanom sem kell, hogy egyiket sem sikerült betartani. Szerencsére ezeket idejében észrevettem. A demó pedig elkészült.

Tanulság

A saját formátumoknak megvan az az előnyük, hogy mi tartjuk kézben, viszont több munkát ró a programozóra, akinek el kell készíteni az eszközöket, konvertáló programokat hozzá. A másik lehetőség, hogy standard fájlformátumokat használunk, de itt elképzelhetőek apró módosulások a szabványhoz képest. Ha nem elég robosztus a demó keretrendszere, hogy felismerje a formátum dialektusait, akkor célszerű csak egy program egy adott verzióját használni, és a demót ahhoz igazítani.

Az 1000Genome projekt elérhetővé tett nagy mennyiségű exome szekvenálásból származó adatot. Ezek egy VCF 4.0 típusú fájlban találhatóak meg egy ftp szerveren. Nincs is sok probléma vele, mindössze annyi, hogy tömörítve 61GB. Felhő ide-kimeríthetetlen tárhely oda, ez igen nagy mennyiségű adat, nem sok kedvem volt letölteni, kicsomagolni, majd kinyerni a nekem kellő rekordokat. Szerettem volna valami elegáns megoldást.

Először elkezdtem letölteni, majd egy tetszőleges időpontban megállítottam a letöltést és a zcat segítségével kinyertem az első pár ezer sort. A letöltött állomány darabka 296MB volt, kicsomagolás után csekély 2,3 GB-ra hízott. Tehát 500GB elég lenne a tömörítetlen adatoknak, amelyeknek nagy részére nem is voltam kíváncsi.

Szerencsére a VCFTools rendelkezésre bocsájt egy csomó eszközt, amivel szűrni lehet a VCF fájlokat. Már csak azt kellett megoldani, hogy ez a szűrés letöltés közben valósuljon meg. Mivel GNU/Linux alatt dolgozom, ez nem is olyan nehéz feladat, mint azt elsőre gontoltam.

A letöltést wget-el végzem. Annak a -O - kapcsolóval megadható, hogy a szabványos kimementnek adja át az állományt. A rendszerüzeneteket kikapcsoltam a -q kapcsolóval. Ezután a zcat kicsomagolja az állományt, majd a vcf-subset parancs elvégzi a szűrést. A -c kapcsolóval megadható neki egy fájl, ami a nekünk szükséges sorokat tartalmazza. Összegezve:

wget -O - -q  'ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20100804/ALL.2of4intersection.20100804.genotypes.vcf.gz' | zcat | ./vcf-subset -c oszlopok. >eredmeny.vcf

A BFast egy rendkívül jó kis short read illesztő program. Indexeli a referencia szekvenciát, amitől sebessége elég gyors lesz. Seed technikát alkalmaz, aminek az a lényege, hogy egy 0-ból és 1-ből állo sorozattal megadhatjuk, hogy mely bázisokat hasonlítsa össze és melyeket ne. Volt néhány nem egyértelmű utalás a dokumentációban, amit szeretnék világossá tenni.

Az indexelés 1-től indul

A referencia indexelésénél több seedet is felhasználhatunk, amit indexekkel különböztetünk meg. Ez az index 1-től indul, és nem 0-tól, ahogy egy C programozó várná :-)

A readek FASTQ-ba legyenek

A program FASTQ formátumban olvassa be az adatokat. Ha nem így kapja, segmentation faulttal elszáll. Szerencsére van konvertáló program (solid2fastq), ami még azt a szívességet is megteszi nekünk, hogy szétdarabolja a readeket. Erre akkor lehet szükség, ha nincs elég memóriánk. Amennyiben nem daraboljuk szét a readeket, akkor is megadhatunk intervallumot az -s és -e kapcsolókkal.

Read méret

BFast nem ad optimális eredményt, ha a read mérete kisebb 30 bázispárnál. Ettől függetlenül használható ebben az esetben is, a szerző szerint.

Legyen nukleotid referencia is

Ha color space adatokat dologzunk is fel, a lokális illesztéshez (bfast local) szükség van a nukleotid referenciára is. Ennek segítségével kapjuk meg SAM fájlunkat nukleotidok formájában.

Figyeljünk a kimenetre

A BFast eredményül egy SAM fájlt ad. Ebben megtalálhatóak az illesztett és nem illesztett readek egyaránt. Ez okozhat problémát olyan segédprogramok esetén, mint a Picard SamSort programja, ami ezekkel a readekkel nem tud mit kezdeni, mert nincs pozíciójuk. A nem illesztett rekordokat két módszerrel is kiszűrhetjük: A második oszlop 4. bitje ha be van kapcsolva, akkor a read nem illesztett. A gyakorlatban ez azt jelenti, hogy ha 4 és 20-t találunk, akkor kiszűrhetjük. A másik, vitatható, de jóval gyorsabb módszer, ha a referencia neve helyett (3. oszlop) * karakter van, akkor nem illesztett a read.
 

Korábban azt írtam, hogy csak egy bonyolult script segítségével tudtam több folyamatot egymás után futtatni. Ez a script folyamatosan cserélgette az .ini fájlokat.

Szerencsére van más módszer is, amivel parancssorban egy folyamatot tudunk összeállítani a Bioscope részére.

Létre kell hozni egy .plan kiterjesztésű állományt. Ez tartalmazza a folyamat egyes elemeit. Az elemek pedig a futtatni kívánt programok ini állományai. Tehát ha egy szekvenálás eredményét először illesztjük a referenciához, majd .bam állománnyá konvertáljuk, akkor a következő sorok szerepelhetnek a .plan állományban:

mapping.ini

matobam.ini

Létre kell hozni a két ini állományt, és a dokumentáció szerint kitölteni a paraméterekkel. Csakhogy, nincs lehetőség ciklusok és változók használatára. Tehát ha van nyolc szekvenálásunk, akkor nyolc ini fájlt kell létrehozni, még akkor is, ha csak egy sor eltérés van bennük.

Trükként lehet használni a global kulcsszót az ini fájlok elején. Ennek célja, hogy bizonyos változókat kiemeljen, amelyek több ini állományban is ugyan olyan értéket vesznek fel.

Amint készen van a .plan fájlunk, nem kell mást tenni, mint elindítani a bioscope-t:

bioscope.sh -l logfile sajat.plan

Egy Microsoft központú világban nem használni Office terméket ( beleértve az ingyenes klónokat is) eretnekség. A diplomadolgozat elkészítése után váltam eretnekké, ahol annyi problémával szembesültem, hogy úgy döntöttem mellőzöm ezeket a programokat az életemből.

A dokumentációkat ettől a pillanattól kezdve LaTeX-ban készítettem, mit sem törődve a főnökök siránkozásával, hogy nem tudják szerkeszteni az általam átküldött anyagokat. Nem vagyok nagy felhasználó, de még az én szintemen is sokkal könnyebben boldogultam vele, mint annak idején a klikkelős szöveg formázó rendszerekkel.

Mikor eljött a doktori dolgozat elkészítésének ideje, nem volt kérdéses számomra, hogy LaTeX-ben fog készülni. A döntésem helyes volta rendszeresen visszaköszönt, ahogy láttam mások mennyi szenvedés árán csinálják dolgozatukat. Persze az így elkészült dolgozatról már messziről látszott, hogy ez valami eretnek termék. A betűk szépek, nincsenek hullámvonalas hosszú ő és ű-k, az oldalak elrendezése esztétikus, és a referenciák teljesen egységes felépítést mutatnak. Ez pedig csak valami gonosz műve lehet.

Rögtön bele is kötöttek házi védésnél, hogy a referenciák a műszaki tudományoknál megszokott módon vannak formázva. Ennek kijavítása rendkívül egyszerű volt. Betöltöttem a natbib csomagot, és az összes \cite parancsot \citep-re cseréltem. Mivel Linux alatt dolgoztam, ez egy sed paranccsal megoldható. Csakhogy, a \citep-nél a szerzők neve között "and" szerepelt "és" helyett. Hirtelen nem találtam rá semmilyen megoldást. Mások is szenvedtek hasonló problémákkal. Egy oldalon pedig olyan bonyolult tex megoldás szerepelt, hogy nem értettem belőle semmit.

Az idő fogyott, nekem pedig nem volt megoldásom rá. A hívők kajánul mosolyogtak nyomoromon, hogy bezzeg a Wordben bármilyen szót ki lehet cserélni, bármikor. LaTeX-ben nem. A LaTeX sok kis szövegfájlból állítja elő DVI v. PDF kimenetet, ami már nem szerkeszthető egyszerű módon. Tehát nekiálltam megkeresni azt a szövegfájlt, ami a problémát okozza. A gondot a bibtex/bst/natbib könyvtár stílusfájljai okozták. Ezekbe bele van égetve az "and" kulcsszó a format.names, format.full.names, format.lab.names függvényekbe. Tehát ezeket kell csak kicserélni és máris mindenhol magyarul jelenik meg az elválasztás. Mindenhol? Igen. Még az irodalomjegyzékben is. Ez viszont nem jó. Ha a format.names-t visszaírjuk, akkor már jó lesz. Csúnya hack, de működik.

A másik problémám a szekeszthetőség volt. Ezt a LaTeX2rtf programmal oldottam meg. Ennek viszont volt egy komoly problémája. Én ugynis UTF8-ban készítettem a dokumentumot, a program viszont csak Latin1-t volt képes kezelni, sok formázást nem volt képes maga elvégezni, ezért a következőképp kell használni:

1. LaTeX-el hozzuk létre a dokumentumot. A folyamat során létrejönnek az átmeneti állományok.
2. iconv segítségével alakítsuk át a programok kódolását. Én az alábbi kis scripttel oldottam meg: for i in *; do iconv -f UTF8 -t Windows-1251 $i >tmp; mv tmp $i; done
3. Futtassuk a LaTeX2rtf programot. Ha szerencsénk van, csak a hosszú ő és ű lesz ronda. Egyéb karakterkódolással lehet kísérletezni. A teljes fordítás soha nem lesz tökéletes.

Nekem a táblázat hivatkozások, fejezet címek (chapter fejezet helyett) soha nem jelentek meg tökéletesen. De az RTF úgysem publikálásra készül, hanem arra, hogy belejavítsanak, tehát sok időt nem szabad vele foglalkozni.

Egy majd hetven oldalas dokumentumnál összesen két probléma. Ez töredéke annak, ami egy Word dokumentumnál fellép. A nyomtatás pedig PDF-ből gyerekjáték, míg Word esetén katasztrófa, ha egy másik gépre kell átvinni. Megéri eretneknek lenni.

Ez a szakma elég megfoghatatlan számomra. Először is, mert véleményem szerint nem lehet tanulni. Ha lehetne, akkor már rég megtanultam volna és Grasst, a csapat grafikusát kirúgtam volna :-) Kétségtelen, hogy fejlesztető, de kell hozzá valami megfoghatatlan érzék, ami nekem nincs meg.

Másokban sincs meg, de őket ez nem tántorítja el, hogy meghatározzák a formáját teszem azt egy weboldalnak.

Történt ugyanis, hogy elvállaltam egy weboldal elkészítését, ráadásul teljesen ingyen, mert a szegény szervezetnek nincs pénze, nekem meg számlám, amit adhatnék. Azt viszont kikötöttem, hogy a külalakot, színeket, arányokat nem fogom megmondani, ahhoz szerezzenek egy grafikust. Én ugyanis olyan vagyok, mint a Commodore 64, csak 16 színt ismerek.

Viszont különböző furmányos okok miatt nem sikerült grafikust találni. Ekkor megkérdeztem Grasst, van-e kedve beszállni a jótékonykodási akcióba. Volt neki. Már ismerem annyira, hogy tudjam, mit szeret és mit nem, ezért elmondtam a megbízóimnak, hogy ő csak azzal a feltétellel hajlandó dolgozni, ha nem szólnak bele, hogy mit hogyan csináljon: Ő a szakember. Ebbe a feltételbe bele is mentek.

Grass elkészítette a látványtervet, ami meg kell mondjam, nagyon jól sikerült. A megbízók szerint nem. Válaszul küldtek egy színmintát (5 színből), amiből Grass válogathatott kedvére.

Más grafikusok is hasonló esetekről mesélnek. Például egy játékiparban dolgozó ismerősöm mondta, hogy a főnöke neki is rendre beleszól a látványtervekbe. Olyan szinten, hogy rámutat egy elemre az összképen és kijelenti, hogy az legyen kék. Ettől felborul a színegyensúly, nem fognak harmonizálni az árnyalatok, a kép szétesik.

Tehát egy grafikusnak nem az a szerepe, hogy megtervezzen valamit, hanem gondolatolvasóként kitalálja, hogy mit akar az ügyfél. A gondolatolvasás pedig nagyon rosszul működik. Néha még akkor is, ha hangosan kimondjuk őket.

Ha pedig ennyire markáns véleménye van a megrendelőnek, miért nem csinálja meg ő? Szerintem azért nem, mert nincs halvány elképzelése sem arról, mit is akar. Még akkor sincs, ha azt mondja, hogy van. Például a cég, ahol dolgozom, kiment egy konferenciára. Vittek "white paper"-t, "pop-up wall"-t és egyéb marketing szempontból lényeges dolgokat, amiknek nincs normális magyar nevük, vagy ha van is, inkább nem használják. Ezeknek a tartalmaknak a kreatív voltát egyetlen szóval fogalmazhatom meg: Stockphoto. Innen összevásárolva lett egy csomó nagyszerű fotójuk, csak éppen az ötlet hiányzott, hogy mihez is kellene felhasználni. Végül mégsem használták a képeket, mert kiderült, hogy a többi kiállító is a kreativitás eme kútjából merít.

Lelki szemeim előtt látom is, amint egy hatalmas csarnokban megelevenedik a Stockphoto egy kulcsszavának első találati oldala.

Bizony, nehéz eldönteni, hogy mi néz ki jól. Azt kitalálni, hogy másnak mi néz ki jól, pedig még nehezebb. Egy weboldalnál pedig ez a cél. A többi embernek legyen szép. A nézőknek, hogy szívesen visszajárjanak.

Egy korábbi munkahelyemen ezért cseréltük le a weboldalt. Az első verzió olyan volt, ami nekünk, a dolgozóknak tetszett. Fekete háttér, nagy kontrasztú színekkel. Csináltunk egy rövid felmérést, mire kiderült, hogy az oldal látogatóinak bizony nem tetszett. Ezért lecseréltük szép világosra.

Korábban bemutattam, hogyan lehet egy OpenGL keretrendszert létrehozni X11 alatt. Most röviden bemutatom, hogyan használom a Framebuffert, hogy ne csak a képernyőre rajzoljak. Miért lehet szükség arra, hogy ne a képernyőre rajzoljunk, hanem a memóriába? Először is, azért, mert további műveleteket végezhetünk a memóriában tárolt képen, mielőtt a nézők szeme elé tárulna a látvány.

Az egyik ilyen művelet az élsimítás, de a deferred rendering nevű eljárás is ezen alapul. Hosszú távon nekem ez utóbbi a célom. Amint elég tapasztalatom lesz a témával kapcsolatban, arról is írok egy bejegyzést. A környezet továbbra is OpenGL 4.1

Inicializálás

Az első lépés, hogy hozzuk létre saját framebufferünket a glGenFramebuffers segítségével. Nagyon hasonló, mint amit textúránál is csinálunk. Rögtön utána kössük is magunkhoz a glBindFramebuffer segítségével. Az első paraméter általában GL_FRAMEBUFFER lesz. Akár mit is akarunk kezdeni a framebufferünkkel, egészen biztos, hogy szükségünk lesz egy mélységi pufferre. Ha ezt nem hozzuk létre, a takarásban lévő és látható pixelek összekeverednek és nagyon ronda eredményt adnak. Tehát kell egy mélységi puffer.

A glGenRenderbuffers hasonlóan működik, mint a glGenFramebuffers. Ezt is kössük (glBindRenderbuffer), majd meghatározzuk a méretét. a glRenderbufferStorage-val. Az első paraméter a két utolsó függvénynél GL_RENDERBUFFER lesz. Más nem is lehet. Mivel mélységi puffert akarunk, ezért a glRenderbufferStorage második paramétere GL_DEPTH_COMPONENT lesz.

glGenRenderbuffers(1, &rb);
glBindRenderbuffer(GL_RENDERBUFFER, rb);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, szelesseg, magassag);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, rb);

Az utolsó lépésben a frissen keletkezett pufferünket hozzárendeljük a framebufferhez. A gyakorlatban csak a második és utolsó paramétert szokták változtatni, ha esetleg más komponenshez is puffert rendelnek. Más komponenshez? Igen! Lehetőségünk van több szín, mélység és stencil pufferbe tárolni információt. A színpufferek száma implementáció függő, a GL_MAX_COLOR_ATTACHMENTS ad róla információt.

Bár minden fórumon és blogban azt olvastam, hogy ahol csak lehet, használjunk renderbuffereket, véleményem szerint a mélységi komponens kivételével (sőt, deferred shading esetén ott sem) ne használjunk renderbuffert. Mégpedig azért ne, mert az ott tárolt információt csak arra használhatjuk, hogy kitegyük a képernyőre. Márpedig egy demóban még sokat kell játszani a képpel, hogy azt ki merjük rakni a képernyőre. De akkor hogy lehet utólagos effekteket rárakni a tárolt pufferre? A renderbuffer mellett van egy másik lehetőségünk. Textúrát is köthetünk a framebufferhez! A textúra pedig könnyedén bemenete lehet egy shadernek, amivel már megbolondíthatjuk a képet. Ezért gondolom úgy, hogy nem érdemes renderbufferekkel foglalkozni.

Textúrák hozzákötése kísértetiesen hasonlít a renderbufferek kötéséhez:

glGenTextures(1, &t);
glBindTexture(GL_TEXTURE_2D, t);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, szelesseg, magassag, 0, GL_RGBA, GL_UNSGINED_BYTE, NULL);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, t, 0);

Természetesen a textúrák esetén még nagyon sok paramétert be lehet állítani, de azokat kihagytam, mert tele velük az internet. Amire itt felhívnám a figyelmet, az a GL_COLOR_ATTACHMENT0. Ez azt mondja meg, hogy a számtalan színpuffer körül mi az elsőt kötjük össze a megadott textúrával. Ennyi.

Használat

Amennyiben használni szeretnénk pufferünket, tegyük a következőt:

glUseProgram(puffershader);
glBindFramebuffer(fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...rajzoló rutinok...

Természetesen a képernyőn nagy feketeség fog megjelenni. Régen, mikor még nem voltak pufferjeink, akkor is tudtunk textúrába renderelni, majd négyszöget rajzoltunk, ami lefedte a képernyőt és ráhúztuk a textúrát. Ennek vége. (Igazából nem. Sok esetben még mindig egyszerűbb így rajzolni) A pufferünket egy lépésben (pontosabban három, ha az utasítások számát nézzük) a képernyőre rakhatjuk a glBlitFramebuffer segítségével.

glBindFramebuffer(GL_READ_FRAMEBUFFER, fb);
glBindFramebuffer(GL_WRITE_FRAMEBUFFER, 0);
glBlitFramebuffer(0, 0, szelesseg, magassag, 0, 0, szelesseg, magassag, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT, GL_LINEAR);

Mint a paraméterekből kikövetkeztethető, nem muszáj a teljes képernyőt kitölteni. Ez érdekes effekt ötleteket adhat az embernek. A 0 jelű framebuffert tartja fenn a rendszer a képernyőn megjelenő képnek. Lehet több framebufferünk is, a fenti megoldással tetszőleges két framebuffer között tudunk másolni.

Ma felhívott egy ismeretlen szám, hogy nyertem valami mobil cég és egy bank közös nyereményjátékán. Közjegyző előtt kisorsoltak és nyertem 250 ezer forintot.

- Nagyszerű - mondtam.

- Nem hallom a hangjában az örömöt.

Nem csoda, hogy nem hallotta, hiszen teljesen nyugodt voltam. Miért is kellett volna meglepődnöm ezen? Én a szerencse gyermeke vagyok. Csupa váratlan áldás szokott rám hullani. Múlt hónapban egy, az olvasók emésztésével foglalkozó lap (angol néven, hogy ne vegye el az étvágyat) nyereményjátékán nyertem, vagy legalábbis elég közel voltam a nyereményhez. Csak vissza kellett küldeni egy válaszborítékot, amiben nyerési dokumentumokat, gyorsaság bónusz kártyát és valami kaparós jegyet kellett beletenni. Ez utóbbi egy autó kódját tartalmazta, amiből teljesen véletlenül pont a sportkocsit nyertem.

A szerencse mindenhova elkísér. Egy átlagos weboldalt sem tudok úgy megtekinteni, hogy ne én legyek a 10ezredik látogató. A levelezésemben naponta átlagosan 3 nyereményről tájékoztató levél van. Annyit nyertem már, hogy a spam szűrő is nehezen bírkózik meg ezzel az áradattal.

Miért kellene meglepődnöm? Meg is mondtam neki, hogy én nagyon sokat nyertem már az interneten, ezért nem lepődök meg.

- Úgy érzem, ön szkeptikus.

Bámulatos volt a figura. Megint rátapintott a lényegre. Nem is tehettem mást, mint egyetértettem vele. Ezután letegezett, felszólított, hogy végezzek el egy jóga gyakorlatot, amiben a szám és az intim szférám is érintett volt, majd lecsapta, Úgy látszik a pénzkeresés is olyan tevékenység, amit nem csinálnak meg helyettünk. Lehet, hogy mégsem vagyok szerencsés?