Showroom - Aktuelle Arbeiten und Projekte

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.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Bomben :-)

Kommt drauf an. Für den Spaß brauchst Du Multiplayer, Netzwerk oder lokal. Und dann paar Extras, weil's sonst schnell langweilig wird. Aufm Amiga gab's damals Dynablaster, glaube ich, das hatte auch nen Story-Modus mit ner Levelprogression und verschiedenen Gegnertypen. Oder Du machst ein Zelda draus und lässt in ner isometrischen Welt mit Bomben Steine rumschieben, Schalter betätigen und kleine Rätsel lösen.

[edit] Dynablaster Orginal SingePlayer:
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2517
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Jonathan »

Schrompf hat geschrieben: 25.09.2024, 15:39 Bomben :-)
Hahaha, ja, das klingt nach einer guten Idee, hehe.

Ich denke ich werde bloß lokalen Multiplayer einbauen. Netzwerk wäre cool aber ist schwierig zu implementieren, ich hab damit zumindest noch quasi keinerlei Erfahrung. Ich hab aber mal irgendwo gelesen, dass man die ganze Engine von Anfang an darauf auslegen muss, weil es später nahezu unmöglich ist das noch obendrauf zu pfropfen - das Beweisen ja auch Beispiele wie Anno 1503 für das immer ein Multiplayermodus versprochen wurde, der dann aber einfach nie kam.

Und zweitens - mal ehrlich, wer spielt das online? Man kann sich ja vom Harald die Online-Highscore anschauen, das haben sehr selten zwei Spieler weltweit zum selben Zeitpunkt gespielt. Klar könnte man am zfx Stammtisch was organisieren, aber für realistisch 1-3 Event in der Lebenszeit des Spiel mach ich mir die Mühe halt nicht.

Lokaler Coop hingegen - warum nicht. Es können ja 2 bis theoretisch 4 Spieler auf einer Tastatur spielen (haben wir früher in Vorlesungen mit Achtung die Kurve! so gemacht), oder man steckt einfach noch ein paar Controller an. Und mit Leuten die man persönlich kennt zu spielen macht ohnehin mehr Spaß :)


Allerdings: Um einen Singleplayermodus komme ich wohl nicht herum, zumindest Bots muss ich wohl einbauen. Denn Spieler müssen das ja erstmal alleine testen, bevor sie ihre Kumpels anstiften das auszuprobieren, denke ich. Man will ja zumindest wissen ob es gut läuft und die Steuerung flutscht und so.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
NytroX
Establishment
Beiträge: 385
Registriert: 03.10.2003, 12:47

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von NytroX »

Also Upgrades auf jeden Fall.
Neben den Klassikern wie Explosions-Vergrößerung, mehr gleichzeitigen Bomben, Durchdringung von Wänden und kürzere Zündschnur zählen dazu auch Bomben-Ketten, kicken, werfen und die Superbomben (wenn man 2 oder 3 ineinander kickt). Und werfen kann man auch andere Spieler.

Skills sind auch nice, wie z.B. ein Raketen-Rucksack, Item-Klauen, kurz unsichtbar machen, etc.

Reittiere sind auch cool, weil sie einem ein 2. Leben geben (beim ersten "Tod" stirbt nur das Reittier). Die können dann auch noch Skills haben, wie z.B. Musik (eine Note schießen) bei der man dann eine Weile tanzen muss, wenn man getroffen wird.

Und den Harry am Ende, der einen überfährt, wenn man zu lange braucht ("hurry!" - und das Spielfeld wird kleiner. Der Vorläufer jedes modernen BattleRoyale-Spiels)

Und natürlich das Feature, dass man nach seinem Tod von außen Bomben reinwerfen kann und wenn man jemand damit tötet dessen Platz im Spiel wieder einnimmt.

Und wenn du dann noch Spass dran hast mehrere Level, z.B. mit Eis wo man ein wenig rutscht, mit Förderbändern, die die Bomben transportieren, mit Teleportern/Portalen, und was dir sonst noch so einfällt :-)

Dann steht einem spaßigem Multiplayer mit Freunden nichts mehr im Weg, der dann auch wesentlich länger als nur 5 Minuten Spass macht.
antisteo
Establishment
Beiträge: 919
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von antisteo »

Einfach mal simples Phong Shading in hardlife.io dazugebaut.

die Normale eines gl_Point bekommt man ganz easy per

Code: Alles auswählen

