Hem Dokumentationen Gruppen Bilder

Abstract

The Hoppolek Application Suite (HOLAS) is a part of the Hoppolek project, led by Ylva Dalén at the Karolinska Institute of Medicine in Stockholm, Sweden. Ylva is the principal of the HOLAS project and the inventor of a machine named Hoppolek (trans. “jump and play”), which gives physically challenged children the ability to move and play and at the same time counteracts skeletal fragility and normalizes muscle density. The HOLAS project's main goal is to create a series of entertainment applications adapted for young children and to interface with the Hoppolek machine. The sense of these applications is to give the users a form of mental stimulation in conjunction with use of the Hoppolek machine.


Innehåll

Inledning
Projektbeskrivning
Användarhandledning
Systembeskrivning
Utvärdering


Inledning

Bakgrund

Hoppolek Application Suite, HOLAS, är en del av ett större projekt, Hoppolek, lett av Ylva Dalén vid KI Starthus i Stockholm. Ylva är uppdragsgivare för projektet HOLAS och har uppfunnit en maskin, kallad Hoppolek, som ger gravt funktionshindrade barn möjlighet att röra sig och leka samtidigt som den motverkar benskörhet och hjälper till att normalisera muskeltonus. Maskinen har möjlighet att vibrera, rotera och höjas och sänkas. Barnen, som inte själva kan stå, står i maskinen med hjälp av ett så kallat ståskal.

Maskinen går att köra fristående eller kopplad till en dator. Vid fristående körning styrs maskinen via en kontrollpanel i form av ett antal stora knappar i glada färger som barnen lätt kan nå. Varje knapps funktion kan stängas av individuellt om man vill att ett visst barn inte skall kunna utföra en viss funktion. Ett tidigare projekt, vid namn Tjoho, har resulterat i ett kommunikationsprotokoll mellan dator och maskin, en simulator för att kunna prova maskinens rörelser och respons utan att behöva koppla in den, samt en datorapplikation.

Kommunikationsprotokollet, kallat Tjoho CRM, utgör grunden för HOLAS kommunikation med maskinen Hoppolek.

Sammanfattning

Projektet HOLAS handlar om att utveckla applikationer som kan användas av de funktionshindrade barnen tillsammans med Hoppolek. Applikationerna skall utnyttja så många funktioner som möjligt hos maskinen, samt naturligtvis vara roliga för barnen att använda, så att de kommer till användning i praktiken. Hela projektet utförs som en del av kursen ”Programutvecklingsprojekt med mjukvarukonstruktion” vid Kungliga Tekniska Högskolan, KTH, i Stockholm.


Projektbeskrivning

Problemställning

Problemet som vi har ställts inför har varit att skapa applikationer som är roliga att använda för gravt funktionshindrade barn, samtidigt som de utnyttjar alla de olika rörelser maskinen Hoppolek har. En problemaspekt är att barnen har väldigt olika nivåer av både synförmåga, förståelse och motorik. Våra applikationer bör därför innehålla olika svårighetsgrader för användning. Minst en applikation skall bygga på musik, då många av barnen tycker att musik är roligt. Applikationerna skall dels kunna vara händelsebaserade, dvs att det händer nya saker om barnet trycker på en knapp på Hoppolek (men inte annars), dels skall man kunna ställa in att saker händer utan knapptryck. Dessutom skall de vara fria från tävlingsmoment, dvs att programmet inte går ut på att försöka åstadkomma något, utan bara används som underhållning för barnen.

De rörelser som Hoppolek kan utföra är:

• Rotation i horisontalplanet, i en viss fart
• H öjning och sänkning, i en viss fart
• Vibration med olika frekvenser
• Kombinationer av ovanstående

Användare

Våra användare är inte en person i taget, utan flera. Dels har vi barnet som rent praktiskt använder produkten, dels så bör man ta förälder och ansvarig personal i beaktande eftersom de också kommer att vara med när Hoppolek används. De barn som slutprodukten riktar sig till är gravt fysiskt funktionshindrade barn i åldrarna 4-12 år. Barnen kommer att stå i Hoppolekmaskinen med hjälp av ett så kallat ståskal. De skall trycka på knapparna och då skall applikationerna generera rörelser som stimulerar deras ben och muskler.

Barnens fysiska funktionshinder har ställt särskilda krav på vår programvara, eftersom buggarkan få oönskade effekter. Vi har heller inte fått skriva program som innehåller alltför svåra moment. Viktigt är naturligtvis också att programmen är roliga, eftersom barnen inte kommer att använda dem om de inte är det. De användare vi haft kontakt med är personal på Reimers specialförskola, där Hoppolek används för tillfället, och Ylva Dalén. De har kunnat berätta dels vad olika barn tycker är roligt, dels om idéer för applikationerna.


Datormiljö och programvara

