(überflüssige) Demo

nman

Deine Entscheidung, ich nehme die Sourcen vom Server.

TGGC

So, erstmal sehen, obs überhaupt noch Interesse an dem Projekt gibt
2D Renderer

TGGC

Wäre cool wennde ne ungefähre Beschreibung des Algo's liefern könntest.

Der Renderer ist nicht dokumentiert, da es sich um eine "alte" Version handelt, die neu geschrieben werden soll, damit der Renderer mehr qualitäts- statt geschwindigkeitsorientiert arbeitet. Es handelt sich noch um die Version aus der RealTime Demo.

Also ersetze einfach mal den Vector durch ne Liste und benutze die Iteratoren

Ich glaube nicht, das der Einsatz von Listen schneller sein kann. Aber du kannst es gerne ausprobieren (nimm dir halt die Zeit...), implementiere einfach eine neue Rendererklasse.

Für jedes Feld schaun welche Objekte sichtbar sind.
Für jedes Feld berechnen welche Farbe es erhält auf Grund der Objekte die sichtbar sind.
(Ein Feld wäre ein Pixel)

Ein Tile (wenn du das mit "Feld") meinst, ist kein Pixel. Ich berechne auch nicht die Farbe für ein Feld.

ChaosAngel

Also ich hatte mir diesen Source hier vorgenommen: http://www.fh-merseburg.de/~roesch/trash/zweid_cleansource_v2.zip
Is also nix mit Echtzeit ...

Vielleicht könnteste einfach ein paar Worte darüber verlieren was du da machst, bin mir sicher das man da ne Menge optimieren kann.
Zeit habe ich leider nicht, bin 24h am lernen ... schreibe Montag und Dienstag meine Abi-Klausuren für die Leistungskurse. Ausserdem habe ich noch nen eigenes Projekt am laufen, sollten also nur Anregungen sein, vielleicht meldet sich ja noch jemand für dein Projekt der die Anregungen dann mal ausprobieren kann.

Ich glaube nicht, das der Einsatz von Listen schneller sein kann.

Sehen wirst du es nur wenn du es ausprobierst, laut Profiler geht dort aber fast genauso viel Zeit verloren wie in der Methode Intersect, und das macht fast 50% des Programms aus ...
Und selbst falls es nicht signifikant sein sollte, da du nur iterativen Zugriff hast warum sollte man nicht einen iterativen Container benutzen. Ist viel intuitiver als ein vector.

Tobiking

Mal ne dumme Frage was soll dieses "Profiler" sein? Ist das nen extra Programm oder bei msvc++ dabei oder was auch immer. Soweit ich das hier gelesen habe hört es sich so an als wenn man dammit sehen kann welcher Teil eines Programmes wie aufwendig ist. Hab mit Google nichts darüber gesehen.

ChaosAngel

In der Tat ...
Ein Profiler gibt an welche Routine wieviele Ticks braucht, wie oft aufgerufen wird, etc...
Gute Profiler können auskunft darüber geben wie gut der ProzessorCache ausgelastet wird wo sich halt Bottlenecks befinden, also Stellen im Programm die besonders lange dauern und sich in den inner-loops befinden. Wie hier im Beispiel die Intersect Methode. Sie nimmt viel Zeit in Anspruch, lässt aber wenig Platz zum optimieren. Aber was fasst genausoviel Zeit in Anspruch nimmt ist die Get() Methode der ObjektListe, und diese besteht nur aus der Answeisung ein Objekt zurückzuliefern. Da sollte man dann doch mal schaun ob man dies nicht verhindern kann.

TGGC

Original erstellt von ChaosAngel:
Sehen wirst du es nur wenn du es ausprobierst

Ich bin mir sicher genug, das ich es nicht erst probieren muss. Ich hab auch nicht die Zeit, irgendwelche unbegründete Vermutungen zu implementieren, vor allem wenn ich garnicht sehe, auf welche Weise ich dort Listen einbauen soll, das es mit hilft. Das ganze erinnert mich irgendwie an das ZFX-Board wo die Liste grad so in sind, das sie die Lösung zu quasi jedem Problem darstellen.

Bye, TGGC

BTW: Wie ich dir helfen kann weiss ich auch net.

TGGC
wieso machst du so ein topic auf,
wenn du eh keine verbesserungsvorschläge annimmst?
jaja wir wissen alle: du bist perfekt, deine proggs sind perfekt usw

ChaosAngel

@ElDorado
Wer nicht will der hat schon
@TGGC
Wer nicht will der hat schon. Man muss sich als programmierer ja auch net unbedingt weiter entwickeln Das ist jedem selbst überlassen.

irgendwelche unbegründete Vermutungen

Ich denke ich hab sie mehr als ausführlich begründet.

Bye

[ Dieser Beitrag wurde am 24.01.2003 um 10:23 Uhr von ChaosAngel editiert. ]

Headhunter

Tggc :
Vergleichst du das ZFX board mit dem C++ Board ? Frevler :p

El Dorado :
TGGC nimmt sehr wohl Verbesserungsvorschläge an, nur wenn sie nicht stimmen ist es noch kein Grund sie zu übernehmen.

