Du bist nicht angemeldet.

Suchergebnisse

Suchergebnisse 1-20 von insgesamt 416.

Werbeanzeige

07.09.2014, 13:15

Forenbeitrag von: »CodingCat«

Const-correctness bei Rückgabe interner Zeiger

Zitat von »newby« Guten Tag zusammen, ich habe eine kurze Frage bezüglich const-correctness. Ich habe eine Klasse Texture die intern ein Zeiger auf eine LPDIRECT3DTEXTURE9 Resource hat. Außerdem habe ich eine Methode C-/C++-Quelltext 1 LPDIRECT3DTEXTURE9 getInterface(); die genau diesen Zeiger zurückgibt. Kann ich diese Methode als const deklarieren? Bei Aufruf dieser Methode wird der logische Status des Texture-Objekts nicht verändert, jedoch ist es mit dem zurückgegebenen Pointer sehr leicht ...

04.04.2014, 22:37

Forenbeitrag von: »CodingCat«

Getter/Setter gut oder schlecht?

Zitat von »Cookiezzz« Und was ist, wenn du erst den Wert einfach setzt und sich dann später rausstellt, dass eine Wertprüfung doch sinnvoll wäre? Dann kann man den kompletten Code umschreiben. Man sieht, damit sind wir nicht weitergekommen und diese Diskussion wird noch weitere 10 Seiten andauern. Ich denke ob man Getter/Setter jetzt verwendet ist Teil des persönlichen Stils. Beides hat Vor- und Nachteile. Ich fasse es sogar noch kürzer als Schrompf: Wenn so viel Code davon abhängt, dass das Um...

16.03.2014, 12:03

Forenbeitrag von: »CodingCat«

Kantenglättung DirectX 11

Zitat von »LukasBanana« Das mit dem "Runterskalieren" habe ich mir am Anfang auch so vorgestellt, aber ich bin mir ziemlich sicher, dass das genau so nicht funktioniert. Der ryg Blog erklärt auch solche Techniken sehr genau (aber eher theoretisch). Auf dieser Seite (im Abschnitt "Other rasterization issues and pixel output") ist auch was zum Thema Multi-Sampling erklärt ;-) Grob erklärt werden pro Pixel einfach mehr "Samples" genommen, um zu testen, ob (bzw. wie stark) ein Pixel innerhalb eines...

06.03.2014, 19:48

Forenbeitrag von: »CodingCat«

Tangent Space, Würfel Bump-Mapping

HLSL-Quelltext 1 2 3 4 5 // Was ist denn das für ein Unfug? Punkt vor Strich! ;-) vec3 normal = tangentSpace * (2) * bumpMapNormal.xyz - vec3(1); // Davon abgesehen ist es gut möglich, dass Z in der // Normalmap kein Biasing erfordert, da Normalen in // Normalmaps in der Regel immer weg von der Oberfläche zeigen Weiterhin ist es keine gute Idee, die ganze Matrix von Vertex in Fragment Shader zu verschieben, mehr als 4 interpolierte Vektoren ziehen die Performance in der Regel ordentlich in den ...

14.07.2013, 13:51

Forenbeitrag von: »CodingCat«

std::vector::push_back: Optimierungsfrage

Zitat von »CodingCat« Zitat von »dot« In keiner der beiden Varianten wird es dem Compiler aber möglich sein, das Objekt direkt im vector zu konstruieren, oder überseh ich was!? Nein, dazu bedarf es dann tatsächlich eines Konstruktors oder einer Initialisierungsliste (geht tatsächlich ab VC 2013!), jeweils mit emplace_back. In beiden Fällen ändert sich die Notation leider grundlegend, mit bedeutendem Informationsverlust. Dazu sollte man aber noch bemerken, dass sich bei ordentlicher Implementier...

14.07.2013, 13:41

Forenbeitrag von: »CodingCat«

std::vector::push_back: Optimierungsfrage

Zitat von »dot« In keiner der beiden Varianten wird es dem Compiler aber möglich sein, das Objekt direkt im vector zu konstruieren, oder überseh ich was!? Nein, dazu bedarf es dann tatsächlich eines Konstruktors oder einer Initialisierungsliste (geht tatsächlich ab VC 2013!), jeweils mit emplace_back. In beiden Fällen ändert sich die Notation leider grundlegend, mit bedeutendem Informationsverlust.

14.07.2013, 13:26

Forenbeitrag von: »CodingCat«

std::vector::push_back: Optimierungsfrage

