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

Aktuelle Zeit: Fr Apr 19, 2024 20:53

Foren-Übersicht » Sonstiges » Meinungen zu den Projekten
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 156 Beiträge ]  Gehe zu Seite Vorherige  1 ... 7, 8, 9, 10, 11  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 06, 2008 16:43 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Nun. Als weißer Programmierer der etwas auf Performance hält, prüft man ob die benötigten Funktionen in Hardware laufen und falls nicht wird ein Fehler geworfen. So wie hier.

Das Problem ist vielmehr, dass laut ausgabe deine Graka das nötige Feature unterstützt und trotzdem der Fehler kommt.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 06, 2008 16:44 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Flash hat geschrieben:
Wegen dem Wasser: Du kannst ja Brunnen und kleine "IndoorTeiche" einbauen. Sieht bestimmt gut aus.

Das hab ich mir auch schon überlegt. Brunnen werden schwer, da ich keine Partikel-Engine drinnen habe. "Indoor-Teiche" sollte aber gehen. Werds mir durch den Kopf gehen lassen.

Flash hat geschrieben:
Die Blumen auf deiner Wiese wirken irgendwie verschwommen. Ist die Textur irgendwie durchsichtig, oder woher kommt das?
Ich meine, es würde passen, wenn alles irgendwie gemalt aussieht. Aber alles andere ist messerscharf zu sehn, nur die Blumen irgendwie nich. Vielleicht kannst du die in Photoshop nochmal schärfen. Keine Ahnung ob das was bringt.

Das liegt daran, dass ich für die Screenshots ausversehen noch den Bloom-Shader aktiviert habe. Normalerweise sind die Blumen auch nicht so verwischt. Werd mir aber den Shader noch mal anschauen, vielleicht wird eine wichtige State-Variable von OGL durch die Blumen falsch gesetzt - mal schauen.

Flash hat geschrieben:
Das kostet doch ne Menge power. Liegt das an der Animation, oder an den Polygonen ansich? Wenns an der Animation liegt, würde ich vorschlagen das Gras kurz zu mähen, sehr dicht zu stellen und nicht zu animieren. Die Blumen kannst du dann darauf setzen und animieren. Ich denke das kommt gut. Zur vollständigen vewirrung der Betrachter kannst du ja an manchen stellen animiertes Gras in das statische einfügen. Dann kapiert keiner mehr, dass ein Teil still steht.

Das größte Problem ist die Tiefensortierung der Polygone. Das kostet sehr viel Power. Die Animationen spielen keine wirkliche bzw. eine fast vernachlässigbare Rolle. Es ist zwar schon so, dass durch die Berechnung vom sin+cos ein wenig CPU-Power gebraucht wird, aber die Tiefensortierung ist bei weitem schlimmer. Wenn ich jetzt noch einen extra Grasteppich hinzufüge, würde es wahrscheinlich in einer Diashow enden.

Yogu hat geschrieben:
Hallo,
ich habe die aktuelle Version deines Projektes herungergeladen und installiert, eine neue Gallerie erstellt und das Spiel gestartet. Dann kam aber folgende Meldung: [gekürzt]
Das nur als Fehlerbericht. Vielleicht kannst du den Fehler ja sogar beheben. Wenn du noch fragen hast, ich beantworte sie gerne.
Ach so, ja: Meine Grafikkarte unterstützt keine Multi-Texturen (was auch immer das sein mögen...). Das Programm sagte mir, ich soll eine neue kaufen.

Naja, die Fehlermeldung ist vielleicht etwas verwirrend. Deine Grafikkarte unterstützt zwar die Extension, aber es sind nicht genügend Texturunits vorhanden. Die Engine prüft, ob mindestens 3 vorhanden sind. Multitexturing ist übrigens ein Verfahren, bei dem man auf ein Polygon mehrere Texturen auf einmal zeichnen kann. Leider kann ich bei dir nur das sagen, was das Program auch schon gemeckert hat - eine neue Grafikkarte. Die Assertion ist ein Ergebniss davon, da durch die nichtvorhandene dritte Texturunit ein glError auftritt. Werd die Assertion aber heraushauen, da sie eigentlich einen anderen Teil überwachen sollte, der mittlerweile funktioniert. Ich werde auch noch die dritte benötigte Texturunit raushauen, so dass das Program automatisch einen anderen Renderpfad wählt, wenn nur 2 vorhanden sind.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 06, 2008 16:49 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 15:18
Beiträge: 62
Das klingt gut :D

