Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Okt 17, 2018 23:18

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 87 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5, 6  Nächste
Autor Nachricht
BeitragVerfasst: Sa Okt 17, 2009 23:14 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wie bereits im Forum angekündigt habe ich mir mal die Zeit genommen und eine Spezifikation für den DGL Benchmark geschrieben.

Dieser Thread soll dazu diesen diese zu Diskutieren um die Spezifikation zu verbessern. Sie ist expliziet Sprachunabhängig gehalten. Ziel soll es sein mehrere Implementationen in verschiedenen Sprachen zu erhalten.
Dies würde später, bei genügend großer Datenbasis, auch Vergleiche der Spracheinflüsse auf die Laufzeit ermöglichen.

Die Spezifikation findet ihr im Wiki unter DGL_Benchmark.


EDIT: Was soll mit den Ergebnisfiles werden?

Es soll bei DGL ein DB Backend geben, wo die Benchmarkergebnisse eingelesen werden und in einer DB zur Verfügung gestellt werden. Man kann dann dort, kommuliert über verschiedene Systeme mit verschiedener HW sehen, was wie schnell läuft.
Der Benchmark ist also nur ein Tool mit dem die Daten erzeugt werden die man dann in die DB einspeist.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Zuletzt geändert von Flash am Fr Okt 23, 2009 22:00, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Okt 18, 2009 11:01 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich sehe Probleme, den Benchmark unter Sprachen wie C++ und FreePascal ans laufen zu Bekommen, zumindest, wenn das Framework unabhängig vom speziellen Benchmark sein soll, da diese Sprachen keine Möglichkeit bieten, die Methoden aufzulisten ... Zumindest nicht ohne weiteres und nicht sicher.

Gibt es einen speziellen Grund, setupBenchmark bei jedem Schleifendurchlauf aufzurufen? Eher bräuchte man denke ich ein Setup für jede Benchmark-Methode, sodass man die Einstellungen für den entsprechenden Benchmark setzen kann, ohne, dass das mit in die Zeit einfließt.

Da fällt mir auch ein, wie man das Problem mit dem Auflisten der Methoden lösen könnte ... getBenchmarkInfo könnte auch in einer Zeile sowas zurückgeben wie "benchmarks=a,b", wobei a und b dann das Suffix der benchmark_ und setup_-Methoden sind. Mit diesem Wissen und der Sicherheit, wie die Parameter der Methoden aussehen, kann man das zumindest in FreePascal implementieren (TObject.MethodAddress) (keine Ahnung, wie das in C++ aussieht?).

Generell könnte man noch die Grafikhardware dazupacken ... gerade, wenn das mit der Übernahme von delphi3d.net funktioniert. Dann könnte man die Testergebnisse den Grafikkarten zuordnen.
Auch so Einstellungen wie Auflösung, Anti-Alias und anderen Dingen, die beim erstellen des Framebuffers festgelegt werden, könnten auch noch interessant sein.

Nachdenken könnte man auch über eine Möglichkeit, dem Benchmark noch Parameter zu übergeben, die dann ebenfalls im Testlog auftauchen. Optimal wäre natürlich, wenn diese auch noch bis zu einem gewissen Maße Scriptbar wären (z.B. für einen Füllraten/Blending-Test sowas wie "quadcount=0..100 step 5", sodass er von 0 bis 100 in 5er-Schritten hochzählt und das als einzelne Subbenchmarks mit in der Schleife durchführt, wiederum für jede Benchmarkmethode. Für die Parameter könnte man eventuell RTTI/Reflection benutzen?).

so, das war mein Teil dazu ;)
greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Okt 18, 2009 11:50 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Danke für deine Antwort.

Lord Horazont hat geschrieben:
Ich sehe Probleme, den Benchmark unter Sprachen wie C++ und FreePascal ans laufen zu Bekommen, zumindest, wenn das Framework unabhängig vom speziellen Benchmark sein soll, da diese Sprachen keine Möglichkeit bieten, die Methoden aufzulisten ... Zumindest nicht ohne weiteres und nicht sicher.


