Ihr 3dgs'ler seid Schuld...

das wäre ein anderes thema

wie auch immer, ich habe mich beim lesen köstlich amüsiert

Dass in lite-c haufenweise bugs vorkommen ist doch irgendwie verständlich. In der neuen Version wurde so viel geändert und ich finde es persönlich um einiges leichter als mit c-script (vor allem gab es dort viele unlogische Aspekte). Zudem ist shader Support angeboten worden, neuerdings auch mit post processing.
Dann wurde noch in WED ein Terrain Editor implementiert.Ein komplett neues Lighting-System mit Radiosität(?) wurde entwickelt und im forcecast (in dem so weit ich weiß bis jetzt alles realisiert wurde) stehen auch noch sehr nützliche und vor allem arbeitserleichternde Dinge aus.

Ich finde gerade in den letzten Monaten ist sehr viel neues und auch sinnvolles hinzugekommen und man sollte sich nicht dadrüber beschweren, dass noch nicht alles 100% klappt. Und wie schon erwähnt wurde hagelt es im bugforum Fehler, was aber nur zur Folge hat, dass all diese Fehler behoben werden. Und dann ist alles gut

Das hoffe ich auch Scorpion.

Wenn das wirklich ein Lite-C Bug ist und der Compiler später irre schnell kompiliert, dann sehe ich da kein Problem. Aber warum stellt Timo dann GameEdit jetzt auf C++ / DLL um? Vielleicht kann er ja mal seinen Eindruck davon vermitteln.

Radiosity klingt wirklich geil und ich freue mich drauf. Allerdings sickert auch im Forecast-Radiosity-Bild das Licht durch die Ritzen. Das ist erstmal wichtiger, dieses Problem zu beheben. Der Levelkompiler ist seit Beginn von A7 in diesem Zustand. Wie lange ist das her?
Damit kann man keine funktionierenden Lightmaps erstellen.

Jeder Künstler weiß, dass die Geometrie und die Textur wichtig sind, aber das Wichtigste sind Licht und Schatten, damit wird Stimmung erzeugt, Realität nachgeahmt und Tiefe erzeugt. Andere Bilder wirken flach, 2d, Cartoon.
Hier nutzen auch 20 neue Lite-C Befehle wenig, wenn der Schattenkompiler Probleme hat.
Es könnte aber helfen, dieses Problem einfach mit einem 2. UV-Set zu umgehen und selbst die Schatten zu rendern. Es wäre ein Workaround, aber wir brauchen dieses UV-Set im MDL Format.

Ich will doch nur eine schöne zeitgemäße Demo in A7 basteln, mehr will ich gar nicht
Aber ohne Licht und Schatten ist es (zumindest für meine Sicht) nicht wert, auch nur eine Zeile Lite-C zu lernen.

Für ein 2d-Projekt oder besser 2,5d als Casual Game ist das was ganz anderes. Da wird man auf jeden Fall glücklich mit A7, ich weiß das von Fogman und Damocles, die beide sehr erfolgreich dabei sind / waren.

...aber das wollen wir ja nicht

das mit den 2 Minuten kann ich irgendwie nicht nachvollziehen, warum sollte es so erheblich länger dauern als bei c-script? Aber leider ist es ja so :/

Das mit den Ritzen in der Shadowmap kann ich jetzt nicht bestätigen aber ich werde sofort mal ein wenig rumexperimentieren...

Edit: ok, also ich konnte nichts entdecken. Ich habe erst bei einer wand die nur noch 2 Quants breit war etwas erkennen können:


Und achtet mal auch in kommerziellen spielen darauf: oft sind dort auch noch diese "Ritzen" zu sehen, das liegt einfach an der Größe (bzw. Kleine^^) der Shadowmap. z.B. in hl2 sieht man so etwas auch dauernd.

Etwas mehr als eine Wand braucht es schon, um eine Lightmap zu beurteilen. Ich kann jetzt leider nichts machen, bin noch auf Arbeit. Ansonsten schau einfach mal im Bug- oder Beta-Forum, da sind einige Posts mit Bildern zu sehen, die das Problem aufzeigen.

Achso: Und probier mal bitte statische Meshes aus!

Hier ist mal ein Bild von MaxF:

Ich verstehe Wichts Post als halb Spass halb Ernst Post.
(Geben wir es zu, wir sind froh über etwas erheiternde oder aufscheuchende Posts im Morbius.
Dabei läßt sich am besten entspannen! )

Man darf allerdings, das Geschehen hier auf dem Forum nicht mit dem Geschehen in den Spieleschmieden verwechseln.
Das hat man früher auch schon oft sehen können, einige der mit 3DGS entwickelten Spiele sind hier im Forum erst nach ihrer Veröffentlichung gezeigt worden.

Zum anderen kannst Du bei der Entwicklung Deines Spiels nicht auf die letzte Version bauen, sondern Du nutzt natürlich die, deren Haken und Ösen Du genau kennst. Alles andere ist zu riskant, wenn Du Dein Spiel veröffentlichen mußt.

Also so schlimm, daß man garnicht damit arbeiten kann, steht es um Lite-C nun wirklich nicht.

Was die Kompilierzeit betrifft: Da mag was dran sein, aber man muß es auch so sehen: Lite-C kompiliert zums chnellen Ausführen on the fly, und 4MB Code (hat TripleX mal erwähnt) mal eben zu builden, dauert halt seine Zeit.
Auf Arbeit hat ein reinrassiger C-Compiler dafür deutlich länger gebraucht - ist ja auch logisch da dieser nochjede Menge Optimierungen macht, aber bei 4MB die geparst werden müssen, ist nunmal nixmehr mit plopp und fertig.
Lite-C ist deutlich komplexer als C-Script, dadurch schießt die Kompilierziet natürlich in die Höhe.

Aber dennoch habe ich die Hoffnung, daß es in Zukunft noch schneller läuft, denn sonst wird das Entwickeln von großen Projekten auf dauer doch etwas nervig.
Es könnte z.b. helfen, wenn es wirklich einen Linker und einen build Ordner gäbe, und somit nicht ALLE Module jedesmal neu kompiliert werden müßten.

Auch würde ich mir für die prekompilierte gepublishte Version einen Code Optimizer wünschen, um Lite-C noch effizienter zu machen.

Wegen dem Level-Kompiler: Ich habe dann gestern doch noch einige kleine Tests mit der A7-Demo von der Download-Seite gemacht. Sobald man ein Modell über Import als statisches Mesh einlädt, kommen beim Kompilieren Fehlermeldungen und es lässt sich nicht mal ein Level fertig stellen. Dabei habe ich nur die Modelle ausprobiert, die mit Gamestudio ausgeliefert wurden.

Genauso wird es jedem Neukunden gehen, wenn er die Demo testet. Das ist ein schlechter Einstieg und wird natürlich Kunden abschrecken.

Ich bin nicht sicher, wie zufrieden man mit Lite-C ist. Vermutlich ist es sehr nett, wie einige von Euch schildern. Das ist gut. Wir dürfen aber nicht vergessen, dass Gamestudio keine Programmiersprache ist, sondern als Ziel hat, Spiele zu erstellen. Da ist die Programmiersprache eher Nebensache, ein Mittel zum Zweck, ein Werkzeug.
Wenn ich gerne coden will, lade ich mir einen Kompiler (sogar kostenlos) aus dem Netz und lege einfach los. Ich habe das tatsächlich in den letzten Wochen häufig gemacht. Ich habe C++ gelernt (es gibt richtig gute Tutorials dazu) und habe Irrlicht, Ogre, C4 gelernt und muss sagen, dass Irrlicht und Ogre sehr einfach aufgebaut sind, schnell rendern und Spaß machen.

Ich schreibe das allerdings nicht, um euch das schmackhaft zu machen, ich wollte nur mitteilen, dass der pure Programmierspaß auch anderswo gesucht werden kann. Hier hätte ich gerne das, was der Name verspricht: Ein Studio, um Spiele zu entwickeln. Da wäre es schön, wenn wenigstens die offizielle Demo funktionieren würde.

Ich habe bis jetzt nicht begriffen, warum es überhaupt Lite-C gibt. Viele Leute fragen nach immer mehr Fähigkeiten von Lite-C. Warum dann nicht gleich VC++ nehmen? Durch Torque bin ich jetzt auch gezwungen, VC++ zu lernen. Genau wie Friendly_Frank wühle ich mich durch C/C++-Tutorials. So schwer ist das auch wieder nicht.
Conitec hätte an dieser Stelle auf Lite-C verzichten können/müssen, zumal der Microsoft-Compiler wirklich nicht übel ist. Und mit Visual C++ Express sogar kostenlos.