Wieso fällt eigentlich gleich das ganze Spiel zusammen, nur weil ein Fehler auftritt? Du könntest doch eine Schaltfläche "Fortfahren" einbinden, die den Fehler einfach ignoriert. Wenn er wieder auftritt, kann man doch immer noch beenden.

Damit das jetzt nicht wie bloße Kritik aussieht: Ich finde die Menüsteuerung schonmal nicht schlecht. Und auch die Screenshots sehen vielversprechend aus... hoffentlich sehe ich das Programm noch "live".

Grüße,
Yogu


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 06, 2008 18:10 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Yogu hat geschrieben:
Wieso fällt eigentlich gleich das ganze Spiel zusammen, nur weil ein Fehler auftritt? Du könntest doch eine Schaltfläche "Fortfahren" einbinden, die den Fehler einfach ignoriert. Wenn er wieder auftritt, kann man doch immer noch beenden.


Gerade Assertions (generiert mit Assert(Bedinung, Meldung); ) sind Fehler, die nicht auftreten sollen und die einen Crash in den Programminternals markieren (wenn z.B. eine Variable nil ist, die eigentlich garnicht nil werden kann/darf), daher sollte man sie nicht einfach ignorieren.

Gruß Lord Horazont

_________________
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 Mai 06, 2008 19:43 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Wie Lord Horazont schon sagte sind gerade Assertions sehr wichtige Fehler. Stell dir mal vor, eine Variable würde jetzt nil sein, obwohl diese Variable auf einen bestimmten Speicherbereich zeigen sollte. Jetzt wirft das Progamm beim Zugriff eine Exception oder eine Assertion raus. Wenn man jetzt auf Continue klicken würde und die Variable immer wieder in einer Schleife die selbe Exception raushauen würde, dann würdest du das Programm nur noch mitm Taskmanager beenden können, da ja die ganze Zeit die Message-Box mit dem Fehler aufpoppen würde - und gerade das ist nicht sehr toll und sehr nervend. Außerdem ist der Benutzer dann so genervt/verwirrt, dass er 1. keine Ahnung mehr hat, wann und wo der ursprüngliche Fehler aufgetreten ist und 2. er kein Bock hat, den Fehlerbericht zu senden. Zudem könnten so Situationen entstehen, die schwer oder garnicht vorhersehbar sind. Es könnten z.B. dadurch die Daten auf der Festplatte überschrieben werden. Darum ist es dann doch sinnvoller zu versuchen, das Programm möglichst ohne weitere Konsequenzen zu beenden.

Edit
So, hab jetzt das minimale Multi-Texturing auf 2 gesetzt und den Renderpfad angepasst. Jetzt sollte es auch bei dir gehen, Yogu - über die Performance möchte ich aber nichts vorhersagen :twisted: (noch nen Edit: natürlich wird es erst mit dem release der neuen Version funktionieren, weiß nicht ob das bei meiner Aussage richtig rüberkam)

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 09, 2008 01:14 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Es ist soweit - Version 1.0 ist online. Alle Infos stehen im ersten Beitrag des Projektthreads.

