[veraltet] Data & Ressources

[ChaosAngel]

Tja, wie können wir Daten und Ressourcen am besten kapseln ?!?!?

Ressourcen zu kapseln sollte kein Problem sein. Einfach ne Basisklasse für die Ressource. Die liefert dann über ne pure virtual Methode nen BaseData Objekt ...

Aber wie sieht ein DataObjekt aus ...
Was wird dadrin gespeichert, wie greift man darauf zu, etc...
Nur unsigned char* zulassen ? Was ist mit floats etc...
Die Daten sollten für Texturen, VertexArrays und alles andere funktionieren ...
Na dann mal los midde Brainstorming.

[DerSensemann]

Echt gute Frage...

Nur char* wäre natürlich die einfache Variante die auch durchaus ausreichen würde (Für Texturen und VAs), aber durch ev. später benötigte Casts nicht sehr elegant ist :(

Werd mal drüber schlafen ;)

[ChaosAngel]

hmmmm ....
*denk*
Und wenn man die Basisklasse weglässt ?
Also nur data<Type> explizit verwendet.
Ich meine man kommt ja nicht darauf nem VertexArray Daten im Format von char zu geben.
Das hätte sogar den weiteren Vorteil das man für VA's vielleicht eigene Strukturen nehmen könnte


struct blupp
{
Vector3 Vertex;
Vector3 Normal;
char color[4];
};

data<blupp>


Müsste man natürlich mal drüber nachdenken inwiefern man die Basisklasse braucht, und inwiefern natürlich die templates von Vorteil sind (was kann ein VA denn schon mit nem data<irgendein_struct> anfangen wenn es nicht weiss was drin steht ?)

Nur so meine Gedanken die mir gerade während des Antwortens eingefallen sind :D

[DerSensemann]

Stooohooop :)

data<blupp>
ist statisch, also zur Compilzeit festgelegt, was aber wenn wer ein Modell laden will dessen VertexDaten er noch nicht kennt? ;)

[ChaosAngel]

was kann ein VA denn schon mit nem data<irgendein_struct> anfangen wenn es nicht weiss was drin steht ?

Deshalb schrieb ich ja diesen Satz :D

Er könnte das data<> Objekt mit einer template Methode empfangen, obwohl dann immernoch das fvf Problem bestehen würde. Das Modell kann mit den Daten einfach nichts anfangen weil es nicht weiss was sie bedeuten...

Allerdings kann man generell kein Modell laden dessen VertexDaten man noch nicht kennt. Es sie denn zu den VertexDaten steht was bestimmtes im File (was weiss ich, hat vorberechnete Normalen oder so ..)
Aber für diesen Fall kann das Model dann eine entsprechende LadeRoutine zur Verfügung stellen.

Oder das ganze Model ist template in Abhängigkeit von Data, kommt drauf an wie es erstellt wird (Factory, etc...)

Egal, i muss ins Bett, bin noch krank :(

[DerSensemann]

Allerdings kann man generell kein Modell laden dessen VertexDaten man noch nicht kennt. Es sie denn zu den VertexDaten steht was bestimmtes im File

Da hast du die Antwort gleich mitgeliefert :)

Entweder wir packen ein FormatInfo mit ins File oder das Format wird zur Compilierzeit festgelegt. Andere Möglichkeiten gibt es nicht. Alleine schon weil letzteres Modeller stark einschränken würde, müssten wir Weg 1 wählen. Aber mal weitergedacht: Das Level z.B. besteht aus vielen Objekten verschiedenem Formats, das vorher festzulegen ist unmöglich ;) (Oder das Game müsste für jedes Level eigens compiliert werden lol)...

Ist natürlich wiedermal n großes Problemchen welches viele Fragen aufwirft/einiges komplexer macht :(...

Merke: Alle Objekte müssen unabhängig vom Datenformat funktionieren und sich dynamisch an ein neues Format anpassen können!

(Dass man vor lauter Planerei solche Sachen übersieht *g*)

[ChaosAngel]

Dann also doch nur char und casten, was hilfts ...
ODER, doch das data<type> template für verschiedene Typen ...
Im Falle eines Modells könnte es einfach mehrere data<> Objekte besitzen die dann zur Laufzeit gefüllt werden (je nachdem ob sie vorhanden sind)
Das wären dann also Vertex, Normals, Color, TexCoord, etc...
Falls das Model keine explizite Farbe hat dann wird Color halt weggelassen ...
Die andere möglichkeit die vielleicht schneller ist (wegen dem Prozessoralignment) wäre wieder alles in ein data<> Objekt zu packen ... Allerdings müsste dann mit einer case Anweisung entschieden werden welches der data<> Member initialisiert wird
das ganze sähe dann so aus ...


class Model
{
//...
private:
union
{
data<V3N3C4T2Struct> bla1;
data<V3N3C3T2Struct> bla2;
data<V3N3T2Struct> bla3;
...
};
};

Die ganzen FVF_Structs müssten natürlich noch geschrieben werden, und am besten ausserhalb des ModelFiles damit andere Klassen sie uach benutzen können.

In der Union stehen dann halt alle data<>'s die Möglich sind für das Model zu laden, welches davon gefüllt wird steht dann in einer case beim fileloaden ...

Die Methode hätte aber gravierende Nachteile...
Generell kommen mir da gravierende Nachteile auf ...
Ein Modell hat garkeine Daten, ein Model hat ein VA. Also sollten wir das ganze für das VA planen, und wenn das VA dann wieder diesen ganzen shit mit case entscheiden muss finde ich das doch schon echt Scheisse ...
Wir sollten dann vielleicht doch mit FVF-enum und char* arbeiten ... Das ganze simple verpackt in ein data-Objekt.


PS: Was bist du um diese Zeit noch auf *doofguck*

[DerSensemann]

Den Unterschied den du hier anspricht ist genau der zwischen Single und Multistream VertexBuffer ;) Entweder mehrere einzelne Streams für VertexPos, Normals etc... Oder eben einen FVF Typen der schneller von der GraKa verarbeitet wird.

[ChaosAngel]

sicherlich ! :D
Habs auch bemerkt.

Jetzt müssen wir das Ding nur noch ausarbeiten. Ohne template sollte das ja kein Problem sein. Was machen wir allerdings mit dem FVF. Oder besser FF (flexibleFormat).
Soll das ins data mit rein ?