Wundert mich das Frosch noch nicht erschienen ist.Zitat
Das sind alle Maker (hoffe ich zumindest, sonst hab ich mich nämlich blamiert)
Dazu rate ich auch!
Wundert mich das Frosch noch nicht erschienen ist.
Das sind alle Maker (hoffe ich zumindest, sonst hab ich mich nämlich blamiert)
Dazu rate ich auch!
--Froschvampirs Ressourcenthread/////Lichteffekte mit Gimp/////E-Book/////XP-Skripte/////SeeVas-Welt
püüp Archeo hat Recht ihr schreibt zu viel!
"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)
--Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
das es viele programme gibt ist wohl kaum ein argument.
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.
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...
--Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
Erläuter das mal genauer, bitte. o,o Also warum die Kollisionsabfrage so komplex ist und wie sie einfacher gestaltet werden könnte.
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... :/
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...
--Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
....
Geändert von Jonas-Desirer (24.01.2007 um 22:21 Uhr)
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)
....
Geändert von Jonas-Desirer (24.01.2007 um 22:21 Uhr)
kaffe oder tee, was ist euch lieber?
....
Geändert von Jonas-Desirer (24.01.2007 um 22:21 Uhr)
....
Geändert von Jonas-Desirer (24.01.2007 um 22:21 Uhr)
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*
Berechtigungen
Zitieren