Zur eingangs gezeigten optimierten Variante bzw. resize(): Prinzipiell haben diese beiden Varianten in Bezug auf Verhalten im Fehlerfall jeweils eine andere Bedeutung als die "unoptimierte" Variante. Ist der vector lokal und fliegt dieser somit im Fehlerfall weg, ist das egal. Übersteht der vector jedoch Fehler, hat er nach Auftreten eines solchen ggf. einen inkonsistenten Zustand: Seine Größe entspricht dann nicht mehr der Zahl gültiger/initialisierter Elemente. Eine sinnvolle und effiziente Va...

20.05.2013, 17:15

Forenbeitrag von: »CodingCat«

IDisposable: Diskussion Resource Management

Zitat von »Schorsch« Ganz ehrlich, sicherlich ist das mal interessant und auch spannend über so Zeug wie hier zu sprechen, aber ich behaupte der Alltagsprogrammierer hier wird das meiste davon nicht brauchen. Was ist denn für dich ein Alltagsprogrammierer? Derjenige, der all die supereasy Crapware für Handys, Websites, Photodruck & Co. schreibt, die bei jedem 4. Klick mit Verlust sämtlicher Daten droht und bei jedem 8. Klick mehrminütige Denkpausen einlegt? Zitat von »Schorsch« Ich behaupte wen...

20.05.2013, 13:58

Forenbeitrag von: »CodingCat«

IDisposable

Zitat von »De_Struktor« Zitat von »MSDN« Wird aufgerufen, wenn die Grafikressourcen entladen werden müssen. Setzen Sie diese Methode außer Kraft, um spielspezifische Grafikressourcen zu entladen. kann mir das einer richtig erlären: "Setzen sie diese Methode außer Kraft" Ja, das lässt sich ganz einfach erklären: Benutze NIEMALS die automatische Übersetzung der MSDN, auch wenn sie sich dir bei jeder Google-Suche aufdrängt. Rechts oben lässt sich notfalls die Sprache zurück auf EN/US umstellen: "O...

20.05.2013, 13:35

Forenbeitrag von: »CodingCat«

IDisposable

Zitat von »De_Struktor« Und wie ist das mit der "UnloadContentmethode. Sie ist doch für das Freigeben von unmanaged Ressourcen zu ständig? Wenn ich ne eigene Klasse über manuelle Speicherverwaltung schreiben muss, wieso ist die dann von Microsoft implementiert?? Wenn du den XNA ContentManager zum Laden benutzt, dann reicht es natürlich, dessen Unload()-Methode zum richtigen Zeitpunkt aufzurufen. Der ContentManager setzt ja genau das für dich um, was ich oben als Manager-Klasse beschrieben habe.

20.05.2013, 13:00

Forenbeitrag von: »CodingCat«

IDisposable: Diskussion Resource Management

Zitat von »De_Struktor« Im Bezug auf BC's Aussage, der ja sagt, er würde keine Spielerklasse mit, indem Fall Texture2D, ausstatten. Dot wiederum behauptet, es ist sehr wohl disposable, was trifft nun denn zu?? Ich habe 4 Klassen, die nach Dot's Aussage, alle IDisposable implementieren müssten, aufgrund von kontrollierter Speicherentsorgung. [...] Was ich dazu sagen muss, scherzhafterweise, das mit so langsam die Speicherverwaltung komplexer vorkommt als die in C++. Mein Bruder, sagte, er persön...

20.05.2013, 11:44

Forenbeitrag von: »CodingCat«

IDisposable: Diskussion Resource Management

Zitat von »Legend« Für C# könnte ich mir einen Lösungsansatz vorstellen, der eigentlich sehr leicht für Microsoft zu implementieren scheint, aber leider nicht umgesetzt ist: Man könnte bestimmt viel machen, wenn structs einen Finalizer haben könnten. Dieser sollte sofort aufgerufen werden, wenn die Variable von Typ der Struct den Scope verlässt. Leider gibt es das nicht. Ja, das wäre eine deterministische Lösung analog zu C++. Zitat von »Legend« Ganz so schlimm wie du sehe ich die Situation mit...

20.05.2013, 11:03

Forenbeitrag von: »CodingCat«

IDisposable: Diskussion Resource Management

Kurzer Nachtrag: Ich habe mich gerade erinnert, dass ich in Java schonmal gezwungenermaßen PhantomReferences nutzen musste, um die Unerreichbarkeit von memory-mapped Files zu prüfen (die in ihrer Standardimplementierung offenbar auch nur halbherzigen Gebrauch vom Speicher-GC Gebrauch machen, sehr unangenehm). Damit ist die Erreichbarkeitsinformation tatsächlich verfügbar, beliebige Referenzen (-> Unmanaged Resources) lassen sich an eine Queue binden, die so lange blockiert, bis die jeweiligen Ob...