Du kannst natürlich auch VC++ nehmen und dll programmieren, auch OpenGl oder DirectX programmieren,
sowie professionellere Model-Editoren etc.
Dann kannst Du aber auch gleich 3dgs links liegen lassen, und an deiner eigenen Engine Arbeiten...

Der Sinn ist doch eine möglichst einfache Anwendung für Leute, die gerade keine Low-Level Programmierung machen wollen,
da sie entweder keine Ehfahrung darin haben, oder keine Zeit dafür verschwenden wollen, und sich lieber
um das realisieren von Projekten kümmern.
Und C ist imer noch besser als eine (selbst entwickelte) Skriptsprache. Lite-C macht (oder soll) das C Programmieren einfach
und auf die Engine abgestimmt machen.
Die entscheidung kann ich nachvollziehen. An der Umsetzung kann man rummeckern.
Im Endeffekt ist acknex keine middleware-Lösung für andere Entwicklungsumgebungen, sondern soll
ein integriertes Paket sein für Leute mit weniger Wissen über Engineprogrammierung.

Timo arbeitet deshalb daran, soviel GameEdit Code in eine DLL zu pushen, weil es auf Grund der aktuellen Situation (langsame Kompilierzeit) ratsam ist. Aber es ist auch ratsam, weil sein Programm nur -eingebunden- werden muss. Somit sollte an sich überhaupt niemals Kompilierzeit auf GameEdit verschwendet werden - außer es dringend notwendig (wie bei Frame-Callbacks und so weiter). Selbst bei einem superschnellen Compiler wäre es Verschwendung jedes Mal ein eigenständiges Modul mit zig Tausend Zeilen von Code mitzukompilieren.

So ein Satz wie "Ihr 3DGS'ler seid Schuld" ist irgendwie frech. Weil wir als Kunden in der Regel doch keinen Einfluss darauf haben, wie das Produkt weiterentwickelt wird. Das muss in diesem Fall JCL und seine Jungs machen - macht er ja auch! Einige kleinere Features werden recht fix implementiert, der support ist gut und das alle "dicken" features nicht im Abstand von Tagen eingebaut werden ist rein logisch betrachtet doch auch klar ^^

Ich hab mir gerade mal die Beta-Page durchgelesen und habe mal ganz nüchtern festgestellt, dass in _jeder_ Beta Features dabei waren, die die meisten Leute zufriedenstellen - die Features decken Verbesserungen an shadern, shader-Zugänglichkeit, WED/MED (DDS Vorschau!), dem WED/MED SDK (jetzt könnt ihr eure ganz eigenen Features hinzufügen!), die Option auf engine-standalone Versionen (für Serverapplikationen z.B.), Postprocessing, Lite-C Verbesserungen, man kann Entities klonen, Skins auslesen, erzeugen, bitmap Funktionen, das neue Templatesystem usw. - ab. Ich glaube das ist ein guter Kessel buntes und fast jedes Feature wurde von usern requested.

Die Kehrseite der Medaille ist, dass das ganze Ding urlange braucht um "vorran" zu kommen - das nervt einige.. nämlich uns. Aber: wenn in alle Seiten entwickelt wird, kommen eben bestimmte Dinge erst später dran. Würde die Crew aber nur .. sagen wir mal am WED und dem Lightmapper arbeiten, dann wäre das früher fertig, aber alle anderen würden beklagen, dass die anderen Bereiche vernachlässigt werden.

Das Problem mit den Lightmaps musste ich letztens auch leidlicherweise einmal komplett durchmachen, sodass ich weiß, wovon Frank erzählt. Das ist ziemlich frickelig das Ganze und nutze daher Ventilators günstiges Plugin. Es wäre nett, wenn es das aus dem MED heraus gäbe aber so ist es auch zu schaffen.

@Frank: rede doch mal mit Herrn Lotter über eine Zusammenkunft bezüglich einer Tech/Grafikdemo und einem gegenseitigen Austausch über Feedback bezüglich der Möglichkeiten des Gamestudios und dem, was nicht möglich ist.

