Eigenes MMOG

Hier können wir über andere Adventurespiele und ähnliches diskutieren.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 03.05.2005, 16:24

Letzter Beitrag der vorhergehenden Seite:

Aber ersteinmal kurz zur Hauptengine zurück:

Ich habe mir überlegt, dass ich folgende Milestones für den Anfang definiere:

1. Milestone: ein Raum mit einer Figurengrafik (statisch), die durch Mausklick an einen gültigen Ort bewegt werden kann auf einem gültigen Weg (ohne gültigen Weg code ich das in recht kurzer Zeit zusammen, daher diese Zusatzanforderung)

Wenn diese steht, kann Gu.Ro, der mir im Rahmen seiner Programmierkenntnisse in Visual Basic seine Unterstützung zugesagt hat, schon mal beginnen, an einem Leveleditor zu programmieren

2. Milestone: mehrere Leute in einem Raum, die herumlaufen können, gesteuert durch einen Server (hierbei ist eine besondere Anforderung, dass nichts passiert, wenn einer der Clients "abgeschossen" wird).

3. Milestone: In Abhängigkeit davon, ob der Leveleditor weit genug ist, wird die Engine entweder um einen Chat oder um volle Unterstützung zum Laden von Levels erweitert.

4. Milestone: der im 3. Milestone fehlende Punkt

5. Milestone: Wechseln von Räumen, rudimentärer Objektsupport (anschauen; nicht manipulieren)

das dürften für den Anfang genug Milestones sein

Ich bitte zu beachten, dass mit 99%iger Wahrscheinlichkeit die ersten beiden Milestones sehr lange dauern werden (Faustregel: für die ersten 10% des Codes braucht man 90% der Zeit, der Rest geht schnell und für das Debuggen am Ende braucht man wieder 90% der Zeit).

Für das Levelformat wird XML herhalten: das ist sehr universell und weit verbreitet (wenn auch nicht extrem schnell einzulesen). Es sei denn, jemand hat eine bessere Idee.

In C++ weiß ich, gibt es eine Lib zum Auslesen von XML-Dateien im Internet. Bei Visual Basic gibt es sicher auch eine, ich kenne aber keine, da ich nicht in VB code.

Für das Berechnen eines gültigen Ortes und Weges habe ich mir folgendes ausgedacht:

der Ort, in dem sich der Avatar aufhalten darf, ist durch das Innere eines sich nicht selbst schneidendes Polygon mit den Ecken p1 bis pn festgelegt.

Wenn man an eine Stelle klickt, wird der Avatar ersteinmal versuchen, an diesen Ort zu gelangen (vorausgesetzt, die angeklickte Koordinate liegt innerhalb des Polygons). Wenn er dabei jedoch eine der Kanten überschreiten müsste, dann ist dieser Weg ungültig. In diesem Fall werden im Polygon 3 Ecken mit der Eigenschaft gesucht, dass der Character innerhalb des durch diese 3 Ecken aufgespannten Dreiecks steht und sich keine sonstige Ecke des Polygons sich innerhalb dieses Dreiecks befindet (wenn dies der Fall ist, tauscht man eine der Ecken des Dreiecks so gegen die, welche sich innerhalb befindet aus, dass die Eigenschaft, dass sich der Character innerhalb des Dreiecks befindet, erhalten bleibt. Eine solche Ecke muss es immer geben).

Ebenso bildet man für die Stelle, wo hingeklickt wurde ebenso ein solches Dreieck.

Nun sucht man von jedem Eckpunkt des "Characterdreiecks" einen Weg zu einer der Ecken des "Zieldreiecks" (über die verschiedenen Eckpunkte, wobei man überprüft, ob man von einem Eckpunkt zu einem anderen gelangen kann, ohne eine Kante des Polygons zu kreuzen) und speichert den kürzesten Weg von einem Eckpunkt des "Characterdreiecks" zu einer der Ecken des "Zieldreiecks" ab. Anschließend lässt man den Character den folgenden Weg laufen:

