Geschwindigkeit Variablen / Parametern

[Terrat]

Was ist schneller ?
Wenn ich ein das D3ddevice per parameter übergebe oder es in der jeweiligen Klasse bei einen zeiger speichern lasse und es danch in der jeweiligen funktion halt einfach auslese.

[warfley]

Beides müsste ziemlich gleich schnell sein, ob du die Parameter zu erst in den Speicherblock für funktionsparameter schiebst, und dann dort drauf zugreifst, oder ob du zu erst die Adresse ließt und dann die Daten aus der Adresse ließt, ist vergleichbarer Aufwand, generell ist es jedoch sauberer die Daten per Parameter zu übergeben.

PS Wenn du mit DX arbeitest, macht eh zu erst der PCI Bus (Grafikkarten anbindung) zu bevor der System Bus (Ram anbindung) oder gar die CPU vollständig ausgelastet ist

[Dr. Coxxy]

generell ist es jedoch sauberer die Daten per Parameter zu übergeben

citation needed.

[Terrat]

Danke schon mal, aber ich nehme sie lieber 1 mal als Parameter da ich sie ansonsten ziemlich oft übergeben müsste.
Weiß jemand wie ich eine DDS Datei Transparenz rendere ? Ps: Ich meine jetzt nicht eine Transparentz wie z.B. nur von 50% (via Blendstate) sondern eine Transparenz das der Alphachannel komplett weg ist (Like Png).

[qqdev]

Originally Posted by Dr. Coxxy

citation needed.

Dafür spricht die Wiederverwendbarkeit. Dagegen das häufige Übergeben. Würde je nach Anwendungsfall entscheiden. Hier würde ich es nicht immer übergeben.

[dowhile]

Originally Posted by qqdev

Dafür spricht die Wiederverwendbarkeit. Dagegen das häufige Übergeben. Würde je nach Anwendungsfall entscheiden. Hier würde ich es nicht immer übergeben.

Wieso ist das besser für die Wiederverwendbarkeit?

[warfley]

Für gewöhnlich versucht man Methoden so zu schreiben, sodass man sie in verschiedenen Situationen verwenden kann, dafür abstrahiert man diese am besten von allen unnötig Abhängigkeiten. Wenn ich z.b. eine such Funktion für eine Listbox schreibe, schreibe ich diese für allgemeine Listen, und gehe in der Prozedur nicht exakt auf diese listbox ein, um diese Methode auf andere Listen auch anwenden zu können

Ps Coxxy du kannst dich mir auch auf deutsch schreiben, ich habe meine Muttersprache mittlerweile recht lieb gewonnen

[snow]

Du musst halt überlegen, wie du die Relation am besten darstellen kannst. Wenn dein Sprite-Objekt unabhängig vom D3D-Kontext existieren kann, würde ich nicht unbedingt den Zeiger speichern, da du nicht wissen kannst, ob der noch gültig ist.

Gefühlt wären da evtl. smart pointer (std::weak_pointer und std::shared_ptr) nützlich, ansonsten würde ich den Zeiger keinesfalls speichern wenn das Objekt unabhängig vom Kontext, in dem der D3D Zeiger erstellt wird, existieren kann.

P.S.: Deine Klassennamen sind ziemlich bescheiden. Dafür wurden namespaces erfunden.

Wenn ich z.b. eine such Funktion für eine Listbox schreibe, schreibe ich diese für allgemeine Listen, und gehe in der Prozedur nicht exakt auf diese listbox ein, um diese Methode auf andere Listen auch anwenden zu können

Nennt sich Abstraktion und lässt sich lösen, indem man z.B. Interfaces bzw. abstrakte Klassen verwendet oder auch direkt cool ist und Iteratoren verwendet (wir sind hier immerhin in der C++ Sektion). Extra für dich, ein komplett generischer Merge Sort (unter der Annahme, dass bool operator<(const T&, const T&) existiert):
Davon abgesehen hat das wenig mit dem Thema zu tun, er nutzt bereits das COM-Interface, das ihm bereitgestellt wird.

[Terrat]

Originally Posted by snow

Du musst halt überlegen, wie du die Relation am besten darstellen kannst. Wenn dein Sprite-Objekt unabhängig vom D3D-Kontext existieren kann, würde ich nicht unbedingt den Zeiger speichern, da du nicht wissen kannst, ob der noch gültig ist.