Deshalb habe ich geschrieben, dass der Benchmark Schreiber, falls seine Sprache/Wissen keine andere Möglichkeit zulässt, den Benchmark-Code hardcoded in den DGL_Benchmark reinschreibt und dann das komplett-Packet veröffentlicht. Das dynamische laden ist ein "kann", kein "muss".

Lord Horazont hat geschrieben:
Gibt es einen speziellen Grund, setupBenchmark bei jedem Schleifendurchlauf aufzurufen? Eher bräuchte man denke ich ein Setup für jede Benchmark-Methode, sodass man die Einstellungen für den entsprechenden Benchmark setzen kann, ohne, dass das mit in die Zeit einfließt.


Damit wollte ich sicherstellen, dass immer die selben Ausgangsbedingungen für die Benchmarks hergestellt werden.
Aber dein Argument ist sicherlich eine Überlegung wert.
Man könnte dann die Spezifikation so ändern, dass als INPUT ein String mit dem Namen der benchmark-Methode übergeben wird, die als nächstes aufgerufen wird. Beim ersten Lauf wird ein leerer String "" übergeben.

Lord Horazont hat geschrieben:
Da fällt mir auch ein, wie man das Problem mit dem Auflisten der Methoden lösen könnte ... getBenchmarkInfo könnte auch in einer Zeile sowas zurückgeben wie "benchmarks=a,b", wobei a und b dann das Suffix der benchmark_ und setup_-Methoden sind. Mit diesem Wissen und der Sicherheit, wie die Parameter der Methoden aussehen, kann man das zumindest in FreePascal implementieren (TObject.MethodAddress) (keine Ahnung, wie das in C++ aussieht?).


Da würde ich gern noch die C++ Fraktion hören und andere Pascaller.


Lord Horazont hat geschrieben:
Generell könnte man noch die Grafikhardware dazupacken ... gerade, wenn das mit der Übernahme von delphi3d.net funktioniert. Dann könnte man die Testergebnisse den Grafikkarten zuordnen.
Auch so Einstellungen wie Auflösung, Anti-Alias und anderen Dingen, die beim erstellen des Framebuffers festgelegt werden, könnten auch noch interessant sein.


Sowas hatte ich auch geplant, weiß aber nicht wie ich das auslesen kann. Platz wäre dafür im Header des Outputs.

Lord Horazont hat geschrieben:
Nachdenken könnte man auch über eine Möglichkeit, dem Benchmark noch Parameter zu übergeben, die dann ebenfalls im Testlog auftauchen. Optimal wäre natürlich, wenn diese auch noch bis zu einem gewissen Maße Scriptbar wären (z.B. für einen Füllraten/Blending-Test sowas wie "quadcount=0..100 step 5", sodass er von 0 bis 100 in 5er-Schritten hochzählt und das als einzelne Subbenchmarks mit in der Schleife durchführt, wiederum für jede Benchmarkmethode. Für die Parameter könnte man eventuell RTTI/Reflection benutzen?).

Das ist eine ziemlich drastische Änderung. Man sollte immer auch bedenken, dass die Benchmarks schnell zu schreiben sein sollten. Ich will nicht das man am Ende vom DGL_Benchmark das selbe sagt wie vom Emacs (Emacs ist kein Editor - Emacs ist ein Betriebssystem! ;) ).

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Okt 19, 2009 17:37 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Weitere Kommentare wären sehr willkommen. Oder interessiert sich keiner mehr für den Benchmark?

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 01:01 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1965
Programmiersprache: C++
Im Prinzip bringen hier Diskussionen nichts mehr. Entweder jemand setzt sich hin und programmiert sowas, oder es wird nichts passieren.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 07:55 
Offline
DGL Member