Der große Vorteil von Listen gegenüber Arrays (=>std::vector) ist, dass man bei Listen *sehr* schnell Daten entfernen oder hinzufügen kann. Der Vorteil des std::vectors ist, dass gezielter Zugriff auf bestimmte Elemente möglich ist (operator[], und at (int) ).

Dass vector::begin schneller oder langsamer als die Variante mit Iteratoren ist, kann ich nicht bestätigen, die sind soweit ich weiß gleich schnell

Ich hab mir TGGCs Source zwar nicht angeguckt, aber wenn die Funktion Get sehr oft aufgerufen wird, ist es doch kein Wunder dass sie den größten Teil der Zeit beansprucht.
Ich hab mal einen Source von mir geprofiled, dort hat eine simple Zuweisung (vector.u = 1.0f; vector.v = 0.f...) *angeblich* 20% der Zeit ausgemacht.

TGGC

Original erstellt von ChaosAngel:
Ich denke ich hab sie mehr als ausführlich begründet.

Muss ich übersehen habe, wo stand das jetzt nochmal.

ChaosAngel

@Headhunter ...
I wollte das eigentlich nicht in eine grosse Diskussion ausweiten ...
Aber wenn du den Source noch nicht gesehen hast kannst du nicht sagen das das nichts bringt.

Ich weiss was der Vorteil einer Litse und eines Vectors ist. Und der "Nachteil" des Vectors ist das er indizierten Zugriff erlaubt. Normalerweise ein Vorteil, aber im Renderer eigentlich unnötig, da hier nur linear, also in einer For-Schleife durch den Renderer gegangen wird
Also jedesmal:

for(int i = 0; i<vec.size();++i)
vec[i]:=bla;

Da ist der indizierte Zugriff völlig Schwachsinnig, da jedes Element dran kommt. Und das spricht nunmal 100% für eine Liste.

for(list<obj>::iterator i = l.begin();i!=l.end(); ++i)
(*i):=bla;

Macht was ihr wollt,, ich will ja nicht streiten, aber sagt nichts darüber wenn ihr noch net den Source gelesen habt. Nur weil TGGC ansonsten echt Klasse Spiele und Demo's macht kann auch er sich ja mal irren.

TGGC

A)

Original erstellt von ChaosAngel:
**```cpp
for(int i = 0; i<vec.size();++i)
vec[i]:=bla;

Original erstellt von ChaosAngel:
**```cpp
for(list<obj>::iterator i = l.begin();i!=l.end(); ++i)
(*i):=bla;

Nochmal für mich zum mitmeisseln, warum kann B schneller als A sein?

ChaosAngel

Weil der op[] in einem vector mehr kostet als der lineare Zugriff über iteratoren.

muss noch die Stelle x "gesucht" werden, während in einer liste nur zum next-pointer gesprungen wird.

Ne Liste ist also nicht nur schneller (keine Ahnung wie viel) sondern auch intuitiver, da du ja nunmal linear durch den Container gehst ...

Am schnellsten wäre ein konstantes Array, da da über PointerArhytmetik zugegriffen wird und der ProzessorCache den Speicher nicht so oft nachladen muss. Aber nen Array ist ja nicht dynamisch.

Headhunter

ChaosAngel :
Warum ist der op [] langsamer ? Damit wird doch direkt ein Element *direkt* returned, ohne irgendwelche Größenchecks oder so.

Ich würde den operator [] so definierien :

template <class T>
T& operator [] (int n)
{
       return m_array[n];
}

Viel schneller geht das doch nicht, oder ?

ChaosAngel

Na sicher ...
Bei nem statischen Container kann man das auch so tun, und da greift auch der ProzessorCache.
Aber std::vector ist nunmal dynamisch ! Das heisst es muss nicht in so einem Array gespeichert sein ! Ein dynamisches Array sieht nunmal anders aus (implementierungsabhängig)

Gibts hier nicht irgendwo nen FAQ wann benutze ich Listen und wann Vectoren ?
Dann könnte man das da nachlesen ...

TGGC

Original erstellt von ChaosAngel:
Gibts hier nicht irgendwo nen FAQ wann benutze ich Listen und wann Vectoren ?
Dann könnte man das da nachlesen ...

Worauf ich dich dann verweisen würde...

Ok, hat sich erledigt, das war ja dann ein Schlag ins Wasser. Hat evtl. noch jemand nützliche Vorschläge?

Bye, TGGC

ChaosAngel

Ich glaube nicht das ich dieses Faq brauche ...
Aber ich will schliesslich niemanden zwingen.
Viel Spass noch ...

oh mann TGGC
du besserst dich nie
schrecklich
nach deiner meinung ist doch eh schon alles perfekt
wenn jemand einen vorschlag macht, machst du ihn nieder. wenn jemand argumente bringt, startest du einen kleinkrieg und hälst dich mit lächerlichen kleinigkeiten auf um zu verdecken daß der andere recht hat.
furchtbar
!!!

Ich glaube hinter std::vector steckt auch ein ganz normales Array, was super schnelle Zugriffzeiten erlaubt. Es wird halt, wenn das Array zu klein wird, ein neues, größeres Array erstellt, umkopiert und das alte Array gelöscht.