[Projekt] Devader

[Chromanoid]

Ich find's schick. Ggf. noch ab und zu Wolkenfetzen, die in surrealer Geschwindigkeit über den Bildschirm sausen. :) Gerade bei Endbössen mit ganz viel Wind wäre das sicher cool. Könnte man auch so als Event machen... Also normalerweise ist alles ruhig doch ab und zu gibt's dann heftige Sandstürme.

Wie wäre es dann noch mit einem leisen Prasseln und Klimpern a'la Regenstab und Windspiel, wenn man nahe an die Blöcke zoomt oder so ^^

[xq]

Sieht schon ziemlich cool aus, was ich noch probieren würde: Schaffst du es, dass der Sand mehr "rollt"? Im Moment sieht man finde ich das textur-geschiebe noch sehr

[Schrompf]

Die subtile Version in der Mitte gefällt mir besser als die sichtbar wiederholte Version ganz unten. In Bewegung ist es... ok. Taugt schon, würde ich aber trotzdem nicht ganzbildschirmig einsetzen.

[scheichs]

Also ich würde Bewegung weglassen. Finde Version in der Mitte auch am besten-

[marcgfx]

Danke für die Meinungen :) ich bin selbst auch noch nicht so gaaanz überzeugt von der Geschichte. Vor allem mit der Animation.
Diese Version gefällt mir aber jetzt tatsächlich. Allgemein veträgt sich der Sand aber nicht soo toll optisch mit den Splattereffekten.


Richtig geil wirds halt erst, wenn Objekte mit dem Sand interagieren... will ich das mir und der Performance aber noch antun ist die grosse Frage. Den Sand muss ich vermutlich sowieso ausschaltbar machen, weil das bestimmt wieder einige GPU's mehr überlasten könnte. Ich könnte ja eine Textur updaten, wo alle Objekte jeweils eine Art Fussabdruck hinterlassen. Oder wenn der Wind von links weht, dass es dann anhäufungen auf der linken Seite der Strukturen gibt. :roll:

[marcgfx]

Hier sieht man recht gut wie der Sand sich mit dem Splatter beisst...

Ich bräuchte eine zusätzliche Textur die bei Explosionen ein Update erfährt und auch die Bereiche anpasst die zumindest von statischen Objekten blockiert werden. Ich habs eigentlich genau im Kopf, nur ob ichs umsetzen soll ist eine andere Frage :roll: Am Schluss läufts nur auf High-End-Geräten :lol:
Die Textur müsste nur aus Graustufen bestehen. 50% Grau wäre der Normalzustand. Damit Haufen entstehen muss ein Bereich Weisser werden, damit der Sand verschwindet muss es Schwarzer sein.
In jedem Zeitschritt wird die Textur etwas Kontrastarmer, d.h. dort wo die Explosion den Sand weggeblasen hat kommt langsam wieder Sand hin. Dort wo ein Haufen gesetzt wurde, wird langsam wieder ausgeebnet.
Der Sand müsste ausserdem über dem Splatter gezeichnet werden, aktuell befindet sich der Sand aber auf der untersten Ebene mit der Bodentextur.
Eigentlich simpel :)

[xq]

Zuerst einmal: Ich finde den letzten Screenshot ziemlich geil! Der Sand macht das ganze definitiv weniger repetetiv.

Ich glaube, man könnte da auch schon sehr viel mit nem guten Blending reissen. Im Moment sieht mir das nach nem normalen Alphablending (src*al + dest*(1-al)) aus. Vielleicht einfach mal in GIMP/Photoshop mit nem anderen Blendmodus rumspielen und gucken, ob sich da was passenderes ergibt

[marcgfx]

Danke MasterQ32 :)