Registriert: So Aug 20, 2006 23:19
Beiträge: 564
Habs mir auch angesehen und ich denke, dass man auf der Basis einheitliche Benchmarks schreiben kann. Sinnvoll zum Vergleich der unterschiedlichen Sprachen wäre es dann aber, wenn die Benchmarks auch identisch sind, bis auf die Tatsache, dass sie in einer anderen Sprache implementiert wurden.
Also ich denke, wenn ein sich ein paar Themen herauskristallisieren, die sich für einen Benchmark eignen, und diese in verschiedenen Sprachen implementiert werden, kann man die Sprachen schonmal gut vergleichen. Aber das ist ja eigentlich auch nur ein sekundärer Vorteil der Benchmarks. Ich werde wohl mal einen Benchmark für VBOs und Texturfiltering in Java schreiben. Vor allem, weil mich gerade dieses Thema sehr interessiert. Am sinnvollsten ist es dann wohl, wenn man die "Benchmarksammlung" einfach wachsen lässt und versucht darauf zu achten, dass alle BEnchmarks diese Spezifikation erfüllen, damit eine VErgleichbarkeit gewährleistet ist. Alles in allem hat ionos wohl aber Recht: Jetzt erstmal welche schreiben.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 11:06 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Sorry wenn ich das so direkt sage. Aber mehrere Sprachen? Seit wie vielen Jahren gibt es dieses Thema jetzt eigentlich schon? Und in der Zeit ist nicht mal eine Version in einer Sprache entstanden. Was ich verstehen könnte ist, wenn man sagt, dass die Schnittstelle zu den Tests sprachunabhängig gestaltet werden soll. Dann könnte A einen Test in Pascal entwicklen und B einen Test in C/C++. Der Unterschied in den Sprachen ist sowieso immer nur auf spezielle Sachen bezogen. Und das Java anders ist als Pascal oder C/C++ dafür brauche ich nun wirklich keinen Benchmark. Zu mal die Abhängigkeiten in der Sprache sowieso immer von dem Abhängen was dort gemacht wird. Ein kleine ungünstige Anpassung hier und C++ ist langsamer als Pascal. Oder ein ungünstiges Kunstrukt da und Pascal ist langsamer als C++.

Das Hauptproblem was ich sehe ist, dass einige Test spezielle Initialisierungen benötigen. Also ein mal ein Test mit AA und ein Mal ohne. Um die Unterschiede zu zeigen. Aber auf der anderen Seite jedem Test dann eine komplette Initialisierung mit aufzudrücken halte ich für unpraktisch. Und wenn man alle solche Fälle berücksichtigen wollte, dann wird das Ganze zu einem Mamutprojekt und endet genau da wo die vorherigen Versuchen auch sind. Da würde ich lieber erst mal kleine Brötchen backen als gleich ein mehrstöckiges Lebkuchenhaus zu versuchen. Ist aber nur meine Meinung.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 12:19 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Also mal kurz noch meine Intention dazu:

1. Mehrsprachigkeit:

Mehrsprachigkeit hab ich nur deshalb mit reingenommen, weil es quasi zwingen erforderlich ist. Es gibt sonst immer welche die Sagen: "Ich würde ja gern einen Benchmark schreiben aber ich kann halt nur Delphi/Java und das Tool ist in Java/Delphi..."

Durch die offene Spezifikation steht es den "Sprachparteien" offen, eine BenchmarkTool-Implementation bereitzustellen, oder nicht.

2. Initialisierung für jeden Test:
Das können wir durchaus mit aufnehmen. Soviel zusätzliche komplexität kommt da sicher nicht mit rein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 13:09 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Flash hat geschrieben:
2. Initialisierung für jeden Test:
Das können wir durchaus mit aufnehmen. Soviel zusätzliche komplexität kommt da sicher nicht mit rein.

Das ist genau das Gegenteil von dem worauf ich mit meinem Post hinweisen wollte. ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 14:17 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich meins aber so wie ich geschrieben habe. ;)

