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