Leider haben es zwei Sachen nicht mit in den Release geschafft. Zum einen die Anti-Aliasing-Unterstützung (da muss man wohl oder übel den Konfigurationsdialog des Grafikkartentreibes bemühen), zum anderen der Fehler, dass man durch das Level fällt, wenn man vom Fahrstul zerquetscht wird. Ich hatte bereits was eingebaut, doch dadurch hat die Synchronisation im Mehrspielerbereich nicht mehr gefunzt. Außerdem war es eher schlecht als Recht implementiert. Ich hab dafür eine Dead-Zone eingebaut. Wenn mal also durch das Level fallen sollte, wird man automatisch wieder neu ins Level gebeamt. Mich hat es einfach zu sehr unter den Fingern gejuckt, das Programm endlich online zu stellen.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 09, 2008 22:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 15:18
Beiträge: 62
Hallo,

die finale Version funktioniert jetzt auch bei mir. Wahrscheinlich deswegen, weil du die Multi-Texturing auf 2 gesetzt hast. Also kann ich jetzt auch ein richtiges Feedback abgeben :D

Die Welten sind schön gestaltet. Vor allem die Fenster finde ich faszinierend. Die Glasscheibe wirkt wirklich echt! :)

Die Figuren sind schonmal ganz ok, aber man könnte noch daran arbeiten. Vor allem sollte man nicht nur einstellen können, wie viele da sind, sondern auch, welche. Und außerdem haben mehrere Akteure oft gleichzeitig die gleichen Gedanken - sie stehen genau ineinander vor dem Aufzug, laufen ineinander hinein, und warten dann ineinander. Wenigstens die Kollision solltest du noch einbauen - dann ergeben sich auch neue Zufallsrichtungen.

Irgendwie ruckelt es bei mir ziemlich, obwohl ich die schlechteste Auflösung bei Vollbild eingestellt habe (800x600x16). Das wundert mich, es haben bei mir nämlich auch schon anspruchsvollere Spiele bei 1024x768 wunderbar gelaufen. Sooo schlecht ist mein PC auch wieder nicht...

Ansonsten: Well done! :D

Grüße,
Yogu


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 09, 2008 23:58 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Falls du es nicht nicht drin hast, dann kann folgendes ziemlich viel leistung rausholen.
Code:
  1.   glColorMask(FALSE,FALSE,FALSE,FALSE);  
  2.   glenable(GL_DEPTH_TEST);
  3.   glDepthFunc(GL_LEQUAL);
  4.   glenable(GL_CULL_FACE);
  5.   glCullFace(GL_BACK);
  6.   glFrontFace(GL_CCW);
  7.   ...
  8.   AllesZeichnen(ZPass);
  9.   glColorMask(TRUE,TRUE,TRUE,TRUE);  
  10.   glDepthFunc(GL_EQUAL);  
  11.   ...
  12.   AllesZeichnen(NormalerPass);
  13.  


Was wird gemacht ?
Die Colormask wird abgeschalten also wird nicht in den Grafikbuffer gezeichnet(nur in den Depthbuffer).
Dabei wird der Tiefentest auf LEQUAL gestellt, damit am ende man die Zwerte hat, die vorne sind.
Nun zeichnet man alles, was in die Szene gehört aber Shader(Vertexshader die für skinning sind natürlich anlassen),Texturen und so weiter werden abgeschalten, sowie transparente flächen garnicht gezeichnet(deswegen das ZPass flag als übergabe).
Nun schaltet man alle Farbkanäle wieder an und stellt den Tiefentest auf EQUAL, damit werden alle Pixel einer Fläche geskippt, wenn sie nicht wirklich vorne ist. Dies sorgt dafür, dass die Shader und Texturen nur einmal für jeden Pixel durchlaufen und den Prozess für jedes Vertice/Triangle frühzeitig abgebrochen wird, wenn es nicht wirklich das vorderste ist.
Also beim 2. Durchgang ganz normal zeichen, mit allen Shadern und texturbindings.

Wenn die Trianglecount höher wird, merkt man den unterschied ziemlich schnell.
Ein umstieg auf DXT1,DXT5 und ATI2(aka 3Dc) ist auch sehr zu empfehlen, das bringt auch ein spürbaren schub, wenn man mehere Texturen verwendet.

_________________
"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: Sa Mai 10, 2008 00:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Danke Yogu für das Lob. Ist immer schön zu hören, dass das Programm nicht nur mir gefällt :-)