Ich mach mir dazu nochmal nen kopf. Aber ich gehe davon aus, das es pro Benchmark vielleicht 2-5 Benchmark-Methoden geben wird. Wenns dann noch 2-5 Setup-Methoden gibt, ist das kein Problem.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 14:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2523
Wohnort: Berlin
Programmiersprache: C/C++, C#
http://developer.nvidia.com/object/openautomate.html <- recht beliebt

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 14:26 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hm, vielleicht könnte man zum Zweck der Mehrsprachigkeit von OOP abgehen und lieber auf DLLs setzen. Denn dort haben wir eigentlich alles, was wir brauchen (außer anständigem String-Handling, aber das bissl ge-PChar-e wird überlebbar sein): Es gibt die Möglichkeit, einzelne Funktionen anhand ihres Namens aufzurufen und das unabhängig von der Sprache (solange es eine Native ist ... *skeptischer Seitenblick zu Java*) und noch dazu muss man die Anwendung nicht neu kompilieren, wenn ein Benchmark dazu kommt...

Zu der Sache mit AA & Co.: Für diesen Zweck sollte man dem Objekt/der DLL vielleicht ein Callback auf eine Methode geben, die den Kontext erzeugt. Zum Start könnte man einen Default-Kontext bereitstellen und wenn ein Benchmark explizite Settings einstellen will/muss (z.B: weil er nen Stencilpuffer braucht), ruft er halt das Callback auf. Die Parameterliste stelle ich mir so vor, dass jede mögliche Komponente eines Framebuffers einen Parameter bekommt, der über die Tiefe entscheidet. Über die Pixelauflösung sollte das Benchmark-plugin aber eventuell nicht entscheiden können, weil das nicht allein von der Grafikkarte sondern auch abhängig vom Bildschirm eingeschränkt ist.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 20, 2009 17:04 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Das wollte ich halt gerade nicht.

Es sollte bewusst eine LowTech Lösung werden. Nix mit DLL dynamisch nachladen und alles supi und so.

Der Code des DGL_Benchmark wird frei sein.

Jeder der einen neuen Benchmark schreibt kann den nehmen und dort dann den Benchmark reincode.
D.h., wenn es die Sprache nicht hergibt, dass es dynamisch geladen wird, dann hat man halt 10 verschiedene DGL_Benchmark exen rumliegen. Jede mit einem anderen hard gecodeten Benchmark.

Das ist vielleicht nicht besonders edel, aber es begreift wirklich jeder und schreckt niemanden ab (auch keine Anfänger die noch nie ne DLL geschrieben haben - und die das PChar gecaste schon stört. ;) )

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Okt 23, 2009 16:00 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich hab die Spec nochmal angepasst.

Die Frage mit den Benchmarks mit sich steigernden Volumen steht noch im Raum.

Ich denke es macht wenig Sinn schrittweise und granular irgendetwas zu erhöhen (lass mich aber gern vom Gegenteil überzeugen).
Falls jemand z.B. Füllratentests machen will, dann kann er ja folgendes machen:

1. eine private methode die den eigentlichen Benchmark-Code enthält.
2. n öffentliche "benchmark_XxxxxXxxXxxxx" methoden die dann einfach auf die Private Methode weiterleiten.
3. Die zugehörigen "setupBenchmark_XxxxxXxxXxxxx" in denen eine Variable gesetzt wird, die die Menge der zu rendernen Objekte vorgibt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Okt 23, 2009 21:07 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hm, ich möchte auch einmal kurz meine Gedanken äußern, auch wenn man von mir später sicherlich keinen Shaderbenchmark erwarten können wird. :)
Das mit den Modulen ist ja leider gecancelt worden, wobei ich das Konzept am besten finde, auch wenn es Java rauskloppen würde bzw. einer einen Java-Wrapper schreiben müsste, also eine DLL/SO, die "java -jar benchmark.jar" ausführt und Rückgabeparameter an den Benchmark durchreicht.