Ich habe jetzt mal versucht, nicht irgendetwas "glorreich" hervorzuheben (wie es mir in einem dieser threads letztens vorgeworfen wurde), sondern mal dem ganzen monotonen Gequengel was entgegenzusetzen. Damit meine ich ausdrücklich nicht die konstruktive Kritik gepaart mit echten und realisierbaren Vorschlägen im Austausch mit dem 3DGS Team - wie zum Beispiel die Workflow-Diskussion und die daraus resultierende Liste von gewünschten Features. Da haben sich alle mal zusammengerissen und es kam auch zu einem Dialog mit den Entwicklern. Auch ich würde einiges gerne anders haben, aber in solchen Fällen mache ich dann in der Regel einen konkreten einzelnen Vorschlag im Future Forum auf oder berichte den Bug ausführlichst mit einer Demo des Fehlers. In der Regel antwortet das Team auf solche Posts und nimmt Stellung dazu. Warum nicht so?

Natürlich sind die 3DGS'ler nicht Schuld, das war ein Spaß und eine Anspielung auf die vielen lustigen Anekdoten im Morbius

Ansonsten kann ich Dir (HeelX) nur zustimmen. Dein Post beschreibt die Situation ganz gut. Aber es ändert leider nichts an dem Fakt, dass die Demoversion (aufgrund halbherziger Features) nicht funktioniert.

Ich kann gerne mal, wie von Dir vorgeschlagen, einen Bug-Bericht vorbereiten. Mich wundert nur, dass es noch keiner gemacht haben soll, denn die A7 ist schon sehr lange draußen. Gibt es wirklich so wenige Leute, die damit arbeiten?

Die Lite-C Diskussion lenkt von einer Sache ab: Was soll eine Game-Engine wirklich leisten? Eigentlich sind es Licht- und Szenenmanagement und ein moderner Renderer. Alles andere dient diesem Zweck.

Tja, ich weiß auch nicht.. könnte vielleicht an einer fehlenden Techdemo liegen, die die Reize der A7 voll ausspielt. Ich denke, das ist die Motivation für den "A7 is nice!" contest der Ende Februar endet.

Ich würde mich darüber freuen - wenn du das durchziehst - dass du eine Art "Bericht" schreibst, indem du kühl den aktuellen Stand analysierst, mit Fallbeispielen (Bilder, Demodateien, etc.) gemessen am Stand der Technikund wie man es eventuell umgehen kann (als Hinweis darauf wie kompliziert manche Dinge sind). So wie die BILD Zeitung das immer macht ^^ dann ist die Bevölkerung auch immer außer Rand und Band und die Verantwortlichen sehen es dann ein und tun dann was oder so.

btw: http://www.microsoft.com/express/vc/Default.aspx

Irrlicht ist lediglich eine graphic library, das kann man natürlich nicht mit 3DGS vergleichen.