20.05.2013, 00:48

Forenbeitrag von: »CodingCat«

IDisposable: Diskussion Resource Management

Ich will den ursprünglichen Thread nicht zu sehr aus der Bahn werfen, deshalb sammle und kommentiere ich hier parallel. Ich lade jeden ein, hier mit über den Tellerrand zu schauen. Nachfragen und Mitmachen ausdrücklich erlaubt. Ressourcenverwaltung in "modernen" Sprachen wie C# und Java Zitat von »De_Struktor« ja, dann muss Player aber IDisposable implementieren, denn sonst kann ich die Methode knicken Zitat von »dot« Willkommen in der wunderbaren Welt der Garbage Collection, wo jegliches Ressou...

17.05.2013, 19:23

Forenbeitrag von: »CodingCat«

[Devlog] 2D Beleuchtung

So ganz optimal sind die aber alle noch nicht; gerade in den hellen Bereichen ist eine merkwürdige Blockbildung erkennbar. Sieht so aus als hättest du noch ein Präzisionsproblem beim Blur o.ä.

17.05.2013, 16:11

Forenbeitrag von: »CodingCat«

[Devlog] 2D Beleuchtung

Ganz genau. Es kommt natürlich auch immer etwas auf das Nutzsignal an; wenn da viele glatte Oberflächen zu sehen sind, stört das Rauschen wesentlich mehr als auf strukturierten/texturierten Oberflächen. Mit 1/100 hatte ich allerdings eventuell ein wenig zu hoch gegriffen, 1/200 reicht vermutlich vollkommen. Krishtys verlinkte Noise-Funktion liefert außerdem Werte im Bereich [-1,1], weswegen man wohl mit 1/400 auskommen kann. Um die Gesamthelligkeit des Bildes nicht zu verändern, ist es im Übrige...

16.05.2013, 23:35

Forenbeitrag von: »CodingCat«

[Devlog] 2D Beleuchtung

Dithering! Krishty ist unser Held. Das als kleinen Zufallsfehler (z.B. 1/100) addieren, Seed mit der aktuellen Framenummer füllen und das Wunder genießen. Und immer weiter, bis auch die Miesmuscheln nicht mehr an sich halten können, weil ihnen der Tanzfaden abgeht!

08.04.2013, 21:20

Forenbeitrag von: »CodingCat«

vector.erase() <-> delete

Zitat von »TGGC« Zitat von »CodingCat« [ Andere Implementierungen schrumpfen ab und zu, nämlich immer wenn ein gewisser Grenzwert an unbenutztem Speicherplatz überschritten wird. Kennst du da konkrete Implementierungen? Soweit ich weiss sagt der Standard, das nie geschrumpft wird. Da hast du tatsächlich Recht, der Standard verbietet bei std::vector::erase() praktisch jegliche Reallokation (konkret dürfen Iteratoren und Referenzen vor dem gelöschten Element nicht invalidiert werden; da mir keine...

08.04.2013, 19:16

Forenbeitrag von: »CodingCat«

vector.erase() <-> delete

Zitat von »Sk!p« [...] Greift man über den Array-Operator überhaupt noch auf dieses Element zu? Wieso ist das dann noch im Vektor? Oder manipuliert man per erase() nur Iterator-Zugriffe? Nur um das nochmal klar rauszustellen: Der Code ist absolut idiotisch, das hast du korrekt erkannt. Nach dem erase() ist das Element nicht mehr im Vektor, das was da deletet wird, ist irgendetwas unsinniges oder existiert nicht und führt direkt zum Crash. Zitat von »Sk!p« Findet nach dem erase() nicht ne Reallo...

24.02.2013, 11:36

Forenbeitrag von: »CodingCat«

for-Schleife Aktionsteil sinnlos?

Zitat von »m3xx« Mh anscheinend hat es ja doch Vorteile, den Zähler im Aktionsteil zu inkrementieren zu lassen, statt im Codeblock :o Dann werde ich es wohl auch im Aktionsteil weiter belassen. Was heißt hier anscheinend? Auf jeden Fall! Public Service Summary: Zitat von »BlueCobold« Zudem, ob man es nun zugeben will oder nicht, vergisst man gern das Inkrement/Dekrement, wenn man es nicht oben rein schreibt. Beim Öffnen der Schleife denkt man noch: "Ah joar, den Counter zähle ich weiter unten d...

Werbeanzeige