vec3 normal = vec3(gl_PointCoord.x * 2.0, gl_PointCoord.y * 2.0, 1.0 - 2.0 * dist); // screen space
Danach braucht man noch die Koordinate der Lichtquelle im Screen Space und fertig
Dateianhänge
Screenshot 2024-10-02 at 16-02-47 Hard Thug Life.png
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Ja, nice! Zusammen mit ner hinreichend genauen ShadowMap könnte das auch Deine "woher krieg ich ne Normale"-Probleme lösen.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
antisteo
Establishment
Beiträge: 919
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von antisteo »

Schrompf hat geschrieben: 02.10.2024, 16:24 Ja, nice! Zusammen mit ner hinreichend genauen ShadowMap könnte das auch Deine "woher krieg ich ne Normale"-Probleme lösen.
Die Normale hab' ich ja. Das war easy.

Jetzt muss ich mich aber noch in die Three.js-Shadowmap-Codes reinlesen, um in meinem Shader den richtigen Schnipsel zu aktivieren dafür. (Naja und noch ein Jammer-Topic: Ich muss mal wieder deren komplettes System aufbohren, damit die Points auch so wie ich es will in die Shadow-Kamera gerendert werden)
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
antisteo
Establishment
Beiträge: 919
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von antisteo »

Hat zwar nix mit Spieleentwicklung zu tun, aber ich habe mal einen hübschen E-Rechnung-Betrachter gebaut:
E-Rechnung-Validator.jpeg
In dem Online-Validator lädt man wahlweise ein Zugferd-PDF oder eine XML-Datei wahlweise im rsm:- oder im cbc:-Format hoch. Der Validator liest die Daten dann ein und stellt dar, was er herausfinden konnte.

Zu bestaunen unter:

https://launix.de/launix/e-rechnung-validator/
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Benutzeravatar
joeydee
Establishment
Beiträge: 1086
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »


Prototyp für Elemente von Puzzle-Games: Polygonzug tesselieren, anfassen, verschieben, drehen. Hier in Winkel- und Rasterschritten, damit man z.B. richtige Endpositionen besser vergleichen kann.
Die Anfass-Logik: Am Rand bedeutet Drehen, weiter in der Fläche Verschieben, beim Hovern ändert sich der Gizmo-Cursor entsprechend. Also ohne Shortcuts oder Werkzeuge oder selektionsbasierte Gizmos. Einfach direkt reinklicken und bewegen.

Ziel ist, mein Framework mit einem spezifischen GUI zu erweitern, welches u.a. auf solchen interaktiven Polygonen basiert, um möglichst beliebige einfache grafische Minigames damit basteln zu können. Also z.B. Teile sortieren/zuweisen, Streichholzrätsel, Symbole mit drehbaren Scheiben einstellen, etc., mit verschiedenen Constraints (nur drehbar, nur 60 oder 90 Grad drehbar, nur verschiebbar in Rasterschritten, nur verschiebbar auf eine Liste gültiger Endpositionen, ...)
Erstmal nur auf Polygonbasis; auf Pixelmaskenbasis wäre später auch noch denkbar, aber ist erstmal nicht vorgesehen.
Benutzeravatar
joeydee
Establishment
Beiträge: 1086
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »




Für so Zeuch und so.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Kollisionstest Kreis gegen Bitmap: Zusammenfassung aller Überlappungs-Pixel durch ein bis zwei Kontaktpunkte, weil Box2D maximal 2 Kontaktpunkte pro Kollisionspartner-Paar zulässt.
kreis_vs_bitmap.png
kreis_vs_bitmap.png (10.11 KiB) 1071 mal betrachtet
Ich lege dazu eine Ausgleichsgerade durch alle überlappende Pixel, teile die Punktewolke anhand dieser Gerade in zwei Hälften, und bilde jeweils den Durchschnitt der Punkte auf beiden Seiten.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
TomasRiker
Beiträge: 83
Registriert: 18.07.2011, 11:45
Echter Name: David Scherfgen
Wohnort: Hildesheim

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von TomasRiker »

Schrompf hat geschrieben: 24.10.2024, 23:45 Ich lege dazu eine Ausgleichsgerade durch alle überlappende Pixel, teile die Punktewolke anhand dieser Gerade in zwei Hälften, und bilde jeweils den Durchschnitt der Punkte auf beiden Seiten.
Klappt das auch, wenn sich der Kreis in einer Art Tunnel befindet, wo es oben und unten Kontakte gibt? Was machst du am Ende des Tunnels, wo es dann Kontakte oben, unten und vorne geben müsste, aber Box2D nur 2 Kontakte zulässt?