Yogu hat geschrieben:
Die Figuren sind schonmal ganz ok, aber man könnte noch daran arbeiten. Vor allem sollte man nicht nur einstellen können, wie viele da sind, sondern auch, welche.

Ich weiß, dass die Models nicht gerade das gelbe vom Ei sind, doch ich persönlich kann keine Models erstellt. Dafür fehlt mir einfach das Wissen. Ich kann bisher mit keinem Modelprogramm wirklich umgehen. Wenn ichs könnte, würden die Figuren sehr menschlich und nicht gerade so abgedreht wirken.
Das mit der Auswahl der Figuren ist wirklich eine gute Idee. Nur ich habe gerade ein kleines Problem (ist wirklich überhaupt nicht böse gemeint): warum? Die Bots sind eher als Gimik gedacht und nicht als Hauptbestandteil. Ich weiß, dass du es nur gut meinst, doch ich will gerade etwas Abstand von dem Programm haben. Nach einer solch langen Entwicklungszeit will ich mir mal eine kurze Pause gönnen (so ein bis zwei Wochen). Wenn die Bots ein Hauptbestandteil wären, würde ich das sofort in die Tat umsetzen, doch leider fehlt mir gerade die Motivation - bitte deshalb nicht böse sein.

Yogu hat geschrieben:
Und außerdem haben mehrere Akteure oft gleichzeitig die gleichen Gedanken - sie stehen genau ineinander vor dem Aufzug, laufen ineinander hinein, und warten dann ineinander. Wenigstens die Kollision solltest du noch einbauen - dann ergeben sich auch neue Zufallsrichtungen.

Das habe ich bereits versucht, doch leider nur mit sehr schlechtem Erfolg. Ich müsste den Bots beibringen, mit ihrer Umgebung interagieren zu können, also anderen Person auszuweichen ohne gleich gegen eine Wand zu renden usw. Das ist höllisch schwer. Deshalb habe ich es bei diesem Kompromiss gelassen. Ich persönlich hätte auch im Moment keine Idee, wie ich das bewerkstelligen könnte. Wenn jetzt z.B. drei Bots direkt "aufeinander"/"ineinander" laufen, wie sollte ich jetzt wissen, welcher Bot kurz stehen bleiben soll und welcher nicht? Wer weicht wohin aus, wer bleibt zur Not im Fahrstuhl, wenn keine Zeit mehr ist? All diese Fragen sind nicht gerade einfach zu lösen.

Yogu hat geschrieben:
Irgendwie ruckelt es bei mir ziemlich, obwohl ich die schlechteste Auflösung bei Vollbild eingestellt habe (800x600x16). Das wundert mich, es haben bei mir nämlich auch schon anspruchsvollere Spiele bei 1024x768 wunderbar gelaufen. Sooo schlecht ist mein PC auch wieder nicht...

Ich weiß, dass meine Engine nicht gerade sehr schnell ist. Doch das Problem ist: ich finde den Flaschenhals nicht wirklich. Ich habe schon so viel Ausprobiert doch nichts hat wirklich etwas gebracht. Ich hab sehr viel Zeit in die Optimierung gesteckt, doch alleine kann ich niemals die Qualität und Geschwindigkeit von kommerziellen Produkten erreichen. Wenn ich fragen darf: Welche Spiele laufen den bei dir sehr gut?