Ich habe testweise einen weiteren Layer eingeführt, der den Sand etwas kontrollieren soll wie im letzten Post erwähnt. Ebenso habe ich den Hintergrund mit dem trockenen Boden aufgehellt. Es ist mir jetzt allerdings etwas zu gelb :|
.... also habe ich das schreiben hier abgebrochen und bin wieder zurück zum code.
stellt sich heraus, der plastische Effekt der beim Sand entsteht ist eigentlich ein Bug. Anstatt dass ich Farbwerte zwischen 0.0 und 1.0 habe läufts drüber, was zu negativen Werten in der Berechnung führt. So entsteht der plastische Eindruck. Also... alles zurück, ebenso die Hintergrundfarbe, denn die braucht es für den Kontrast :roll:


Ich muss mir einen besseren Zugang für die wichtigen Parameter schaffen, dann kann ich da noch etwas bequemer dran schrauben ;)

[marcgfx]

Ein totaler Schlag ins Wasser... ich habe mal den Sand-Layer vom Hintergrund getrennt und über den Splatter-Layer gezeichnet. Scheusslich. In Bewegung ist es noch schlimmer, weil der Sand jetzt wie Nebel ausschaut :roll:


Ich muss wohl oder übel die letzten Arbeiten wieder rückgängig machen, eventuell auch auf den bewegten Sand / die verschiedenen Stimmungen verzichten. Oder ich bin einfach nicht so pingelig mit dem Realismus. Mal sehen.

[Chromanoid]

Schon mal daran gedacht statt Dünen Sandstürme zu realisieren? Müsste doch nen ganz witziger Effekt sein, der sogar Einfluss auf das Gameplay hat. Vielleicht kann man es ja irgendwie hinkriegen, dass die Säulen wenn sie hoch genug sind noch rausschauen.

[marcgfx]

An Sandstürme habe ich schon gedacht, ich habe gar mal angefangen Graphiken zu erstellen. Irgendwie bin ich dann aber nicht weitergekommen, u.a. weil mir die Graphiken nicht gefielen. Vielleicht sollte ich es noch mal angehen, ich hatte eben eine Idee wie ich bessere Graphik machen könnte. Es darf dann einfach nicht zu sehr das Bild verdecken und die Hexa spitzen rausschauen lassen wird nicht gehen (ohne grossen Aufwand).

Die Dünen werde ich sicher in irgendeiner Form behalten, es ist einfach nicht so flexibel wie ich erhofft hatte.
- Ich habe bemerkt, dass es eigentlich nur bei voller Deckkraft richtig gut wirkt. Eventuell kann ich da aber noch was anpassen.
- wenn ich die Dünen skalieren, kommt es zu unerwünschten Effekten, wenn ich gleichzeitig animiere. Kann vermutlich mit etwas Mathe korrigiert werden
- Lücken in den Sand explodieren ist wohl keine so tolle Idee. Der grosse Kontrast zwischen Sand und Untergrund macht das ganze etwas unansehnlich. Ich müsste ausserdem noch eine zusätzliche Texture erstellen, die immer wieder geupdatet wird. Performance ist schon lang ein leidiges Thema...

[marcgfx]

Performance ist leider immer noch ein grosses Thema bei mir. Einiges stammt aus alten Code, der nicht mehr die gleiche Funktion erfüllt wie früher. Ich hatte damals für das Rennspiel "Influencer" eingeführt, diese konnten auf x Parameter einer Einheit einen Einfluss ausüben, z.b. verlangsamen, Schaden über Zeit etc. In Devader brauche ich das aber alles nicht, das einzige wozu ich es brauchte war um einen abstossenden Effekt bei Explosionen auszuüben. Wie ich feststellen musste war der Code aber alles andere als performant und hat ganz schön Speicher gefressen, was wieder den GC bedient hat. Der Mist wurde jetzt entfernt, ich muss aber nun alle Objekte die damit ausgerüstet waren wieder anpassen.