Gefühlt wären da evtl. smart pointer (std::weak_pointer und std::shared_ptr) nützlich, ansonsten würde ich den Zeiger keinesfalls speichern wenn das Objekt unabhängig vom Kontext, in dem der D3D Zeiger erstellt wird, existieren kann.

P.S.: Deine Klassennamen sind ziemlich bescheiden. Dafür wurden namespaces erfunden.

ziemlich bescheiden. Langeweile läst grüßen. Das mit dem zeigern ist schon sinnig aber da die gesamten Buffer im Device nacher sind (Sprites) und jeweils meine "Os" nurnoch die Pointer managed bleibe ich lieber dabei.

Aber nochmal zu den transparenten texturen hat wer eine idee ?

[Dr. Coxxy]

Originally Posted by warfley

Ps Coxxy du kannst dich mir auch auf deutsch schreiben, ich habe meine Muttersprache mittlerweile recht lieb gewonnen

"citation needed" ist mehr oder weniger ein witz, dass du deine aussage bitte auch belegen sollst - was du imo nicht kannst, da die objektorientierte lösung deutlich sauberer ist, da sie die redundanten übergaben des devices in eine einzige methode (z.b. konstruktor) auslagert - dafür nimmst du halt ein duplikat des device ptrs in der klasseninstanz in kauf - die 4/8 byte sind aber verschmerzbar.
Kann zwar je nach anwendungsfall anders sein, in der regel wird aber die objektorientierte lösung wesentlich sauberer sein - und nicht per parameter.

[MrSm!th]

Die Diskussion über die Frage, ob es ein Parameter sein sollte (aus Designsicht), ist völlig schwachsinnig, weil dafür die nötigen Informationen fehlen.

Allgemein kann man sagen "Parameter sind besser als Instanzvariablen", so wie man sagen kann "Lokale Variablen sind besser als globale". Es ist immer besser, den Gültigkeitsbereich so klein wie möglich und so groß wie nötig zu halten.
Hier ist aber überhaupt nicht definiert, welcher Gültigkeitsbereich nötig ist.

Z.B. ist gar nicht genannt, was denn "die jeweilige Klasse" ist. Das spielt aber, wie folgendes Beispiel zeigt, eine wichtige Rolle.

//cool typedefs here
//...

class DrawableMenu
{
public:
	virtual void Draw(DeviceType *device) = 0;
	//...
};

class FancyMenu : public DrawableMenu
{
	void DrawSomeSubMenu(DeviceType *device);
public:
	virtual void Draw(DeviceType *device);
	//...
};

void FancyMenu::DrawSomeSubMenu(DeviceType *device)
{
	//draw this shit
}

void FancyMenu::Draw(DeviceType *device)
{
	DrawSomeSubMenu(device);
	//draw even more
}

class MenuController
{
	std::vector<DrawableMenu *> _menus;
	DeviceType *_device;
	
public:
	
	MenuController(DeviceType *device, const std::vector<DrawableMenu *> &menus)
		: _device(device)
		, _menus(menus)
	{}
	
	void UpdateMenus();
};

void MenuController::UpdateMenus()
{
	//...
	
	for (DrawableMenu *menu : _menus)
	{
		menu->Draw(_device);
	}
	
	//...
}

std::vector<DrawableMenu *> CreateMenus()
{
	//...
}

HRESULT __stdcall hkEndScene(DeviceType *device)
{
	static MenuController menuController(device, CreateMenus());
	
	//...
	
	menuController.UpdateMenus();
	
	return origEndScene(device);
}

(man entschuldige meine eingerosteten C++ Kenntnisse)

MenuContoller realisiert hier eine Verwaltung von mehreren D3D Menüs für ein Device. Er selbst speichert daher selbiges Device, da er daran gebunden ist und es mehr oder weniger verwaltet.