Ich möchte aber anmerken, dass c++ klare Vorteile hat. Einmal die schnellen Compilezeiten wg. Linker (wenn's das nicht gibt, dann ist das echt mal ziemlich sinnlos) und Klassen. Wer nie damit gearbeitet hat, der kann es auch nicht vermissen, aber ich kann sagen, dass - sobald die Engine halbwegs steht - die Programmierung deutlich leichter fällt.

Aber jeder wie er will. Der Aufwand, um grafisch auf Acknex-Stand zu kommen, ist relativ gering. Wenn ich nicht Programmierer wäre und momentan alles nur mit eckigen Blöcken programmieren würde, würde ich mal was mit Irrlicht zeigen.

MK1: Ich kann Dir da gerne helfen, wenn Du Content für Irrlicht brauchst.

Wobei ich sagen muss, Irrlicht ist zwar als Graphik-Engine konzipiert, aber das stimmt so nicht mehr. Durch irrKlang, irrEdit und das irrFormat ist es jetzt schon ein rundes Studio geworden.

By the way - Wo ich aber die härteste Konkurrenz für Gamestudio sehe sind folgende Tools:

Unity3d - wenn der Editor für Windows kommt, wird es den Markt aufmischen.

BV / GameCore - ich habe den Entwickler Blog der neuen Version gesehen und kenne Teams, die schon mit der Beta arbeiten. Der Lightmapper schlägt den von WED locker und der neue Renderer ist komplett shaderbasiert und damit auf neuer Hardware sehr schnell. Neue Shader können genutzt werden, indem man einfach die passende Textur (Normalmap, Specmap) dem richtigen Kanal zuweist. Mehr ist nicht nötig. Neue Schatten sind auch shaderbasiert.

Längerfristig könnte Torque2 die Konkurrenz aufmischen. Das Konzept ist sehr offen, modern und auf Indies wie auch AAA-Studios zugeschnitten. Aber das hat noch Zeit.

Die Konkurrenz schläft also nicht und unterstützt häufig mehr als nur Windows, aber derzeit muss man wohl noch etwas Geduld haben.

ja frank, sobald unity für windows kommt, werd ich definitiv umsteigen.. (leider dauerts ncoh jahre)


aber irrlicht, z.b. wenn ich mir die shots anschaue seh ich da nichts besonderes

na und?? wer braucht 2000fps? ist doch absoluter käse.. das geht mit 3dgs auch mit einem hohlen würfel und dem rechner den die da verwendet haben.

Ja Ello, bis auf die Shots von Rabcat sieht es dünn aus mit guten Irrlicht-Beispielen. Das Gleiche gilt für C4. Da findet man meistens Programmierer-Arts (nichts gegen Programmierer, ich bin selber einer ).
Allerdings habe ich über das WIKI ein Video von einem Projekt gefunden, dass irre geil aussieht. Ich hatte mal den Link bei Tools gepostet.

So war es bei Ogre auch am Anfang, aber jetzt haut es mich fast jedesmal aus den Socken, wenn ich da schaue, da sind professionelle Projekte, abgesehen von sowieso bekannten professionellen Deck 13 Projekten (Ankh) sind dort Autorennen, die Speed-Tree modernste Shader usw. einsetzen.

Somit muss wohl erst ein bestimmter kritischer Punkt erreicht werden, dass professionelle Teams aufspringen und ein Tool für ihre Projekte einsetzen. Dafür sind eigentlich nur 2 Dinge notwendig: flexible, schnelle Engine (die z.B. auch ein 2. UV-Set unterstützt), ein guter Workflow für die Künstler.

Wenn man mal die sehr professionellen Demos von Quest3d ansieht, erkennt man, dass ein Tool mit gutem Workflow für Künstler auch super geile Demos entstehen lässt.
Umgekehrt zeigt aber auch eine total flexible Engine wie Ogre, dass dieser Vorgang auch von Programmierern ausgelöst werden kann, wenn diese die Modelle perfekt rendern können (inklusive Lightmaps, was z.B. Deck13 mit einer 2. UV Map macht.).

Auch darüber habe ich nachgedacht, aber da kamen mehrere Probleme auf mich zu:

1) ist es erlaubt, am Contest mit externen Plugins teilzunehmen?
2) darf dieses Plugin später an andere 3dgs-User weiter gegeben werden? Ventilator will es ja noch verkaufen.
3) könnte ich dann theoretisch nicht auch eine Demo mit Sphere machen?

von welchem contest ist die rede (link) ?

AUM

sicher kann mein plugin mit einem gepublishten projekt weitergegeben werden. es ist an deine engine gebunden und läuft mit der engine von anderen usern nicht.

...
c/c++ hat im gegensatz zu lite-c z.b. keinen scheduler und den finde ich für spieleprogrammierung schon sehr praktisch.

Wer mal auf das Irrlichtforum geht, wird auch gute Screenshots finden.
Es ist auf jeden Fall genauso gut möglich wie mit Acknex, nur schneller.
Wie gesagt, wenn ich soweit bin, dass man mein Spiel wenigstens ein wenig spielen kann, dann kann ich mich mal um Grafikcontent kümmern und dann schauen wir mal.

Ventilator:
Genau da ist das Problem, falls ich das nicht falsch verstehe. Wenn das Plugin nur an meine Engine gebunden ist, läuft es bei den anderen doch nicht, wenn sie den Source-Code haben wollen.
Oder läuft es dann als Demo-Version weiter?

Wenn der Contest aber erlaubt, fertige kompilierte Projekte ohne Source-Code einzusenden, dann bin ich dabei

