git.sesse.net Git - ccbs/blob - doc/arch.txt

   1 Arkitektur\r
   2 ==========\r
   3 \r
   4 - Nettleserklienter, antageligvis Windows, hva nå folk har\r
   5 - Linux-server\r
   6   - Apache\r
   7   - PostgreSQL (overkill? galt verktøy?)\r
   8   - C++ med OpenGL, mot projektor\r
   9   - Perl (CGI.pm, Template.pom)\r
  10 - Lavhastighets Ethernet, evt. WLAN\r
  11 \r
  12 Use case\r
  13 ========\r
  14 \r
  15 1. Snute får 9983 på Max 300.\r
  16 2. draconia dytter inn i webinterfacet (i Snutes gruppe, som han\r
  17    har oppe) at Snute har valgt Max 300 som selvvalgt sang, og fikk 9983 \r
  18    på den.\r
  19 3. Webinterfacet oppdaterer PostgreSQL, og HUPer projektordæmonen. (Dette er\r
  20    ikke et bokstavelig SIGHUP, vi fikser det antageligvis med en socket der\r
  21    bare en får snakke av gangen, e.l..)\r
  22 4. Projektordæmonen kaller refresh_data() på alle subscreens.\r
  23 5. Subscreens som merker endret data, legger til et element på sin\r
  24    aktivitetsliste (hvis ting skal gjøres fancy), eller invaliderer seg\r
  25    selv totalt (hvis supersystemet skal gjøre evt. overganger). Eksempler:\r
  26 \r
  27    5.1. Subscreenen for Snutes gruppe lager en fancy effekt (evt. bare\r
  28         skriver ett og ett siffer :-) ) der scoren hans detter på plass,\r
  29         og evt. neste spiller highlightes. (Dette kan være to helt separate\r
  30         aktiviteter...) Hvorvidt denne aktiviteten skal hardkodes på noe\r
  31         vis eller om man skal ha et scenegraphsystem og f.eks. lua er ikke\r
  32         bestemt ennå, evt. kan vi bare gå for ren invalidering (se neste\r
  33         punkt).\r
  34    5.2. Subscreenen for "dagens beste scores" invaliderer seg selv, da den\r
  35         ser at top5-lista har endret seg. Supersystemet spawner den på nytt,\r
  36         pusher prioriteten på den nye opp (fordi den inneholder ny info) og\r
  37         drar den med inn i rotasjonen neste gang. (Rationale: Vi har ikke\r
  38         kapasitet til å lage fancy endringsfunksjoner for alskens rare\r
  39         situasjoner, like greit bare å lage litt fades her og der og ha et\r
  40         enhetlig system for å ordne det.)\r
  41 \r
  42    I begge tilfelle kan vi legge en rød ramme rundt (blinkende?) for å\r
  43    signalisere ny informasjon, f.eks. første gang en skjerm vises.\r
  44 6. refresh_data() returnerer en liste over alle nylig spawnede skjermer.\r
  45 7. draconia gis feedback ved at "nylig spawnede screens" (fra refresh_data)\r
  46    kommer opp på skjermen slik at han kan se hva som er skjedd.\r
  47 8. Tilbake til punkt 1, antageligvis.\r
  48 \r
  49 Typer screens i projektordæmonen\r
  50 ================================\r
  51 \r
  52 Terminalscreens:\r
  53 \r
  54 Alle terminalscreens rendrer til en tekstur (640x480? 1024x768? Trenger den\r
  55 overhodet å vite noe om det? Noe power-of-2?) slik at grenscreens kan fade\r
  56 mellom dem o.l. etter behov. (Det er ikke "terminal" som i "xterm", det er\r
  57 terminal som i "avsluttende", da en terminalskjerm ikke kan ha noen barn.)\r
  58 \r
  59 1. Gruppescreen\r
  60    - Viser spillere i gruppa, med scores og selvvalgte sanger\r
  61      (plassproblem?)\r
  62    - Viser hvem som er neste, og evt. hvor mye som skal til for å gå \r
  63      videre/vinne gruppa. (Nederst er kanskje best her, vi har ikke så \r
  64      mye å gå på i bredden.)\r
  65 2. Dagens fem beste scores. (Ren score, standardavvik.)\r
  66 3. Tidligere spilte grupper.\r
  67 4. Video-input?\r
  68 5. PG-reklame e.l.\r
  69 6. Sjekk innspill fra draconia her.\r
  70 \r
  71 Grenscreens:\r
  72 \r
  73 1. Splitscreen (rommultipleksing).\r
  74    - Alle logiske splittkonfigurasjoner (mao. MxN).\r
  75    - Statisk oppdeling, må invalideres om man skal endre konfigurasjonen?\r
  76 2. Rotasjon (tidsmultipleksing).\r
  77    - Har flere skjermer, organisert etter prioritet. Nye skjermer har mer\r
  78      prioritet, utover det går det på round-robin. Vi må passe på her så\r
  79      det blir en logisk rekkefølge av ting med lik prioritet (tidligere\r
  80      grupper burde f.eks. sorteres etter gruppenummer, dette kan vi løse\r
  81      helt OK med bare en "global prioritet" vi reverter til når vi er på\r
  82      slutten av lista og ikke har ny info som skal vises).\r
  83    - Fader mellom skjermene i et gitt tidsintervall.\r
  84    - Viser "n/N" nederst (tekst-TV følgesider).\r
  85    - Også nyttig for bare én terminalskjerm, som sørger for å fade til en\r
  86      ny skjerm når den gamle invalideres.\r
  87 3. Overlays.\r
  88    - Alle terminalscreens burde sette destination alpha riktig, ergo er det\r
  89      bare å tegne teksturene oppå hverandre i rekkefølge.\r
  90 \r
  91 Typisk tilfelle:\r
  92 \r
  93 rotation(inf,0.5)           // ytterste hovedvindu, kan ikke fjernes\r
  94   split(2,2)                // hovedvindu, 2x2\r
  95     rotation(inf,0.5)       // gruppe 3\r
  96       group(3)\r
  97     rotation(inf,0.5)       // gruppe 4\r
  98       group(4)\r
  99     rotation(inf,0.5)       // gruppe 5\r
 100       group(5)\r
 101     rotation(10,1.0)        // diverse nederst til høyre\r
 102       topscores()           // dagens beste\r
 103       group(1)              // tidligere grupper\r
 104       group(2)\r
 105       image(pglogo.png)\r
 106 \r
 107 \r
 108 Grafen her ordnes antageligvis også av webinterfacet på noe vis, som sørger\r
 109 for å splitte og ordne etter behov. Trikset her er å få i stand best mulige\r
 110 primitiver mellom Perl og C++ over socketen; her må man nok tenke mer.\r
 111 \r
 112 Beste alternativ så langt er å la en manuell operatør ta seg av rendergraphen\r
 113 i et språk lignende det over. Tanker:\r
 114 \r
 115 - Det at en node invaliderer seg selv og det spawnes en kopi (ikke veldig\r
 116   vanskelig å gjøre, antageligvis) er et spesialtilfelle. Det er omtrent\r
 117   den eneste operasjonen man trenger å gjøre automatisk som respons på input\r
 118   av scores utenfra, og det er alltid én node som fjernes og én (lik) node\r
 119   som legges til på samme sted.\r
 120 - Vi får ganske mye gratis om vi navngir alle nodene våre. Da kan vi håndtere\r
 121   endringer o.l. ganske greit; hvis en node har samme navn og samme innhold\r
 122   beholdes objektet, hvis ikke destrueres det og et evt. nytt lages. Type:\r
 123 \r
 124   group3: group(3)\r
 125   group3_rot: rotation(inf,0.5) group3\r
 126   mainsplit: split(2,2) group3,group4,group5,misc\r
 127 \r
 128 - Et system ala det over er lett å bygge ut til noe som automatisk lager\r
 129   graftreet.\r
 130 - Vi trenger ikke å løse alle verdens problemer på en gang. Det er sikkert\r
 131   veldig fancy å ha splitscreens som ekspanderer og trekker seg sammen o.l.,\r
 132   men når du får for mange parameterendringer på en gang blir det fort knot.\r
 133   Det er et reellt alternativ å lage en funksjon som sier "her har du nye\r
 134   parametre, oppdatér deg selv hvis du kan, ellers returner false og jeg lager\r
 135   en ny". rotation() kan håndtere denne situasjonen rimelig lett (oppdater\r
 136   parametre, hent inn alle nye noder, fade til neste (hva er neste?), kast\r
 137   ut alle gamle), split() vil nok ha mye mer problemer, men det er\r
 138   funksjonalitet man evt. kan legge til seinere. Dersom man faktisk lager en\r
 139   ny, må kanskje foreldrenoden få beskjed slik at den kan fade e.l. :-)\r
 140 \r