Gå til innhold

C#: Graphics, sirkler og rektangler kombinert med litt matte..


Anbefalte innlegg

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
Videoannonse
Annonse

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 av slippern
Lenke til kommentar

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 av slippern
Lenke til kommentar

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 av GeirGrusom
Lenke til kommentar
  • 2 uker senere...

var punkt = new PointF(SenterPunkt.X + Math.Cos(Roter) * Radius, SenterPunkt.Y + Math.Sin(Roter) * Radius);

 

Invalidate er dog en GDI funksjon, ikke GDI+ :ph34r: 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

var punkt = new PointF(SenterPunkt.X + Math.Cos(Roter) * Radius, SenterPunkt.Y + Math.Sin(Roter) * Radius);

 

Invalidate er dog en GDI funksjon, ikke GDI+ :ph34r: 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

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 av LonelyMan
Lenke til kommentar

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

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. :tease:

 

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. :cool:

 

EDIT: Men uansett så er det utenfor topic, trådstarter vil sikkert diskutere andre ting.

Endret av LonelyMan
Lenke til kommentar

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. :tease:

 

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. :cool:

 

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

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. :tease:

 

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. :cool:

 

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 av LonelyMan
Lenke til kommentar
  • 2 uker senere...

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 av LonelyMan
Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...