Punkte auf einem Kreis

Vertexwahn

Ich habe Probleme mit dem rotieren von Punkten - der Einfachheit halber hab ich einfach mal um die y Achse gedreht

1. Code

float a = 0;
for(int l = 0; l < 120; l++)
{
	float x = 1,
        	      y = 1,
               z = 1;

               a += 0.1f;
	      x = cos(a)*x-sin(a)*z;
	      z = sin(a)*x+cos(a)*z;

 	SetPixel(x*50+200, z*50+200, 0, 255, 0);
}

2. Code

float a = 0;
for(int k = 0; k < 12000; k++)
{
	    float x = 1,
		  y = 1,
	  z = 1;

	     	  a += 0.001f;
		  float xs = cos(a)*x-sin(a)*z;
		  float zs = sin(a)*x+cos(a)*z;

  		  SetPixel(xs*50+200, zs*50+200, 0, 255, 0);
}

Ergebnis:
http://www.fh-landshut.de/~jamann/msvc6.bmp

der zweite Code liefert mir einen schönen Kreis - der erste nicht - woran liegt das? Die beiden Codes sind ja fast identisch bis auf zusätzliche -eigentliche unnötige temporäre Variablen...

irgendwie glaube ich das es nicht an mir liegt, sondern an MsVC 6.0

Blue-Tiger

Hi!

Sag mal, muss das sein dass du ein fast 800 kb grosses BMP verlinkst? Mit einem 56k Modem tut man sich da arg hart! Es gibt wesentlich angenehmere Dateiformate! Nicht jeder hat Breitband-Internet!! *boese_dreinblick*

BTW solltest du evtl. in Erwaegung ziehen, deine Variablen AUSSERHALB der Schleife zu deklarieren, ist wesentlich effizienter.

Zur Frage: ich denk es liegt daran:

a += 0.1f;
          x = cos(a)*x-sin(a)*z;    // x bekommt neuen Wert
          z = sin(a)*x+cos(a)*z;    // neuer Wert von x wird verwendet

float xs = cos(a)*x-sin(a)*z;  // Wert von x wird nicht veraendert
          float zs = sin(a)*x+cos(a)*z;  // alter Wert von x wird verwendet

Vertexwahn

manchmal steht man halt einfach auf der Leitung... danke

0x00000001

Blue-Tiger schrieb:

BTW solltest du evtl. in Erwaegung ziehen, deine Variablen AUSSERHALB der Schleife zu deklarieren, ist wesentlich effizienter.

Bist Du Dir da sicher? Ich denke der Compiler wird das entweder automatisch so machen oder er wird gleich ein festes Register benutzen.
Davon gehe ich zumindest aus, ich deklariere meine Variablen immer im möglichst tiefsten Block.

TGGC

Debugger ist bei sowas auch nicht schlecht.

Übrigens ist das auch der Grund, warum gotos schlecht sind. Uns Gehirn denkt nicht in der gleichen schrittweisen Struktur, wie der Computer. Hier fasst es zum Beispiel beide Zeile zu einer elementaren Operation zusammen (Berechnung eines Vektors) und kann so nicht erkennen, das die erste Zeile Auswirkungen auf die zweite hat. Nur wenn ein Programm einfach von "oben nach unten" durchläuft, kann man gut erkennen, wie alle Befehle nacheinander abgearbeitet werden. Springt das Programm aber immer herum, wird dies sehr schwer.