Die Tausendfüssler hatten ihr eigenes Problem, um die 4 Graphiken pro Segment zu zeichnen, hatte ich das ein Segment aus 4 "Components" aufgebaut. Components sind Elemente einer Einheit die sich von der Basis unabhängig rotieren, eigene Waffen und auch Code haben können. Aber nur um 3 zusätzliche Graphiken zu zeichnen, war es recht dämlich diese doch recht komplexen Objekte einzusetzen. Alle Tausendfüssler wurden jetzt auf ein Basiselement reduziert und die Zusatzgraphiken werden nur noch gezeichnet. Macht auch mehr Sinn. Irgendwie ist es manchmal erschreckend zu sehen, was für ineffizienten Mist man produziert hat :roll:

Sturm ist jetzt eingebaut. Mit dem Sturm kommt der Sand. Wenn der Sturm vorbei ist, dann bleibt der Sand und die Umgebung sieht wie oben etwa aus. Auf die Löcher im Sand verzichte ich jetzt ganz, es lohnt sich nicht den Aufwand zu betreiben, da es eh schlecht ausschaut.

[marcgfx]

Ich treibe mich weiterhin in den Wahnsinn. X Sachen umgestellt, dann bemerkt das was buggy war. Die Anzeige der Hexas war irgendwie im Arsch und hat rumgespackt. Nach 3h suchen hatte ich es noch immer nicht rausgefunden und war auch kein bisschen schlauer. Also wurde die Arbeit von gestern vernichtet und noch mal von vorne begonnen... jetzt läuft es aber ich weiss weiterhin nicht was das Problem war.

Zu meiner Schande muss ich gestehen, dass ich bis anhin nichts von "use strict"; gehört hatte. Damit kann man einige dumme Javascript-Fehler schon früh abfangen. Ein weiteres spannendes Feature ist Object.seal(data). Damit kann man verhindern, dass weitere Properties auf einem Objekt angelegt werden. Damit habe ich auch viele Fehler aufdecken können, die ich gar nie bemerkt habe. Ausserdem sollte es dem Compiler beim optimieren Helfen, da Objekte sich nicht dauernd verändern. Was ich interessant finde, ist dass ich bei all den Optimierungstyps, die ich gelesen habe noch nie darüber gestolpert war. Ebenso las ich nix im Zusammenhang mit "Deoptimization", dass genau dann passieren kann, wenn man einem Objekt versehentlich neue Properties zuweist. Object.seal hat den Nachteil, dass es etwas lahm ist, also werde ich es wieder rausnehmen, wenn alle Fehler weg sind (bzw. für den Release).

Etwas dass mich auch noch zu viel Performance kostet ist die Sortierung aller Graphiken nach z-Wert. Da ich Alphablending verwende, kann ich soweit ich verstanden habe den Depth-Buffer nicht nutzen. Ich muss also vorsortieren. Der Sortiervorgang dauert aber ziemlich, das kann schon mal 1ms gehen (für 60fps habe ich nur 16ms zur Verfügung). Aktuell Sortiere ich mit dem Standard Javascript sort. Ich habe schon x-Sachen gelesen, die empfehlen was anderes zu nutzen, aber bislang hat mich alles schwer enttäuscht. Bei JSPerf gibt es einen schönen Vergleich, der IMHO falsch ist, aber gut ausschaut.
https://jsperf.com/sort-algorithms/31
Der Native Sort wird mit einem Callback aufgerufen, alle anderen aber nicht. Dann kommt noch der Memory-Verbrauch dazu.
Aktuell führe ich einen Array/Buffer mit allen zu zeichnenden Objekten (es ist wichtig das dieser Buffer nicht verändert wird, da ich die Positionen für updates benutze). In jedem Frame wird dieser Buffer in einen Render-Array übertragen und dieser Render-Array wird sortiert. Ich hatte die gute Idee anstatt linear zu übertragen, direkt einen Insert-Sort zu nutzen. Hat wunderbar funktioniert, war aber etwa doppelt so langsam.

