Som man kan se så er vi igang med at kigge på quadbuilder men har ikke noget i sving lige nu :-)
fredag, september 28, 2007
I skal da ikke snydes for et screenshot
Jamen I skal da ikke snydes for at screenshot....
Som man kan se så er vi igang med at kigge på quadbuilder men har ikke noget i sving lige nu :-)
Som man kan se så er vi igang med at kigge på quadbuilder men har ikke noget i sving lige nu :-)
Sjov detalje
Det virker også fint med at have vilkårlig mange SceneNode's efter hinanden. Så strukturen
Men underligt nok kan man ikke lave det samme med bare GeometryNodes .... man kan undre sig!!
+---------+
| SceneN |
+---------+
^
|
|
+---------+
| SceneN |
+---------+
^
|
|
+---------+
| SceneN |
+---------+
^
/ \
/ \
+------+ +------+
| GeoN | | GeoN |
+------+ +------+
Men underligt nok kan man ikke lave det samme med bare GeometryNodes .... man kan undre sig!!
Ting man ikke skal gøre med scene grafen
Vi er igang med både QuadNode og BSPNode og eftersom vi skulle have noget at teste vores QuadNodes på så skulle den nye Sahara level loades. Men så var det at tingene gik hen og blev underlige. Til en forelæsning havde vi hørt at man godt kunne have en GeometryNode som havde GeometryNodes som børn og få tegnet det hele. Virker meget lige til .... men prøv bare og din verden ser anderledes ud..
Vi fik oprettet en GeometryNode root og satte 2 GeometryNode's under med henholdsvis skybox og ground fra sahara modellen. Med stor spænding kiggede vi og opdagede at der ikke skete noget :-/ Skærmen blev ved med at være sort og ingen grafik viste sig.
Denne fejl er ikke den fedeste at vise screenshots af så det lader jeg være med. Men jeg tog problemet over til OE folkene og de kunne så konstatere at det skulle den sq ikke gøre... men hvorfor den gjorde sådan kunne de ikke svare på. Så hvis du ønsker at have 2 GeometryNodes over hinanden i din scenegraf så vær klar på mærkelig opførsel!
The way to do it... som I nok allesammen vidste er
+--------------+
| SceneNode |
+--------------+
^
/ \
/ \
/ \
+------+ +------+
| GeoN | | TraN |
+------+ +------+
^
/ \
/ \
/ \
+------+ +------+
| GeoN | | GeoN |
+------+ +------+
Så hav altid en SceneNode i toppen og lad være med at have GeometryNodes lige efter hinanden :) Ellers renderer det ikke ordentligt.
Nå, men tilbage til QuadTreeBuilder.....
Vi fik oprettet en GeometryNode root og satte 2 GeometryNode's under med henholdsvis skybox og ground fra sahara modellen. Med stor spænding kiggede vi og opdagede at der ikke skete noget :-/ Skærmen blev ved med at være sort og ingen grafik viste sig.
Denne fejl er ikke den fedeste at vise screenshots af så det lader jeg være med. Men jeg tog problemet over til OE folkene og de kunne så konstatere at det skulle den sq ikke gøre... men hvorfor den gjorde sådan kunne de ikke svare på. Så hvis du ønsker at have 2 GeometryNodes over hinanden i din scenegraf så vær klar på mærkelig opførsel!
The way to do it... som I nok allesammen vidste er
+--------------+
| SceneNode |
+--------------+
^
/ \
/ \
/ \
+------+ +------+
| GeoN | | TraN |
+------+ +------+
^
/ \
/ \
/ \
+------+ +------+
| GeoN | | GeoN |
+------+ +------+
Så hav altid en SceneNode i toppen og lad være med at have GeometryNodes lige efter hinanden :) Ellers renderer det ikke ordentligt.
Nå, men tilbage til QuadTreeBuilder.....
onsdag, september 26, 2007
Scene representation og DirectX
For at state men nogle reflectioner på OE frameworket så er der tænkt over rigtig mange ting, men nogle gange er dokumentationen ikke præcis omkring hvor noget kan bruges. Et eksempel kunne være en node->GetTransformationMatrix().ToArray(blah) her står der ikke noget om at dette array som leveres tilbage har strukturen som kan bruges til noget i forhold til OpenGL, men det er noget som man selv skal gætte. Sådan er der flere små steder hvor dokumentationen kunne bruge en lidt skarpere formulering.
Selve scene repræsentationen er meget generel og kan derfor let udvides. Det virker meget som om at der er tænkt over hvordan dette hænger sammen.
Selve den måde at man gennemløber scenegrafen og brugen af visitor er igen generel og derfor let at forstå, men igen så er der nogle performance issues med alle de forskellige metoder der skal kaldes.
Hvis man skal se OE i forhold til DirectX og bruge det i stedet for OpenGL vil der være en række ændringer man skulle tage. Jeg vil ikke gå i detaljer med hvor men bare give et overordnet billed af hvor sådanne ændringer skulle laves.
Dette viser at det ikke bare er i vores kode, men i hele frameworket som skal udvides. Men det er bestemt ikke umuligt, da OpenGL kode er isoleret til en del af frameworket og ikke spredt ud over det hele.
Vi har ikke implementeret follow cameraet, da vi havde meget at gøre med bare at lave de shaders og forstå hvordan sådanne skulle udvikles.
Selve scene repræsentationen er meget generel og kan derfor let udvides. Det virker meget som om at der er tænkt over hvordan dette hænger sammen.
Selve den måde at man gennemløber scenegrafen og brugen af visitor er igen generel og derfor let at forstå, men igen så er der nogle performance issues med alle de forskellige metoder der skal kaldes.
Hvis man skal se OE i forhold til DirectX og bruge det i stedet for OpenGL vil der være en række ændringer man skulle tage. Jeg vil ikke gå i detaljer med hvor men bare give et overordnet billed af hvor sådanne ændringer skulle laves.
- Vi bruger GLSL men skulle i stedet bruge HLSL så der skulle skrive en HLSL plugin til at loade shaders
- I vores RenderView klasse bruger vi OpenGL kald til at tegne face's på screen, dette skal laves om til DirectX kald.
- I OE frameworket under Renderer::OpenGL skal der laves en tilsvarende Renderer til DirectX
Dette viser at det ikke bare er i vores kode, men i hele frameworket som skal udvides. Men det er bestemt ikke umuligt, da OpenGL kode er isoleret til en del af frameworket og ikke spredt ud over det hele.
Vi har ikke implementeret follow cameraet, da vi havde meget at gøre med bare at lave de shaders og forstå hvordan sådanne skulle udvikles.
Parallax og Oily Shaders
I denne uge skulle der udvikles 2 shaders. Nedenfor ses der nogle screenshots af vores implementation af de forskellige shaders.
Her ses parallax shaderen på RockWallBumpMapped modellen. Denne parallax er bygget over bumpmap coden og ændret i forhold til den tegning fra slides omkring hvordan de korrekte punkt findes i forhold til eyeVec.
Vores oily shader eller også kendt som thinfilm shader til at give en olie films agtig overflade.
Udviklingen af shaders er meget vanskeligt som begynder i game development. Der er nogle detaljer omkring at ting bliver compilet væk hvis de ikke bruges, dette kan give nogle underlige fejl. Der er også meget svært .. til tider at gennemskue fejl i shader kode. Det kunne være en ide at til en anden gang give 1 lidt mere gennemskuelig opgave og så en opgave som thinfilm eller parallax!
Her ses parallax shaderen på RockWallBumpMapped modellen. Denne parallax er bygget over bumpmap coden og ændret i forhold til den tegning fra slides omkring hvordan de korrekte punkt findes i forhold til eyeVec.
Vores oily shader eller også kendt som thinfilm shader til at give en olie films agtig overflade.
Udviklingen af shaders er meget vanskeligt som begynder i game development. Der er nogle detaljer omkring at ting bliver compilet væk hvis de ikke bruges, dette kan give nogle underlige fejl. Der er også meget svært .. til tider at gennemskue fejl i shader kode. Det kunne være en ide at til en anden gang give 1 lidt mere gennemskuelig opgave og så en opgave som thinfilm eller parallax!
fredag, september 21, 2007
Shaders, mouselook, transforms og bugs
Så!
Nu fik vi langt om længe implementeret et (billigt) mouselook. Vi har udviddet Structen i IMouse klassen så der i mousemovedeventarg er kommet dx og dy på (efter kyndig vejledning fra Ian), og når denne løsning på et tidspunkt bliver officielt implementeret skulle det være meget let at patche vores kode. Er vi blevet lovet.
Det betyder at vores kamerahandler nu bliver kaldt med et mousemovedeventarg i stedet for ijkl til at rottere om kameraets akser. Det betyder også at vi ikke rotterer i chunks mere, men direkte anvender den afstand musen flytter sig, og det bør give et kønnere resultat, og vi kan også dreje på flere akser samtidig.
Vi prøvede at lave muse-centrering vha. SDL efter hvert movedevent blev sendt til kamera handleren, men det gik ikke så godt - Værdierne bliver forvrænget, "tilsyneladende" rammer vi den state i SDL som bliver brugt til at opbevare den præcise museplacering fra sidste cycle. Den bliver anvendt til at beregne næste cycles relative muse-bevægelser, og når den så bliver flyttet midt i at de relative bevægelser er ved at blive optaget, så sker der noget uventet (og grimt). Hvornår det er sikkert at kalde mouse-wrap funktionen så det ikke får side-effekter kan vi ikke umiddelbart overskue, så vi har droppet centreringen til en start og i stedet skal man holde venstre museknap inde for at kamerahandleren reagerer på de mouse-events den får tilsendt.
Vi har også lagt planer for hvordan et "rigtigt" fps-style kamera kan implementeres. Kameraets evne til automatisk at lave translates og rotations til een transformationsmatrix vil her være rigtig god, idet der bare skal opbevares en lille smule state i kameraet for at den horizontale og vertikale rotation kan foretages som det sker i for eksempel half life.
Det var mouselook - det næste er, at vi har fået vores kode til at virke sammen med den udleverede. Sådan da. Vores texturekode er ikke så køn som vi gerne ville ha, og den er vidst ikke engang aktiv lige pt. Til gengæld virker shaders nu.
Og vi har lavet en implementation af transformationnode; Den tager imod transformationsmatrixen som ligger i noden og omskriver den til en matrix som opengl kan forstå, og så bliver den applied (de andre på holdet må lige kommentere hvis det ikke er helt korrekt formuleret).
Nu fik vi langt om længe implementeret et (billigt) mouselook. Vi har udviddet Structen i IMouse klassen så der i mousemovedeventarg er kommet dx og dy på (efter kyndig vejledning fra Ian), og når denne løsning på et tidspunkt bliver officielt implementeret skulle det være meget let at patche vores kode. Er vi blevet lovet.
Det betyder at vores kamerahandler nu bliver kaldt med et mousemovedeventarg i stedet for ijkl til at rottere om kameraets akser. Det betyder også at vi ikke rotterer i chunks mere, men direkte anvender den afstand musen flytter sig, og det bør give et kønnere resultat, og vi kan også dreje på flere akser samtidig.
Vi prøvede at lave muse-centrering vha. SDL efter hvert movedevent blev sendt til kamera handleren, men det gik ikke så godt - Værdierne bliver forvrænget, "tilsyneladende" rammer vi den state i SDL som bliver brugt til at opbevare den præcise museplacering fra sidste cycle. Den bliver anvendt til at beregne næste cycles relative muse-bevægelser, og når den så bliver flyttet midt i at de relative bevægelser er ved at blive optaget, så sker der noget uventet (og grimt). Hvornår det er sikkert at kalde mouse-wrap funktionen så det ikke får side-effekter kan vi ikke umiddelbart overskue, så vi har droppet centreringen til en start og i stedet skal man holde venstre museknap inde for at kamerahandleren reagerer på de mouse-events den får tilsendt.
Vi har også lagt planer for hvordan et "rigtigt" fps-style kamera kan implementeres. Kameraets evne til automatisk at lave translates og rotations til een transformationsmatrix vil her være rigtig god, idet der bare skal opbevares en lille smule state i kameraet for at den horizontale og vertikale rotation kan foretages som det sker i for eksempel half life.
Det var mouselook - det næste er, at vi har fået vores kode til at virke sammen med den udleverede. Sådan da. Vores texturekode er ikke så køn som vi gerne ville ha, og den er vidst ikke engang aktiv lige pt. Til gengæld virker shaders nu.
Og vi har lavet en implementation af transformationnode; Den tager imod transformationsmatrixen som ligger i noden og omskriver den til en matrix som opengl kan forstå, og så bliver den applied (de andre på holdet må lige kommentere hvis det ikke er helt korrekt formuleret).
tirsdag, september 18, 2007
Enable key repeat
Når man nu bliver træt af at trykke hver gang man vil flytte på kameraet kan man jo enable keyboard repeat. Dette er gjort via
SDL_EnableKeyRepeat(int delay, int interval);
En finte er nu at det event som bliver sendt en en KeyDown og derfor skal man huske at lytte på KeyDownEvent køen.
SDL_EnableKeyRepeat(int delay, int interval);
En finte er nu at det event som bliver sendt en en KeyDown og derfor skal man huske at lytte på KeyDownEvent køen.
FutureTank up and running
Efter at vi i sidste uge fik gjort vores OBJ loader færdig (troede vi) kunne vi i denne uge konstatere at vi ikke lyttede efter usemtl og derved ikke fangede hvornår vi skulle bruge en given material resource. Dette blev tilføjet og som hurtigt til at virke.
Det var relativt simpelt så at få tegnet vores loadede model uden textures. Dette var bare for at komme igang og derved få testet at vi havde fat i den rigtige ende.
Derefter tilføjede vi texture mapping hvilket gik relativt smertefrit hvis man tænker bort fra en cut'n'paste fejl der vagte lidt undren ;-)
Vi har i gruppen fået arrangeret os med to darcs repos her på uni, som vi kan tjekke ind og ud af og derfor holde folk i gruppen up-to-date.
Det var relativt simpelt så at få tegnet vores loadede model uden textures. Dette var bare for at komme igang og derved få testet at vi havde fat i den rigtige ende.
Derefter tilføjede vi texture mapping hvilket gik relativt smertefrit hvis man tænker bort fra en cut'n'paste fejl der vagte lidt undren ;-)
Vi har i gruppen fået arrangeret os med to darcs repos her på uni, som vi kan tjekke ind og ud af og derfor holde folk i gruppen up-to-date.
lørdag, september 15, 2007
Fix i SDLInput og bedre OBJ loader
Efter at have fået nogle tips på mail listen omkring SDLInput og have tænkt lidt selv, blev vi enige om at have en mouse state inde i SDLInput og update den hver gang der kom et MouseMoved event, dette gør så at GetState() giver den korrekte mouse state hver gang!
Samtidig med dette blev der også lavet nogle små updates af koden!
Den anden store bedrift er at have en fungerende OBJ loader (eller det mener vi at vi har). Vi har brugt boost::algorithm::string::trim og boost::algorithm::string::split til at kunne klippe lidt i tekst strenge. Vi synes allesammen at gøre det ved hjælp af sscanf var en smule for ikke intuitivt så derfor ville vi gå efter en måde at klippe os frem til det.
Når man læser en OBJ fil, får det hele ud på at lave en Face ud fra nogle vertices, texture coordinates og nogle normals. Som det kan ses nedenfor har vi brugt nogle indbyggede klasser i OE for at gøre dette lettere.
Ved at bruge boost::algorithm::string::split og trim er det ikke sværere at klippe en tekst i stykker end at skrive.
Det var lettere i test of debug fasen at bruge en mindre OBJ fil som ind-put til loaderen. Der kunne måske godt have været udleveret en simpel model som en Cube beskrevet med de dele af OBJ formatet som vi skulle læse. Derved have vi noget simpelt som stadig skulle have det hele i sving.
Samtidig med dette blev der også lavet nogle små updates af koden!
Den anden store bedrift er at have en fungerende OBJ loader (eller det mener vi at vi har). Vi har brugt boost::algorithm::string::trim og boost::algorithm::string::split til at kunne klippe lidt i tekst strenge. Vi synes allesammen at gøre det ved hjælp af sscanf var en smule for ikke intuitivt så derfor ville vi gå efter en måde at klippe os frem til det.
Når man læser en OBJ fil, får det hele ud på at lave en Face ud fra nogle vertices, texture coordinates og nogle normals. Som det kan ses nedenfor har vi brugt nogle indbyggede klasser i OE for at gøre dette lettere.
vector< Vector<3,float> > vertices;
vector< Vector<3,float> > texture_coords;
vector< Vector<3,float> > normals;
Ved at bruge boost::algorithm::string::split og trim er det ikke sværere at klippe en tekst i stykker end at skrive.
in->getline(buf,255);
string str(buf);
vector<string> tokens;
// remove whitespaces from string
trim(str);
// populate tokens with the bits from str seperated by " "
split(tokens, str, is_any_of(" "));
Det var lettere i test of debug fasen at bruge en mindre OBJ fil som ind-put til loaderen. Der kunne måske godt have været udleveret en simpel model som en Cube beskrevet med de dele af OBJ formatet som vi skulle læse. Derved have vi noget simpelt som stadig skulle have det hele i sving.
torsdag, september 13, 2007
3dObjekter og fillæsning
I dag sad vi og nørklede med .obj formatet.
*.obj filer er, kort fortalt, filer som indeholder geometrisk data, enkodet med karakterer. Vi fik en container til geometriske faces stillet til rådighed, og ligeledes en container til containerne, som så, inden for openengine, kan opbevare store geometriske figurer svarende til dem som er i .obj filerne.
Vores hovedpine gik så på at skrive kode som kan iterere igennem en vilkårlig .obj fil, opdele indholdet i små bidder og fylde hver bid i "face" containere, og så derefter fylde disse containere i "faces-list" containere.
Efter at have sat fillæsnings delen op så den indlæste filen i tokens arbejdede vi med tolkninger af de tokens, som alle var strings, og fik opstillet en algoritme som fortolker dem fornuftigt, og indlæser dem i vektorer, og derefter løbende skal overføre indholdet af vektorerne til face objektor.
Det var sådan ca. her vi sluttede, med en dejlig masse fejl vi skal ha rettet næste gang vi kigger på det, men vi er fortrøstningsfulde og mener vi har den rette tilgangsvinkel.
Af andre nyheder kan vi støtte det seneste forslag mht. mousemotion der er kommet op på mailinglisten - der er, som vi ser det, ingen grund til at vores listener klasse selv sidder og roder med et mouse-motion-event når den alligevel modtager et godt event fra SDL - lad den sende eventet videre som det er, direkte ud til handlerne. Idet openengine ikke har noget overordnet specifikt formål, men derimod må forventes at blive anvendt til en række forskellige ting vil det, efter vores mening, være oplagt ikke at skære ting fra på den måde.
Det er rart med en listener som oversætter events så de giver mening i vores kontekst, men at reducere størrelsen af event arg'et virker ikke udpræget som noget vi har brug for.
Endelig er der ingen kode som vil gå i stykker hvis den strukt mouse-motion-event-arg benytte bliver udviddet så den er mage til det arg der kommer fra sdl.
Vi lavede gerne selv udviddelsen, men vi tør ikke give os i kast med så relativt stor en ændring i en motor som trods alt stadig er os relativt ukendt, en ændring som ikke nødvendigvis ville være kompatibel med fremtidige patches... og vi håber derfor at denne ændring vil blive foretaget fra kursusarrangørenes side.
Det må være det for denne gang - et af vores gruppemedlemmer har oplevet en del tekniske...issues, men de virker til at være udbedret nu, og de er veldokumenterede på mailinglisten så dem vil jeg ikke nævne her.
Over and out
*.obj filer er, kort fortalt, filer som indeholder geometrisk data, enkodet med karakterer. Vi fik en container til geometriske faces stillet til rådighed, og ligeledes en container til containerne, som så, inden for openengine, kan opbevare store geometriske figurer svarende til dem som er i .obj filerne.
Vores hovedpine gik så på at skrive kode som kan iterere igennem en vilkårlig .obj fil, opdele indholdet i små bidder og fylde hver bid i "face" containere, og så derefter fylde disse containere i "faces-list" containere.
Efter at have sat fillæsnings delen op så den indlæste filen i tokens arbejdede vi med tolkninger af de tokens, som alle var strings, og fik opstillet en algoritme som fortolker dem fornuftigt, og indlæser dem i vektorer, og derefter løbende skal overføre indholdet af vektorerne til face objektor.
Det var sådan ca. her vi sluttede, med en dejlig masse fejl vi skal ha rettet næste gang vi kigger på det, men vi er fortrøstningsfulde og mener vi har den rette tilgangsvinkel.
Af andre nyheder kan vi støtte det seneste forslag mht. mousemotion der er kommet op på mailinglisten - der er, som vi ser det, ingen grund til at vores listener klasse selv sidder og roder med et mouse-motion-event når den alligevel modtager et godt event fra SDL - lad den sende eventet videre som det er, direkte ud til handlerne. Idet openengine ikke har noget overordnet specifikt formål, men derimod må forventes at blive anvendt til en række forskellige ting vil det, efter vores mening, være oplagt ikke at skære ting fra på den måde.
Det er rart med en listener som oversætter events så de giver mening i vores kontekst, men at reducere størrelsen af event arg'et virker ikke udpræget som noget vi har brug for.
Endelig er der ingen kode som vil gå i stykker hvis den strukt mouse-motion-event-arg benytte bliver udviddet så den er mage til det arg der kommer fra sdl.
Vi lavede gerne selv udviddelsen, men vi tør ikke give os i kast med så relativt stor en ændring i en motor som trods alt stadig er os relativt ukendt, en ændring som ikke nødvendigvis ville være kompatibel med fremtidige patches... og vi håber derfor at denne ændring vil blive foretaget fra kursusarrangørenes side.
Det må være det for denne gang - et af vores gruppemedlemmer har oplevet en del tekniske...issues, men de virker til at være udbedret nu, og de er veldokumenterede på mailinglisten så dem vil jeg ikke nævne her.
Over and out
onsdag, september 12, 2007
Sidste minuts rettelser... ;-)
Det er ikke så meget en rettelse men mere en tilføjelse til hvad der allerede er skrevet. Jesper sagde at vi skulle skrive hvad for en platform og IDE vi har valgt at bruge!!
Sagt på den korte måde har vi valgt at bruge daimi's linux maskiner og derved linux som platform. Der var ikke nogen af os der havde en mac og windows er ikke noget man udvikler på .. hehe ;-)
Som IDE var valget ikke svært nu vi var på en linux platform, det blev til Emacs ;-)
Nu da vi bruger emacs og openengine bruger doxygen til dokumentation, kan det anbefales at man installer doxymacs som stort hjælp til at lave og highlighte doxygen kommentare i koden. Andre gode extensions til emacs er ido.el, cua.el og color-theme.el. De 2 første ligger som standard i emacs 22.1.
Sagt på den korte måde har vi valgt at bruge daimi's linux maskiner og derved linux som platform. Der var ikke nogen af os der havde en mac og windows er ikke noget man udvikler på .. hehe ;-)
Som IDE var valget ikke svært nu vi var på en linux platform, det blev til Emacs ;-)
Nu da vi bruger emacs og openengine bruger doxygen til dokumentation, kan det anbefales at man installer doxymacs som stort hjælp til at lave og highlighte doxygen kommentare i koden. Andre gode extensions til emacs er ido.el, cua.el og color-theme.el. De 2 første ligger som standard i emacs 22.1.
tirsdag, september 11, 2007
Uge 1 - Brug af SDL til keyboard og Mouse input
Første uge er ved at være slut og der skal laves status på denne uges arbejde. Eftersom gruppen medlemmer har meget at se til kom vi også lidt sent igang med opgaverne, men ikke destro mindre fik vi da gennemført hvad der skullle laves i denne uge.
Målet for denne uge:
Det at implementere interfacet fra IMouse og Ikeyboard gik rimeligt smertefrit, dog har vi stadig ikke helt fundet ud af metoden GetMouseState som skal returnere en MouseState. Vi har ikke helt kunne blive enige i gruppen om hvordan den skal laves og eftersom der ikke var nogen metoder der testede den havde vi ikke nogen mulighed for at se hvad der blev forventet af os :-)
Det at kunne styre kameraet fra vores keyboard eller mus skulle ikke være så slemt. Dog var der efter vores mening nogle begrænsninger i den måde OpenEngine var designet på som ville gøre det unødvendigt besværligt at implementere kamera rotation vha af MouseMotion.
Vores MouseMovedEventArg indeholder x, y, buttons. Der forventes af den test som blev leveret med at x og y var de nye x og y koordinater som musen er flyttet til. Men eftesom at SDL event.motion kan give et x,y som er der hvor musen er og et xrel og yrel som er bevægelsen fra dette x,y er dette en mere finkortet information som ikke kan videregives i vores MouseMovedEventArg men kun x+xrel, y+yrel ...
Derfor valgte vi at lave 2 handlers til vores kamera, en HandleTranslate og HandleRotate som begge styres fra keyboardet. Vi ville dog meget gerne at handlerotate kunne styres af musen, men så skulle handleren selv holde styr på hvor den lige har været og så regne et delta x og deltay ud ... i stedet for at gå det fra sdl eventet!!!
Som konklusion kan det siges at vores mål for denne uge blev løst og vi ser frem til næste uge.
Målet for denne uge:
- Vi skulle blive bekendt med opbygnignen af OpenEngine
- Implementere IKeyboard og IMouse interfacet i vores SDLInput klasse
- Lave handlers så vores kamera kan styres rundt i vores 3D verden
Det at implementere interfacet fra IMouse og Ikeyboard gik rimeligt smertefrit, dog har vi stadig ikke helt fundet ud af metoden GetMouseState som skal returnere en MouseState. Vi har ikke helt kunne blive enige i gruppen om hvordan den skal laves og eftersom der ikke var nogen metoder der testede den havde vi ikke nogen mulighed for at se hvad der blev forventet af os :-)
Det at kunne styre kameraet fra vores keyboard eller mus skulle ikke være så slemt. Dog var der efter vores mening nogle begrænsninger i den måde OpenEngine var designet på som ville gøre det unødvendigt besværligt at implementere kamera rotation vha af MouseMotion.
Vores MouseMovedEventArg indeholder x, y, buttons. Der forventes af den test som blev leveret med at x og y var de nye x og y koordinater som musen er flyttet til. Men eftesom at SDL event.motion kan give et x,y som er der hvor musen er og et xrel og yrel som er bevægelsen fra dette x,y er dette en mere finkortet information som ikke kan videregives i vores MouseMovedEventArg men kun x+xrel, y+yrel ...
Derfor valgte vi at lave 2 handlers til vores kamera, en HandleTranslate og HandleRotate som begge styres fra keyboardet. Vi ville dog meget gerne at handlerotate kunne styres af musen, men så skulle handleren selv holde styr på hvor den lige har været og så regne et delta x og deltay ud ... i stedet for at gå det fra sdl eventet!!!
Som konklusion kan det siges at vores mål for denne uge blev løst og vi ser frem til næste uge.
Gruppe nr 1 ... weeeee
Denne blog er lavet i forbindelse med Computer Game Development kurset i efteråret 2007 på datalogi ved Århus universitet. Gruppen består af
Jakob Balle Christensen aka. pfaff
Mads Olesen
Kasper Vesth
Anders Bach Nielsen aka. abachn
Så snart vi lige får fundet nogle billeder kommer de på bloggen. Indtil da kan der kigges på vores blogger profiler da er der nemlig billeder :) af nogle af os. Gruppen er sat og vi skal igang med arbejdet......
Jakob Balle Christensen aka. pfaff
Mads Olesen
Kasper Vesth
Anders Bach Nielsen aka. abachn
Så snart vi lige får fundet nogle billeder kommer de på bloggen. Indtil da kan der kigges på vores blogger profiler da er der nemlig billeder :) af nogle af os. Gruppen er sat og vi skal igang med arbejdet......
Abonner på:
Opslag (Atom)