Vom aktuellen Punkt zum Startpunkt des Weges.
Von dort den Weg ablaufen und bei einem der Knoten des Zieldreiecks landen.
Von dort zum Punkt laufen, an den geklickt wurde.

Nun fehlt noch der Fall, dass an einen Punkt geklickt wurde, der außerhalb des Polygons liegt, in dem sich der Character bewegen darf. In diesem Fall bestimmt man den Punkt innerhalb des Polygons, der am nächsten zur Mausklickposition liegt. Das ist einfacher als man denkt: Einfach den Abstand zu allen Kanten des Polygons berechnen und überprüfen, bei welcher Kante er mininmal ist und auf dieser Kante den Punkt finden, der am nächsten zum angeklickten Punkt liegt (vom per floating-point-operations berechneten Punkt ggf. in alle Richtungen um 1 bis 2 pixel schauen, dass es innerhalb des Polygons liegt).

Okay, ich weiß, das ist nicht einfach (insbesondere der Suchalgorithmus bereitet mir Kopfschmerzen): allein: hat jemand eine bessere Idee, wie man die Wegfindung implementieren könnte?
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
Thoro
Forscher
Beiträge: 1494
Registriert: 23.09.2004, 14:43
Geschlecht: männlich
KI-Nummer: 529779
Wohnort: Duisburg
Alter: 42
Kontaktdaten:

Beitrag von Thoro » 03.05.2005, 16:40

(Faustregel: für die ersten 10% des Codes braucht man 90% der Zeit, der Rest geht schnell und für das Debuggen am Ende braucht man wieder 90% der Zeit).
Das sind dann doch schon 180% der Zeit ... :kratzen:
Für das Levelformat wird XML herhalten: das ist sehr universell und weit verbreitet (wenn auch nicht extrem schnell einzulesen). Es sei denn, jemand hat eine bessere Idee.
Wenn es sich um reine Datensätze (vornehmlich mit Strings realisiert) handelt, ist XML sicherlich eine gute Idee. Wenn es jedoch um große Zahlenkolonnen oder irgendwelche Binärdaten geht, ist dieses Format einfach irgendwie unpraktisch. Und ich denke mal für die ganzen Polygonzüge werden eine Menge Zahlenkolonnen anfallen. Da schwillt das Datenformat regelrecht über. Dann wäre ein schnell zu lesendes Binärformat praktischer.
In C++ weiß ich, gibt es eine Lib zum Auslesen von XML-Dateien im Internet. Bei Visual Basic gibt es sicher auch eine, ich kenne aber keine, da ich nicht in VB code.
Also für VB ist mir noch keine bekannt. Sollte es aber doch hoffentlich irgendwo geben ... vielleicht ...
Sarkasmus ... wie originell.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 03.05.2005, 17:05

Also so viel Daten, die gespeichert werden müssen, fallen mir nicht ein:
die ganzen Grafiken in PNG-Dateien (kann SDL_image auslesen).

Dann noch pro Raum ein Polygon mit vielleicht 20-30 Ecken (ziemlich sicher nicht allzu viel mehr), die außerdem für die Perspektivkorrektur und Sichtbarkeit verwendet werden (vor der Beschreibung dessen habe ich euch verschont, da sie schon kompliziert genug ist). Das heißt lediglich ein floating point mehr zusätzlich pro Ecke. Außerdem ein paar "Spawn Points" im Raum. Und noch ein paar Interaktionsregionen (nur Stelle wo sich die Grafik befindet und Name des Scripts). Ach ja: da fällt mir die weise Frage ein: was für eine Scriptsprache soll verwendet werden. Meine spontane Wahl fiele auf Lua, aber kennt jemand was besseres?