Bye, TGGC (der sich mal wieder verquatscht hat...

Blue-Tiger

0x00000001 schrieb:

Blue-Tiger schrieb:

BTW solltest du evtl. in Erwaegung ziehen, deine Variablen AUSSERHALB der Schleife zu deklarieren, ist wesentlich effizienter.

Bist Du Dir da sicher? Ich denke der Compiler wird das entweder automatisch so machen oder er wird gleich ein festes Register benutzen.
Davon gehe ich zumindest aus, ich deklariere meine Variablen immer im möglichst tiefsten Block.

das ist mir zwar auch durch den Kopf gegangen als ich's geschrieben hab, aber sich auf Compileroptimierungen zu verlassen ist IMO nicht immer der sicherste Weg. Andrerseits seh ichs auch ein, dass Variablen so lokal wie moeglich sein sollten. Ich persoenlich waer auf Nummer Sicher gegangen und haette die Deklaration aus der Schleife rausgezogen, aber vielleicht ist das wirklich die Arbeit des Compilers.

rapso

hoffen wir einfach, dass ein guter compiler merkt dass die initialisierung an sich schon total unnötig ist, genau wie die multiplikation.

bei c sollte man variablen an einer festen stelle möglichst am anfang einer funktion deklarieren, bei c++ so lokal wie möglich.
der grund für das c verhalten sind alte compiler die damit manchmal nicht klarkommen den scope richtig zu bestimmen, deswegen geht sowas wie

for(int a=0;...)

erst garnicht.
der grund bei c++ ist, dass den speicherverbrauch minimiert wird, dabei kann es sein dass der stack optimaler benutzt wird (weil er kleiner ist eventuel besser gecached) und es hilft dem compiler weil es eventuell regiser pressure senkt ohne dass der compiler das selbst machen muss.

rapso->greets();

TGGC

Ein Profiler würde vermutlich sagen, das 80% der Zeit in SetPixel verbraucht werden... also getreu der alten Regel

Bye, TGGC

volkard

TGGC schrieb:

Übrigens ist das auch der Grund, warum gotos schlecht sind. Uns Gehirn denkt nicht in der gleichen schrittweisen Struktur, wie der Computer.

deines nicht.
lerne coden!

TGGC

Tschuldingung das ich nicht so'n Kellerkind wie andere hier bin.

Bye, TGGC

Helium

volkard schrieb:

TGGC schrieb:

Übrigens ist das auch der Grund, warum gotos schlecht sind. Uns Gehirn denkt nicht in der gleichen schrittweisen Struktur, wie der Computer.

deines nicht.
lerne coden!

Du bist also auch so einer, der lieber sich selbst an den Computer anpasst, anstatt so zu programmieren, wie man üblicherweise denkt?

Power Off

Blue-Tiger schrieb:

das ist mir zwar auch durch den Kopf gegangen als ich's geschrieben hab, aber sich auf Compileroptimierungen zu verlassen ist IMO nicht immer der sicherste Weg. Andrerseits seh ichs auch ein, dass Variablen so lokal wie moeglich sein sollten. Ich persoenlich waer auf Nummer Sicher gegangen und haette die Deklaration aus der Schleife rausgezogen, aber vielleicht ist das wirklich die Arbeit des Compilers.

Die Variablen dort zu deklarieren, wo man sie benutzt, dient vor allem der Lesbarkeit. Die Compiler, die von Otto Normalcoder benutzt werden, reservieren schon beim Funktionseintritt den Platz fuer alle automatischen Variable (d.h., die, die auf dem Stack deklariert wurden). D.h. es ist prinzipiell wurscht, wo man die Deklaration hinschreibt (natuerlich spielt es eine Rolle, was den Geltungsbereich der Variable angeht).

Bei dem winzigen Registersatz der IA-32 Architektur (von MMX und SSE mal abgesehen) wird eh meist auf Register-Aliasing verzichtet (d.h. Variablen Registern zuzordnen), da die Register eh schon zu wenig sind. Ich finde es schade, dass die Compiler auch bei aktivierter 686er-Option weder die MMX noch die SSE Register ausnutzen. Es ist ja durchaus moeglich, z.B. Integer oder Pointer in MMX-Registern zu speichern, floats und doubles in SSE / SSE2 Registern.

Da die heutigen Prozessoren anscheinend auf unoptimierten Code hin optimiert wurden (als Assembler-Programmierer kann man da nur DANKE sagen, der User freut sich), spielt das alles aber keine Rolle mehr.

D.h. als C/C++ Programmierer braucht man sich ueber das Placement von Variablen heutzutage meist keine Gedanken mehr zu machen.