Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

24.02.2013, 15:42

[XNA, VB.NET] Sprite Kollision mit Hintergrund möglich?

Hi,
habe vor einen kleinen 2D Scroller zu programmieren.
Es soll ein kleines Ballergame im C64 Style sein.

Was ich bereits habe ist die Steuerung meines Raumschiffes, verschiedene Waffensysteme (per Items ausrüstbar) und ein paar animierte Gegner.

Ich zerbreche mir die ganze Zeit den Kopf, ob es möglich ist abzufragen, ob meine Sprites (Rectangles) mit dem Hintergrund kolidieren.
Die Hintergrundgrafik würde ich nicht uznbedingt nutzen, eher vielleicht eine Maske (0 für nichts, 1 für Kollisionspunkt) die ich dann anstatt des Bildes benutze.

Kann mir da wer einen Lösungsansatz bieten oder auf den richtigen Weg führen?

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

2

24.02.2013, 16:19

Ich denke, du willst nicht auf Kollisionen mit dem Hintergrund prüfen, sondern auf Kollision mit Objekten auf dem Hintergrund. Ob diese nun statisch sind oder sich bewegen könnten spielt dabei erstmal keine Rolle.
Wenn dir ganz einfache Kollisionen (nur Rechtecke oder nur Kreise) reichen, kannst du auch versuchen, es selbst zu impleentieren. Sollen die Kollisionsboxen aber komplexer sein, dann solltest du dir mal Physik-Bibliothrken anschauen, wie Box2D (es gibt .Net Portierungen).
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

3

24.02.2013, 19:02

dann hätte ich Objekte geschrieben :) Nein, tatsächlich mit dem Hintergrund.
Deiner Antwort zufolge geht das wohl nicht - schade.

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

4

24.02.2013, 20:41

Das wollte ich damit nicht geschriebn haben. Pixelgenaue Kollisionn gehen schon, nur ist es i. d. R. besser, wenn man nicht auf Pixeln arbeitet, sondern auf einer "Umschreibung" des Objekts, also auf geometrischen Figuren. So erspart man sich unschöne Effekte und je nach Implementierung dürfte eine pixelgenaue Kollision weniger Rechenzeit beanspruchen.
Auch wenn du also keine Objekte in deinem Sinne hast, so hast dudennoch für den Spieer auf irgendeine Art erkennbare Gebiete.
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

5

25.02.2013, 14:07

Was im Hintergrund soll denn genau kollidieren? Pixel mit bestimmten Farben? Darüber musst du dir Gedanken machen. Irgendwie müssen die Kollisionsinformationen ja aus dem Bild gezogen werden. Ansonsten ist das ganz wie schon geschrieben nur noch eine Pixelgenaue Kollision. Einfach gucken, ob zwei Grafiken übereinander liegen. Wenn ja, dann guckst du die Bereiche an, welche übereinander liegen. Jetzt vergleichst zu die Pixel. Überlappen sich "kollidierende" Pixel, hast du halt eine Kollision.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

6

28.02.2013, 18:56

ich werde das Pixelgenaue verwerfen und auf Objekte zurückgreifen.
Macht glaube ich mehr Sinn, als dass ich mich jetzt verrenne :)

Danke

Werbeanzeige