Da bin ich der Meinung, dass die XML-Datei nicht zu groß wird. Vielmehr stellt sich IMHO eher die umgekehrte Frage, ob da XML nicht dem Schießen mit Kanonen auf Spatzen gleicht. Der Vorteil von XML ist halt, dass man das einfach als Zeichenstring abspeichern kann und durch das textähnliche Format Änderungen im Dateiformat erheblich einfacher sind (das stellt ein ziemlich gewaltiges Problem da, wenn neue Erfordernisse für das Format auftauchen und noch viele Dateien im alten Format sind (da muss man auch noch das alte Format lesen können, wodurch diese Routine stark aufgebläht wird), geschweige denn das Problem, wenn man Dateien in einem alten Format einliest => da hilft es nur Versionsinformationen einzubinden). Ich meine: es ist kein Problem für mich, mir irgendein Binärformat auszudenken. Ich dachte nur, dass XML das ganze vereinfacht, da man dann nicht ganz so viel vollkommen neu programmieren muss.

Wo sich die ganzen Gegenstände befinden, halte ich für unpraktisch in den Räumen zu speichern, da die doch sowieso dauernd den Besitzer wechseln. Daher wird dies vom Server verwaltet.
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
Gu.Ro
Forscher
Beiträge: 217
Registriert: 02.05.2004, 17:37
Wohnort: Zwickau
Alter: 74

Beitrag von Gu.Ro » 03.05.2005, 19:45

Hallo Searcher,

vielleicht ist es an dieser Stelle sinnvoll erst mal etwas mehr über den Raum zu sprechen, in dem alles stattfinden soll. Wenn ich bis jetzt alles richtig verstanden habe, soll die Handlung in einem echten 3D-Raum stattfinden, der aber mit Hilfe von 2D- oder Pseudo-3D-Grafiken dargestellt wird.
Wenn die Darstellung dieses Raumes aus unterschiedlichen Blickwinkeln möglich sein soll, so müssen alle Objekte (Bäume, Häuser, usw.) einzeln verwaltet werden. Damit solche Szenen nicht zu plump erscheinen, wird es vielleicht sogar notwendig sein, manche Objekte aus mehreren Teilobjekten zusammenzusetzen. Das spricht zwar einerseits für XML, da damit eine sehr gute Strukturierung möglich ist, andererseits werden die Dateien wohl doch recht groß werden. Vielleicht sollten wir hier erst einmal versuchen, "irgend eine" allgemeine Form der Objektbeschreibung zu finden um danach zu entscheiden, ob XML günstig ist.

Zur Bewegung der Spielfiguren hätte ich folgende Idee:
Die Figur bewegt sich auf dem Boden des Raumes. Die Höhe des Bezugspunktes (Z) der Spielfigur kann damit "zwangsgeführt" werden, d.h., sie wird automatisch abgeleitet von der Höhe des Bodens.
In der X-Y-Ebene gibt es Bereiche, die die Figur betreten kann, und solche, die ihr verboten sind. Das lässt sich einfach festlegen, durch eine S/W-Grafik, in der z.B. die schwarzen Punkte "verbotenes Gebiet" bedeuten.
Ein Befehl zum Bewegen der Figur ist nur möglich, wenn ein direkter Weg zwischen Start- und Endpunkt erlaubt ist, oder die Figur umgeht "verbotene Gebiete" indem sie solange am "Rand" entlang läuft, bis wieder ein direkter Weg zum Ziel möglich ist.

Viele Grüße
Gu.Ro
Benutzeravatar
pali64
Forscher
Beiträge: 935
Registriert: 13.05.2004, 18:19
Geschlecht: männlich
Wohnort: Bayern
Alter: 61
Kontaktdaten:

Beitrag von pali64 » 03.05.2005, 20:20

