Screen Blending wurde nun komplett in Assembler geschrieben. Leider lässt sich Screen Blending nicht mit SIMD optimieren, weil die Screen Buffer-Pixel im RGB565-Format sind und damit ungeeignet für SIMD (das Entpacken und Verpacken ist zu teuer). Dennoch ist Screen Blending in RPGSS äußerst schnell und mit der Implementierung in Assembler konnte ich größtenteils Verbesserungen von 50-100% erzielen.
Kleiner Tipp an dieser Stelle: Wer viele und große Images jeden Frame zeichnet, kann bessere Performance erzielen, indem er die Images zuerst auf ein Image-Buffer und den Buffer dann auf den Screen zeichnet. Image-Blending ist in der Regel SIMD-optimiert und damit viel schneller als Screen-Blending.
Echt genial! Die Zeichenmethoden von RPGSS sind echt hammer!
Wird langsam echt mal Zeit für's offizielle DynRPG v0.2 ^^
Wie sieht's mit der Performance aus, Kyuu?
PeAcE
MorDen
--
»Ein Traum kann auch die Wehmut nach der verlorenen Vergangenheit sein…«
»Manchmal ist eine Enttäuschung auch einfach nur das Ergebnis zu hoher Erwartungen.«
__________________________________________________________________________
Ich denke es ist bewegt. Immerhin sprach Kyuu von "Partikeln"
PeAcE
MorDen
--
»Ein Traum kann auch die Wehmut nach der verlorenen Vergangenheit sein…«
»Manchmal ist eine Enttäuschung auch einfach nur das Ergebnis zu hoher Erwartungen.«
__________________________________________________________________________
Echt genial! Die Zeichenmethoden von RPGSS sind echt hammer!
...
Freut mich, dass jemand sie nützlich findet. :>
Zitat von Morden
Wie sieht's mit der Performance aus, Kyuu?
...
Wovon genau?
Die Performance der Grafikroutinen? Echt schwer zu sagen, da die Performance von so vielen Faktoren abhängt (Prozessor, Blend Mode, Algorithmus, Anzahl der gezeichneten Pixel, etc.).
Bei der Partikel-Demo unten schaffe ich beispielsweise 350 Partikel gleichzeitig auf einem Pentium 4 (3,4 GHz) bei 60 FPS. Auf einem Core i3 (3,3 GHz) schaffe ich mehr als das Fünffache (wobei die Anzahl der gezeichneten Pixel pro Frame bereits bei 350 Partikeln in Millionenhöhe liegt!).
Wenn es dich interessiert, könnte ich ein paar Benchmarks veröffentlichen (wenn ich mal Zeit habe). Oder du machst deine eigenen Benchmarks. ;>
Hey. Ich hab ne Frage.
Folgende Map hat eine Lightmap.
Diese benutzt verschiedene Photoshop-Blendmodes (Color Dodge, Overlay, Multiplizieren etc. etc.).
Da sich diese ja nicht einfach so in den Maker übertragen lassen (zumindest nicht ohne Parallax), dachte ich, ich verzichte auf ein paar schönere Effekte und komprimier das ganze auf einen Effekt.
Den LE-Manager kann ich ja aufgrund fehlender Unterstützung für BlendModes eh momentan streichen, deshalb habe ich mit den verfügbaren Blend Modes in spritelib rumgespielt.
(Mix, 100 Opacity)
(Multiplizieren)
Wie man sieht, sind die Ergebnisse nicht wirklich ansehlich. Ist da irgendwas in die Richtung geplant? :0
Das erste Bild ist aus Photoshop (wobei es mehrere Layer sind; der unterste ist die Map und alle drüber liegenden sind Lightmaps mit unterschiedlichem Blending)? Und deine Frage ist, ob es möglich ist, die Blend Modes aus Photoshop hinzuzufügen? Habe ich das richtig verstanden? :o
Neue Blend Modes hinzufügen ist kein Problem, ich müsste nur an die Blending-Formeln kommen. :<
Was den LE-Manager angeht: In der Datei LightmapManager.lua, in Zeile 54, ist der Aufruf von game.screen.draw. Dort einfach den Aufruf um den Blend Mode-Parameter erweitern. Der Blend Mode gilt dann natürlich für alle Maps. Es ist selbstverständlich auch möglich den LE-Manager um mehrere Lightmap-Layer zu erweitern. Will den eh noch in der nächsten Zeit überarbeiten, damit Lightmaps eine Tiefe (Z-Position) bekommen.
Das erste Bild ist aus Photoshop (wobei es mehrere Layer sind; der unterste ist die Map und alle drüber liegenden sind Lightmaps mit unterschiedlichem Blending)? Und deine Frage ist, ob es möglich ist, die Blend Modes aus Photoshop hinzuzufügen? Habe ich das richtig verstanden? .
...
Das wäre optimal, ja. Im Moment ist die gängige Art für solche Lichteffekte, den Effekt direkt als Parallax mit der Map einzufügen. Dadurch werden natürlich Events und der Hero nicht vom Effekt erfasst, und diese müssen entweder manuell eingefärbt oder einfach ignoriert werden. Wenn man die direkt als Picture mit dem passenden Blend Mode einfügen könnte, sähe das echt super aus.
Ich kann dir ja mal nen Breakdown der benutzten Blend Modes geben:
Ganz unten ist natürlich die Map
Dann Weiches Licht / Soft Light
Ineinanderkopieren / Overlay
Farbig Abwedeln / Color Dodge
Multiplizieren / Multiply
Und das wird einfach so drübergelegt
Bezüglich der Formeln hab ich nicht wirklich Ahnung von der Implementierung, ich kann lediglich etwas googlen und >>sehr<<>>vielversprechend<<>>aussehende<<>>Ressourcen<< finden. °-o (Die obigen Bilder wurden übrigens in Photoshop CS5 gemacht, ich weiß nicht, ob sich da was über die Versionen geändert hat.)
Hm, ok. Multiply ist eh schon drin. Color Dodge und Overlay sollten kein Problem sein. Soft Light könnte für die Echtzeitanforderungen eines Spiels aber zu langsam sein, zumindest in der "exakten" Version (Wurzel muss gezogen werden). Das könnte ich aber mit einem LUT, oder mit einer angenäherten Version beschleunigen. Ich teste es mal am Wochenende aus.
Sorry, aber daraus wird nichts. Die Blend Modes sind ungeeignet für Software Blending in Echtzeit. Habe die Blend Modes bis jetzt zwar nur in C++ ausprobiert, aber selbst in Assembler wird sich vermutlich nicht viel ändern. Hätte ich bloß OpenGL + Shader zu Verfügung... :/
Okay, das ist schade, aber nicht allzu tragisch. ^-^
Mir ist aber noch eine andere Sache aufgefallen: Gibt es einen simplen Weg, um festzustellen, ob sich ein Charakter bewegt? <Character>.moving gilt ja nur fürs Bewegen durch Move Event und es gibt afaik auch keinen Sprite-Offset (wie weit die Grafik vom eigentlichen Eventblock entfernt ist, wenn das != 0 ist, dann ist das Event ja in Bewegung). Es gibt natürlich den üblichen Weg über das abgleichen von Koordinaten, aber vielleicht hat Dyn ja Zugriff auf was simpleres als das. :0
Zitat von Morden
Zitieren
.