HOLAS är skrivet för att fungera på en dator som kör någon variant av operativsystemet Windows och som har programvaran Tjoho installerad. Till datorns s.k. serieport kopplas Hoppolek via en kabel. För att applikationerna skall utnyttjas till fullo är det tänkt att datorns skärm placeras framför barnet som står i Hoppolek. Som programvaruutvecklingsmiljö har använts ett flertal olika datorer, främst projektmedlemmarnas egna hem- och bärbara datorer. Datorerna har kört olika versioner av operativsystemen UNIX, Windows och Linux.

Huvuddelen av kodningen har skett i programspråket C++, med små inslag av C. För versionshantering har CVS, Concurrent Versioning System, använts. För att nyttja detta har de flesta använt sig av CVSklientprogrammet TortoiseCVS.


Funktioner i programvaran

Den programvara vi har utvecklat består av två applikationer. Den ena anpassar sig till takten i musik. Saker på skärmen rör sig i takt till musiken. Det handlar främst om former och färger. När man trycker på knappar så ändras rörelsemönster och färger i bilden. Samtidigt ändras Hoppoleks rörelsemönster, som hela tiden är anpassat till bilden. Den andra applikationen visar en bil som kör på en väg och när man trycker på knappar så dyker saker upp bl.a. längs med vägens kant, och Hoppolek rör sig på lämpligt sätt relaterat till bilden. Båda applikationerna har inställningar för olika svårighetsgrader. För mer detaljerad beskrivning av programvarans innehåll, användning och gränssnitt, se användarhandledningen.

Användargränssnittet

Hoppolek är en motoriserad plattform, som kan röra sig uppåt, nedåt, rotera åt vänster och höger, samt vibrera. Nederst har den en tung och stabil botten, i vilken motorerna som styr rörelserna sitter. Hela maskinen står på hjul, så att den förhållandevis lätt går att förflytta. Från bottenplattan står en stång upp, på vilken en plattform på cirka 30×50 cm är fäst. Det är här barnet står. Under plattformen sitter två cylinderformade vibratorer.

Framför sig har barnet en panel med nio stora knappar i olika former och färger. På baksidan av panelen sitter små omkopplare, med vilka man kan stänga av funktionen för enstaka knappar, eller alla knappar på en gång. Detta kan vara användbart, exempelvis om det är ett barn som man vet inte tycker om att åka upp och ned, och att det då inte händer något när barnet trycker på någon av de knapparna.

Maskinen kan köras i fristående läge, eller kopplas till en dator. I fristående läge används knapparna till att styra plattformen direkt. Två av knapparna var tänkta att ha funktioner som inte finns i den här prototypen, men som troligtvis kommer i en senare modell.

Då Hoppolek kopplas till en dator, innebär istället varje knapptryckning att en signal skickas till datorn, och där är det det program som körs för tillfället som bestämmer vilka rörelser som utförs. Dessa styrs i regel indirekt av knapptryckningar på Hoppolek. De två knappar som i fristående läge sköter vibrationsfrekvensen (1 och 2) genererar inga signaler till datorn, varför man endast har sju tillgängliga signaler. På datorns tangentbord kan man använda sig av siffertangenterna 3-9 för att åstadkomma samma signaler till programmen som motsvarande knappar på Hoppolek gör.

För att koppla Hoppolek till en dator behövs en seriellkabel, vars ena ände sätts i datorn och andra änden i sidan på Hoppoleks bottenplatta. Ovanför kontakten sitter två omkopplare med vardera två lägen, ”data” och ”manuell”. Den ena omkopplaren sköter om signaler in till Hoppolek från datorn, dvs om den skall styras av datorn eller inte, och den andra sköter utsignaler, dvs om signaler från knapparna skall skickas till datorn eller inte. I de allra flesta fall används Hoppolek på ett sådant sätt att bägge omkopplarna skall stå i samma läge.

Referenser

Ylva Dalén, KI Starthus
Initiativtagare till projektet och uppdragsgivare
070-574 20 28

Anders Andersson
Utvecklare av basprogramvaran till Hoppolek
anders.andersson@gotlandica.se

Åsa Nygren
Arbetsterapeut på Reimers specialförskola
Kontaktperson vid studiebesök på förskolan
08-720 19 16


Användarhandledning

Välkomna till Hoppolek Application Suite, HOLAS. Det här är användarhandledningen till de två applikationer som skrevs våren 2004 som programvara åt maskinen Hoppolek. I detta paket finns två applikationer, ”Studs studs” och ”Brum brum”. Dessa är skrivna för barn i åldrarna 4-12 år som har ett eller flera funktionshinder. Båda applikationerna har funktionalitet för att kunna underhålla barn med eventuella synskador genom starka färger och kontraster, men även möjlighet för att stänga av potentiellt störande effekter och rörelser.

Inloggning

När man väljer att starta en applikation (ett spel) som skall köras med Hoppoleken möts man först av inloggningsrutan. Via inloggningsdialogen kan man logga in en användare, skapa ny användare, ändra i en användares uppgifter och ta bort en användare. Här väljer man även vilken seriellport som Hoppoleken är kopplad till.