Also TheSearcher
wenn ich das alles so lese dann wäre doch eine Umsetzung mit dem M.H. Konzept gar nict so daneben? der unterschied ligt darinn das bei uns chte 3D umgebungen und Gerenderte bilder zusammenkommen (Also beispielsweise die Welt in der Ferne oder Stäte oder oder oder?
Sollen wir unsere Kräfte nicht vereinen?
Ein Programmierer bei uns hat sogar teile von Augera inklusive die Treppe nachgebaut also so einfach zum sagen wäre eine Komplette URU Qualität erreichbahr! aber aus C right gründen müssen wir uns sehr zurückhalten.
Also warum schliessen wir uns nicht zusammen TheSearcher?
Ich glaube wenn wir Mehrere wären wäre ein Kompettes URU Live Feeling Möglich? weil wir arbeiten an einer Engine die auch unter Linux und ev sogar unter Apple OS läufen sollte. Was Meint Ihr? anstat zu verzetteln unsere Kräfte Vereinen? wass ja mal mein Urgedanke wahr?
Deshalb half ich ja auch mit als der Erste deutsche Server in Betrieb genommen wurde es war ja an meiner Backbound leitung....
das URU Live lebt in Mysteri-House und UntilUuru weiter :wink:
and URU live continued in Mysteri-house and UntilUru
http://www.mysteri-house.ch
Bild
Benutzeravatar
Locutus
Forscher
Beiträge: 3132
Registriert: 23.05.2007, 17:26
Geschlecht: männlich
KI-Nummer: 626986
Wohnort: Mitteldeutschland
Alter: 47
Kontaktdaten:

Beitrag von Locutus » 03.05.2005, 20:41

Wenn ich hier so mitlese, stimme ich dir voll und ganz zu pali. Ich finde ihr solltet euch zusammen tun. Das wäre auch jeden Fall eine Bereicherung für alle Beteiligten.
"Qualität schreibt man mit mYst, oder würdest du für die fatale Schreibverschreibung haften wollen? ... Ich rauche nur URU, denn was anderes kommt bei mir nicht in die Tüte!"

:clever:
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 04.05.2005, 10:00

@Gu.Ro:
Nein, es wird rein technisch alles in einem 2D-Raum stattfinden. Also von daher ist deine Vermutung falsch. Vielmehr handelt es sich bei dieser Zusatzkoordinate um einen Wert, der lediglich eingerechnet wird, um Perspektive darstellen zu können - es bleibt trotzdem alles 2D (warum ich nicht 3D vorhabe, habe ich ausführlich begründet). Vielleicht entstand die Verwirrung dadurch, dass ich geschrieben habe, dass ich OpenGL vielleicht mit verwenden will, welches den meisten als 3D-Api bekannt ist. Ist es auch, allein: man kann auch die 3. Koordinate auf eine Konstante setzen und dann hardwarebeschleunigt 2D-Grafik machen.

Zur Wegfindung ist mir gestern Nacht eine andere Idee gekommen, die der von Gu.Ro gar nicht so unähnlich ist:
in der Tat spielt auch hier eine Betretbarkeitsbitmap (Schwarzweiß oder Graustufen, wobei dann schwarz für "nicht betretbar" steht) eine Rolle, lediglich mit dem Unterschied, dass da die Wegsuche mit dem A*-Algorithmus durchgeführt wird. Ist zwar rechenaufwändiger, aber einfacher zu implementieren. Die Graustufen-Informationen könnte man zur Perspektivkorrektur verwenden (wer auch immer die Levels designert, wird mich für diese Idee umbringen, aber das Risiko muss ich eingehen).

@pali:
Die allerdümmste Idee wäre die Zusammenführung nicht - ich will es nicht leugnen.
Allerdings ist das bei Mysteri House zur Zeit als Engine verwendete Programm meines Erachtens einfach bei weitem nicht flexibel genug - ich bin halt einfach der Typ: wenn ich eine Idee habe, dann will ich nicht durch eine schlechte Engine daran gehindert werden, sie umzusetzen, sondern allein durch meine Pogrammierfähigkeiten.
Wenn ihr jedoch tatsächlich eine neue Engine programmieren wollt, dann bin ich grundsätzlich interessiert mich anzuschließen (ich bin wirklich nicht der Typ, der um jeden Preis selbst etwas auf die Beine stellen muss, wenn es wenig sinnvoll ist).
Sende mir einfach mal die technischen Details der Engine, die ihr programmieren wollt, dann werde ich mal schauen, wie ich fortfahren werde.
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
pali64
Forscher
Beiträge: 935
Registriert: 13.05.2004, 18:19
Geschlecht: männlich
Wohnort: Bayern
Alter: 61
Kontaktdaten:

Beitrag von pali64 » 04.05.2005, 14:50

Ich werde es mal G0 weiterleiten, dass er mit dir Verbindung aufnehmen soll, weil ich Kümmere mich haubtsächlich um die Skripte und die Welten selbst. Aber so viel ich weis oder eher meine Geldbörse :? habe ich geld ausgegeben füe Darkbasic Purebasic.... und div 3D Enginen aber er hat wass gesagt das er die 3D engine in "C" xxx programiert habe aber eben K.A.
Gruss pali64 ;)
PS: Apropo Flexiblität die einzige einschränkung di mir Bekannt ist, ist das es nur mit IE under Windows funktioniert aber sonst? kann ich alles programieren wass ch will. :shock:
das URU Live lebt in Mysteri-House und UntilUuru weiter :wink:
and URU live continued in Mysteri-house and UntilUru
http://www.mysteri-house.ch
Bild
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 05.05.2005, 16:36

