slippern Skrevet 2. desember 2011 Del Skrevet 2. desember 2011 Plages noe fælt med en innlevering... Skal lage et spill.. Har en dome/kuppel, og oppå denne skal det da gå en trekant... Så når jeg trykker på pil-venstre / pil-høyre så skal da trekanten følge domen/kuppelen. Trekanten har jeg laget vedhjelp av DrawPolygon. Så noen som har et tips? Lenke til kommentar
GeirGrusom Skrevet 2. desember 2011 Del Skrevet 2. desember 2011 Går utifra dette er snakk om System.Drawing? Lenke til kommentar
slippern Skrevet 2. desember 2011 Forfatter Del Skrevet 2. desember 2011 (endret) Går utifra dette er snakk om System.Drawing? ja Kan putte inn litt kode.. private float Roter = 0.0f; private int x_Ellipse = 150; private int y_Ellipse = 150; private double x_Cos, y_Sin; //Lager kuppelen / domen Pen MyPen = new Pen(Color.Black, 1); Rectangle ForceField = new Rectangle(x_Ellipse, y_Ellipse, 500, 500); e.Graphics.DrawEllipse(MyPen, ForceField); //Beregner x og y verdier av sirkelen x_Cos = x_Ellipse + 500 * Math.Cos(grader * (Math.PI / 180)); y_Sin = y_Ellipse + 500 * Math.Sin(grader * (Math.PI / 180)); //Lager trekanten/pistolen e.Graphics.RotateTransform(Roter); e.Graphics.DrawPolygon(Pens.Green, new Point[] { new Point (x_Cos, 150), new Point(400, 250), new Point (y_Sin, 250) }); Roter += 1.5f; if (Roter >= 360) Roter = 0.0f; Hva er egentlig radiusen på ellipsen? Er da denne trekanten/pistolen som skal følge alt etter hva brukeren trykker på(venstre/høyre)... Men på new Point, så skal den ha en int verdi, prøvde og konvertere double til int, men den likte ikke det spessielt godt. Endret 2. desember 2011 av slippern Lenke til kommentar
GeirGrusom Skrevet 2. desember 2011 Del Skrevet 2. desember 2011 Bruk KeyPress og lignende for å endre variabler som bestemmer vinkel og posisjon til objektet. Bruk Invalidate() for å tvinge GDI+ til å tegne opp kontrollen på nytt. PointF er det samme som Point bare med flyttall istedet for heltall. Lenke til kommentar
slippern Skrevet 2. desember 2011 Forfatter Del Skrevet 2. desember 2011 (endret) Scriptet kjører osv, men ingenting skjer når jeg trykker på pil venstre eller pil høyre.. og hvordan får jeg trekanten til og ligge på sirkelen? Hvor i Point klassen må jeg sette inn xcos og ycos? Og hva med gradene og radiusen i cosinus og sinus utregningen? TastaturLytter klasse, ser slik ut: public void TastaturLytter(Object sender, KeyPressEventArgs e) { //Roterer kanonen/våpnet etter bruker inndata. Keys Tast = (Keys)e.KeyChar; if (Tast == Keys.Left) { Roter += 1.5f; if(Roter >= 360) Roter = 0.0f; Invalidate(); } if (Tast == Keys.Right) { Roter -= 1.5f; if(Roter >=360) Roter = 0.0f; Invalidate(); } Endret 2. desember 2011 av slippern Lenke til kommentar
GeirGrusom Skrevet 2. desember 2011 Del Skrevet 2. desember 2011 (endret) Siden du kaller det en TastaturLytter høres det ut som du har Java bakgrunn. Heldigvis benytter ikke C# det forferdelige listener opplegget. C# baserer seg på events. Dvs. at du binder en funksjon opp mot en event. Koden din ser forsåvidt grei ut, men du må binde TastaturLytter til KeyDown event. Gjør dette på selve Formen, og sett KeyPreview til True. Dette gjør at Formen alltid vil ta imot KeyDown uavhengig av hvilken kontroll som har fokus. Du benytter både RotateTransform samt Cos og Sin. RotateTransform gjør denne Cos og Sin operasjonen for deg (hvis du gjør det riktig) Men hvis du skal gjøre det selv, så er det jo egentlig bare å huske hvordan det gjøres i mattetimen. En Point er en XY tuppel. For å få et punkt til å rotere rundt et annet punkt setter du det slik: Xut = Xa + cos(Roter) * radius Yut = Ya + sin(Roter) * radius Endret 2. desember 2011 av GeirGrusom Lenke til kommentar
slippern Skrevet 3. desember 2011 Forfatter Del Skrevet 3. desember 2011 La til denne i formen i et forsøk med og binde den i sammen slik du sa: this.KeyPreview = true; this.KeyPress += new KeyPressEventHandler(TastaturLytter); Kan du skrive et lite kode eksempel på den cos, sin funksjonen? skjønner ikke så veeeldig mye av det der... Lenke til kommentar
GeirGrusom Skrevet 3. desember 2011 Del Skrevet 3. desember 2011 (endret) var punkt = new PointF(SenterPunkt.X + Math.Cos(Roter) * Radius, SenterPunkt.Y + Math.Sin(Roter) * Radius); Endret 3. desember 2011 av GeirGrusom Lenke til kommentar
slippern Skrevet 3. desember 2011 Forfatter Del Skrevet 3. desember 2011 (endret) Men hvordan får jeg radiusen av ellipsen da? Endret 3. desember 2011 av slippern Lenke til kommentar
LostOblivion Skrevet 9. desember 2011 Del Skrevet 9. desember 2011 Den definerer du jo selv. Lenke til kommentar
LonelyMan Skrevet 22. desember 2011 Del Skrevet 22. desember 2011 var punkt = new PointF(SenterPunkt.X + Math.Cos(Roter) * Radius, SenterPunkt.Y + Math.Sin(Roter) * Radius); Invalidate er dog en GDI funksjon, ikke GDI+ den opererer på vindu device context PointF og Point er begge 32 bit variabler, det spiller ingen rolle hvilken du bruker, med mindre du koder høynivåspråk (noe jeg antar sterkt, men prøver bare å være korrekt) Math.Cos og Math.Sin kjører FSIN og FCOS separat, hvilket betyr at det kjører dobbelt så tregt som vanlig, se om du finner en FSINCOS funksjon istedet, den kjører over dobbelt så raskt. Lenke til kommentar
GeirGrusom Skrevet 22. desember 2011 Del Skrevet 22. desember 2011 var punkt = new PointF(SenterPunkt.X + Math.Cos(Roter) * Radius, SenterPunkt.Y + Math.Sin(Roter) * Radius); Invalidate er dog en GDI funksjon, ikke GDI+ den opererer på vindu device context PointF og Point er begge 32 bit variabler, det spiller ingen rolle hvilken du bruker, med mindre du koder høynivåspråk (noe jeg antar sterkt, men prøver bare å være korrekt) Math.Cos og Math.Sin kjører FSIN og FCOS separat, hvilket betyr at det kjører dobbelt så tregt som vanlig, se om du finner en FSINCOS funksjon istedet, den kjører over dobbelt så raskt. Jeg gidder ikke spekulere i om det er GDI+ eller GDI, ettersom det i utgangspunktet er ingen av delene (Det er InvalidateRect som er en USER32 funksjon, altså har det med vindu-behandling, ikke GDI32). Men System.Drawing under Windows benytter GDI+ for tegning. Jo, det spiller en rolle om du bruker Point eller PointF, ettersom den ene benytter flyttall og den andre benytter heltall. At begge er 32-bit er likegyldig. Og dette er et høynivåspråk: det er C#. Ettersom C# er sterkt typet kan du ikke blande sammen heltall og flyttall uten i det minste å få en warning når du kompilerer. .NET er plattformuavhengig, og ettersom ikke alle prosessorer har FSINCOS (dette er en x87 instruksjon) så bruker man Math.Sin og Math.Cos. Det er heller ikke noen garanti for at FSIN eller FCOS bruker på x86 prosessorer, men det gidder jeg ikke sjekke fordi det er uvesentlig. Lenke til kommentar
LonelyMan Skrevet 22. desember 2011 Del Skrevet 22. desember 2011 (endret) Jeg gidder ikke spekulere i om det er GDI+ eller GDI, ettersom det i utgangspunktet er ingen av delene (Det er InvalidateRect som er en USER32 funksjon, altså har det med vindu-behandling, ikke GDI32). Men System.Drawing under Windows benytter GDI+ for tegning. Som jeg sa, det er relatert til vinduet, og det er en gdi funksjon, den ligger i user32, stemmer, men den er en gdi funksjon og ligger under gdi kategorien på msn, ikke under gdi+. Jo, det spiller en rolle om du bruker Point eller PointF, ettersom den ene benytter flyttall og den andre benytter heltall. At begge er 32-bit er likegyldig. Og dette er et høynivåspråk: det er C#. Ettersom C# er sterkt typet kan du ikke blande sammen heltall og flyttall uten i det minste å få en warning når du kompilerer. En 32 bit variabel benytter ingenting, den er dum, død og stum. Der er rutiner i .NET som tolker den som flyttall, ingenting i hardwaren tolker den som flyttall, med unntak når en .NET rutine spesifikt laster den inn i et fpu register. .NET er plattformuavhengig, og ettersom ikke alle prosessorer har FSINCOS (dette er en x87 instruksjon) så bruker man Math.Sin og Math.Cos. Det er heller ikke noen garanti for at FSIN eller FCOS bruker på x86 prosessorer, men det gidder jeg ikke sjekke fordi det er uvesentlig. Det er mange ting det ikke fins garantier for, men i 90% av tilfellene så vil den forsøke å løse ting i hardware fremfor software, og jeg kan garantere deg at denne rutinen vil løse det i hardware i de aller fleste tilfeller, og da vil det kjøre over dobbelt så tregt. 480 sykluser vs 160 sykluser for FSINCOS. Og kjører den i en loop så vil throughputen være 260 sykluser vs 140. Og om den ikke løser det i hardware vil disse rutinene kjøre saktere likevel, det fins ikke forskjell på software algoritme vs hardware algoritme i prinsipp. Endret 22. desember 2011 av LonelyMan Lenke til kommentar
GeirGrusom Skrevet 22. desember 2011 Del Skrevet 22. desember 2011 Jeg gidder ikke spekulere i om det er GDI+ eller GDI, ettersom det i utgangspunktet er ingen av delene (Det er InvalidateRect som er en USER32 funksjon, altså har det med vindu-behandling, ikke GDI32). Men System.Drawing under Windows benytter GDI+ for tegning. Som jeg sa, det er relatert til vinduet, og det er en gdi funksjon, den ligger i user32, stemmer, men den er en gdi funksjon og ligger under gdi kategorien på msn, ikke under gdi+. Jo, det spiller en rolle om du bruker Point eller PointF, ettersom den ene benytter flyttall og den andre benytter heltall. At begge er 32-bit er likegyldig. Og dette er et høynivåspråk: det er C#. Ettersom C# er sterkt typet kan du ikke blande sammen heltall og flyttall uten i det minste å få en warning når du kompilerer. En 32 bit variabel benytter ingenting, den er dum, død og stum. Der er rutiner i .NET som tolker den som flyttall, ingenting i hardwaren tolker den som flyttall, med unntak når en .NET rutine spesifikt laster den inn i et fpu register. .NET er plattformuavhengig, og ettersom ikke alle prosessorer har FSINCOS (dette er en x87 instruksjon) så bruker man Math.Sin og Math.Cos. Det er heller ikke noen garanti for at FSIN eller FCOS bruker på x86 prosessorer, men det gidder jeg ikke sjekke fordi det er uvesentlig. Det er mange ting det ikke fins garantier for, men i 90% av tilfellene så vil den forsøke å løse ting i hardware fremfor software, og jeg kan garantere deg at denne rutinen vil løse det i hardware i de aller fleste tilfeller, og da vil det kjøre over dobbelt så tregt. 480 sykluser vs 160 sykluser for FSINCOS. Og kjører den i en loop så vil throughputen være 260 sykluser vs 140. Og om den ikke løser det i hardware vil disse rutinene kjøre saktere likevel, det fins ikke forskjell på software algoritme vs hardware algoritme i prinsipp. I motsetning til Assembly, er C# sterkt typet. Selv om hardware gir blanke i hva som ligger på hvilke minneaddresser, så gjør ikke C# kompilatoren det. Hvis en funksjon forventer å få inn 32-bit flyttall, så vil ikke C# la deg gi den funksjonen et heltall uten å først konvertere til flyttall. Du kan ikke vite om den bruker FSIN, FCOS eller FSINCOS bare ved å se på koden. Det er rene antagelser fra din side. Det kan også godt hende at Math.Sin eller Math.Cos slår opp i tabeller, eller cacher resultatet for så å benytte FSINCOS. Det kan også hende de ikke blir til funksjonskall i det hele tatt. Umulig å vite bare ved å se på koden. Det avhenger også av systemet en kjører koden på. Lenke til kommentar
LonelyMan Skrevet 22. desember 2011 Del Skrevet 22. desember 2011 (endret) Jeg kan faktisk se at den bruker FSIN og FCOS, med mindre dette er et COM prosjekt, så kan jeg faktisk se det. Det er umulig å ikke se det. Om Sin funksjonen skulle benyttet Cos eller både sin og cos, så ville prototypen til funksjonen være misvisende, og det kjøres faktisk 2 separate og ulike funksjoner med veldig tydelige navn. EDIT: Men uansett så er det utenfor topic, trådstarter vil sikkert diskutere andre ting. Endret 22. desember 2011 av LonelyMan Lenke til kommentar
GeirGrusom Skrevet 23. desember 2011 Del Skrevet 23. desember 2011 Jeg kan faktisk se at den bruker FSIN og FCOS, med mindre dette er et COM prosjekt, så kan jeg faktisk se det. Det er umulig å ikke se det. Om Sin funksjonen skulle benyttet Cos eller både sin og cos, så ville prototypen til funksjonen være misvisende, og det kjøres faktisk 2 separate og ulike funksjoner med veldig tydelige navn. EDIT: Men uansett så er det utenfor topic, trådstarter vil sikkert diskutere andre ting. Du kan se det ved å kjøre disassembly av programmet når det kjører bygget som release. Du kan ikke se det ved å se på koden alene. Lenke til kommentar
LonelyMan Skrevet 23. desember 2011 Del Skrevet 23. desember 2011 (endret) Jeg kan faktisk se at den bruker FSIN og FCOS, med mindre dette er et COM prosjekt, så kan jeg faktisk se det. Det er umulig å ikke se det. Om Sin funksjonen skulle benyttet Cos eller både sin og cos, så ville prototypen til funksjonen være misvisende, og det kjøres faktisk 2 separate og ulike funksjoner med veldig tydelige navn. EDIT: Men uansett så er det utenfor topic, trådstarter vil sikkert diskutere andre ting. Du kan se det ved å kjøre disassembly av programmet når det kjører bygget som release. Du kan ikke se det ved å se på koden alene. Jeg har ikke sagt jeg ser det på koden, men på prototypen, og jeg ser det selvfølgelig ikke med øyet, det er ingen som kan se "gjennom internett" hvordan koden måtte være spesialisert. Når jeg sier at jeg "ser" så er det med forståelsen. Jeg ser dette tydeligere enn du ser det motsatte, i stor sannsynlighet. Endret 23. desember 2011 av LonelyMan Lenke til kommentar
GeirGrusom Skrevet 23. desember 2011 Del Skrevet 23. desember 2011 Du har egentlig bare vist at du har null forståelse for hvordan .net fungerer. Og du gjør antagelser om mine kunnskaper, og om hvordan .net sin virtuelle maskin jobber. Lenke til kommentar
LonelyMan Skrevet 5. januar 2012 Del Skrevet 5. januar 2012 (endret) Det har lite med .net å gjøre. .net er bare en arkitektur, det jeg mente med at jeg ser det bedre enn deg, er faktisk riktig. Jeg ser med ca 87% nøyaktighet at den bruker FPU og du ser med 13% nøyaktighet at den IKKE bruker det. Håper du ser bedre nå hva jeg forsøker å si til deg. Jeg SER, med STØRRE sannsynlighet at jeg har riktig og du tar feil. Dette er ikke antakelser om dine kunnskaper, det er en matematisk kjensgjerning. Jeg VET at du med 13% sannsynlighet kan få rett, og jeg vet at jeg har 87% sannsynlighet for å ha rett, så når jeg sier at jeg med stor sannsynlighet har rett, så er det riktig av meg å si. Endret 5. januar 2012 av LonelyMan Lenke til kommentar
GeirGrusom Skrevet 5. januar 2012 Del Skrevet 5. januar 2012 Det kommer fullstendig an på prosessoren du kjører på. Under x86-32 kan det godt hende den bruker fsin og fcos. Under ARM gjør den åpenbart ikke det. Det ser ut til at under x64 at den benytter en software implementasjon med SSE2 instruksjonssett (fra MSVCRT). Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå