Import doc/ from train thinking.
authorSteinar H. Gunderson <sesse@samfundet.no>
Sat, 19 Feb 2005 00:46:18 +0000 (00:46 +0000)
committerSteinar H. Gunderson <sesse@samfundet.no>
Sat, 19 Feb 2005 00:46:18 +0000 (00:46 +0000)
doc/arch.txt [new file with mode: 0644]
doc/mockup1.png [new file with mode: 0644]

diff --git a/doc/arch.txt b/doc/arch.txt
new file mode 100644 (file)
index 0000000..60b6c2a
--- /dev/null
@@ -0,0 +1,140 @@
+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
diff --git a/doc/mockup1.png b/doc/mockup1.png
new file mode 100644 (file)
index 0000000..35834a8
Binary files /dev/null and b/doc/mockup1.png differ