Ich erhielt eine EMail von Gu.Ro, der anhand einer selbst programmierten Bibliothek eine Möglichkeit gefunden hatte, wie man sehr schnell eine lauffähige Demo erzeugen könnte.

Ich will nicht leugnen, dass die Methode grundsätzlich funktionieren könnte (wenn ich es wollte, hätte ich schon längst auch mit SDL etwas, was irgendwas grafisches enthält, zusammengebastelt und hier zum Download angeboten).

Allerdings: schnell irgendetwas schön aussehendes erzeugen bringt nichts. Der Effekt ist folgender: dann hat man zwar ein wenig Grafik, aber wenn man es erweitern will, wird es sehr aufwändig (eine leidvolle Erfahrung, die ich bei "Ayirah" machen musste).

Da behandle ich es lieber umgekehrt: ich baue von Grund auf das Programm auf (als tiefste Ebene ein System der Interaktion zwischen Räumen, Charakteren und Objekten) und wenn das solide ist, baue ich ein Grafiksystem drumherum.

Ich will nicht leugnen, dass es viele Leute anders machen, ich will auch nicht leugnen, dass das viele Spiele-Firmen anders machen. Ich behaupte aber, dass es eine schlechte Idee ist, es anders zu machen (okay, um ganz ehrlich zu sein: ganz 100% halte ich mich auch nicht dran, aber grundlegend lege ich mir die oben genannte Herangehensweise als Maxime auf).

Der Grund, warum viele Spiele-Firmen es anders machen, ist der, dass der Chef gerne möglichst schnell etwas schön grafisches sehen will. Was für Folgen das später hat, weiß jeder: Release-Termine werden stark überschritten und Beta-Versionen werden auf den Markt geschmissen. Später erscheinen Patches, die neue Bugs schaffen, einfach weil das dem Spiel zugrundeliegende Fundament sehr zusammengehackt ist (erinnert euch das an etwas). Jemand, der in der Computerspielebranche arbeitet, schrieb sogar mal, dass es angesichts dessen fast einem Wunder gleicht, dass die meisten Spiele überhaupt funktionieren.

