Druckbare Version
Wundert mich das Frosch noch nicht erschienen ist.Zitat:
1.maker: RPGmaker2000
2.maker: RPGmaker2003
3.maker: RPGmakerXP
SO ich glaub jetzt hab ichet komplett.
Das sind alle Maker (hoffe ich zumindest, sonst hab ich mich nämlich blamiert)
Dazu rate ich auch!Zitat:
vllt sollte ich net nebenbei Gothic zokken???
Hey Lordi..
Hast Recht kleine Fischchen im Meer!
Aber könn ja noch wachsen!;)
Und Easy isn Kumpel! :rolleyes:
"Es gibt zu wenig Ressourcen für den XP" und für das nächste mal weißt du hoffentlich deine Multi-tasking Fähigkeiten besser einzuschätzen, ja?
(Da fällt mir auf, die Sache mit den Grafikprogrammen sollte auch auf die Liste, ist immerhin nicht das erste mal)
Gehts immer noch um falsche Klischees bezüglich des XP? Ich will ja nicht mit übermäßigem Zynismus das Ganze ins Lächerliche ziehen, aber beispielsweise das mit dem Spruch von wegen "Der RMXP ist schuld, dass es für den zu wenig Ressourcen gibt" klingt für mich fast so, als seien Aschenbecher daran schuld, dass auf Tabakwaren die Tabaksteuer erhoben wird. Und was das pixeln an sich anbelangt: Gibt doch so viele Grafikprogramme... Paint Shop Pro, Paint .NET, Paint (das klassische)... erfordert halt Mühe. Ich meine, die grafische Begabung hab ich bei der Geburt nicht bekommen, aber selbst ich bekomms hin, für die Protagonistin meines Projekts (008-fighter08.png) ein Hexenkostüm zu pixeln. Dauerte zwar ewig (3 Tage) und hat einiges an Mühe gekostet, aber es geht. Zur Not pixelst du halt für den 2k und passt die Grafiken von Hand an die RM-Ressourcenspezifikation an (z.B. durch strecken... je nach dem, worum es grad geht). So~ schwer ist das nicht... nur Mühe und Zeit sollte man schon investieren, wenn man was gutes haben will.
das es viele programme gibt ist wohl kaum ein argument.Zitat:
Und was das pixeln an sich anbelangt: Gibt doch so viele Grafikprogramme... Paint Shop Pro, Paint .NET, Paint (das klassische)... erfordert halt Mühe
man kann nicht ploetzlich pixeln, weil man jetzt paint.net anstatt paint shop pro verwendet, genauso umgekehrt.
Wenns kein Argument ist, kann mans auch dem RMXP nicht ankreiden, dass es keine/kaum Ressourcen für gibt. Was kann bitte eine "Entwicklungsumgebung" dafür, dass es kaum Grafiken dafür gibt? {} Nicht mehr und nicht weniger. Zudem: Man kann ja auch Collagen aus einzelnen Grafikteilen machen. Und wenn ich das als grafischer Kach-B00n kann, können andere das auch.
Ich glaube Alzis Aussage bezog sich darauf, daß man die Sets angeblich mit dem normalen Windows-Paint nicht bearbeiten kann, was dark beliar im Anfangspost behauptet hat.
Der einzige Punkt wo man dem XP vielleicht wirklich zusprechen kann die Kreativität einzuschränken bzw. nicht zu fördern ist der Bereich "kreativer Lösungsansätze".
Beim 2k und 2k3 gab und gibt es immer Leute die Spaß daran haben Dinge zu machen, für die der Maker nie gedacht war. Die kreative Herausforderung liegt dabei gerade in den beschränkten technischen Bedingungen des Makers. Wenn der XP diese Schranken wegnimmt, nimmt er auch diesem Bereich einen Teil seiner Herausforderung.
In den anderen Punkten wurde da eigentlich schon genug gesagt. Kreativität ist normalerweise eine Frage des Menschen und nicht des Werkzeuges. Die Kreativität Grenzen zu überschreiten ist natürlich schwierig zu erreichen wenn man die Grenzen nicht kennt, aber auch das wird IMO noch kommen.
Die Performance vom XP ist schon eine kleine Grenze. Als ich versucht habe ein Custommenü zu basteln ist mir z.B. aufgefallen, dass der Cursor des Menüs merklich langsamer wird, wenn das Updaten des Bildschirminhalts eine größere Zahl an Funktions- bzw. Eventaufrufen erfordert. Am Ende war das fast eine halbe Sekunde pro Cursorsprung. Der Menücode war btw. eine Mischung aus Eventcode und ein wenig Ruby.Zitat:
Die Kreativität Grenzen zu überschreiten ist natürlich schwierig zu erreichen wenn man die Grenzen nicht kennt, aber auch das wird IMO noch kommen.
Ein anderes Problem hab ich ja schon mal im Technikforum geschildert. Wenn man in einem Autostartprozess einen Wert von 100 bis 1 runterzählt, dann wird solange die Grafik eingefroren und trotzdem braucht die Berechnung ca. 1-2 Sekunden, was mMn schon ziemlich lahm ist. Das liegt wohl daran, dass im Autostartprozess implizit ein Wait 1 enthalten ist ( nehme ich zumindest an ). Dennoch war da beim 2K die Performance viel besser.
Solche Sachen nerven schon, wenn man ein flüssiges CBS und Custom-Menü benutzen möchte. Deswegen benutze ich jetzt die Standardsachen. XD
Der Event-Interpreter ist IMO ein erheblicher Performance-killer. Events waren nie dazu gedacht so etwas komplexes wie ein CMS oder ein CBS zu regulieren. Selbst Ruby, daß über "Call Script" ausgeführt wird, ist langsam, weil es durch "eval" gejagt wird, was eine recht langsame Funktion von Ruby ist.
Der Interpreter ist auf solche Dinge nicht ausgelegt und deswegen in dieser Hinsicht auch überhaupt nicht optimiert. Ich glaube mit reinem Ruby und gutem Code ist da eine ganze Menge mehr herauszuholen.
Vor allem, wenn man besseren Code schreibt als gewisse Leute bei Enterbrain, die es sogar geschafft haben eine Kollisionsabfrage mit O(n²) zu bringen...Zitat:
Zitat von MagicMagor
Erläuter das mal genauer, bitte. o,o Also warum die Kollisionsabfrage so komplex ist und wie sie einfacher gestaltet werden könnte.Zitat:
Zitat von Der Drake
Jedes Event prüft pro frame die Kollision mit jedem anderen Event auf der Map. Lass mal einen Profiler über den Code laufen, es entwickelt sich ein echter Flaschenhals an der Stelle, wenn die Zahl der Events steigt... :/Zitat:
Zitat von Dingsi
Und besser, man könnte einfach irgendeine räumliche Datenstruktur benutzen, da bei den meisten in Frage kommenden Strukturen allerdings das Einfügen und Entfernen relativ aufwändig ist würde ich etwas noch simpleres, wie einen Hash oder dergleichen benutzen, bei dem sich die Schlüssel aus den Positionen der Events berechnen.
Da Hash's in Ruby konstante Zugriffszeit haben sollte das immer noch bei weitem effizienter sein als das bisherige...
Aber das war nur ein Beispiel das mich letztends etwas überrascht hatte, es gibt viele kleinere Dinge die den XP im Endeffekt langsamer machen als nötig wäre. Ein anderes Beispiel... die meisten Objekte basieren auf einer Art von MVC (Database, Sprite_* Klassen und Game_* Klassen), wobei das V dabei sehr lustige Verhaltensweisen an den Tag legt und selbst dann aktualisiert wird, wenn es garnicht zu sehen ist.
Ja, das war "rein zufällig" an Stelle 2 beim profiler. Graphics.update (ich denke mal da wird das ganze Zeug geblittet) kommt erst ein gutes Stück später...
....
ey easy bleib ma legga! det game the fog is net komplett aus deinem hirni entstanden! n bissl kleinen futzi pups beitrach hab ich da auch zu gebracht (geschichte/ teil der idee)
....
kaffe oder tee, was ist euch lieber?
....
Wenn ihr beiden sowieso schon am gleichen PC sitzt, könnt ihr eure Privatgespräche auch aus dem Forum raushalten. Außerdem muss man auch nicht in alle Threads hineinspammen, nur weil sie da sind.
....
ey ich steh net auf de nummer 45 mit extra mayo, ich will lieber menü 34 dass mit dem rpg xp mit extra vielen char und chipsets...
*schmoll*:(