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^^
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)
@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^^
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.
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... ... ...
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 ...
...
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.
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.
tja,
bei der readme steht nur wie mans installiert und in der hilfe datei ist alles englisch. ich kann zwar a bissel englisch aber nich das alles was da steht!
Dann schau dir am besten mal das Forgotten E-Book an. Is zwar nich für den XP aber was du da lernst kannst du ohne Probleme auch beim XP anwenden. Jedenfalls größtenteils.
beim makern ham sich ein paar fragen gesammelt 8zum makerxp)
1. Gibt es keine Facesets mehr?
2. Muss ich Texte immer mit Message schreiben?
3. Was für ein Programm brauche ich um zb. Charakter umzumalen ohne das der hintergrund weiß wird? (also wie bleibt er transparent?)
4. Kann ich midi lieder in mp3 umwandeln, so das ich se auf dem mp3player hörn kann?
5. wo bekomme ich mehr charas etc? (gibt ja nur sehr wenig, also es sind schon viele aber halt doch noch zu wenige )
6. ... habsch vergessen, kommt noch
danke, schonmal
achja, kann ich ressorcen die hier sind einfach nutzen(die man hier downloaden kann)
@schamane
Wie?
Wenn ich einen Krieger mit paint öffne und rote Augen male, hat er im spiel nen weißen hintergrund-wo kann ich da tranparent einstellen?
Zitat
Brauchst du nicht, einfach beim importieren die transparente Farbe einstellen
@schamane
Wie?
Wenn ich einen Krieger mit paint öffne und rote Augen male, hat er im spiel nen weißen hintergrund-wo kann ich da tranparent einstellen?
...
hast du überhaupt importiert? also über die Funktion vom Maker und nicht einfach per Kopieren in entsprechenden Ordner?
wenn du die grafik veränderst, solltest du die dann auch neu importieren...
dann beim importieren die entsprechende fläche anklicken, sodass unten beides mal die jeweilige farbe angezeigt wird
Man hat ja genügend Platz im Script Editor. Wenn die 11 Zeilen für die Befehle nicht ausreichen sollten schreibt man eben alles in ein eigenes Script im Script Editor und ruft es dann mit dem "Script" Button auf.
Und Draw_Text kann man ganz gut für eigene Menüs benutzen, ja...dazu kann ich dir auch zwei sehr gute Einsteiger Tutorials von Dubealex empfehlen in dem er u.a. auch beschreibt wie man eigene Fenster macht. Zwar auf englisch, aber mir hat es sehr geholfen: Kapitel 1: Allgemeine Einführung in Ruby Kapitel 2: unter Punkt 5 wird auch erklärt wie man eigene Fenster (Messageboxen) macht
btw: mache ich auch ein eigenes Menü, aber noch Eventbasiert da ich mit Ruby nicht allzu vertraut bin um das hinzubiegen.
Ja, die meinte ich, aber eher den Umfang. Nachdem was Lil_Lucy gesagt hat geht das dann ja nicht, wenn das Kommando auf 11 Zeilen beschränkt ist.
...
Ja, das ist eigentlich ziemlich dämlich... man könnte es umgehen - ohne Frage - aber bevor ich dazu komme möchte ich noch anmerken, dass es wahrscheinlich keine gute Idee ist.
Event Skripte werden mit der Kernel#eval methode ausgeführt, die liest im Grunde genommen einen String ein und führt ihn als Ruby Code aus... der Mist an der Sache ist, dass während das gewöhnliche Ruby Skript bereits zu Beginn des Programmes durch einen lexer und parser wandert muss dieser String es bei jedem mal aufs neue. Bei kleineren Dingen macht das sicherlich keinen Unterschied, aber wenn du nun zum beispiel ein ganzes KS auf diese Art und Weise schreiben wolltest ist es mMn schon was anderes...
Aber um auf die umsetzung zurückzukommen... naja, geh in Interpreter (7) Zeile 260. Ursprünglich sollte das hier dort stehen:
ersetz es einfach durch
Damit werden aufeinanderfolgende Skript Kommandos als zusammenhängend angesehen und zusammen ausgewertet - soviel zu den 11 Zeilen Skript...
--
Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown