C++ Spieleprogrammierung bewegung

[kiname]

Hallo,

ich habe von ein Spiel im 2D Worms Style zu programmieren (C++/SFML).

Jedenfalls habe ich noch keinen direkten Ansatz wie ich die Bewegung eines Spielers über so eine Unebene Ebene in der Collision Detection realisieren soll.
Wenn der Spieler sich beispielsweise nach rechts bewegt könnte es sein dass er bergauf oder bergab geht oder vielleicht sogar von einer Klippe stürzen.

In einem Klassischen "Blockgame" Jump and Run kann man ja einfach auf die Position des Blocks prüfen aber so mit einer Schiefen Ebene geht das nicht mehr.

Kann mir jemand Tipps geben wie ich sowas realisieren kann?

mfg

 

[benneq]

Im Grunde hast du ja nicht mal Ebenen oder Geraden, sondern einfach nur 'nen Haufen Pixel. Wenn irgendwo ein Loch gesprengt wurde, dann würde ich die kreisrunde Landschaft nicht als mathematische Funktion ausdrücken wollen.

Ich würde einfach die x/y-Koordinate des Pixels nehmen, auf dem der Spieler gerade steht, bzw. statt einem Pixel mit 4 Pixeln Breite arbeiten. Und beim Laufen schiebst du halt immer die x-Koordinate weiter und berechnest die Kollision auf Pixelebene.

 

[kiname]

Hallo,
Danke für die Antwort aber ist das nicht total rechenaufwendig wenn man jeden Pixel im umkreis des Spielers überprüft?

 

[blöderidiot]

Danke für die Antwort aber ist das nicht total rechenaufwendig wenn man jeden Pixel im umkreis des Spielers überprüft?

Das wäre es, es sei denn ==> ...

 

[kiname]

Danke dann werde ich es mal so ausprobieren

 

[Nai]

Ich bezweifle einfach einmal stark, dass es sich bei den Überprüfungen um den Spieler herum lohnt einen Quadtree zu verwenden. Bei 9 auf 9 Pixel sind es gerade einmal 81 Überprüfungen die zudem noch gut vektorisiert werden können. Deshalb ist wahrscheinlich die Suche in einem Quadtree (oder alternativ in einem hierarischen Gitter, was m.E. in diesem Fall besser geeignet wäre) kaum schneller. Selbst wenn es schneller wäre, in beiden Fällen wird die Zeit so klein und damit bedeutungslos sein, sofern du nicht 10000000 Figuren überprüfen musst.

 

[The Ripper]

Aus den 9 können gerne mal mehr werden bei höher auflösenden Displays. Sofern man dann auch genauer rendert

 

[VikingGe]

Man sollte nie seine Spiellogik von der Bildschirmauflösuing abhängig machen.

Entweder, er hat die Level als Rastergrafik gegeben, dann kann er immer noch in der Originalauflösung rechnen, oder aber er hat die Geometrie in Form von Linien oder Polygonen gegeben, in dem Fall wird sowieso anders gerechnet.

(oder alternativ in einem hierarischen Gitter, was m.E. in diesem Fall besser geeignet wäre)

Hat das auch irgendeinen englischen Namen oder zumindest irgendeine Bezeichnung, unter der man auch etwas findet, wenn man Google danach befragt?

Bei 9 auf 9 Pixel sind es gerade einmal 81 Überprüfungen die zudem noch gut vektorisiert werden können.

Wobei C++-Compiler generell kaum bis gar nicht in der Lage sind, Dinge zu vektorisieren, in denen if-Abfragen o.ä. vorkommen. Solchen Code müsste man dann schon von Hand schreiben.

 

[Nai]

Rendering sollte ja von der Physik entkoppelt sein oder nicht (wobei es auch hiervon ausnahmen gibt wie den Z-Buffer für Partikelphysik zu verwenden)? Des Weiteren besitzen die Gradientenoperatoren immer einen niedrigen Radius - zu unlokal und die Klippe in 2 meter Entfernung beeinflusst noch dein Rutschverhalten.

@ VikingGe
Meinte damit mehrere Gitter mit unterschiedlicher Auflösung, wo man in jedem Gitter leicht einen Lookup anhand der Position machen kann und nicht zum Finden des entsprechenden Knotens einen Baum traversieren muss.