@TAK2004
Das ist ja mal interessant. Auf sowas wäre ich niemals gekommen. Nur dafür muss ich sehr viel verändern. Alle statischen Objekte, die keinen Shader haben, nicht per Blending gezeichnet werden müssen oder ähnliches, werden komplett in eine DisplayList geschrieben - zusammen mit allen Texturbindings. Jeder Raum hat solch eine DisplayList. Es werden dann beim eigentlichen Rendern nur die DisplayLists der wirklich sichtbaren Räume aufgerufen. Danach werden alle sonstigen Objekte, die sich nicht in der DisplayList befinden, gezeichnet. Ganz zum Schluss werden die Blending-Elements gezeichnet (natürlich tiefensortiert bzw. Abstand-Zur-Kamera-Sortiert). Die einzelnen Elemente, die nicht in einer DisplayList vorhanden sind, werden in seperaten Listen gespeichert um nicht immer alle Objekte eines Raumes durchgehen zu müssen.
Jetzt ist die Frage: ist das nicht schon relativ gut optimiert? Ist das vielleicht langsamer als ohne DisplayListen? Würde bei sowas deine Methode wirklich noch etwas herausholen? Ich frag das lieber vorher, bevor ich mir noch die Mühe vielleicht umsonst mache.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mai 10, 2008 09:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Es kommt auf die Szene an und wieviel shader du im Einsatz hast.
Ich bin darauf gekommen(paper von ati), als ich mein SceneGraph optimiert habe.
http://developer-alliance.org/?site=006.png
Da hier viele Objekte sind, die hintereinander angereiht sind, bringt es schon bei dem Simplen Lighting Shader 2stellige FPS schübe.
Je komplexer die Shader werden(texturzugriffe ganz besonders) schiesst der Wert noch wesentlich steiler hoch.
Bringen tut es nur nichts, wenn du fast leere Räume hast und auch immer nur 1 Raum gezeichnet wird(durch sichtbarkeitsbäume).
Man profitiert halt davon, dass bei Pixeln, wo mehere Objekte in frage kommen, dann Shaderzeit eingespart wird.
http://developer-alliance.org/?site=016.png
Selbst in der Szene hat es schon FPS unterschiede gegeben, obwohl nur ne handvoll Pixel mehere Kandidaten bieten.

Von Displaylisten würde ich mich ganz schnell trennen, schlimmer gehts eigentlich nicht.
Für sehr Leistungs optimierte darstellung rate ich eine Klasse zu schreiben, die VBO Kapselt(vertice,colors,normals,texcoords,indices), dann eine Klasse, die pointerliste auf die Shader/Texturen hällt und eine Faceliste, wo start Index,Count und Index auf pointerliste enthalten sind.
Eine Methode Draw geht dann die Faces durch und kann nun die Shader/Texturen binden und dann zeichnen(wenn die einzelnen Daten zugelassen sind).
siehe TKar_Mesh

Meine neue Implementierung Abstrakte Meshklasse
OpenGL implementierung von VBO und abgeleitete Meshklasse.
Passendes neues ModelFormat
Also TKar_Mesh wird von der Engine zur darstellung angeboten und kann mit Daten gefüllt werden.
TKar_Model ist eine Datei Format spezifische implementierung(für Obj,3DS,MD5 oder andere müsste eine weitere Implementierung her), die das TKar_Mesh mit Daten befüllt und eine zeichenroutine mitbringt, die dann mit den Faces und Flags zeichnet.
Durch die UseColor,UseNormals,... Flags in der Meshklasse kann man der zeichenmethode sagen, welche buffer gebunden werden sollen.
Dieses Klassenkonstrukt ist sehr flexibel einsetzbar, drum hat es sicht seit X-Dream zeiten fast garnicht verändert.
An der stelle möchte ich dann auch anmerken, dass die Implementierung durch Templates den Code stark reduziert :)

_________________
"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: Sa Mai 10, 2008 10:35 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
@TAK: Die Idee gefällt mir wirklich. Das werde ich auf jeden fall für mich in die ToDo-Liste aufnehmen. Gut, dass ich das vorher erfahre :wink:

@littleDave: Wenn du nicht auch das glEnable(GL_TEXTURE_2D) mit drin hast, kannst du vielleicht trotzdem was rausholen. Du aktivierst vorher einfach die Texturen nicht, so sparst du auch die Lookups, oder?

Gruß Lord Horazont

_________________
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: Sa Mai 10, 2008 11:39 
Offline
DGL Member

Registriert: Mi Mär 31, 2004 15:24
Beiträge: 114
Hi!

