Natürlich geht das. Weiß nur nicht, ob das auch noch so gut funktioniert, wenn du den Laser rotierst (du gibst bei der Skalierung X- und Y-Skalierung an). Vor allen Dingen aber wollten wir eben keinen langweiligen Laser, der einfach nur aus einem Strahl besteht. Wir wollten schon ein bisschen mehr Struktur reinbringen.Zitat von R.D.
In XNA kannst du eine Textur nicht stretchen? Das glaub ich irgendwie nichtAlso wenn der Laser eine komplizierte horizontale Animation hat sondern einfach nur ein Streifen, hätte es auch ein Strech getan denke ich. Ich dachte immer RenderTargets sind einfach nur FrameBuffer.
Was ich nie auch nur ansatzweise behauptet habe.
Sei mal nicht so arrogant. Das unterstreicht nur die Vorurteile, die man ohnehin schon gegenüber Programmierern hat. Ich verstehe echt nicht, warum 95% der Programmierer so verdammt arrogant sein müssen. Bloß, weil ich mich anders ausdrücke, als du, heißt das noch lange nicht, dass ich etwas nicht verstehe. Ich programmiere nun immerhin auch schon seit gut fünf Jahren und das zwar bisher noch nicht für ein Unternehmen, aber immerhin schon in den verschiedensten Programmiersprachen, darunter sogar ASM für das SNES. Und da es im guten alten Turbo Pascal noch nicht so Datentypen wie Listen oder Vektoren gab, habe ich selbst verständlich auch schon mit selbst programmierten, dynamisch verlinkten Listen gearbeitet. Zu behaupten, ich würde Pointer nicht verstehen, ist hier also pure Arroganz, bloß weil ich anderer Ansicht bin, als du (oder denselben Standpunkt anders darstelle). Komm mal von deinem hohen Ross runter, du göttlicher Super-Programmierer!
Faktisch tatsächlich eher selten. Kann mich bisher eigentlich nur an einen Fall erinnern, wo ich mal die Kopie einer Klasse brauchte. Und da hätte ich theoretisch auch mit dem Original arbeiten können. Generell ist es eben einfach so, dass man Klassen meistens als Referenzen und andere Sachen meistens nur als Wert braucht. Das Standardverhalten ist in C# ja nicht grundlos so definiert. In 90% der Fälle ist das eben genau das, was man braucht.
Naja, ich habe da tatsächlich etwas ganz anderes gemeint, als ich gesagt habe. Was ich meinte war, dass du beispielsweise in einer Klasse nicht ohne Umwege eine Referenz auf einen Wertetyp deklarieren kannst. Also dass du beispielsweise in einer Klasse eine Eigenschaft namens intPointer hast, die auf einen int zeigt. Dafür müsstest du dann erst einen Wrapper oder so verwenden. In C++ (oder Unmanaged Code) könntest du ja einfach int* nehmen.
Ja, das ist auch nicht unbedingt das beste Beispiel. Der umgekehrte Fall, einen Wertetyp als Referenz zu verwenden, ist eh wahrscheinlicher.
Das ist doch überhaupt nicht der Punkt. Rede ich denn gegen eine Wand? Alles, was ich sage, ist dass der Unterschied zwischen Referenztypen und Wertetypen in C# einfach in 90% der Fälle für den Programmierer egal ist. Natürlich gibt es da Unterschiede, natürlich wird da mit Pointern gearbeitet, natürlich gibt es Ausnahmen. In 90% der Fälle - so war es zumindest bei mir bisher - arbeitet C# aber immer genau so, wie du es gerade erwartest bzw. brauchst. Das liegt eben auch daran, dass C# eben automatische Speicherverwaltung hat. Wenn du in C++ eine Funktion nimmst und ihr einen Pointer übergibst, musst du dir anschließend oft sagen "so, und jetzt nach der Funktion bloß nicht vergessen, den Speicher wieder freizugeben". In dieser Hinsicht unterscheiden sich in C++ Pointer stark von Wertetypen, denn Wertetypen musst du nie manuell freigeben. In C# hingegen musst du ja so gut wie nie Speicher manuell freigeben. Dadurch verschwimmen die Grenzen zwischen Referenztyp und Wertetyp in der Anwendung. Du musst dir nie erst sagen "Ach ja, das ist ja eine Referenz, also bloß nicht vergessen, den Speicher wieder freizugeben", sondern kann sie ähnlich, wie Wertetypen verwenden. Das ist doch wirklich alles, was ich damit habe sagen wollen. War das nun wirklich so schwer zu verstehen und diese ganze Diskussion wert? Mann, Mann, Mann...
Zitieren