Inloggningen fyller två funktioner:
1. Göra det enklare att hålla reda på barnens favoritinställningar.
2. Föra logg över vilka vibrationsfrekvenser barnen använt sig av. Denna logg används sedan iforskningssyfte när man undersöker hur pass mycket barnens bentäthet har ökat.

När man valt användare och seriellport så loggas användaren in mot CRM:en och spelet startas. För att försvåra att man loggar fel händelser till fel användare kan man inte använda sig av systemet utan att en aktiv användare har valts.

När man skapar en ny användare, skriver man in användarens namn, hemkatalog (där loggfilen sparas) och svårighetsgrad som användaren vill ligga på. När man klickar på Skapa så registreras användaren i CRM:en och uppgifterna sparas. Man tar bort en användare genom att välja den användare man vill ta bort och klicka på Ta Bort.

”Studs studs” – musikspel

Inställningar

När Studs studs startas kommer en inställningsruta upp, där man kan göra olika inställningar för spelet och maskinen. Det första man skall göra är att klicka på knappen ”Hämta inställningar”. Då hämtas de tidigare använda inställningarna för spelet. När man hämtat inställningarna ser man status för de olika funktionerna, ifall de är aktiva (”På”) eller inaktiva (”Av”). Vill man ändra någon av inställningarna klickar man bara på knappen och den uppdateras då för att visa ny status. Vissa knappar är beroende av varandra och är den ena aktiverad är den andra automatiskt inaktiverad.

När man vill välja vilken musik som skall användas i spelet väljer man först om man vill spela musik från en CD eller om man vill spela musikfiler som finns på datorn. Väljer man att spela musikfiler från datorn kan man genom att klicka på knappen välja vilken katalog filerna ligger i. Förslagsvis har man i så fall skapat en katalog för användaren med dess favoritmusik och man väljer då denna.

De inställningar som kan göras i Studs studs är för själva spelet:

Blinkningar – man kan stänga av blinkningar som förekommer i spelet om användaren av någon orsak är känslig för dessa.
Tidsbaserat spel – om denna är aktiv slutar händelserna av sig själva efter en viss tid och om denna är aktiv samtidigt som Interaktion är inaktiv startas även händelser efter en viss tid.
Knappbaserat spel – olika knappar, de olika knapparna startar olika händelser och samma knapp startar hela tiden samma händelse.
Knappbaserat spel – samma knappar, alla knappar startar slumpvisa händelser, dvs ingen specifik knapp startar en specifik händelse.
Interaktion – om knapparna måste tryckas ned för att händelser skall startas eller om de skall startas ändå.

Inställningarna som kan göras för själva maskinen:

Vibrationer, rotation och förflyttelse upp och ned kan var och en separat stängas av för den användare som inte gillar den specifika funktionen. Om man vill avbryta programmet och stänga rutan klickar man på ”AVBRYT”-knappen. Annars är det bara att klicka på "Starta spelet". Det sista man skall göra innan användaren börjar spela är att trycka, i takt till musiken, ca 10 slag på mellanslagstangenten på tangentbordet till datorn. Detta för att ställa in takten i programmet. Denna inställning kan när som helst under spelets gång korrigeras, t.ex. då en ny låt börjar spelas och då på samma sätt, genom att trycka på mellanslagstangenten i takt till musiken.


Funktioner

De funktioner som finns i Studs studs är i stort uppdelat i två delar: de händelser som syns på skärmen och de som rörelser som maskinen gör. Skärmen blinkar, om blinkningar inte är avstängda, i takt till musiken och om en knapp trycks ned kommer det fram studsande bollar i färgglada färger, självklart studsar dessa i takt till musiken. Beroende på vilken händelse som aktiveras kommer det olika många bollar och de studsar och beter sig på olika sätt. Vilken knapp som aktiverar vilka bollar är det bara att pröva sig fram till på maskinen.

De rörelser maskinen gör är så bra som möjligt anpassade till musiken. Hoppolek rör sig upp och ned och åt sidorna i mönster och dessutom vibrerar den till och från. Allt för att få ut det mesta möjliga av att leka till musik. De olika händelserna går även att starta från tangentbordet med hjälp av siffertangenterna 1-9.

"Brum brum” – bilspel

Inställningar

När man startar Brum brum kan man på liknande sätt som för Studs studs göra en del inställningar. Det man kan ställa in är om spelet skall vara tidsbaserat, dvs att olika händelser inträffar slumpmässigt, eller om det skall vara knappbaserat. Väljer man knappbaserat spel finns det två möjligheter, antingen startar alla knappar på Hoppoleken en slumpmässig händelse som är oberoende av vilken knapp som tryckts ner eller så har alla knappar varsin specifik funktion. Man ställer in musik på samma sätt som i Studs studs.

Funktioner