Ich wollte mal mein Lob hier lassen! Sehr stimmige Atmosphäre, vor allem im großen Level, wie ich finde. Die Musik passt auch sehr schön. Lensflare sieht wirklich gut aus, und auch die Specularmaps. Da hat sich ja wirklich was entwickelt! Respekt!

Zwei Verbesserungsvorschläge hätte ich:
Ich würde versuchen die Pflanzen im Innenhof ohne Billboards zu realisieren. Die sehen von weitem schon echt gut aus, nur beim Betreten des Hofes fliegt der Billboardeffekt auf.

Ich persönlich (ich glaube aber, viele Leute sehen das anders) komme mit der Art des Gehens nicht gut klar. Die weichen Übergänge, und die leichte Neigung beim Seitwärtslaufen. Sieht zwar gut aus, macht mich aber schwindelig :) Wenn es passen würde, dann könnte man es ja vielleicht irgendwo optional "ausschalten".

Aber noch einmal: Respekt!

Viele Grüße,
Rüdiger


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mai 10, 2008 12:23 
Offline
DGL Member

Registriert: Di Mai 24, 2005 16:43
Beiträge: 710
Großartiges Programm, sieht wirklich gut aus.
(Die Grafik erinnert mich an Splinter Cell ;) )

Ein paar Kleinigkeiten:
Standart statt Standard im Menü unter Audio
Man müsste nen Runtoggle machen können oder Rennen immer aktivieren, mir läuft der Spieler viel zu langsam ;)
Der Introtext läuft zu schnell vorbei
Mehr Levels wären cool (wobei ich natürlich verstehe, dass das mit einem enormen Aufwand verbunden ist)

mfg


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mai 11, 2008 14:08 
Offline
DGL Member

Registriert: Di Sep 19, 2006 13:24
Beiträge: 173
Echt super das Programm!

Bei mir stürzt der Galeriecreator manchmal ab wenn ich nen Ordner draufziehe, ich glaube das liegt dadran das er auch nicht Bilddateien die sich dadrin befinden können benutzen will.

Ich würde vielleicht noch im Programm als Alternative zu den Galerien anbieten das man einfach einen Ordner "anschauen" kann.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 12, 2008 13:42 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
@Lord Horazont: glEnable(GL_TEXTURE_2D) ist leider mit in den Display-Listen vorhanden. Das liegt daran, dass manche Surfaces zwei Textur-Units haben und machen gar keine. Ich müsste wahrscheinlich eher eine globale Boolean-Variable erstellen, die dann sagt, ob Texturen verwendet werden sollen.

@TAK2004: Warum sind die DisplayListen so schlimm? Ich habe schon sehr oft gelesen, dass DisplayListen immernoch schneller als VBOs sind, da die Grafikkarte beim kompilieren diese noch weiter optimieren kann, oder täusche ich mich da? Der Vorteil von VBOs ist doch, dass man sozusagen eine Art DisplayList hat, die man aber verändern kann, oder sehe ich da was ganz ganz falsch? Ich hab noch nie mit VBOs gearbeitet, deswegen sträube ich mich gerade etwas davor.

@Rüdiger: Danke für deinen positiven Kommentar, sowas liest man immer sehr gerne. Mit den Billboards hab ich mir auch schon gedanken gemacht. Wahrscheinlich werd ich mich von denen mal trennen müssen und einfach zwei senkrecht aufeinander stehende Quads nehmen - naja eigentlich eher 4 Quads, sonst funktioniert das Blending nicht mehr. Mit dem gehen (inkrementelle Geschwindigkeitsveränderung, leichtes Neigen) hatte ich persönlich noch keine Probleme. Ich fand es persönlich etwas besser, wenn die Steuerung nicht ruckartig ist. Ich werds mir überlegen und vielleicht eine weitere Option in Version 1.1 einbauen.