du könntest den source code ja trotzdem dazugeben! aber wenn ein user den code mit der eigenen engine starten will geht das nicht.

http://www.gstools.de/aum/aum68/fall_contest.htm

Ich habe nochmal den Text des Contests gelesen. Es steht nicht, ob man den Source-Code mitliefern muss. Es muss eine A7-Demo sein, die Conitec frei weiter geben darf. In welcher Form ist dort nicht beschrieben.

Der Preis eines Gutscheins von 300$ im Conitec-Shop ist eher weniger ein Anreiz und deckt bei Weitem nicht die Arbeit, die man in so ein Projekt steckt. Aber vielleicht könnten wir als Gemeinschaftsprojekt nur für Ehre und Ruhm soetwas gemeinsam auf die Beine stellen?

Also frage ich, Fogman, Ello, Ventilator, HeelX, MK1, Firoball und wer auch immer noch Interesse und Erfahrung mitbringen möchte: Wollen wir gemeinsam so ein Projekt angehen?

Ich stelle meine Modelle und Texturen zur Verfügung und würde weiteren Content erstellen. Jemand muss helfen, ein paar Shader zu basteln und wir brauchen funktionsfähigen Code für Kamera oder Player (hängt davon ab, ob es spielbar oder selbstablaufend sein soll). Partikel und dynamische Lichter wären auch nett.
Details klären wir dann im Team.

Die Frage ist: Was kommt dann?

Angenommen wir hätten eine wunderschöne Techdemo und sind dann ein eingespieltes Team - wäre es nicht für die Katz´, wenn sich alle hinterher wieder verlaufen?
Ich würde solch ein Projekt mit angehen, wenn es ein weiteres Ziel gäbe. Wenn sicher ist, daß die Techdemo nicht auf Conitecs Webspace verstaubt, sondern als Referenz für weitere Taten des Teams dient.

Das wiederum bedingt Dokumentation, Planung und auch regelmässige Treffen.
Halt richtig viel Arbeit, die sich lohnen muss.

Das würde ich ebenso sehen und begrüßen. Wenn so eine Kooperation funktioniert, sollte das eine feine Basis sein, darauf aufzubauen, das Projekt weiter zu entwickeln und sich der Öffentlichkeit zu präsentieren.

Es wäre sehr schade, so ein Team zu zerschlagen und ich glaube auch, dass der harte Kern sich sowieso dadurch zusammen rauft und gemeinsam weiter wirkt, wenn das Ergebnis fruchtbar war.

Hallo....

also eine Techdemo... sollte das zeigen wozu A7 mit den eigenen Mitteln in der Lage ist und nicht was möglich ist wenn man Plugins benutzt die man sich erst kaufen muss... Das verfälscht nur das Bild vom jetzigen Entwicklungsstand der Engine.

Würde mich also nicht davon überzeugen ein update auf A7 durchzuführen.

mpde

Warum sollte ich Werbung für die Engine machen wollen?
Mir würde es eher darum gehen, eine Userdemo zu machen.
Also nicht "was kann die Engine?" sondern "was können wir?"

Edit:

Ihr alten Erbsenzähler. (Scherz)
Wer was gemacht hat, lässt sich aus den Credits herauslesen.
Es ist so gesehen ja eine Techdemo der Techniken, die im Team zur Anwendung kommen.

das is dann aber keine techdemo, sondern ein team-demoreel

Okay, ich gebe mal ein kurzes Resume:

HeelX und Fogman haben Interesse an einer kleinen Demo bekundet, sind aber beide auch mit anderen Projekten beschäftigt. Mit Ello hatte ich vorher schonmal über so ein klitzekleines Projekt gesprochen.

Das Feedback ist also etwas ernüchternd. Wenn wir jetzt doch noch was zusammenstellen, dann vermutlich erst nach Weihnachten.

Ich brauche noch etwas Hilfe wegen den Shadern. Ich denke da an Nils, Ello oder xXxGuitar, die sich in der Vergangenheit als sehr hilfsbereit erwiesen haben. Aber vielleicht gibt es auch andere, die dabei helfen könnten, wie z.B. ChrisB, Excessus usw. Ich kenne vermutlich nicht jeden der Shader-Erfahrenen.