Ich schieb das mal in die Expertenrunde, weil das wohl wirklich nicht einfach ist und eine interessante Diskussion werden könnte.

@Topic: Das ganze Pixelweise zu überprüfen wäre unmöglich mit dem GM denk ich mal. Vielleicht könnte man die Fläche in Quadrate unterteilen und dann prüfen, mit vielen Quadraten das Objekt kollidiert.

Pixelweise geht doch auch
Wenn man nur einmal überprüft welche "Reihe" (Fachbegriff bitte xD) wieviel Pixel hat und dann einfach nur das ganze abfragt...

In dem aufgezeigten Fall ist doch pixelweise sehr einfach. Oben links anfangen und so lange nach rechts und unten gehen bis man auf einen schwarzen Pixel trifft. dann der Randlinie folgen, bis man den Anfang des Bereichs findet. (entweder A oder B je nach Farbe). Dem Rand kann man ja folgen indem man von dem aktuellen schwarzen Pixel das benachbarte schwarze Pixel in die Bewegungsrichtung findet, das an ein schwarzes und ein andersfarbiges Pixel grenzt.
Dann folgt man der Linie bis man das Ende des Bereichs findet und zählt die Pixel innerhalb des Umlaufenen Abschnitts des Objekts.

War das einigermaßen verständlich erklärt? Falls nicht fragt und ich versuchs nochmal zu erklären...

Edit: Das ist zwar so eigentlich ganz elegant, aber eigentlich gehts ja einfacher. Man geht einfach jede Reihe ab, wie copyboy gesagt hat, und zählt wieviele schwarze Pixel sie hat, wenn sie in dem Bereich liegt.

Sicher geht das mit den Pixeln, mein Problem ist nur die Geschwindigkeit. Durch sämtliche Pixel zu gehen und dann auch noch draw_getpixel (was du ja vermutlich nehemn willst, etwas anderes fällt mir da nicht ein), welches ja auch noch mal recht lahm ist...in echtzeit wird das nicht möglich sein. Ist halt die Frage ob das in jedem Step berechnet werden soll, oder nur an besonderen Stellen.

Das braucht man ja nur zum Start einmal überprüfen.
Man zählt alle Pixel und schreibt die in ein Array.
Beispiel (Kanns anders nicht erklären):

Jetzt fragt man ab wo das Objekt ist und zählt die Pixel der einzelnen Reihen zusammen, die in dem Bereich sind.

ein kleiner Denkanstoß (ka ob der weg geht):

der Schwerpunkt eines Objektes ist doch der punkt um den mann das Objekt beliebig drehen könnte ohne, das es sich zurückdreht
wenn der Schwerpunkt eines Objekts genau auf dem strich zwischen a und b liegt ist die auf a und b verdeckte Fläche gleich groß

man könnte also von jedem Objekt einmal manuell den Schwerpunkt und die Fläche ermitteln also bei der Programmierung das spiel
diesen Schwerpunkt speichern und dann je nach höhe relativ zur Trennlinie das Verhältnis der Flächen bestimmen?

vlt red ich auch grad quatsch

wenn das Objekt wie auf der Zeichnung nur aus kreisen besteht gäbe es ja auch die Möglichkeit durch geometrische Formeln an die jeweilige Fläche zu kommen
aber das geht halt nur sehr schwer und auch nur wenn die Objekte grundlegende geometrische formen sind

gruß
iTeM

Du müsstest theoretisch nicht jeden Pixel überprüfen. Sagen wir du überprüfst jeden 10. Pixel, was ja 10 mal so schnell geht. Wenn dann ein Pixel schwarz ist und der davor weiß war weist du, dass die "Grenze" dazwischen ist. dann kannst du den Pixel genau in der Mitte prüfen, und dann so weiter. Dann könntest du wieder an der Grenze entlang gehen wie ich das vorher beschrieben hab. Falls du Interesse an dem Prinzip hast sag Bescheid dann führ ich dir das gerne etwas genauer aus...

@T-Moe
Deine Idee ist zwar vom Prinzip her gut, funktioniert aber nicht sehr genau. Ein Beispiel:

Nach deiner Methode würdest du ersten und elften Pixel prüfen und weil sie beide schwarz sind annehmen, dass dazwischen auch alles schwarz ist.
Du gehst nämlich davon aus, dass es dazwischen nur eine "Grenze" gibt, bei mehreren schlägt deine Methode fehl.

copyboy's Methode scheint mir die beste, schnellste und genauste zu sein. Eventuell könnte man die Methode auch noch optimieren indem man auch noch zu Beginn Zwischensummen ausrechnet, damit man nicht in jedem Step so viele Zeilen addieren muss.