Brum brum går ut på att man ser en bil i profil som rör sig i ett landskap. Olika händelser inträffar och de utlöses olika beroende som sagt på vilken typ av spel det är. De knappbaserade spelen går även att styra med tangentbordet förutom att trycka på Hoppolekens knappar. Varje händelse på skärmen ger upphov till en liknande rörelse hos Hoppoleken. Det kommer även att passera lite föremål i bakgrunden - kor, fåglar och träd. Tabellen nedan visar vad respektive knapp ger upphov till.

Knapp Händelse Tangentbord Förklaring
3
Tuta
3
Bilen tutar.
4
Ramp
4
Bilen accelererar och åker upp för en ramp och flyger genom luften för att slutligen landa på en ramp. Hoppoleken roterar åt höger och vibrerar sedan under hoppet för att sedan rotera tillbaka till mitten.
5
Acceleration
5
Bilen accelererar upp på bakhjulen en stund för att sedan återgå till vanlig körning. Hoppoleken roterar åt höger för att sedan rotera tillbaka till mitten.
6
Stopp
6
Bilen stöter på en stoppskylt och måste stanna. Sedan återgår bilen till att åka som vanligt. Hoppoleken rör sig åt höger under inbromsningen och rör sig sedan åt vänster när bilen
accelererar.
7
Grusväg
1
Bilen stöter på en grusväg och börjar skaka. Hoppoleken aktiverar sin vibrationsfunktion.
8
Kulle
8
Bilen åker upp för en kulle och sedan ner igen. Hoppoleken rör sig upp och ner på motsvarande sätt.
9
Smågupp
2
Bilen stöter på några smågupp och åker upp och ner medan man hör hur underredet
skrapar emot marken. Hoppoleken rör sig upp och sedan ner igen.

 


Systembeskrivning

Abstraktionslager

För att göra applikationerna så portabla som möjligt, så att det ska gå att flytta dem mellan olika plattformar, såsom Windows, MacOS och Unix, så har vi byggt dem ovanpå ett abstraktionslager. Detta består av tre moduler för styrning av grafik, ljud respektive Hoppolek-hårdvaran. Nedan följer en kort beskrivning av dessa moduler.

GAPI - Graphics

Grafik-API:t underlättar grafikhanteringen för applikationerna. Det använder sig av SDL (Simple DirectMedia Layer), ett funktionsbibliotek för bland annat grafik och ljud, och tillhandahåller ett gränssnitt anpassat för våra behov. SDL finns till ett stort antal operativsystem vilket främjar portabiliteten. Tack vare att GAPI:t innehåller det mesta av koden för grafikhantering så har det varit relativt enkelt att använda grafiska element i applikationerna. Det har också givit mer lättläst applikationskod.

SAPI - Sound Application Programming Interface

Sound-API:t fyller samma funktion som GAPI:t, men för ljud. Där GAPI använder SDL använder SAPI istället biblioteket FMOD.

TAPI - Tjoho Application Programming Interface

TAPI utgör en länk mellan våra applikationer och Hoppolek-maskinen, eller egentligen mellan våra applikationer och den programvara som konstruerades av Tjoho-projektet förra året. Genom TAPI kan man få information om knapptryckningar på Hoppoleken och skicka kommandon till dess motorer.

Klientbiblioteket för Hoppolek-hårdvaran

Tjoho-projektet från förra årets projektkurs konstruerade ett gränssnitt mellan Hoppolekhårdvaran och en dator. De skrev dock all sin programvara i Java, medan vi beslöt att använda C++. Dels därför, och dels därför att det klientbibliotek som Tjoho tillhandahöll inte riktigt passade våra syften, beslöt vi att implementera ett eget klientbibliotek i just C++. Biblioteket, kallat libtjoho, är en realisation av TAPI-modulen.

Libtjoho består av tre klasser. Den första, tjoho_connection, representerar en anslutning mot Tjoho-mjukvaran. När en tjoho_connection skapas försöker biblioteket ansluta till Tjoho CRM (Communication and Resource Manager) på den lokala datorn - alltså måste den vara startad. När anslutningen väl upprättats sker all kommunikation med XML-språket TjohoXML som bl.a. innehåller kommandon för att avläsa Hoppolekens knappsats samt slå på och av dess motorer.

När ett tjoho_connection-objekt skapats kan man anropa medlemsfunktioner hos det för att skapa ett tjoho_control- eller tjoho_simple_control-objekt. Dessa två klasser är styrgränssnitt för hårdvaran.Tjoho_simple_control tillhandahåller bara enkla kommandon för att starta och stoppa vissa motorer samt för att läsa av knappsatsen. Tjoho_control, som ärver tjoho_simple_control, tillhandahåller dessutom en kommandokö. Med en tjoho_control är det möjligt att köa fler instruktioner efter varandra med tidsangivelser, som t.ex. "åk höger i 200 ms, ner och vänster i 500 ms och börja sedan vibrera i 50 Hz och åk samtidigt uppåt i en sekund". Tjoho_control har också en kalibreringsfunktion som, oberoende av startposition, förflyttar Hoppolekplattformen till sitt mittläge i sid- och höjdled.

