ich würd bei sowas empfehlen ruby-code einzubinden und berechnungen in threads ausführen lassen, das entlastet ungemein^^
...
Oh? Ich dachte immer, Threads würden das ganze noch langsamer machen... Ruby benutzt - aus Portabilitätsgründen - Green Threads, das heißt sie werden nicht über den Betriebssystem Kernel geregelt sondern sind dierekt im Programm implementiert -> Ruby Threads können nichts mit Super/Hyper Threading oder gar Dual Core Systemen anfangen. Und afaik waren das die einzigen Situationen in denen man durch Threads noch was gut machen kann...
Wo genau hast du mit Ruby's Threads also Performance gewonnen? Ich hab noch nicht viel mit gemacht oder dergleichen, kann also auch nicht wirklich was dazu sagen... nur rein von der Logik her würde es mich wundern. Oô
Ansonsten aber ja, Threads an sich sind schwer im kommen, bei kommerziellen Spielen (was die Sache aber höchstens noch komplizierter macht als es eh schon ist *g*)
--
Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
du hast teilweiße recht, ruby verwendet (leider) ruby-threads die wegen portabilitätsgründen nur innerhalb des ruby-interpreters laufen ... aber verlangsamen tun sie auf keinen fall, denn das würde sie völlig nutzlos machen.
durch die wegnahme einer berechnung durch einen thread wird das hauptprogramm entlastet, würd aber einfach mal empfehlen das ganze auszuprobieren, was schneller ist ... arbeite zwar beruflich schon seit etwa 3 jahren mit threads und co, aber ruby programmierung mach ich erst seit letzten freitag (endlich mit meinem cbs angefangen xD)
da verwende ich threads hauptsächlich für gleichzeitige berechnungen und das ist auf jedenfall deutlich performanter als wenn ich alles in der hauptroutine laufen lass^^
threads sind nicht im kommen, die sind schon lange da xD könnte mir ein arbeiten ohne die kleinen gar nicht mehr vorstellen^^ und so schwer sind die wirklich nicht handzuhaben ... thread=Thread.new{blablabla} und fertig ... (natürlich muss man halt auch bissl drauf achten, dass man sich damit nicht selbst ins nirvana schießt xD
Oh, das ist gut zu wissen... hm, ja ich werd wirklich mal ein paar Test dazu machen, wenn es so einen Unterschied macht gäbe es da doch einen ziemlich breiten Anwendungsbereich ^^"
Zitat
threads sind nicht im kommen, die sind schon lange da xD
...
Das ging jetzt speziell zur Spieleindustrie; wenn Leute schon Algorhytmen zur Terrainberechnung mit Multithreading ausstatten wird es so langsam etwas viel, mMn.
Und nya, vielleicht liegt es auch einfach nur an mangelnder Erfahrung, aber gerade in Java gab es einige Stellen an denen mich das gesamte Thread Zeug wirklich verwirrt hat - in 50% der Java Standardklassen wird man ja praktisch gezwungen mit Threads zu arbeiten... und dann diese lustigen Fehler, wenn man mal ein entsprechendes Schlüsselwort vergessen hat, in einer Methode die ein mal in x Stunden aufgerufen wird, und nur unter Umständen überhaupt von zwei Threads zur gleichen Zeit...
--
Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
najo, wenn man was vergisst ist man selber schuld xD und bitte in welchen java standard-klassen wird man zur nutzung von threads genötigt oO;; vielleicht benutz ich auch einfach nur die anderen 50 %, aber ist mir bis jetzt noch nirgends untergekommen xD
solang man alles auch brav austestet, was man macht, hat man eigentlich keinerlei probleme^^
ich würd bei sowas empfehlen ruby-code einzubinden und berechnungen in threads ausführen lassen, das entlastet ungemein
...
Ich weiß nicht, ob mir da eine Auslagerung in einen Thread weitergeholfen hätte, denn die Berechnung soll nicht parallel stattfinden, sondern das System schon so lange warten bis sie fertig ist. Vermutlich hätte ich das alles in reinen Rubycode machen sollen, nun ist es aber sowieso egal, da ich das SKS vom XP benutze.
Das ist btw. ein interessanter Aspekt was das "Man braucht kein Ruby"-Argument angeht. Ein CBS bzw. CMS alleine mit dem Eventcode scripten geht beim XP extrem auf die Peformance.
obs wirklich was bringt hängt natürlich auch davon ab, wofürs eigentlich eingesetzt werden sollte, aber um auf das ergebnis zu warten muss man eh nur ne schleife einbauen, die auf ne aktion ausm thread wartet ...
man braucht auch kein ruby fürn xp^^ schließlich braucht ein spiel auch kein cbs oder cms xD wer mehr haben will als standard muss halt auch mehr leisten (wobei das mit ruby viel leichter geht als mit scripten ... da muss man für die meisten sachen eh nur das vorhandene bissl editieren)
obs wirklich was bringt hängt natürlich auch davon ab, wofürs eigentlich eingesetzt werden sollte, aber um auf das ergebnis zu warten muss man eh nur ne schleife einbauen, die auf ne aktion ausm thread wartet ...
...
Aber wenn das System sowieso wartet, kann ich mir nicht vorstellen, dass ein Thread die Geschwindigkeit merklich erhöht.
Zitat
schließlich braucht ein spiel auch kein cbs oder cms xD wer mehr haben will als standard muss halt auch mehr leisten
...
Auf dem 2K kriegt man so was aber auch hin, ohne so eine Sprache wie Ruby beherrschen zu müssen. ^^ Also sollte man auch annehmen, dass es auf dem XP genauso geht.
@geschwindigkeit, müsste man halt austesten xD aber ist durchaus denkbar, dass es bessere performance gibt, weils abseits der hauptroutine verarbeitet wird ... was wärs denn überhaupt für eine berechnung gewesen?
bemi xp kannst auch ohne ruby arbeiten, aber dann frisst das ding halt mehr saft^^
Für 6 KS-Teilnehmer von 100 bis 1 runterzählen. XD Später hab ich das dann sogar auf 50 reduziert, hat trotzdem immer noch für ca. 1-2 Sekunden das Spiel gefreezt. Im Event gab es eigentlich nicht viel mehr als ein paar Abfragen, ansonsten wurde der Counter von jedem KS-Teilnehmer reduziert. Das Problem liegt aber wohl an der Struktur von Autostart-Prozessen. Vermutlich gibt es da wie beim 2K ein internes Wait, wodurch alles ziemlich verlangsamt wird.
grad für sowas wären threads ideal ... da kannst sogar in zehntel, hunderstel, tausendstel sekundentakt zählen lassen ... und es bringt absolut performance, sowas im thread zu lösen ...
zb. bei meinem pcbs ... wenn ich da die zeitwerte der ganzen kampfteilnehmer in der hauptschleife berechne ruckelt das auch ordentlich, im eigenen thread ist das ganze kein problem, inklusive aktualisierung der anzeigen alle 0,1 sekunden und weniger ...
Mich würde ja interessieren inwiefern man die "Lahmheit" des XP noch aufbessern kann. Wenn man den gesamten Rubycode im Scripteditor mal wirklich optimieren würde, könnte man bestimt so einiges an Performance gewinnen - finde das vorgegebene nicht wirklich optimal. Bisher kenne ich nur das Anti Event Lag Script, welches sich damit befasst, gibt es da eigentlich noch Alternativen?
da kann man sicher noch einiges rauskitzeln, muss halt nur mal wer machen xD
das anti-event-lag-script ist aber imho nicht sonderlich gut, das deaktiviert lediglich die nicht sichtbaren events, und das ist nicht unbedingt sinnvoll ...
Das konsequenteste wäre es IMO die ganze Event-Geschichte zu überarbeiten. Also zwischen sichtbaren sich bewegenden Objekten (NPC etc..) und reinen Events zu unterscheiden.
Das Problem ist, daß die ganze Event-Geschichte darauf ausgelegt ist möglichst einfach zu bedienen zu sein und nicht darauf besonders performant zu sein.
Ich suche die Bedingung 'Musik einmal durchgespielt'.
Wo finde ich die?
--
Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- und Meinungsforschung (§ 28 Absatz 3 und 4 Bundesdatenschutzgesetz).
Der Thread hier ist bekanntlich schon etwas älter und geht inhaltlich von Grundlegenden Unterschieden zwischen RM2k und RMXP bis zu speziellen Ruby Fragen. Und da konnte ich bisher rauslesen, dass es für performance-abhängige Spiele quasi notwendig ist, sich mit (Ruby-)"Threads" auszukennen. Inwiefern kriegt man bei den grundlegenden Ruby-Tutorials das Wissen darüber vermittelt? Oder andersherum gefragt: Wie lange muss ich mich mit Ruby auseinander setzten, bis ich all das umsetzen kann, was mit dem RM2k ohne Ruby und Performance-Verluste machbar ist (siehe kelvens KS)?
Vielleicht kann auch jemand mal kurz beschreiben, was ein Thread überhaupt ist. Im übrigen kann ich bisher kein Bisschen Ruby, außer das, was hier beschrieben wurde... ... ...
1.6
B: Ja, aber für den RmXP gibts soooo wenig Ressourcen ! Da hat der Rm2k viel mehr !
A: Das stimmt so nicht. Mithilfe -->dieses<-- wunderbaren Tools kann man Rm2k Grafiken auf RmXP größe recken. Somit ergibt sich folgende Gleichung: ResRmXP = Res.Rm2k * Tool
(oder: Res.RmXP == Res.Rm2k)
...
Wo isn das hin? *schnief*
--
~> Fantasie ist wertvoller als Wissen, denn Wissen ist begrenzt. (Einstein) <~:
1. Demo hier erhältlich =D
-------------------------------------
Der Thread hier ist bekanntlich schon etwas älter und geht inhaltlich von Grundlegenden Unterschieden zwischen RM2k und RMXP bis zu speziellen Ruby Fragen.
[
...
Also su musst Ruby nicht unbedingt können. Ich kann selbst auch keine Scripte schreibe.
Ich kann sie in besten Falle verstehen und einfachste Dinge austauschen.
Die Performence des Xp's kannst du kaum verbessern. Es gibt ein Ruby-Script was Lags bei zu vielen Events verhindert, das wars dann aber schon.
Zitat
Wie lange muss ich mich mit Ruby auseinander setzten, bis ich all das umsetzen kann, was mit dem RM2k ohne Ruby und Performance-Verluste machbar ist (siehe kelvens KS)?
[
...
Im Pronzip kannst du ein Ks genauso im Xp bauen wie im 2k.
Ich selbst habe mein AKS mit Events gemacht und es funktioniert.
Wenn man es gescheit macht braucht ein Event-Script auch nicht sehr viel mehr Systemressourcen als ein Ruby-script (glaube ich).
Allerdings kannst du es mit Ruby schneller erstellen.
Zitat
Vielleicht kann auch jemand mal kurz beschreiben, was ein Thread überhaupt ist. Im übrigen kann ich bisher kein Bisschen Ruby, außer das, was hier beschrieben wurde...
...
Erlichgesagt weis ich es nicht und ich brauchte es bisher auch nicht, aber hier ist die Definition von Thread in Wikipedia
Der Wikipedia-Artikel ist vielleicht etwas hoch. Einfach gesprochen erlaubt ein Thread es, einen bestimmten Code gleichzeitig neben dem Hauptprogramm auszuführen. Der neue Thread läuft dann, quasi wie ein zweites Programm im Programm, nebenher.
Normalerweise muss man damit vorsichtig sein, da man nie weiß an welcher Stelle der Abarbeitung der andere Thread ist und es zu Problemen kommen kann wenn zwei Threads auf die gleiche Variable zugreifen.
In Ruby kann man aber einen Thread fragen "bist du fertig?" und wenn der dann ja zurück gibt entsprechend damit arbeiten, ansonsten läßt man ihn weiterlaufen. Die Auslagerung von Berechnungen in andere Threads entlastet den Hauptthread (also das Programm) was im Falle des XP sich dann wohl in weniger ruckeln äußert.
Für "Set Terrain ID" gibt es bei dem XP unter "Control Variables" bei "Character" die Option "Terrain Tag". Wenn du das Terrain unabhängig von einem Event ermitteln willst, kannst du das auch per "Call Script" machen. x und y sind die Koordinaten auf der Map. In meinem Beispiel wird das Ergebnis vom Scriptaufruf der ersten Variable zugewiesen.
Wenn du mit "Wait until key hit" die Option bei "Enter Password" meinst, dann ist das bei dem XP das Eventkommando "Button Input Processing". Die Abfrage wartet automatisch solange bis eine Taste gedrückt wurde.
Zitat
Zitieren
Ein CBS bzw. CMS alleine mit dem Eventcode scripten geht beim XP extrem auf die Peformance.
...
... 