[Dummie]

Hast du die Z-Werte bereits und es geht nur darum es entsprechend in der korrekten Reihenfolge zu zeichnen? Könntest du anstatt der Sortierung nicht ein großes zweidimensionales Array (Z-Wert, Referenz zu der Grafik, z.B. Position im anderen Array) erstellen? In dem Fall würdest du das Array dann einfach nur entsprechend auffüllen. Wenn du die Anzahl der Elemente im Array speicherst brauchst du es nicht mal nullen, sondern überschreibst es ständig und setzt eben nur die Anzahl wieder auf 0. Natürlich bist du dann bezüglich Z-Werte und Anzahl der Grafiken pro Ebene limitiert, aber wenn du die Werte groß genug wählst sollte das ja auch kein Problem sein. Außerdem muss der Z-Wert natürlich als Ganzzahl vorliegen oder sich zumindest näherungsweise als solche repräsentieren lassen.

[scheichs]

Ich würde das Render-Array gar nicht jedes Frame neu sortieren, da Z ja bei 2D konstant bleibt. Also nur noch bei object.new/delete sortiert einfügen/entfernen.

[marcgfx]

Der Z-Wert ist nicht konstant, er wird positionsabhängig neu berechnet und ist ein absoluter double Wert. Wenn sich ein Objekt nicht bewegt, bleibt der Z-Wert konstant. Die Formel für den Z-Wert benutzt x,y,z und zi, wobei zi dazu dient um den z-Wert unabhängig von der Position zu adaptieren. Explosionen haben meist einen hohen zi Wert, so dass sie über andere Sachen gezeichnet werden.

Im Array der zu sortieren ist befinden sich Objekte mit allen Infos (position, zindex, texturcoordinaten, rendersettings). Ich glaube ich muss mir mal Merge-Sort noch anschauen, aber ich habe meine Zweifel, dass es was bringt. Ich habe schon timsort angeschaut, dass hat aber einen massiven Memory-Overhead mitgebracht, was dann zu GC Spass führte.

Ich hatte gehofft ich könnte das übertragen vom Buffer in den Render-Array nutzen könnte. Ein Insert Merge-Sort vielleicht :lol: ?

[marcgfx]

Ich habe eine simple heap-sort implementation gefunden und für mich angepasst. Für einen Array mit 1689 einträgen (direkt aus dem Spiel):

Code: Alles auswählen

var tlist = rlist.slice()
console.time('measure');
tlist.sort(function(a,b){ return a.z-b.z; });
console.timeEnd('measure');
VM1976:4 measure: 1.994140625ms

Code: Alles auswählen

var tlist = rlist.slice()
console.time('measure');
heapSort(tlist)
console.timeEnd('measure');
VM1977:4 measure: 0.404052734375ms

Das hat sich wohl gelohnt :)

[scheichs]

Ich hatte vermutet, dass ich etwas übersehe. Dennoch versteh' ich nicht ganzan welcher Stelle sich der z-Wert ändert. Im Endeffekt liegen die Objekte doch quasi in Layern, also quasi dein zi-Wert? Selbst wenn du ballistische Flugbahnen und ähnliches hast, sollte in 2D der Layer pro Objekttyp fix sein. IMHO...
EDIT: Ok... ich glaub ich hab gerafft was das Problem ist...

[marcgfx]

hier sieht man relativ gut die verschiedenen Situationen. Objekte die sich überlappen, brauchen einen anderen z-Wert damit sie in der richtigen Reihefolge gezeichnet werden. So ist der Schatten vom Raumschiff über die Hexas gelegt.

Also meine Z-Index Funktion sieht so aus:

Code: Alles auswählen

this.zindex = function(x,y,z,zi){
	return ((y + z) * 2 + x / 5 + zi + 4000);
}

Ich merke aber das reicht auch:

Code: Alles auswählen

this.zindex = function(x,y,z,zi){
	return y+z+zi;
}