@Seth: Danke für dein Lob, doch die Grafik von Splinter Cell ist noch um Welten besser. Dynamische Licht- und Schatteneffekte (was ja der Hauptteil von Splinter Cell ist) ist bei mir ja überhaupt nicht vorhanden. Ich meine, es ist zwar wirklich super zu hören, dass einer meine Engine mit einer kommerziellen vergleicht, doch ich muss mich da selbst wieder etwas auf den Boden der Tatsachen zurückschrauben. Zu deinen Punken:
  • Standart -> Standard: danke, hätte ich nie gesehen. Habs schon ausgebessert und wird ebenfalls bei Version 1.1 dabei sein
  • Runtoggle: gute Idee, ist sogar mit relativ wenig aufwand zu verwirklichen. Wirds ebenfalls bei Version 1.1 geben, sehr gute Idee
  • Introtext: dann passt die Musik aber nicht mehr, wenn ich alles langsamer mache. Ist ja eigentlich auch eher eine Spielerei von mir ;-) Vielleicht lässt sich da noch was drehen
  • Mehr Levels: das wird eine ganze Weile dauern, da ich mir erstmal überlegen muss, wie die einzelnen Teile aufgebaut werden soll, in welchen groben Rahmen die Levels seien sollen (z.B. eine Höhle oder in einer Weltraumstation usw). Sobald ich mir sowas überlegt habe, kommt der eigenltich langwierige Teil - die Umsetzung. Hab zwar mal angefangen, an einer neuen Lobby für ein weiteres Level zu arbeiten - aber ich habe den eigentlichen Plan, den ich mir dafür vorgenommen habe, nicht aufgeschrieben und wieder vergessen. Somit liegt jetzt ein kleines Level brach auf der Platte.


@gucky: Was für eine Fehlermeldung kommt denn, wenn du einen Ordner auf das Programm ziehst? Kommt das nur, wenn du Ordner draufziehst, in denen überhaupt keine Bilder sind oder auch schon, wenn manche Dateien keine Bilder sind? Ich hab eigentlich beide Szenarien getestet und hatte das Problem bei mir nicht beobachten können. Wäre sehr gut, wenn du das Problem nochmal reproduzieren könntest und mir dann schreibst, was genau passiert.
Deinen Vorschlag hab ich nicht ganz verstanden, mit dem Extra-Programm. Meinst du sowas wie eine einfache SlideShow für einen beliebigen Ordner? Also komplett ohne den ImageViewer?

@All:
Ich habe vorgestern eine neue Version sowie einen Patch online gestellt. Die aktuelle Version ist jetzt 1.0.1. Der Download-Link befindet sich im ersten Beitrag des Projekt-Threads. In dem Patch hab ich endlich die Ordner, in denen die Konfiguration sowie die Picture-Sets gespeichert werden, aus dem Programm-Ordner ausgelagert. Somit sollte das Programm jetzt auch ohne Admin-Rechte und unter Vista laufen (bis auf das Problem mit Aero-Oberfläche + OpenGL). Die Picture-Sets werden jetzt in C:\Documents and Settings\[UserName]\My Documents\My Pictures\My Picture Sets\ gespeichert. Die Konfiguration sowie alle gedownloadeten Daten werden in C:\Documents and Settings\[UserName]\Application Data\Sysygy Image Viewer\ gespeichert. Die bisher erstellten Picture-Sets, die in [Hauptverzeichnis]\Galleries gespeichert wurden, werden ebenfalls mit beachtet. Es ist also nicht notwendig, die Dateien in die neuen Ordner zu kopieren. Nur die Konfigurationsdateien werden aus dem alten Ordner nicht mehr ausgelesen. Diese kann man aber manuell nach C:\Documents and Settings\[UserName]\Application Data\Sysygy Image Viewer\Config verschieben. Die Ordner erstellt das Programm automatisch.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Zuletzt geändert von littleDave am Mo Mai 12, 2008 14:32, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 156 Beiträge ]  Gehe zu Seite Vorherige  1 ... 7, 8, 9, 10, 11  Nächste
Foren-Übersicht » Sonstiges » Meinungen zu den Projekten


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 53 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.155s | 17 Queries | GZIP : On ]