Båda våra applikationer använder genomgående tjoho_control och dess kommandokö för att styra Hoppolek-maskinen

Inloggning

Inloggningsdialogen är delvis tagen från förra årets projekt. De tillhandahöll en inloggningsdialog som var inkapslad i varje applikation de skrev. Vad vi gjorde var att extrahera den och bygga ihop en klass som startade inloggningsdialogen. Inloggningsdialogen initierar en uppkoppling mot CRM-servern och frågar vilka användare som finns registrerade. Detta gör den med att skicka XML-kommandot:

<admin command = "getusers" />.

Dessa användare visar den sedan i användarlistan. När man valt vilken användare man vill logga in, seriell port och klickat på Logga In så skickar inloggningsprogrammet ett XML-kommandot som sätter vald användare som aktiv användare. Detta görs med XML-kommandot:

<admin command = "setactiveuser" name = "~"><home dir = "~"/><difficulty level = "~" /></admin>

Varje gång en applikation startas så anropar den först vår klass som i sin tur bygger ihop inloggningsdialogen. När en användare loggat in så stängs inloggningsdialogen och applikationen startas.

Applikationerna – översikt

De båda programmen har i princip samma struktur och använder sig av många gemensamma klasser och funktioner. Kod för grafik, ljud och kommunikation är i stort gemensam, även om naturligtvis båda programmen använder sig av specialiserade klasser, främst för grafiken. I stort ser en körning av programmen ut så här. När programmet startas öppnas först en dialogruta där man kan göra inställningar. Efter det initieras alla komponenter, Hoppoleken kalibreras till att stå i mitten och ljudet från CD eller MP3 startas. Efter initieringen går programmet in i en eventloop, som den inte går ur förrän användaren avslutar programmet. Vid varje genomgång i loopen sker följande saker:

Först anropas en funktion som styr Hoppoleken. Denna funktion beskrivs i mer detalj i stycket om HAPI:t. Sedan undersöks om musiken som spelas har nått sitt slut. I så fall byter vi spår på CD:n om vi spelar musik från CD:n, eller byter MP3:a till nästa MP3-fil i MP3-katalogen. Efter det uppdateras de komponenter vi har lagt till på skärmen. Om vi till exempel vill ha studsande bollar som i Studs studs så uppdateras deras positioner här. Mer om det i stycket om GAPIt.

Sedan tar vi hand om knapptryckningar från tangentbordet och Hoppoleken. I våra program anropas samma funktion när man trycker på 1-9 på tangentbordet som när man trycker på motsvarande knapp på Hoppoleken. Sist ritar vi upp alla komponenter som vi har lagt till på skärmen.

Klasser

Viktiga grafikklasser

Nedan följer de viktigaste grafikklasserna. För en mer utförlig beskrivning av klasserna, se kommentarer i .h-filerna.

Screen

Varje program som använder sig av grafikklasserna måste ha ett objekt av typen Screen. Screen är en liten wrapperklass som håller koll på en skärm eller ett fönster. Den innehåller också en Container som ritas ut när skärmen ritas om. Viktiga funktioner i Screen är:

init:
Initierar Screenen. Här skickar man med vilken upplösning och vilket färgdjup Screenen skall ha, samt flaggor som bland annat anger om den skall vara fullskärm eller inte. Här kan man också skicka med en Container om man vill ange en viss container som grundcontainer för skärmen.

changeRes:
Ändrar upplösning och eventuellt färgdjup.

draw:
Ritar upp Screenens container. Ändringen syns inte på skärmen.

flip:
Det man ritar i draw kommer inte att synas på skärmen förrän man anropar flip, detta för att skärmen inte skall flimra om man ritar många komponenter ovanpå varandra.

Component

Component är den mest grundläggande klassen för allt som ritas på en Screen. Klasser som ärver från Component kan läggas till i en Container, och får dessutom grundläggande egenskaper såsom x- och y-position, bredd, höjd, förgrunds- och bakgrundsfärg, samt ett z-värde, som vissa Containrar använder för att sortera i vilken ordning komponenter ritas ut. Viktiga funktioner i Component är:

draw:
Ritar ut komponenten. Varje klass som ärver från Component bör troligen overrida den här funktionen. De argument som funktionen tar är en SDL_Surface som är den yta vi ritar på, ett x-och ett y-värde som är de koordinater vi skall börja rita från, samt en tid som kan användas exempelvis för animerade komponenter som skall rita olika saker beroende på tiden.

update:
Kan anropas från en container för att till exempel flytta saker som rör på sig eller dylikt. Skall man använda update anropas funktionen med fördel en gång per runda i eventloopen. update tar också emot en tid.