Die Begrenzung auf 2 Kontakte kommt wahrscheinlich daher, dass Box2D nur konvexe Formen zulässt, aber deine Bitmap wird in der Regel konkav sein - ich fürchte, da sind Probleme vorprogrammiert ... Eine mögliche Lösung wäre, bei Bedarf mehrere Shapes zu verwenden, dann wäre die Anzahl der Kontakte unbegrenzt.

Alternativer Ansatz: Du erzeugst echte konvexe Shapes (Rechtecke) "on demand" für den Bereich der Bitmap, der gerade relevant für Kollisionen ist und löschst sie anschließend wieder. Dazu könntest du nebeneinander liegende Pixel zu Blöcken zusammenfassen. Vorteil ist, dass du dich dann zu 100% auf die Kollisionsbehandlung von Box2D verlassen kannst und nicht dein eigenes Süppchen kochen musst.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Ja, das könnte Probleme geben. Ist mir bewusst, nehme ich in Kauf. Sie sind aber seltener, als man glaubt, denke ich. Dein Beispiel mit der Kugel im Tunnel z.B. - die Kugel wäre da nie hingekommen. Wenn sie sich in einen immer engeren Tunnel hinein schiebt, wären dann die Kontaktpixel alle vorn, und dann gibt's ne Ausgleichsgerade durch die Mitte und einen Kontakt links davon und einen rechts davon. Passt.

Problematischer wird's eher später dann, wenn ich dann auch Bitmaps bewegen lasse. Und da kann man ja z.B. auch ein 'm' kriegen und durch die Gegend schubsen... mal gucken.

Wenn ich konvex zerlegen muss, hab ich aber eh verloren. Das hätt ich nämlich gleich ab Start machen können, wie Noita es gemacht hat, und hätte mir diesen ganzen Pfad erspart. Find's jetzt trotzdem gut, dass ich es gemacht habe, hat bisweilen Spaß gemacht und mir paar schöne Tools ins Framework gebracht. Aber wär doch ne ziemliche Zeitverschwendung, wenn man am Ende eh doch wieder nur konvexe Polys rumschubst.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
TomasRiker
Beiträge: 83
Registriert: 18.07.2011, 11:45
Echter Name: David Scherfgen
Wohnort: Hildesheim

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von TomasRiker »

Schrompf hat geschrieben: 25.10.2024, 09:42 Problematischer wird's eher später dann, wenn ich dann auch Bitmaps bewegen lasse. Und da kann man ja z.B. auch ein 'm' kriegen und durch die Gegend schubsen... mal gucken.
Oh ja, das könnte schwierig werden. Dann musst du auch Kollisionen Bitmap vs. Bitmap behandeln.
Was aber noch viel schwieriger werden dürfte, ist Continuous Collision Detection für Bitmaps zu implementieren (insbesondere bei Bitmap vs. Bitmap). Box2D kann das ja für die eingebauten Shapes. Das verhindert, dass Objekte bei hohen Geschwindigkeiten durcheinander durch fliegen (z. B. ein Geschoss durch eine dünne Wand).
Auch da würdest du enorm profitieren, wenn du deine Pixel in Rechtecke verwandelst und Box2D seine "Magic" machen lässt.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Tomas, hör auf. Ich mach das jetzt so :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
TomasRiker
Beiträge: 83
Registriert: 18.07.2011, 11:45
Echter Name: David Scherfgen
Wohnort: Hildesheim

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von TomasRiker »

Mach bitte vorher und nachher eine Bestandsaufnahme deiner grauen Haare :)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Naja, wir haben den Thread hier jetzt eh schon hart derailed, aber:

Einerseits beruhige ich mich die ganze Zeit selbst: hey, ein Großteil der Arbeit ist auch dann nicht umsonst gewesen, wenn ich das in Box2D nicht reingeklöppelt kriege. Dann zieh ich halt meine eigene Physik auf, mit Kartenspielen und Leichten Personen. Und für's Tauchspiel wird das auch klappen, ich mach hier keine elaborierten Konstrukte aus Motoren, Federn und Zahnrädern. UND alles passiert unterwasser-gemächlich. Geht schon.

Andererseits könnte mich der Bitfield-Ansatz auch in den Hintern beissen. Ich kann z.B. keine ordentliche Eindringtiefe angeben, weil mir Subpixel-Genauigkeit fehlt. Hätte ich ab Start auf Päckchen gesetzt, hätte ich ganz banal hierarchisch reinbohren können - zuerst nen 8x8-Pack, als Quad oder Kugel, wenn der kollidiert als nächstes 4x4-Päckchen und so weiter. Quasi implizite Boxen oder Kreise für jeden Pixel, nur halt nicht explizit millionenfach instanziiert. Hat immer noch die Konkav-Probleme, aber wär auch kontinuierlich machbar. Das krieg ich dann aber nicht mehr in Box2D reingepatcht, dazu ist deren interne Struktur allzu festgelegt auf Paare aus Körpern.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
TomasRiker
Beiträge: 83
Registriert: 18.07.2011, 11:45
Echter Name: David Scherfgen
Wohnort: Hildesheim

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von TomasRiker »