Kurz: ich könnte mit einem Codeaufwand von vielleicht 1 bis 2 Stunden locker eine grafisch tolle Demo zusammenbasteln. Jedoch will ich das nicht, weil die Wegsuche nicht einmal ansatzweise implementiert ist (ich habe gerade die dazu notwenigen Datenstrukturen gecodet). Wenn die dann einwandfrei funktioniert, werde ich einen Raum basteln, in dem man herumlaufen kann.

Wenn das funktioniert, bin ich bereit den ersten Milestone, der dadurch bedingt niemanden großartig beeindrucken wird, zum Download anbieten.

Jedoch wird dieser solide erweiterbar sein und so kann ich nach und nach Imi zu dem bringen, was es sein soll, ohne dauernd irgendwelche radikalen Änderungen im Code machen zu müssen.

P. S.: Für alle, die Anhänger der anderen Herangehensweise sind, gilt die Regel "10% des Codes benötigen 90% der Zeit" auch. Nur, dass es nicht die ersten, sondern die letzten 10% sind, was den Entwicklungsaufwand unkalkulierbar macht
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 06.05.2005, 09:01

Gestern um halb 1 in der Nacht (meine kreativste Zeit) hatte ich eine geniale Idee zur Wegfindung: und zwar sind wie in meiner ersten Idee zahlreiche Punkte definiert. Diese werden dann zu Dreiecken zusammengesetzt und diese Dreiecke dann dann diese Dreiecke abgespeichert. Wichtig ist lediglich (Verantwortung Leveldesigner), dass sich die Dreiecke nicht überlappen. Falls das jedoch passieren sollte, sollte dies keine Probleme verursachen.

Als Anmerkung: ich denke es ist offensichtlich, dass die Dreiecke die Bereiche bilden, in denen sich der Avatar aufhalten darf.

Nun kommt der Clou:
die Dreiecke werden durchnummeriert und anschließend wird eine Matrix gebildet, in welchem abgespeichert wird, zu welchem Dreieck man gehen soll, wenn man von Dreieck A zu Dreieck B will. Dieses Dreieck sei Dreieck C. Nun schauen wir wieder in der Matrix, zu welchem Dreieck man gehen soll, um von Dreieck C zu Dreieck B zu kommen: nämlich zu Dreieck D. Dies setzt man fort, bis man bei Dreieck B angekommen ist.
Anschließend lässt man den Character auf direktem Weg von Dreieck A zu Dreieck C bewegen, dann von Dreieck C zu Dreieck D usw.

Anmerkung: Als ich die Idee schnell auf einem Schmierblatt aufschrieb, kam mir folgender Gedanke: was ist, wenn zwei stumpfwinklige Dreiecke an ihren stumpfen Winkeln (ggf. sogar nur ein stumpfwinkliges und ein spitzwinkliges) beim selben Punkt eine Kante gemeinsam haben: dann verläuft der direkte Weg von dem einen zum anderen Dreieck außerhalb des erlaubten Bereichs (Skizze im Anhang).

zur Lösung ist es denke ich das einfachste, wenn die Leveldesigner wissen, dass sie in solchen Fällen einfach die erlaubte Fläche anders in Dreiecke teilen sollen. Falls das wirklich nicht gehen sollte - wofür ich im Moment keinen Grund sehe - wüsste ich noch eine kompliziertere Art der Problemlösung.
Dateianhänge
pfad.png
pfad.png (10.3 KiB) 9017 mal betrachtet
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 07.05.2005, 11:19

Übrigens, @pali:
bislang hatte ich noch keinen Kontakt von G0 bekommen, weshalb ich ersteinmal stur weiter am Code arbeite, wie gehabt. Selbstverständlich bin ich weiterhin offen für eine Zusammenarbeit mit Mysteri House und warte daher auf ein Lebenszeichen von G0.

P. S.: Zur Zeit arbeite ich an der Berechnung, ob in ein Dreieck geklickt wurde. Ich hoffe in ein bis zwei Wochen euch irgend etwas präsentieren zu können, vorausgesetzt, dass ich neben Studium die Zeit dazu finde (ob man dafür viel oder wenig zu tun hat, ändert sich jede Woche aufs neue).
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 08.05.2005, 13:34