Ein Menü hingegen kann an beliebig vielen Controllern hängen und zumindest rein theoretisch mit beliebig vielen Devices gezeichnet werden. Es hat also keine Instanzvariable, sondern erhält das Device für die Zeichnung als Parameter. Zwar wird das Device ebenfalls in weiteren privaten Methoden gebraucht, aber an den nötigen Stellen wird es dann halt durchgereicht, denn es wäre unsauber und fehleranfällig, eine Instanzvariable zum Durchreichen zu verwenden, nur um sich den zusätzlichen Parameter bei den betroffenen Methoden zu sparen.

da die objektorientierte lösung deutlich sauberer ist
[...]
Kann zwar je nach anwendungsfall anders sein, in der regel wird aber die objektorientierte lösung wesentlich sauberer sein - und nicht per parameter.

Nur dass eine Instanzvariable für etwas zu verwenden nicht automatisch bedeutet, dass es objektorientiert(er) ist als die Version mit dem Parameter.

Du musst halt überlegen, wie du die Relation am besten darstellen kannst. Wenn dein Sprite-Objekt unabhängig vom D3D-Kontext existieren kann, würde ich nicht unbedingt den Zeiger speichern, da du nicht wissen kannst, ob der noch gültig ist.

^this

[Terrat]

Originally Posted by MrSm!th

Die Diskussion über die Frage, ob es ein Parameter sein sollte (aus Designsicht), ist völlig schwachsinnig, weil dafür die nötigen Informationen fehlen.

Allgemein kann man sagen "Parameter sind besser als Instanzvariablen", so wie man sagen kann "Lokale Variablen sind besser als globale". Es ist immer besser, den Gültigkeitsbereich so klein wie möglich und so groß wie nötig zu halten.
Hier ist aber überhaupt nicht definiert, welcher Gültigkeitsbereich nötig ist.

Z.B. ist gar nicht genannt, was denn "die jeweilige Klasse" ist. Das spielt aber, wie folgendes Beispiel zeigt, eine wichtige Rolle.

//cool typedefs here
//...

class DrawableMenu
{
public:
	virtual void Draw(DeviceType *device) = 0;
	//...
};

class FancyMenu : public DrawableMenu
{
	void DrawSomeSubMenu(DeviceType *device);
public:
	virtual void Draw(DeviceType *device);
	//...
};

void FancyMenu::DrawSomeSubMenu(DeviceType *device)
{
	//draw this shit
}

void FancyMenu::Draw(DeviceType *device)
{
	DrawSomeSubMenu(device);
	//draw even more
}

class MenuController
{
	std::vector<DrawableMenu *> _menus;
	DeviceType *_device;
	
public:
	
	MenuController(DeviceType *device, const std::vector<DrawableMenu *> &menus)
		: _device(device)
		, _menus(menus)
	{}
	
	void UpdateMenus();
};

void MenuController::UpdateMenus()
{
	//...
	
	for (DrawableMenu *menu : _menus)
	{
		menu->Draw(_device);
	}
	
	//...
}

std::vector<DrawableMenu *> CreateMenus()
{
	//...
}

HRESULT __stdcall hkEndScene(DeviceType *device)
{
	static MenuController menuController(device, CreateMenus());
	
	//...
	
	menuController.UpdateMenus();
	
	return origEndScene(device);
}

(man entschuldige meine eingerosteten C++ Kenntnisse)

MenuContoller realisiert hier eine Verwaltung von mehreren D3D Menüs für ein Device. Er selbst speichert daher selbiges Device, da er daran gebunden ist und es mehr oder weniger verwaltet.

Ein Menü hingegen kann an beliebig vielen Controllern hängen und zumindest rein theoretisch mit beliebig vielen Devices gezeichnet werden. Es hat also keine Instanzvariable, sondern erhält das Device für die Zeichnung als Parameter. Zwar wird das Device ebenfalls in weiteren privaten Methoden gebraucht, aber an den nötigen Stellen wird es dann halt durchgereicht, denn es wäre unsauber und fehleranfällig, eine Instanzvariable zum Durchreichen zu verwenden, nur um sich den zusätzlichen Parameter bei den betroffenen Methoden zu sparen.


Nur dass eine Instanzvariable für etwas zu verwenden nicht automatisch bedeutet, dass es objektorientiert(er) ist als die Version mit dem Parameter.

^this

Hm, da ich nur 1 mal eine Klassenvererbung mit nur 1 virtuellen funktion nutze, bleibe ich einfach erstmal bei meinem