Ich sage: Da gibt es eine ralativ sehr einfache Lösung. Ich bin aber noch am genauen überlegen und mache evtl. noch ein Example. Wenn ich Zeit habe. Aber ich probiere es jetzt mal.
Die Frage ist nur:
Brauchst du das in jedem Step oder nur am ende. Also zB. wenn der Spieler in eine gewissen Zeit die Fläche des anderen zerstören soll und am ende dann berechnet werden soll, wie viel er jetzt in % zerstört hat.

Zerstören???
Darum geht's doch garnicht - es geht darum wie viel % (oder was auch immer) ein Objekt (= dessen Sprite) in einer bestimmten/bestimmten Region/en einnimmt...?
Noch eine Frage an den Ersteller:
Muss das sehr genau sein? Man kann je nach dem auch nur jede 3/5/10 Pixel prüfen, was dass ganze 3/5/10 mal schneller mach obwohl es immer noch ziemlich genau ist. Wenn es dir überhaupt nicht um die Genauigkeit geht kannst du ja auch einfach ein imaginäres Rechteck nehmen (was die Sache sehr vereinfachen würde).

Ich bin gerade an der arbeit. Bis jetzt klappts noch ganz gut.
Ich berechne erstmal die Pixeln in Zeilen des Sprites mit unter for.
...

Also, jetzt bin ich doch etwas schockiert... ich meine, Berechnungen von Flächen hatten wir damals glaub ich schon in der Grundschule. Klar, Du hast vielleicht nicht nur eine Ellipse, sondern mehrere überlappende, aber wie mein Mathelehrer damals schon gesagt hat:
Die Transferleistung mußt Du schon bringen.

gm-d.de/wbb/index.php/User/1168/@Melancor: das will ich aber jetzt mal sehen, dass du das "sooo einfach" ausrechnen kannst
außerdem:
die objkete müssen aus geometrischen formen bestehen damit man das ganze geometrisch berechnen kann

die Pixelzählvariante ist wohl am einfachsten wenn auch langsam

@copyboy:
ich glaube Daniel braucht nur die info ob das script so schnell sein muss, dass es in jedem step ausgeführt werden kann das mit dem zerstüren war nur ein bespiel

wie Daniel schon sagte wäre es vlt ganz gut den Hintergrund der Berechnung zu kennen

Genau. Zwischendurch: Es geht gut voran. Bin evtl. gleich fertig. Ob's blubberblub so meint, weiß ich nicht.

Beispiel-Download
Ich hab jetzt was gemacht - bin aber nicht sicher ob es stimmt was ich da geschrieben hab.
Am Anfang gibt man die Genauigkeit an.
Dann zeigt es einem die Zeit an die es für die Berechnung brauchte.
Man kann das Objekt ziehen und verschieben (vertikal).
Mit R kann man das Programm neustarten.

Tipp: Du kannst das auch in eine Datei schreiben und dann halt beim Spielstart laden, dass Berechnungszeit jedes mal am Anfang wegfällt.

EDIT: Sry Daniel, hab garnicht gesehen, dass du auch was machst o_O (Poste es trotzdem).
EDIT2: @blubberblub: Hast du eig. die registrierte Version? Wenn nein: Meins wird bei dir nicht gehen (Benutze Surface)

EDIT3: Siehe unten
Muss echt sagen seins ist besser
Doch, ehrlich Perfekt, Reskekt

Hehe ich hab aus langeweile auch eines geschrieben bevor ich gesehen habe, dass copyboy schon fertig ist ^^
Jedenfalls ist hier noch meines: Download
Mal schnell die Unterschiede zum Beispiel von copyboy auflisten:
- ds_grid wird benutzt => schnellere berechnung der Summe
- durch das ds_grid können beliebige Rechtecke und nicht nur zwei horizontale Flächen berechnet werden
- meins hat keine Genauigkeitsauswahl am Anfang => Starten geht ein wenig länger
- Wenn du GM7 hast kannst du über die neue ds_grid_irgendetwas Funktion das Grid direkt abspeichern, dann fällt die Berechnung weg

Dragoon

So bin fertig mit der beta1. Das Objekt kann man jetzt noch nicht verschieben. Mache ich aber noch.
Will aber jetzt nicht zu viel Zeit damit verbringen. Wenn euch gefällt mache ich weiter.
Aber ihr könnt auch weiter daran arbeiten oder verändern.

EDIT: Ihr beide, Dragoon und copyboy, seit ja Experten. Ich mit ja nur Fortgeschrittener :).
Ich finde das von Dragoon besser. Mit grid und surface kenne ich mich nicht so aus.
EDIT2: Aber jetzt haben wir ja 3 unterschiedliche Beispiele :D.
@copyboy: Stimme dir echt zu. Außer dem verzögerten start ist Dragoon's Echtzeitbeispiel perfekt.