updateColors:
Kan anropas när man byter pixelformat. Det är långt ifrån alla komponenter som behöver göra något i den här funktionen, men vissa komponenter kan till exempel behöva uppdatera sina färger eller dylikt.

Container

En Container är en komponent som kan innehålla andra komponenter. Själva superklassen Container är abstrakt, och den enklaste underklassen är SimpleContainer. Component själv kan inte lagra några komponenter, eftersom olika underklasser kan vilja lagra komponenterna på olika sätt beroende på vad de vill göra med dem. De klasser en underklass till Container måste overrida är:

addComponent:
Lägger till en komponent till containern.

removeComponent:
Tar bort en komponent.

removeAll:
Tar bort alla komponenter.

update:
Anropar alla komponenter som ligger i containerns update-funktion.

updateColor:
Anropar alla komponenter som ligger i containerns updateColor-funktion.

Övriga grafikklasser

SimpleContainer är en subklass till Container. Den lagrar alla komponenter den har i en länkad lista, och ritar upp alla komponenter i den ordning de lades till. Font är en klass som laddar in en bild som typsnitt och sedan kan skriva strängar på en SDL-yta. Label är en komponent som kan skriva ut strängar på en Screen. Den kommer troligtvis inte användas så mycket i de färdiga programmen, men det är en bra klass att ha för debugutskrifter under utvecklingsarbetet. SpriteBase lagrar information om en sprite. En sprite är en del av en bild som vi vill kunna rita upp på skärmen. SpriteBase är inte en komponent, utan används för att lagra dels själva bilden vars innehåll vi vill kunna rita upp, dels information om vilka delar av bilden vi skall rita upp, samt informaiton om animationer och dylikt. Samma SpriteBase kan sedan användas av flera komponenter.

Klasser i Brum brum

Bil

Bil är den komponent som representerar bilen. Den lagrar i själva verket tretton olika bilder på bilen, vriden i olika vinklar. En bils position beskrivs som x-position, y-position, vinkel, samt avståndet från bilens horisontella mittaxel till bakre hjulet och avståndet från bilens horisontella mittaxel till det främre hjulet. En bil kan också ges en rad instruktioner för hur den skall bete sig en tid framåt. Det är det som händer när bilen till exempel åker över en kulle. Då lagras en kö med nyckelpositioner, och i tiden mellan två nyckelpositioner färdas bilen likformigt mellan de båda positionerna.

ScrollingBackground

ScrollingBackground är den komponent som visar en scrollande bakgrund. I applikationen finns två sådana objekt, ett för sjön i bakgrunden och ett för träden. Bakgrunden flyttas lite varje gång update anropas, och hastigheten med vilken bakgrunden rör sig kan ändras.

Road

Road är vägen. Den påminner mycket om ScrollingBackground, men innehåller en kö över vilka vägsegment som skall visas. Om det till exempel kommer ett hopp köas först en ramp, sedan ett antal vanliga vägsegment och sist en landningsramp. Dessa kommer sedan att ritas ut allteftersom vägen scrollas framåt. Man kan även här ställa in hur fort vägen skall röra sig.

Klasser i Studs studs

FadingComponent

FadingComponent är en abstrakt klass som är en komponent med de två extra funktionerna fadeIn och fadeOut. fadeIn anropas för att komponenten på något sätt skall initieras, och fadeOut anropas när man vill att komponenten skall försvinna gradvis. Den enda underklass som ärver från FadingComponent är CBouncingBalls, som vid fadeIn placerar bollarna under skärmens nederkant och sätter igång dem, och vid fadeOut låter bollarna trilla ut från skärmen.

FadingContainer

FadingContainer är en container som bara kan lagra FadingComponenter. Den fungerar som en vanlig container, men visar bara en komponent åt gången. Med funktionen next kan man anropa den aktiva komponentens fadeOut-funktion och när sedan komponenten har fadeat ut byts aktiv komponent till nästa komponent och denna komponentens fadeIn startas.

FlashingBackground

FlashingBackground är den komponent som blinkar i bakgrunden. Den har funktioner för att byta bakgrundsfärg gradvis, men sköter sig i stort sett själv.

Studs studs

Översikt

Studs studs är baserat på FMOD, som är ett API för ljudhantering under ett stort antal system, bland annat Windows. FMOD erbjuder funktionalitet för att spela upp ljud av ett flertal format och tekniker samt stöd för digital ljudhantering (DSP). Denna implementation möjliggör uppspelning av musik från följande källor:

• CD Audio
• Microsoft WAV (.wav)
• Komprimerad WAV vid närvaro av berörd ACM-codec (.wav)
• MPEG Audio Layer 2 (.mp2)
• MPEG Audio Layer 3 (.mp3)
• Ogg Vorbis (.ogg)
• Windows Media Audio File (.wma)
• Advanced Streaming Format (.asf)
• Macintosh Audio Interchange File Format (.aiff)