Der x-Wert wurde früher benötigt, da ich den Schatten nicht in einem seperaten Layer hatte. Ohne x Wert konnte es komischen Überlappungssprüngen kommen.

[joeydee]

Vielleicht ist das Hanging-Moss-Prinzip (1-dimensional) ein Beschleuniger? Also Screen-Y-Wert-Gruppen, anschaulich betrachtet für die Fußpunkte von Objekten:
- Bildschirm in n horizontale (gedachte) Streifen geteilt, je (screenheight/n) Pixel hoch. Jeder Streifen enthält eine Liste von Objekten, deren Fußpunkt sich in dem Streifen befindet.
- Wenn ein Objektfußpunkt seine Screen-Y-Koordinate ändert, wird geprüft ob es in seinem Streifen bleibt, ansonsten dort herausgenommen und in den passenden eingefügt.
- Wenn in einem Streifen ein Objekt hinzugekommen ist, wird es innerhalb dieser Objektliste passend einsortiert.
Es wird also nur noch dann sortiert, wenn ein Streifen gewechselt wird. Und dann auch nur ein kleiner Anteil (ein n-tel) aller Objekte.

Von deinen Ausführungen (bzw. der Z-Buffer-Frage) her gehe ich mal von WebGL, also Hardwareunterstützung aus?
Alphablending schließt den Z-Buffer nicht grundsätzlich aus. Hast du auch opake Objekte? Oder machst du das einfach grundsätzlich wegen PNG-Antialiasing an den Kanten? Dann kann das natürlich wegen der Fillrate in den Keller gehen. Hauptsächlich das Lesen des bisherigen Framebuffers hält beim Alphablending auf soviel ich weiß, das kann man sich aber i.d.R. für sehr viele Pixel sparen. Wenn die Fillrate aktuell überhaupt ein Flaschenhals ist?
Wenn du opake Objekte hast (oder Objekte so rendern kannst, dass zuerst alle 100%-Pixel gerendert werden und der Rest ignoriert wird), dann rendere zuerst alles opake ohne aktiviertes Blending (spart das Lesen des Framebuffers), wenns geht möglichst Front-To-Back (spart das Setzen vieler Pixel bei sich überlappenden Objekten), mit Z-Buffer (compare+write). Danach nochmal die Alpha-Transparenzen Back-To-Front, mit Z-Buffer-compare, kein Z-write. Dann muss nur noch für diejenigen Pixel der Framebuffer gelesen werden, für die es wirklich notwendig ist. Alles was der Z-Buffer opak verdeckt hat, fällt weg.

Diese Optimierung müsstest du im Zusammenhang "Partikelengine" im Web genauer nachlesen können, im Prinzip ist dein Renderer ja nichts anderes.

[marcgfx]

Ich habe rein gar nix, was kein Alphablending braucht :) Komplett opake Objekte gibt es nicht. Danke für den Vorschlag mit dem Hanging-Moss, falls ich noch mehr rausholen will, könnte das spannend sein. Im Moment bin ich recht zufrieden mit der Heap-Sort Ersparnis :D

[Laney]

yo.. die bewegten Dünen machens nochmal eine ganze Ecke krasser. Gänsehaut

[marcgfx]

:D Danke Laney, nicht zu viel schmeicheln sonst werd ich noch rot.

[marcgfx]

Bin fleissig dabei (local) Multiplayer einzubauen. Es soll möglichst simpel sein. Ein Druck auf Start auf Gamepad 2/3/4 und schon ist man im Spiel. Ein weiterer Spieler macht es natürlich viel einfacher um zu bestehen, doppelte Feuerkraft ist nicht zu verachten. Um dem etwas entgegenzuwirken habe ich beschlossen das Nukes global sind. Jeder Spieler kann sie auslösen, aber keiner kann bis zum Reset eine weitere abfeuern.
Im Screenshot kann man sehen wie die Assistenten zu den jeweiligen Devadern "gehören". Die zugehörigkeit wechselt anhand von etwas Zufall und abhängig von der Distanz. Der Farbwechsel der Assistenten ist nur für Debugzwecke, ansonsten flackerts zu viel.

