[Projekt] Devader

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.

Re: [Projekt] Devader

Beitragvon marcgfx » 19.06.2017, 11:44

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: ?
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 19.06.2017, 12:21

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: Ansicht erweitern :: 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: Ansicht erweitern :: 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 :)
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon scheichs » 19.06.2017, 12:23

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...
scheichs
 
Beiträge: 195
Registriert: 28.07.2010, 20:18

Re: [Projekt] Devader

Beitragvon marcgfx » 19.06.2017, 14:00

Bild
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: Ansicht erweitern :: 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: Ansicht erweitern :: 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.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon joeydee » 19.06.2017, 14:49

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.
joeydee
 
Beiträge: 467
Registriert: 23.04.2003, 15:29

Re: [Projekt] Devader

Beitragvon marcgfx » 19.06.2017, 14:53

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
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon Laney » 20.06.2017, 14:59

yo.. die bewegten Dünen machens nochmal eine ganze Ecke krasser. Gänsehaut
Benutzeravatar
Laney
 
Beiträge: 15
Registriert: 30.05.2017, 14:23

Re: [Projekt] Devader

Beitragvon marcgfx » 21.06.2017, 01:38

:D Danke Laney, nicht zu viel schmeicheln sonst werd ich noch rot.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 22.06.2017, 17:06

Bild
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.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 22.06.2017, 21:05

Bild
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.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 23.06.2017, 14:25

Bild
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.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 25.06.2017, 18:34

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.
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon Laney » 26.06.2017, 11:44

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.
Benutzeravatar
Laney
 
Beiträge: 15
Registriert: 30.05.2017, 14:23

Re: [Projekt] Devader

Beitragvon marcgfx » 01.07.2017, 14:20

@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.
Bild
Bild
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

Re: [Projekt] Devader

Beitragvon marcgfx » 05.07.2017, 03:07

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. :(
Benutzeravatar
marcgfx
 
Beiträge: 998
Registriert: 18.10.2010, 23:26

VorherigeNächste

Zurück zu Vorstellungsbereich

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron