+Arkitektur\r
+==========\r
+\r
+- Nettleserklienter, antageligvis Windows, hva nå folk har\r
+- Linux-server\r
+ - Apache\r
+ - PostgreSQL (overkill? galt verktøy?)\r
+ - C++ med OpenGL, mot projektor\r
+ - Perl (CGI.pm, Template.pom)\r
+- Lavhastighets Ethernet, evt. WLAN\r
+\r
+Use case\r
+========\r
+\r
+1. Snute får 9983 på Max 300.\r
+2. draconia dytter inn i webinterfacet (i Snutes gruppe, som han\r
+ har oppe) at Snute har valgt Max 300 som selvvalgt sang, og fikk 9983 \r
+ på den.\r
+3. Webinterfacet oppdaterer PostgreSQL, og HUPer projektordæmonen. (Dette er\r
+ ikke et bokstavelig SIGHUP, vi fikser det antageligvis med en socket der\r
+ bare en får snakke av gangen, e.l..)\r
+4. Projektordæmonen kaller refresh_data() på alle subscreens.\r
+5. Subscreens som merker endret data, legger til et element på sin\r
+ aktivitetsliste (hvis ting skal gjøres fancy), eller invaliderer seg\r
+ selv totalt (hvis supersystemet skal gjøre evt. overganger). Eksempler:\r
+\r
+ 5.1. Subscreenen for Snutes gruppe lager en fancy effekt (evt. bare\r
+ skriver ett og ett siffer :-) ) der scoren hans detter på plass,\r
+ og evt. neste spiller highlightes. (Dette kan være to helt separate\r
+ aktiviteter...) Hvorvidt denne aktiviteten skal hardkodes på noe\r
+ vis eller om man skal ha et scenegraphsystem og f.eks. lua er ikke\r
+ bestemt ennå, evt. kan vi bare gå for ren invalidering (se neste\r
+ punkt).\r
+ 5.2. Subscreenen for "dagens beste scores" invaliderer seg selv, da den\r
+ ser at top5-lista har endret seg. Supersystemet spawner den på nytt,\r
+ pusher prioriteten på den nye opp (fordi den inneholder ny info) og\r
+ drar den med inn i rotasjonen neste gang. (Rationale: Vi har ikke\r
+ kapasitet til å lage fancy endringsfunksjoner for alskens rare\r
+ situasjoner, like greit bare å lage litt fades her og der og ha et\r
+ enhetlig system for å ordne det.)\r
+\r
+ I begge tilfelle kan vi legge en rød ramme rundt (blinkende?) for å\r
+ signalisere ny informasjon, f.eks. første gang en skjerm vises.\r
+6. refresh_data() returnerer en liste over alle nylig spawnede skjermer.\r
+7. draconia gis feedback ved at "nylig spawnede screens" (fra refresh_data)\r
+ kommer opp på skjermen slik at han kan se hva som er skjedd.\r
+8. Tilbake til punkt 1, antageligvis.\r
+\r
+Typer screens i projektordæmonen\r
+================================\r
+\r
+Terminalscreens:\r
+\r
+Alle terminalscreens rendrer til en tekstur (640x480? 1024x768? Trenger den\r
+overhodet å vite noe om det? Noe power-of-2?) slik at grenscreens kan fade\r
+mellom dem o.l. etter behov. (Det er ikke "terminal" som i "xterm", det er\r
+terminal som i "avsluttende", da en terminalskjerm ikke kan ha noen barn.)\r
+\r
+1. Gruppescreen\r
+ - Viser spillere i gruppa, med scores og selvvalgte sanger\r
+ (plassproblem?)\r
+ - Viser hvem som er neste, og evt. hvor mye som skal til for å gå \r
+ videre/vinne gruppa. (Nederst er kanskje best her, vi har ikke så \r
+ mye å gå på i bredden.)\r
+2. Dagens fem beste scores. (Ren score, standardavvik.)\r
+3. Tidligere spilte grupper.\r
+4. Video-input?\r
+5. PG-reklame e.l.\r
+6. Sjekk innspill fra draconia her.\r
+\r
+Grenscreens:\r
+\r
+1. Splitscreen (rommultipleksing).\r
+ - Alle logiske splittkonfigurasjoner (mao. MxN).\r
+ - Statisk oppdeling, må invalideres om man skal endre konfigurasjonen?\r
+2. Rotasjon (tidsmultipleksing).\r
+ - Har flere skjermer, organisert etter prioritet. Nye skjermer har mer\r
+ prioritet, utover det går det på round-robin. Vi må passe på her så\r
+ det blir en logisk rekkefølge av ting med lik prioritet (tidligere\r
+ grupper burde f.eks. sorteres etter gruppenummer, dette kan vi løse\r
+ helt OK med bare en "global prioritet" vi reverter til når vi er på\r
+ slutten av lista og ikke har ny info som skal vises).\r
+ - Fader mellom skjermene i et gitt tidsintervall.\r
+ - Viser "n/N" nederst (tekst-TV følgesider).\r
+ - Også nyttig for bare én terminalskjerm, som sørger for å fade til en\r
+ ny skjerm når den gamle invalideres.\r
+3. Overlays.\r
+ - Alle terminalscreens burde sette destination alpha riktig, ergo er det\r
+ bare å tegne teksturene oppå hverandre i rekkefølge.\r
+\r
+Typisk tilfelle:\r
+\r
+rotation(inf,0.5) // ytterste hovedvindu, kan ikke fjernes\r
+ split(2,2) // hovedvindu, 2x2\r
+ rotation(inf,0.5) // gruppe 3\r
+ group(3)\r
+ rotation(inf,0.5) // gruppe 4\r
+ group(4)\r
+ rotation(inf,0.5) // gruppe 5\r
+ group(5)\r
+ rotation(10,1.0) // diverse nederst til høyre\r
+ topscores() // dagens beste\r
+ group(1) // tidligere grupper\r
+ group(2)\r
+ image(pglogo.png)\r
+\r
+\r
+Grafen her ordnes antageligvis også av webinterfacet på noe vis, som sørger\r
+for å splitte og ordne etter behov. Trikset her er å få i stand best mulige\r
+primitiver mellom Perl og C++ over socketen; her må man nok tenke mer.\r
+\r
+Beste alternativ så langt er å la en manuell operatør ta seg av rendergraphen\r
+i et språk lignende det over. Tanker:\r
+\r
+- Det at en node invaliderer seg selv og det spawnes en kopi (ikke veldig\r
+ vanskelig å gjøre, antageligvis) er et spesialtilfelle. Det er omtrent\r
+ den eneste operasjonen man trenger å gjøre automatisk som respons på input\r
+ av scores utenfra, og det er alltid én node som fjernes og én (lik) node\r
+ som legges til på samme sted.\r
+- Vi får ganske mye gratis om vi navngir alle nodene våre. Da kan vi håndtere\r
+ endringer o.l. ganske greit; hvis en node har samme navn og samme innhold\r
+ beholdes objektet, hvis ikke destrueres det og et evt. nytt lages. Type:\r
+\r
+ group3: group(3)\r
+ group3_rot: rotation(inf,0.5) group3\r
+ mainsplit: split(2,2) group3,group4,group5,misc\r
+\r
+- Et system ala det over er lett å bygge ut til noe som automatisk lager\r
+ graftreet.\r
+- Vi trenger ikke å løse alle verdens problemer på en gang. Det er sikkert\r
+ veldig fancy å ha splitscreens som ekspanderer og trekker seg sammen o.l.,\r
+ men når du får for mange parameterendringer på en gang blir det fort knot.\r
+ Det er et reellt alternativ å lage en funksjon som sier "her har du nye\r
+ parametre, oppdatér deg selv hvis du kan, ellers returner false og jeg lager\r
+ en ny". rotation() kan håndtere denne situasjonen rimelig lett (oppdater\r
+ parametre, hent inn alle nye noder, fade til neste (hva er neste?), kast\r
+ ut alle gamle), split() vil nok ha mye mer problemer, men det er\r
+ funksjonalitet man evt. kan legge til seinere. Dersom man faktisk lager en\r
+ ny, må kanskje foreldrenoden få beskjed slik at den kan fade e.l. :-)\r
+\r
projects / ccbs / commitdiff