Schrompf hat geschrieben: 25.10.2024, 10:39 Das krieg ich dann aber nicht mehr in Box2D reingepatcht, dazu ist deren interne Struktur allzu festgelegt auf Paare aus Körpern.
Evtl. liegt da ein Missverständnis vor. Es gibt bei Box2D einerseits Bodies und andererseits Fixtures. Die Fixtures bestimmen die geometrische Form, die Verteilung der Masse und die Materialeigenschaften. Ein Body kann beliebig viele Fixtures haben. Deine Bitmap hätte einen einzigen Body, aber sehr viele Fixtures. Im einfachsten Fall für jedes Pixel ein Quadrat, wobei du dann größere komplett gefüllte Flächen zu größeren Rechtecken zusammenfassen kannst, um die Performance zu verbessern. Optimierungstechnisch wäre das sicherlich auch ein interessantes Problem, an dem man sich austoben kann: Wie fasst man die Pixel möglichst schnell zu möglichst wenigen Rechtecken zusammen? Auf die Schnelle mal ein Paper dazu: https://library.utia.cas.cz/separaty/20 ... images.pdf

Wenn du wolltest, könntest du für das "Welt-Bitmap" auch die Fixtures dynamisch erzeugen und löschen, um nur die Bereiche abzudecken, die gerade für potenzielle Kollisionen relevant sind, und um Box2D nicht permanent mit tausenden von Fixtures arbeiten zu lassen. Da sollte man aber gucken, ob das wirklich nötig ist.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Jetzt häng Doch nicht am deutschen Wort "Körper" auf. Irgendwann ist einfach mal gut.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
joeydee
Establishment
Beiträge: 1086
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Im Zuge meiner letzten Polygon-Experimente (Tesselation, Polygon-Puzzle-GUI), und auch inspiriert von Schrompf's Baustellen, habe ich mal das "Physics of JellyCar"-Video wieder hervorgekramt und Lust bekommen, einen Teil davon umzusetzen.
Konzepte daraus:
a) Es gibt nur Massenpunkte, die die Polygone formen.
b) Es wird nur "Punkt in anderem Polygon" gegenseitig getestet, der kürzeste Weg für den Punkt hinaus ermittelt, und das Ergebnis auch anteilig auf die Massenpunkte des betroffenen Liniensegments angewendet.
Heißt auch, alles muss mit einem gültigen Zustand starten, und die Schritte müssen klein genug sein dass keine Kollision verpasst wird.
Dazu meine vorhandene 2D-SDF-Polygon-Distanzfunktion von Inigo Quilez so aufgebohrt, dass sie neben der Distanz auch Segment und anteilige Lage auf dem Segment zurückgibt, worüber auch Kontaktpunkt und Normale direkt bestimmt werden können.
c) Auf Springs ganz verzichtet, stattdessen nur die Idee mit der Referenzform umgesetzt. Dabei statt Winkelberechnungen nur Dotprodukte verglichen und gemittelt, da diese dem sin und cos des Winkels entsprechen, und man die beiden Werte sowieso gleich wieder zum Drehen der Referenzform benötigt. Also Trigonometrie komplett vermieden.
Außerdem statt dem deformierten Softbody am Ende nur die Referenzform gezeichnet (deshalb tauchen die Formen im Video auch leicht ein bis alles wieder "relaxed" ist).

Was noch fehlt ist ein ordentlicher Euler-Integrator, mit korrektem Aufteilen der Massepunkt-Geschwindigkeiten nach Winkel und Masse bei Kollision. Hatte ich früher schonmal gemacht (Partikelkollisionen, Springs), aber beim Abrufen des ganzen mal eben schnell aus dem Kopf gestern Abend doch etwas verhaspelt ;) Demnächst dann doch nochmal "richtig", mit INet-Unterstützung.

Bisher habe ich also nur Positionskorrektur nach Kollision drin, keine Physik. Daher fühlen sich auch die resultierenden Drehungen falsch an. Gibt außerdem noch Grenzfälle die ich nochmal anschauen muss, aber prinzipiell läufts.


Viel Text, unspektakuläres Video. Trotzdem Freude.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2517
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Jonathan »

Ahjo, das sieht ziemlich nett und robust aus. Wäre dann interessant das mit Graviation und ggf. schnelleren Objekten zu sehen, aber das ist so schon echt nett, wenn man bedenkt, wie komplex die Objekte doch sind.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
joeydee
Establishment
Beiträge: 1086
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Jonathan hat geschrieben: 28.10.2024, 12:44 Wäre dann interessant das mit Graviation und ggf. schnelleren Objekten zu sehen
Jupp, da waren nur per-Frame-Positionskorrekturen bei Detection drin, keine Geschwindigkeiten oder irgendein Timestep.
Aber jetzt habe ich mal einen Verlet Integrator mit festem Timestep draufgeworfen. Nur ein kurzes Video, aber Spielwiese eröffnet. Es ist trotzdem noch viel zu tun bis man damit was Sinnvolles anfangen kann.


Bisher hatte ich immer nur mit Euler Semi-Implizit rumgepfuscht(d.h. das intuitive v+=a*dt; p+=v*dt;).
Verlet soll gerade für solche gegenseitig voneinander abhängigen Sachen numerisch stabiler sein. Die Berechnung selbst mag auf den ersten Blick unintuitiv sein (pos = 2 * pos - opos + acc * dt * dt;) aber mir gefällt hier auch das Handling besser (man ändert von außen z.B. bei Kollision nur noch Positionen, keine Geschwindigkeitsvektoren).
Die Erklärungen von Pikuma waren dabei sehr hilfreich: https://www.youtube.com/watch?v=-GWTDhOQU6M
Zu seiner Frage bei Miunte 55:xx zur ordentlichen Reflektion an einer Plane wäre meine Antwort: Einfach pos und oldpos auf die andere Seite der Plane spiegeln. Das funktioniert dann auch mit beliebig ausgerichteten Planes. Meine im Video ist so eine.
Und noch ein Pro-Tipp: Für mehr Spaß die automatischen engl. Untertitel anschalten und bei jeder neuen "Verlet"-Übersetzung einen Schnaps ;)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Nice, sieht echt solide aus! Und Danke für den Link.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
joeydee
Establishment
Beiträge: 1086
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »


Hier gibts jetzt mehr zu sehen :)

Zwischendurch wechsle ich zwischen Rigid und Soft, das ist kein eigener Modus, sondern die Wiederherstellungskraft der Bodies. Im Moment nur als Lerp-Faktor implementiert, nicht als Feder, d.h. ich bin da noch nicht frameunabhängig, ist noch die letzte Baustelle vorerst.
Mit Verlet kann ich den Lerp direkt auf 1 setzen für Rigid Bodies; am Ende des Verlet-Videos wurden "Sticks" vorgestellt, "Springs" ohne Federkraft, die immer ihre Länge halten, nicht federn. Bei Euler war mir sowas gern mal explodiert. Aber wahrscheinlich hatte ich da früher auch andere Fehler gemacht.
An manchen Stellen sieht man auch, dass die Körper sich durchdringen können, vor allem die spitzen Zacken des Sterns sind da anfällig, wird auch im Jelly-Video erklärt. Natürlich kann das hier vor allem auch beim Umschalten von Soft auf Rigid passieren, aber an sich löst sich das Gewusel meist schnell auf.
Ich habe einen kleinen SDF-Radius von wenigen Pixeln drin, bei einer Physik-Framerate von 240 (0-1 Steps/Bildframe ohne VSync, 4 bei 60Hz), da läuft das relativ stabil bei den gezeigten Geschwindigkeiten und Größen.

Fazit: War am Ende gar nicht so schwierig wie ich zuerst dachte, und der "schmutzige" Kollisionsalgo reicht für viele Anwendungen.
Knackpunkte für mich waren die Kollision und Wiederherstellung von Polygonen (s. Jellycar-Video), und ein ordentlicher Integrator für Massenpunkte (s. Verlet-Video).
Für die eigene kleine 2D-Physikengine fehlt jetzt noch Friction, Broad Phase Collision Detection, Massen-Management, Joints, ... aber nicht heute, und morgen nicht gleich ;)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4996
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

screenshot0001.png
Meinen Surface-Generator auf den aktuellen Stand gebracht. Sieht echt fies aus mit so großer Simpel-Geometrie als Eingabe. Zugrunde liegt immer noch ein 2mx2m Grid für einen DungeonCrawler. Gibt noch viel zu tun.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Andy90
Beiträge: 72
Registriert: 08.10.2023, 13:02

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Andy90 »

Habe die letzten tage begonnen, ein Beispiel Projekt für mein Framework zu erstellen. Ziel wird ein kleines Jump 'n Run game, indem man münzen einsammeln muss um das Level abzuschließen.

Antworten