Ljudsystemet är baserat på ljudströmmar som knyts till filer eller spår på en CD. Den skapade strömmen spelas genom ett generellt anrop, och på detta sätt kan stöd för nya filformat enkelt läggas till genom att metoder för att skapa strömmar av andra filformat läggs till. Ljudsystemet har inte stöd för ljud som inte är strömmande, exempelvis MIDI (.mid) och Amiga Tracker Module (.mod). Detta kan dock åtgärdas genom funktioner för uppspelning som använder FMODs delbibiliotek FMUSIC som kompelement till det rådande FSOUND.

Användningen av strömmar minskar systemets minnesåtgång mot en viss ökning av använd processortid då all beräkning sker i realtid. Hanteringen av CD Audio sker med hjälp av direktåtkomst till CD-spelaren (CDDA), vilket minskar belastningen på databussen (IDE eller SCSI), men detta kan i gengäld vid vissa tillfällen orsaka problem vid uppspelning.

De viktigaste funktionerna

initSound:
Initierar rutiner för uppspelning av ljud i det gällande systemet och skapar en mjukvarumixer med 32 kanaler.

findCDLetter:
Hämtar enhetsbokstaven som pekar på systemets första CD-spelare. Detta är den enda spelare som kan användas för uppspelning av CD Audio.

initCD:
Skapar filströmmar för samtliga spår på den skiva som finns i CD-spelaren och möjliggör därmed uppspelning av CD Audio.

loadMP3:
Skapar en ström knuten till någon av de ovan nämnda strömmande filtyperna.

playEffect:
Skapar en ström av någon av de ovan nämnda strömmande filtyperna och spelar upp den omedelbart.

initDSP:
Ger åtkomst till den aktiva ljudmixern och ger möjlighet att läsa information ur denna. Returnerar pekare till 512 värden beskrivande den nuvarande energin i det uppspelade ljudet fördelat över frekvensspektret. Användbar för olika typer av visualisering.

playTrack:
Startar uppspelning av en skapad ström och anropas i programmets huvudloop. Hanterar fördröjning av start internt.

Brum brum

Sprajtar

Då Brum brum skulle visa en del föremål på skärmen valde vi att skapa ett eget filformat för sprajtar - .sob. Själva bilderna lagras som bitmappsbilder medan sob-filerna innehåller information om hur många sprajtar som finns i en viss bildfil och på vilka koordinater de börjar och hur stora de är. Vi ville även kunna lagra information om animerade sekvenser av dessa olika sprajtar så i filen lagras även information om frames, vilket är sprajtar och hur lång tid de skall visas, samt animationer, som här lagras som sekvenser av tidigare nämnda frames. Informationen lagras i sob-filen på formen:

<bitmappsbildens namn>
<antalet sprajtar i bitmappsbilden>
<antalet frames>
<antalet animationer>

<sprajtens nr>
<startkoordinat x-led>
<startkoordinat y-led>
<sprajtens bredd>
<sprajtens höjd>

<framens nr>
<nr på den sprajt man refererar till>
<tid i ms som framen skall visas>

<animationens nr>
<antalet frames i animationen>

<nr på framen som skall visas>

En .sob-fil för en bitmapsbild med två sprajtar som är 50x50 pixlar som är kopplade till varsin frame som skall visas i 100 ms och som tillsammans bildar en animationssekvens ser då ut så här:

test.bmp filnamn  
2 antalet sprajtar  
2 antalet frames  
1 antalet animationer  
0 sprajt nr 0  
0 startkoordinat x-led  
0 startkoordinat y-led  
50 bredd  
50 höjd  
1 sprajt nr 1  
0 startkoordinat x-led  
50 startkoordinat y-led  
50 bredd  
50 höjd  
0 frame nr 0  
0 refererar till sprajt nr 0  
100 ska visas i 100 ms  
1 frame nr 1  
1 refererar till sprajt nr 1  
100 ska visas i 100 ms  
0 animation nr 0  
2 består av 2 frames  
0 först visas frame 0  
1 sedan visas frame 1  

Vi skapade även en Component för sprajtarna, SpriteComponent. Denna kan tilldelas en hastighet så att sprajten rör sig över skärmen. Komponenten har även funktionalitet för att starta en av de lagrade animationerna samt att stoppa animering.

Referenser

About.com's free C++ programming tutorial
http://cplus.about.com/library/blcplustut.htm

C++ Direkt
Jan Skansholm
Studentlitteratur, Lund, 2000
ISBN 91-44-01463-5

FMOD
http://www.fmod.org – dokumentation, nedladdning m.m.

Learning XML
Erik T. Ray
O'Reilly, 2001
ISBN: 0-596-00046-4

The cplusplus.com tutorial - Complete C++ language tutorial
http://www.cplusplus.com/doc/tutorial/

The skew.org XML Tutorial
http://skew.org/xml/tutorial/


Utvärdering

Samarbetet i gruppen

Gruppen fungerade på många sätt bra. Vi var väldigt kommunikativa och det blev aldrig några större konflikter mellan gruppmedlemmarna. Vi har framför allt haft två stora problem, nämligen tidsplan och arbetsfördelning. Vi gjorde aldrig en ordentlig utvärdering eller uppskattning i början av kursen, och den vi gjorde tog inte i beaktande att alla läste olika kurser och därmed hade svårt att arbeta tillsammans. Vi hade tillräckligt svårt som det var att få hela gruppen till ett veckomöte. Vi satte ej heller några bestämda deadlines, utan åsikten var ungefär att om programmet är klart innan redovisningstillfället så kan det anses bra.

Arbetsfördelningen var nog det största problemet, och anledningar till det kommer vi till under en senare punkt. Ett par medlemmar i gruppen utförde större delen av kodningsarbetet medan resten av gruppen främst skötte mindre kodningsuppgifter, periferiarbete och småuppgifter. Kommunikationen fungerade bra och vi hade ett möte i veckan, varje vecka. Oftast skedde dessa möten på bestämd plats vid en bestämd tid, men någon enstaka gång hölls ett möte på IRC.

Rollerna i gruppen

Gruppen hade en projektledare, men enligt honom själv hade den de facto flera ledare. Anledningar till detta kan diskuteras, liksom för- och nackdelar. Gruppen innehöll ett flertal ledartyper, vissa som vid tillfälle kunde överta ledarrollen. Fördelen med detta är att gruppen aldrig saknar ledarskap, men detta vägs mot risken att man underminerar en redan osäker ledare. Gruppen hade ej heller någon självklar hierarki, trots att en rudimentär sådan bestämdes i början av kursen. Strukturen vi hade var en central gruppledare och ett antal lösa undergrupper med underansvariga.

Ett stort problem i det här fallet var just valet av C++ som programmeringsspråk, något som majoriteten av gruppen var mycket ovana vid. Detta ledde i sin tur till att vissa gruppmedlemmar kom igång mycket fortare än resten av gruppen och slutligen hade bättre koll på applikationen än sina undergruppsansvariga. Detta ledde i sin tur till att vissa aldrig egentligen kom igång med sina egentliga uppgifter eftersom de låg så pass mycket efter i utvecklingen av projektet. Ett val av Java som programmeringsspråk hade nog normaliserat kunskapsnivån, men det hade inte varit tillämpbart i det här projektet.

Mer jobb borde ha lagts ner på fördelning av arbetet och intern utbildning. Medlemmarna med bättre koll kunde t.ex. från början ha satts som gruppledare och med sin ökade kunskapsnivå verka för en rättvisare fördelning av arbetet. Just arbetsfördelningen var som nämnt det största problemet med det här projektet.

Kontakten med uppdragsgivaren

Vår uppdragsgivare verkar nöjd, men applikationen har ännu inte testats på barnen. Kommunikationen skedde genom tre möten under utvecklingsarbetet och kontakt mellan Ylva Dalén och gruppledaren. Det har alltid varit lätt att få tag i Ylva. Hon har dessutom under hela projektets gång varit mycket positivt inställd till allt som har med projektet att göra och alltid ställt upp när vi behövt hennes hjälp.

Tidsplanen

Som nämnt ovan så har tidsplanen varit dåligt sammanställd utan konkreta deadlines. Tyvärr har många i gruppen svårt att komma igång utan stress, och internt satta deadlines är ett bra sätt att skapa detta tryck. Tyvärr är det inte alla som kan hålla dessa deadlines heller. Att alla har haft olika scheman har också som nämnt försvårat samarbetet och möjligheten att hålla tidsplanen. Ett sådant här projekt vore egentligen enklast att ha på heltid under en kortare period.

Programvara

Vi använde CVS och mailinglista från SourceForge från början, vilket kom att ge en del strul. Vissa fick aldrig CVS-tjänsten att fungera och mailinglistan visade sig vara obrukbar eftersom fördröjningstiderna var för långa. Efter byte av mailinglista fungerade det dock som tänkt. De flesta jobbade i Microsoft Visual Studio, som visade sig ha en inlärningströskel, men en snabbt
överkommen sådan. De klassbibliotek vi brukade (SDL och FMOD) fungerade alldeles utmärkt.

Utrustning

All utrustning har fungerat enligt önskemål, förutom att Hoppoleken saknade viss funktionalitet som skulle ha varit specificerad.

Vad vi har lärt oss

Förutom rena kodkunskaper vittnar gruppen om att vi har lärt oss mer om hur vi fungerar, både som individer och som medlemmar i en grupp. Många har fått en del goda tankeställare om hur det här projektet hade fungerat om det hade varit skarpt. Som alltid underskattar man värdet av att sätta tidiga deadlines och att utföra planeringsarbete innan man kommer igång. Många har nog blivit medvetna om att de antingen tar för lite eller för mycket plats i en uppgift.