Extras/Power-Ups müssen geteilt werden, ebenso die verfügbaren Leben. Da es aber doof wäre, wenn man nicht mehr einsteigen kann, weil der Spieler keine Leben mehr hat gilt für Multiplayer Leben etwas besonderes. Wird ein Controller das erste mal benutzt, kann man ohne Leben zu verwenden einsteigen. Besitzt der Spieler 3 zusätzliche Controller, ist er also etwas im Vorteil. Aber eigentlich ist mir das ziemlich egal. Ich werde beim Highscore einfach eine Unterscheidung machen wie viele Controller verwendet wurden.

[marcgfx]

GUI funktioniert jetzt auch für 4 Spieler. Im moment schaltet es um sobald ein weiterer Spieler dazu kommt, aber vielleicht sollte ich immer dieses GUI verwenden, weil es etwas schlanker ist.

[marcgfx]

Ich versuche mehr Leben in die Umgebung zu bringen. Beim Start des Spiels hats noch sowas wie eine leichte Eisschicht (oder sonst was, wer weiss) auf dem Boden. Diese Verschwindet nach und nach, bis der trockene Boden zum Vorschein kommt. Irgendwann kommt ein Sturm auf und windet den Sand in die Ebene und es entstehen die Sanddünen. De Code für Eis/Sand ist praktisch identisch, ein paar Parameter werden getauscht u.a. die Textur und die Farbe.

[marcgfx]

Habe eben wieder kurz den Sortieralgo angeschaut. Irgendwie hats mir einfach nicht gepasst, das Heapsort schneller als Quicksort sein sollte. Wie es sich rausgestellt hat, war es auch ein Trugschluss. Ich hab es falsch getestet:
Heapsort habe ich eingebaut und damit das Spiel laufen lassen. Das Programm habe ich unterbrochen und via Konsole den Test gestartet. Heapsort 0.4ms Quicksort 3.5ms. Klare Sache! Ich hatte aber einen Verdacht und mal Quicksort direkt vor dem Heapsort eingebaut und damit das Spiel gestartet. Quicksort 0.1ms, Heapsort 0.4ms... Was war passiert? V8 hatte den Heapsort bereits optimiert, meinen Quicksort von der Konsole aber nicht.

[Laney]

Ne, das hat nichts mit schmeicheln zu tun. Du machst da einfach echt solide Arbeit und es sieht optisch dazu noch sehr gut aus. Finde nur das muss auch appreciated werden.

[marcgfx]

@Laney: Danke :mrgreen:

Bin mal wieder am Testen. Das kann auf die Dauer etwas langweilig werden (weil ich mich eh unverwundbar mache). Da kam mir eine lustige Idee: In Devader gibt es einen Parameter der die Schwierigkeit einstellt. Aktuell von -1 bis 2. Aber es gibt eigentlich kein oberes Limit... Also habe ich mal zaghaft die Schwierigkeit auf 5 gestellt. Der Schwierigkeitsgrad beeinflusst die Anzahl der Gegner, wie ihr seht auch die vom Boss. Vermutlich gibt es damit neue Bugs und die Performance leidet massiv, aber spassig ist es schon.

[marcgfx]

Habe heute bemerkt, dass Devader nicht mehr so rund läuft auf meinem Laptop. MasterQ32 hat das leider auch miterleben dürfen auf seinem Gerät. Ich befürchte es liegt am Sand und zu vielen texture-lookups... WebGL shader optimieren, wirklich noch nicht mein Spezialgebiet. Ich muss es allerdings noch zuerst testen, bevor ich mich komplett in die Materie stürze. :(