Aber davon sind wir ja weg. Was in Bezug auf Betriebssystemunabhängigkeit vielleicht auch nicht schlecht ist... Also stell ich mir nun vor, jede Sprache (also z.B. C++, Pascal oder Scala) schreibt sich einen Benchmark-Kern nach gewissen wohl definierten Kriterien. Am besten wäre ja z.B. zuerst in Pascal, die anderen programmieren nach. Wo werden nun aber die Benchmarks zusammengeführt? Ich sage Benchmark "1000 Cubs in einer Pornodrehumgebung" soll gestartet werden, das Programm sagt mir, ob das geht oder nicht, ich bekomme ein Ergebnis und nun? Gebe es ich es nur aus? Gibt es eine (Internet-)Datenbankanbindung und wenn ja, wie sieht die aus? Oder gibt es nur eine wohl definierte Textfile, die man dann "einreicht", dass sie hinzugefügt wird in den Resultpool?

Und was für Werte interessieren einen als Ergebnis? Nur die FPS' (können ja mehrere sein bei Vergleichen)? Es ist klar, dass das Result natürlich auch die Grafikhardware, die CPU usw. enthalten wird, aber das ist ja unabhängig vom speziellen Benchmark.

Und ich bin für eine Umfrage, die in Erfahrung bringen will, wie viele sich zur Verfügung stellen würden bei dem Projekt mit zu wirken. Es bedarf imho eines festen Kernteams (sagen wir 3 Leute, z.B. Flash, Horazont und noch jemand, der sich berufen fühlt und ein wenig Ideen und Umsetzungsvorschläge mitbringt, wobei auch die 3 Leute nur ein Vorschlag ist, der demokratische Mehrheiten bei gleichzeitig wenig "drumrumdiskutieren" möglich macht), das z.B. das "Interface" (Bullshitbingo) und allgemein das Konzept schriftlich festhält - ohne dabei bitte zu kompliziert zu werden, aber immernoch genau. Die letzten beiden Punkte werden wohl schwierig. ;-)

Gut wären auch erste konkrete Vorstellungen von bestimmten Benchmarks. Und wie das Erweitern genau gedacht ist. Schreibe ich irgendwas (ich teste z.B., wie schnell ich 1000 3DM-Modelle laden und zeichnen kann) oder gibt es eine "Jury", die vorher abklärt, ob überhaupt Interesse an einem Benchmark besteht?

Ich hoffe, es sind nicht zu viele (dumme) Fragen, aber ich Begrüße das Projekt erstmal prinzipiell und würde auch gerne etwas (Kleines, wegen kleiner Hardware und so...) beisteuern.

LG Ziz

PS: Ich hätte sogar schon einen ersten Benchmarkvorschlag, wo Erfahrungen zwar Vorliegen aber ohne konkrete Zahlen:
Objekte mit 10, 20, 50, 100, 200, 500, 1000, usw. Polygone werden im Immediate Mode, mit Vertex Arrays im Quasi Immediate Mode, mit Displaylisten und mit VBOs gezeichnet. Einmal mit, einmal ohne Texturen. Interessant sind die fps und die prozentualen Unterschiede untereinander, z.B. in einer Tabelle mit Polygonanzahl und Zeichnungsmethode ohne Texturen und noch eine mit Texturen. Die Ergebnisse würden mich z.B. sehr interessieren und wenn man das ganze vorher gut festsetzt, schreibe ich nicht für den Lokus, wenn ich es mal täte. Mir fällt hierbei auch auf, dass hier z.B. definiert werden muss, ob man mit oder ohne Culling zeichnet, mit oder ohne Frustum Culling, Oct Trees, Vorsortierung, Transparenz und so weiter und so fort. Am besten wäre es hier also wenn einer in seiner Sprache vorschreibt, es diskutiert und angepasst wird, dass es der Masse (oder dem Kernteam) gefällt und die anderen dann in "ihrer" Sprache 1:1 anpassen/abschreiben, so gut es geht. Zumindest, was das Grafische angeht. In Scala z.B. gibt es für Berechnungen und Herangehensweisen bestimmt andere, hochkomplexe oder aber total intuitive Wege, die das ganze auf eine nie dagewesene Abstraktionsstufe heben. ;-) (Und das war nicht mal eine Kritik gemeint, die Aussage ist wertbefreit)

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 87 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5, 6  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.057s | 17 Queries | GZIP : On ]