ZweiDe
Übersicht
Sonstiges SmalltalkGehe zu Seite Zurück 1, 2, 3 ... 9, 10, 11 ... 18, 19, 20 Weiter
|
WüstLing |
 Fr, Nov 13, 2009 17:23Antworten mit Zitat 
|
|---|---|---|
|
Ich hab gerade versucht die DemoApplication zu starten.
Nun bekomme ich folgenden Error: DllNotFoundException Die DLL "glfw.dll": Unzulässiger Zugriff auf einen Speicherbereich. (Ausnahme von HRESULT: 0x800703E6) kann nicht geladen werden. Hatte das Problem schon jemand? |
||
|
Fetze |
Fr, Nov 13, 2009 21:07 Antworten mit Zitat
|
|---|---|---|
|
[OT]
Das Praktikum bei Deck13 war sehr sehr cool. Die Arbeit dort hat echt Spaß gemacht und entgegen anfänglicher Befürchtungen (Unabhängig von der Firma) konnte ich tatsächlich "richtig" mitarbeiten anstatt nur hier und da Tabellen zu verwalten oder simple Commandline-Tools zur Dateiumwandlung zu schreiben oder sowas. Unter anderem durfte ich für Venetica Cutscenes Scripten, habe mich dort weiterhin contentseitig um den Sound (Vertonung von Cutscenes, Locations und teilw. Skills) gekümmert und den Deck13-Internen Editor erweitert. Für ein noch nicht offiziell angekündigtes (kleineres) Projekt habe ich eine OpenAL-Schnittstelle (Im Prinzip: Die Lowlevel-Soundimplementierung) schreiben dürfen und für ein anderes (noch kleineres) Projekt Komponenten innerhalb der GameEngine. Alles in allem also mehr als ich mir vorher erträumt hätte - so viel machen zu dürfen und zu bemerken, wie einem langsam immer mehr zugetraut wird, war auch extrem motivierend. 
Auch die Atmosphäre dort war sehr angenehm, sodass ich mich dort sehr schnell wohlgefühlt habe. Irgendwie hat man gemerkt, dass die Leute dort größtenteils nicht nur "irgendwie halt da arbeiten" sondern mit Leib und Seele dabei sind. Das steckt an und schweißt zusammen. Alles in allem bin ich hochzufrieden
[/OT] Ich kann allen BlitzMaxe'lern einen Umstieg auf C# eigentlich nur wärmstens empfehlen und mit ZweiDe wird man vermutlich auch nicht viel von der BlitzMax-Spielefunktionalität (Grafik, Sound, Input) vermissen 
@WuestLing Ja, das Problem ist auch in der Vollversion bereits behoben.. leider ist die Demo-Application offenbar älter als der Fix. Ich würde dir empfehlen, stattdessen also einen Blick auf die neueren Demos zu werfen oder das Rpg-Projekt hier eben als Demo zu nutzen. Wenn du Quellcode sehen willst, von letzterem der sollte auch hier drin stehen
|
||
|
hecticSieger des IS Talentwettbewerb 2006 |
Fr, Nov 13, 2009 22:14 Antworten mit Zitat
|
|---|---|---|
|
Fetze hat Folgendes geschrieben: Ich kann allen BlitzMaxe'lern einen Umstieg auf C# eigentlich nur wärmstens empfehlen und mit ZweiDe wird man vermutlich auch nicht viel von der BlitzMax-Spielefunktionalität (Grafik, Sound, Input) vermissen
Was willst du uns eigendlich damit sagen? Das wir alle umsteigen sollten um dein Produkt zu kaufen? In einem C-Forum wäre es noch hinnehmbar. Hier jedoch nicht. |
||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
|
|
Fetze |
Sa, Nov 14, 2009 13:52 Antworten mit Zitat
|
|---|---|---|
|
Äh, lol
Ich formuliere es mal so: 1. Ich habe diesen Satz nicht ohne Grund mit einem Augenzwinkern geschrieben und auch gemeint. 2. Auch ohne ZweiDe kann ich einen Umstieg auf C# nur wärmstens empfehlen. Wer mit BlitzMax auf den OOP-Geschmack gekommen ist und wen es nicht stört, sich eben eine andere Lib (oder auch mehrere) suchen zu müssen, um Spiele zu programmieren, sollte das unbedingt mal ausprobieren. Ich bin ja nicht umsonst letztendlich an C# und nicht BlitzMax hängengeblieben. Für Hobbyentwicklung ist das einfach eine sehr coole Sache: Gigantische Funktionsbibliothek (.Net), schicker Code und wenig Wartungsaufwand oder für Einsteiger hakelige Wartungsarbeit à la C++ Linker Fehler o.Ä. Also mal ernsthaft, soll mein Produkt kaufen wer will und Spaß dran hat, wirklich was verdienen tu ich damit so oder so nicht - ich freue mich, wenn ich mir mal ein Vollpreis-Spiel pro halbes Jahr leisten kann, und wenn nicht, dann eben nicht. Letztendlich ist der größte Lohn bei einer derart kleinen Ziel- oder Interessengruppe doch, zu bemerken, wenn Leute mit dem Produkt zufrieden sind. Wenn du jetzt auf die Idee kommst (oder irgendjemand anderes, ist ja ne berechtigte Frage), zu fragen, warum ich es dann überhaupt verkaufe.. das ist nicht schwer zu erklären: Meinen Arbeitsaufwand deckt der Preis so oder so nicht, ganz zu schweigen davon, dass mir die Arbeit Spaß gemacht hat. Die 10 € sind nicht mehr als ein kleines Dankeschön für Support (Dazu würde ich beispielsweise die Online-Einstiegshilfe zählen, welche mich sehr viel Zeit gekostet hat und mir persönlich nicht viel bringt) und Entwicklung. Wem es das Wert ist, der schlägt zu, wem nicht, der lässt es eben bleiben, jeder wie er eben mag
|
||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Sa, Nov 14, 2009 14:30 Antworten mit Zitat
|
|---|---|---|
|
ja, ich kann auch jedem VW-Besitzer den Umstieg auf ein Porsche nur wärmstens empfehlen. Mehr Leistung, mehr Aufmerksamkeit, mehr Spaß, mehr Komfort, schickes Design, gigantische Funktionen, und wer einmal im Genuss der Sporttaste gekommen ist, wird nichts anderes mehr haben wollen. Am besten, ich schreiben das gleich mal in ein VW-Forum.
|
||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
|
|
Fetze |
Sa, Nov 14, 2009 14:40 Antworten mit Zitat
|
|---|---|---|
|
Ich weiß nicht, was dich davon abhält, wenn das deine Meinung ist.
Darf ich dich daran erinnern, dass ich mich nicht "mal eben" hier registriert hab, um Werbung zu streuen oder Leute zu bekehren? Ich bin in diesem Forum und seinen Vorgängern seit vielen Jahren passiv am Lesen oder aktiv am Schreiben. Nun habe ich die Programmiersprache gewechselt und plötzlich habe ich mein Recht verwirkt, Empfehlungen auszusprechen bzw. meine Meinung zu äußern? Es ist ja nicht so, dass ich darauf bestehe, dass hier irgendwer zu irgendwas wechselt oder dass ich es so hinstelle, als sei das objektiv die Idealentscheidung. Das wäre etwas anderes - aber so sieht die Sache ja auch nicht aus. |
||
|
BladeRunnerModerator |
Sa, Nov 14, 2009 14:58 Antworten mit Zitat
|
|---|---|---|
|
Ich denke auch mal jedem seine Meinung.
C# hat seine Existenzberechtigung wie Max auch, und den Test sollte sich niemand verwehren. Ich bin bei Max hängen geblieben, aber das muss ein jeder für sich herausfinden. |
||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
|
Geeecko |
Sa, Nov 14, 2009 15:08 Antworten mit Zitat
|
|---|---|---|
|
hectic hat Folgendes geschrieben: ja, ich kann auch jedem VW-Besitzer den Umstieg auf ein Porsche nur wärmstens empfehlen. Mehr Leistung, mehr Aufmerksamkeit, mehr Spaß, mehr Komfort, schickes Design, gigantische Funktionen, und wer einmal im Genuss der Sporttaste gekommen ist, wird nichts anderes mehr haben wollen. Am besten, ich schreiben das gleich mal in ein VW-Forum.
Ist was ganz anderes. Nicht jeder VW Fahrer kann sich mal eben einen Porsche kaufen -> Nicht möglich. JEDER BMax Nutzer kann aber locker auf C# umsteigen -> Möglich. Ich persönlich finde beide Sprachen gelungen. Anfangs ist BMax schöner, und es reicht noch aus... Später ist es lustiger C# zu benutzen, da man auf dauer mehr aus der Sprache herausholen kann. |
||
| .... | ||
|
Starwar |
Sa, Nov 14, 2009 18:43 Antworten mit Zitat
|
|---|---|---|
|
Ich kann nur sagen, dass das Gesamtkonzept von C# sehr gelungen ist und ich die Sprache jedem empfehlen kann, da sie sehr Produktiv und übersichtlich ist. Die Visual Studio IDE ist auch nicht schlecht, besonders beim Debuggen.
Jedoch habe ich noch nicht geschafft zwei Fenster parallel laufen zu lassen. Weiß jemand wie das geht? MFG |
||
|
|
Fetze |
Mi, Feb 03, 2010 11:39 Antworten mit Zitat
|
|---|---|---|
|
Mit Bezug auf mein Grafikergesuch (BladeRunners Post unten): Der folgende Link führt in ein bis vor kurzem unsichtbares Fetzenet-Unterforum, welches zu meiner aktuellen Hobbybeschäftigung gehört.
http://forum.fetzenet.de/viewf...4a0ac3e701 
In der Hoffnung, damit vielleicht eher den einen oder anderen Interessenten zu erreichen, habe ich das ganze Ding mal sichtbar gemacht. Das ganze trägt den Arbeitstitel StarTrade2, da mir spontan kein besserer Name für ein Spacegame eingefallen ist - es hat aber insgesamt sonst relativ wenig mit StarTrade zu tun.
Wie man dort lesen kann, bis vor kurzem konnte ich Grafiken von einem User namens Nox beziehen; der meldet sich aber nicht mehr, also vermute ich mal, dass ihn sein RL eingeholt hat. Da er mir demzufolge aber auch nicht sagen kann, ob er bald oder überhaupt jemals wieder zurück ist, bräuchte ich nen Ersatzmann, der gut mit einem 3D-Modellingprogramm umgehen kann und bereit wäre, mir einige Renderings zu erstellen. Weiteres steht im oben verlinkten Jobgesuch.
|
||
|
|
Fetze |
Fr, Feb 05, 2010 16:26 Antworten mit Zitat
|
|---|---|---|
|
So langsam bereue ich meine Entscheidung, irrKlang als Basis für ZweiDe Sound zu verwenden. Wie sich nun im Anwendungsfall "ST2" herausstellt, funktioniert die Library stellenweise nicht richtig (Listener-Position, unerwartetes Verhalten in Sound-Falloffs, etc.) und ist zudem noch langsam wie sau, wenn es darauf ankommt, öfter mal Sound properties zu verändern.
Kleines Beispiel: Mir fiel vor kurzem auf, dass der GameObjectManager sich in der von ihm beanspruchten Zeit sehr unregelmäßig verhält, soll heißen: Standardmäßig 0,1 ms, aber in vereinzelten Frames dann doch mal das dreißigfache. Dem ging ich natürlich nach und siehe da: Der Urheber dessen ist, dass ich von Zeit zu Zeit, etwa beim Abfeuern einer Waffe, einen Sound abspiele. Um das ganze gegenzutesten, ließ ich mal pro Schuss die fünfzigfache Menge an Projektilen erstellen --> Alles läuft wie zuvor, nur insgesamt etwas langsamer. Dann der eigentliche Test: Normale Projektilmenge, aber fünfzigfache Soundmenge --> Das Spiel friert für 500 - 1500 ms komplett ein. Dabei macht es offenbar keinen Unterschied, ob gestreamed wird oder die Daten explizit vorausgeladen wurden. Eine andere Sache: Der SoundManager, der nichts anderes tut als laufende Sounds zu managen, ihre Parameter zu updaten und Sounds, die fertig sind, zu entfernen, braucht pro Frame im Durchschnitt 2 ms - was etwa 20 mal so viel ist wie alle anderen Berechnungen, die in einem laufenden Raumkampf derzeit passieren. Ich denke mal, das spricht für sich selbst. Mittlerweile reicht mein Unmut aus, irrKlang aus ST2 bei nächster Gelegenheit zu verbannen und auf OpenAL umzuschwenken, auch wenn ich dafür dann einen eigenen Ogg Vorbis Loader schreiben muss. Ob ein entsprechendes ZweiDe-Update folgt, und wenn ja, wann, kann ich noch nicht sagen. Ich bin momentan eher in der Stimmung, ZweiDe lieber neu zu coden als zu erweitern, weil mir viele Dinge daran mittlerweile nicht mehr so gefallen; mal gucken. Bin momentan sowieso nicht so ganz sicher, wann ich mal wieder richtig zum coden komme, da ich gerade in den Klausurwochen bin. 
Wie dem auch sei. Zum Abschluss vielleicht noch ein, zwei Worte zum Projekt, für alle, die es interessiert: 
Der obige Screenshot zeigt nicht viel. Was man aber darauf erkennen kann, ist, dass ich derzeit an einem System für Partikeleffekte arbeite. Ich habe mir dazu folgendes Konzept überlegt:  Ein Partikelsystem handhabt Partikel und Partikeleffekte. Es wird auch verwendet, um die zugehörigen Partikel zu zeichnen und optimiert dabei automatisch OpenGL state changes: Die Textur wird nur gewechselt, wenn nötig, etc.. Dadurch, dass Partikelanimationen grundsätzlich nur eine Textur benötigen und jeder Partikeltyp in derselben Textur mehrere Grafikversionen nutzen kann, wird die Anzahl dieser state changes zusätzlich verringert. Es ist nicht perfekt, aber bei weitem mehr als genug.
Ein Partikeffekt koordiniert die Erstellung von Partikelemittern, Sounds und temporären Lichtern. Er verwendet dazu eine Art "Timeline".
Ein Partikelemitter emittiert Partikel. Wenn er will, verschiedene Partikeltypen nebeneinander, mit unterschiedlichen Einstellungen.
Partikelsysteme und all ihre Verwandten werden als temporäre Objekte angesehen und dementsprechend konsequent nicht gespeichert oder geladen.
Woran ich derzeit arbeite, ist unter anderem eine einem Effekt zuweisbare Intensität, die sich auf Optik und Akustik des Effekts auswirken; grundsätzlich ist die für regulierbare Antriebsstrahlen gedacht, aber ich möchte auch erproben, wie sich das Konzept mit skalierbaren Explosionen und Einschlagseffekten verhält. Könnte was hermachen ^.^ Wenn es fertig ist werden mit diesem System sowohl Antriebsstrahlen als auch Einschlagseffekte oder Explosionen realisiert werden.
|
||
|
|
FetzeBetreff: Ein Wort zur Hobbyentwicklung |
Sa, Feb 06, 2010 11:46 Antworten mit Zitat
|
|---|---|---|
|
Es ist schon komisch. Wenn man sein erstes Hobbyprojekt entwickelt, schert man sich einen Dreck darum, wie die Engine designed ist, oder welche Klassenhierarchie man aufbaut - es kommt nur darauf an, ob es funktioniert und gut aussieht. Früher oder später in der Entwicklung dieses Projekts wird man damit an die Wand fahren: Entweder, man scheitert daran, weil die notwendige Flexibilität fehlt, oder ist unzufrieden mit den Kompromissen, die noch möglich sind - oder aber, man stellt das Projekt "irgendwie" fertig, muss aber auf zahlreiche Dinge verzichten.
Das bleibt natürlich im Gedächtnis. Üblicherweise ist dies der Punkt, an dem man sich als Hobbyentwickler schwört, es beim nächsten Mal besser zu machen und gleichzeitig die Ursache dafür, mit Quellcode an sich unzufrieden sein zu können. Langsam aber sicher entwickelt sich eine Art Sinn für Code-Ästhetik und in letzter Konsequenz wird man viel Zeit mit Planung und Design verbringen. Der klassische nächste Schritt ist: Komplette Überplanung. 70% des Zeitbudgets wird darauf verwendet, den Potentialballon der Entwicklungsmöglichkeiten aufzublasen - dass von diesen Möglichkeiten die wenigsten jemals genutzt werden, entgeht dem eifrigen Entwickler dabei leider allzu oft. In aller regel sind solche Projekte vielversprechend und ambitioniert, aber letztendlich geht dem Entwickler dabei die Puste aus, bevor er sich daran machen kann, den gigantischen Potentialballon mit Nutzinhalt zu füllen. Was nun folgt ist ein ewiges Hin und Her, man versucht, sich auf auf einen konstanten Kompromiss zwischen Potentialballon und Inhalt einzupendeln - was letztendlich ein endloses Unterfangen wird, denn die Tendenz ist: Am Ende eines Projekts wird der Entwickler zumindest teilweise unzufrieden damit sein, weil er währenddessen dazugelernt hat und es vermutlich noch keinem Entwickler jemals gelungen ist, den "perfekten" Sourcecode zu schreiben. Ich denke, die Kunst besteht darin, nicht mehr den Code, sondern das Produkt zu designen - in der Hobbywelt oft ein Problem, denn derjenige, der das Produkt konzeptioniert, ist in aller Regel Programmierer. Es ist die Kunst, sich das Spiel vorzustellen, es zu entwerfen und dabei den Code weder überzugewichten noch aus den Augen zu verlieren. Es ist auch die Kunst der Abwägung und Einschätzung - wird sich die Arbeit für Feature X lohnen? Es ist auch die Kunst, sich kritisch zu hinterfragen: Brauche ich für Feature X wirklich eine allgemeine Codelogik, oder kann ich denselben Effekt bei ähnlicher Qualität auch gefaked erreichen? Früher war Hobbyentwicklung für mich der Kampf mit dem eigenen Sourcecode - jetzt halte ich es für den Kampf der eigenen Ambitionen mit der eigenen Vernunft; auf einem Felsgrat, dessen linke Schlucht Motivationslosigkeit und dessen rechte Schlucht Zeitlosigkeit ist. Ich habe ehrlichen Respekt vor allen Hobbyentwicklern, die jemals ein größeres Projekt fertiggestellt haben und am Ende zurecht damit zufrieden waren. Das ist die wahre Kunst der Hobbyentwicklung und ich vermute, nicht viele beherrschen sie. PS: Ich hoffe, es stört sich niemand dran, dass ich diesen Thread mittlerweile ein wenig wie einen Blog betrachte?
|
||
|
|
BladeRunnerModerator |
Sa, Feb 06, 2010 11:48 Antworten mit Zitat
|
|---|---|---|
| Wir sind im smalltalk, Fetze. Solange es nicht zum reinen Blog verkommt soll es mir recht sein. | ||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
|
ComNik |
Sa, Feb 06, 2010 15:04 Antworten mit Zitat
|
|---|---|---|
|
Ich mag den Thread sehr gerne.
Aber diesmal hab ich was nicht verstanden. Was ist mit State Changes gemeint? Also ist mir schon in etwa klar was das sein soll, aber ich verstehe nicht was es mit OpenGL oder DirectX zu tun hat? Vielleicht steh ich einfach nur aufm Schlauch, lg ComNik |
||
| WIP: Vorx.Engine | ||
|
|
Fetze |
Sa, Feb 06, 2010 19:44 Antworten mit Zitat
|
|---|---|---|
|
OpenGL ist als State Machine aufgebaut, daher verwendet man für Dinge wie "Zu verwendende Textur wechseln" oder "Shader binden" die Bezeichnung "State change", weil der OpenGL-Zustand damit verändert wird. Wenn man die Performance der Grafikpipeline optimal ausnutzen will, gilt im Allgemeinen die Faustregel: Die Grafikkarte ist am schnellsten dann, wenn sie immer dasselbe machen muss, ergo sollte man es vermeiden, redundante State Changes einzubauen.
Beispiel: Standardmäßig zeichne ich eine Textur etwa so: 1. Textur aktivieren 2. UV-Koordinaten berechnen 3. glBegin 4. Vertices setzen 5. glEnd 6. Textur deaktivieren Während das im Normalfall die "sauberste" / sicherste Variante für eine 2D-Engine ist, wäre das für Partikel viel langsamer, als es sein müsste: Wenn man Partikel zeichnet, zeichnet man in der Regel eine große Menge von Quads, die dieselbe Textur verwenden. Folgendes lässt sich also tun: glBegin Loop begin --> Wenn bisher andere Textur aktiv: Textur wechseln --> UV-Koordinaten berechnen und Vertices setzen Loop end glEnd Das ist zwar noch nicht so schnell wie die Verwendung von VBOs, aber weitaus schneller als zuvor und für meine Zwecke schnell genug. Nun wäre das aber noch weitgehend ineffektiv, wenn jeder Partikel eine nadere Textur verwenden würde; aus diesem Grund befinden sich alle Animationsschritte eines animierten Partikels sowie all seine Animationsversionen auf einer Textur - so muss im Idealfall für ein gesamtes Partikelsystem trotz zahlreicher verschiedener Partikel nur ein einziges Mal eine Textur gebunden werden. Befinden sich alle Partikel auf einer Textur oder einem Satz weniger Texturen, spricht man im Allgemeinen von einem Singlesurface Partikelsystem. Das hier ist sozusagen eine abgespeckte Variante davon. Hoffe, es ist jetzt etwas klarer geworden
|
||
|
|
ComNik |
Sa, Feb 06, 2010 21:22 Antworten mit Zitat
|
|---|---|---|
|
Das heisst man lädt nur einmal ein Bild und zeichnet das dann aber "unterschiedlich" auf die Partikel?
Ich glaub ich habs verstanden. Da man aber die Textur in BlitzMax nicht "changen" muss, braucht man da kein Single Surface oder? Ich dachte immer das wäre einfach schneller eine Textur zu zeichnen. Aber es hängt nicht mit dem Zeichnen sondern mit dem tauschen der Textur zusammen (oder?). Dankeschön
lg ComNik |
||
| WIP: Vorx.Engine | ||
|
|
Fetze |
Sa, Feb 06, 2010 23:01 Antworten mit Zitat
|
|---|---|---|
| In BlitzMax hast du das System, das ich oben beschrieben hab - also ohne SInglesurface und für Partikelsysteme eher ungeeignet. Leider kannst du nichts dagegen tun, da BlitzMax die OpenGL-Interna vor dir verbirgt. Die einzige Möglichkeit, es effizienter zu machen, ist direkt OpenGL-Code zu schreiben - oder irgendwelche OpenSource-Engines zu nutzen, die sowas drin haben. kA, vllt lohnt sich ein Blick auf Avas Engine? Bin nicht sicher, ob die sowas explizit supported, könnte ich mir aber eher vorstellen als bei Max2D. | ||
|
mpmxyz |
Sa, Feb 06, 2010 23:22 Antworten mit Zitat
|
|---|---|---|
|
Ein Blick hinter die Kulissen von BlitzMax kann sich lohnen:
(Der Code von allen Modulen wird ja mitgeliefert.) Eine Möglichkeit, die Geschwindigkeit zu erhöhen, sollte diese sein:
Wenn bestimmte Funktionen aus GLMax2D nicht versteckt sondern zu Type-Funktionen gemacht worden wären, könnte man diese gleich übernehmen und die Image-Erweiterung würde nahtlos an den Rest von GLMax2D zusammenpassen. mfG mpmxyz |
||
|
Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer |
||
|
|
ComNik |
So, Feb 07, 2010 0:16 Antworten mit Zitat
|
|---|---|---|
|
Hm stimmt,
das ist natürlich blöd... Naja ich werd schauen. Danke für die Hilfe mpm und fetze
lg ComNik |
||
| WIP: Vorx.Engine | ||
|
|
Fetze |
So, Feb 07, 2010 12:05 Antworten mit Zitat
|
|---|---|---|
So, das Partikeleffektsystem ist fertig und findet bereits seine Verwendung:
Der Antriebsstrahl eines Schiffes wird basierend auf der aktuellen Antriebsleistung dynamisch in seiner Intensität angepasst. Hier zu sehen: Ein einzelner Partikeleffekt unterschiedlicher Intensitäten. Der Partikeleffekt verwendet einen einzigen Partikelemitter, welcher wiederum drei Partikeltypen emittiert: Partikeleffekt: Code: [AUSKLAPPEN] [ParticleEffectBlueprint="Engine1"] [actions] [ParticleEffectAction="ActionOne"] time = 0.0 emitterType = "Engine1" layer = Back [/ParticleEffectAction] [/actions] [/ParticleEffectBlueprint] Partikelemitter: Code: [AUSKLAPPEN] [ParticleEmitterBlueprint="Engine1"] [emissionGroups] [ParticleEmissionGroup="GroupOne"] particleType = "Engine1" particleLifetime = 0.25, 1.0 emitSpread = 1.0 emitDelay = 0.1, 0.25 emitDelayPhase = 0.0 emitNum = 2, 3 particleAttachFactor = 1.0 particleAttachRotation = true intParticleSize = 0.5 intParticleAlpha = 0.25 [/ParticleEmissionGroup] [ParticleEmissionGroup="GroupTwo"] particleType = "Spark1" particleLifetime = 0.25, 1.0 particleVelAngle = 3.14 particleVelLen = 0.5, 1.0 particleTurnVel = -0.1, 0.1 emitSpread = 3.0 emitDelay = 0.1, 0.25 emitDelayPhase = 0.0 emitNum = 1 particleAttachFactor = 1.0 particleAttachRotation = true intEmitDelay = -0.5 intEmitSpread = 0.5 intParticleSize = 0.25 intParticleLifetime = 0.25 [/ParticleEmissionGroup] [ParticleEmissionGroup="GroupThree"] particleType = "Light1" particleLifetime = 1.0, 2.0 particleTurnVel = -0.01, 0.01 emitSpread = 0.0 emitDelay = 0.5, 1.0 emitDelayPhase = 0.0 emitNum = 1 particleAttachFactor = 1.0 particleAttachRotation = true intParticleSize = 0.5 intParticleAlpha = 0.5 [/ParticleEmissionGroup] [/emissionGroups] [/ParticleEmitterBlueprint] Wie man hier gut sehen kann, kann beim Partikelemitter je Emissionsgruppe separat stufenlos eingestellt werden, inwieweit sich die Intensität auf verschiedene Emissionseigenschaften auswirkt: Code: [AUSKLAPPEN] intEmitDelay = -0.5 intEmitSpread = 0.5 intParticleSize = 0.25 intParticleLifetime = 0.25 Das entsprechende Charakteristikum wird multipliziert mit (Intensität ^ Intensitätsfaktor), wobei die Intensitätsfaktoren standardmäßig alle 0 sind und bei Bedarf, wie hier zu sehen, auf einen beliebigen Wert gesetzt werden können. Bei dieser Emissionsgruppe kann man das also übersetzen in: Code: [AUSKLAPPEN] intEmitDelay = -0.5 ; Wenn sich die Intensität vervierfacht, halbiert sich der Zeitabstand zwischen zwei Emissionen intEmitSpread = 0.5 ; Wenn sich die Intensität vervierfacht, verdoppelt sich die räumliche Partikelverteilung intParticleSize = 0.25 ; Wenn sich die Intensität verachtfacht, verdoppelt sich die Partikelgröße intParticleLifetime = 0.25 ; Wenn sich die Intensität verachtfacht, verdoppelt sich die Partikel-Lebenszeit Bin alles in allem sehr zufrieden mit dem System und zuversichtlich, dass sich damit auch die meisten anderen Effekte leicht intensitätsabhängig gestalten lassen. Einschlagseffekte basierend auf dem verursachten Schaden, Explosionen mit leichter Random-Intensität.. ich freue mich schon drauf
|
||
Gehe zu Seite Zurück 1, 2, 3 ... 9, 10, 11 ... 18, 19, 20 Weiter
Übersicht
Sonstiges Smalltalk
Powered by phpBB © 2001 - 2006, phpBB Group