Was haltet ihr von folgender Story:

Nach dem Zerfall des DRCs sind die meisten Forscher wieder in ihr alltägliches Leben zurückgekehrt. Doch eine kleine Gruppe hat sich im Geheimen zusammengeschlossen (Name dafür noch gesucht), um tiefer in die Geheimnisse D'nis einzudringen. In Nacht-und-Nebel-Aktionen betreten sie regelmäßig aufs neue die alten Fundstätten, um so die letzten Geheimnisse D'nis zu erforschen.

Doch nicht alle Forscher sind von dieses neuen Bundes sind von solch edlen Motiven beseelt. Es gehen Gerüchte um, dass es ein paar Forscher gibt, die lediglich Fundstücke aus den alten Ruinen mit sich nehmen, um sie teuer zu verkaufen. Zumindest weist das Verschwinden von immer mehr Artefakten darauf hin. Oder steckt da etwas ganz anderes dahinter?
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 39

Beitrag von TheSearcher » 04.06.2005, 11:50

Lange ist es her, dass ich zuletzt etwas zum Status von Imi gepostet habe :
Das gravierende Problem, dass die Transparenzen absolut nicht funktionieren, ist gelöst (OpenGL verhält sich manchmal SEHR eigenwillig). Allerdings habe ich den Fehler erst gefunden, als ich die Routine zum Laden der Bilder von SDL_image auf den TGA-Loader von NeHe umgestellt habe (der nebenbei eine eigene Struktur für die Texturen definiert). Ich glaube dennoch, ich werde beim NeHe-Loader bleiben, auch wenn dies weitere Umstellungen erfordert (so z. B. muss ich dann komplett das Koordinatensystem von OpenGL statt das von SDL nehmen).

Immerhin ermöglicht es mir die Entdeckung der Fehlerursache endlich weiterarbeiten zu können :)
Der Zyklustyp einer Permutation ist konjugationsinvariant.
DelHor
Forscher
Beiträge: 1335
Registriert: 05.02.2004, 23:31
Geschlecht: männlich
KI-Nummer: 995034
Wohnort: Neuwittenbek
Alter: 47

Beitrag von DelHor » 04.06.2005, 12:12

TheSearcher hat geschrieben:Doch eine kleine Gruppe hat sich im Geheimen zusammengeschlossen (Name dafür noch gesucht), um tiefer in die Geheimnisse D'nis einzudringen.
Wie wäre es mit dem URC? :D

Zwar kein besonders innovativer Ansatz, aber in der weiteren Entwicklung ließe sich aus der Story sicher etwas machen...
.
“It's a magical world, Hobbes ol' buddy. Let's go exploring!” - Calvin & Hobbes [222]
Benutzeravatar
KlyX
Forscher
Beiträge: 4445
Registriert: 05.02.2004, 17:37
Wohnort: Langenthal, Schweiz
Alter: 40
Kontaktdaten:

Beitrag von KlyX » 04.06.2005, 12:26

Oder der URDR? *hähähä* *gg*

Wirf einen Blick in meinen Blog - und kommetiere :-)
Chris' Weblog
abacado.com - Total neu
DelHor
Forscher
Beiträge: 1335
Registriert: 05.02.2004, 23:31
Geschlecht: männlich
KI-Nummer: 995034
Wohnort: Neuwittenbek
Alter: 47

Beitrag von DelHor » 04.06.2005, 13:22

Ne, der URDR ist der welcher die Teile auf dem Schwarzmarkt verhökert - und der URC versucht ihn zu stoppen... *wildvorsichhinfantasier* :lol:
.
“It's a magical world, Hobbes ol' buddy. Let's go exploring!” - Calvin & Hobbes [222]
Antworten