Frage zur Sprite Kollission

[Schranz0r]

hmm Doppelpost.... Naja

ROTOCOPY ist eine schlechte Idee, da es, wie Gernot schon sagt, massig an Speicher frisst.

Ich Schreib mal schnell ne Function,  die dein Problem lösen kann( Hoffe ich).
Dann hat Gernot seine ruhe , und kann sich auf die wichtigeren Dinge konzentrieren.

[Luckeie]

hmm Doppelpost.... Naja

ROTOCOPY ist eine schlechte Idee, da es, wie Gernot schon sagt, massig an Speicher frisst.

Ich Schreib mal schnell ne Function,  die dein Problem lösen kann( Hoffe ich).
Dann hat Gernot seine ruhe , und kann sich auf die wichtigeren Dinge konzentrieren.

Du musst für mich nichts programmieren. Ich habe schon verstanden wie Du es meinst und kann das selbst lösen. Trotzdem vielen Dank für Dein Angebot.

Liebe Grüße

  Luckeie

[Quentin]

dabe fällt mir gerade ein, wenn man so eine allgemein nutzbare Funktion basteln will, hat man ja nicht nur das von Gernot beschriebene problem der unterschiedlichen Größen, sondern auch das von sich überlagernden Sprites. Wenn ich das richtig sehe, müsste man vor dieser Aktion erst mal den kompletten Bildschirminhalt im Backbuffer sichern, das rotierte Sprite zeichen, grabben, Backbuffer restoren, Sprite zeichen ... ich glaub jetzt hab ich alles *grübel*

[Luckeie]

hmm Doppelpost.... Naja

ROTOCOPY ist eine schlechte Idee, da es, wie Gernot schon sagt, massig an Speicher frisst.

Ich Schreib mal schnell ne Function,  die dein Problem lösen kann( Hoffe ich).
Dann hat Gernot seine ruhe , und kann sich auf die wichtigeren Dinge konzentrieren.

Es frißt keinen Speicher. Deine Lösung würde viel mehr Speicher verbrauchen.

  Luckeie

[Luckeie]

dabe fällt mir gerade ein, wenn man so eine allgemein nutzbare Funktion basteln will, hat man ja nicht nur das von Gernot beschriebene problem der unterschiedlichen Größen, sondern auch das von sich überlagernden Sprites. Wenn ich das richtig sehe, müsste man vor dieser Aktion erst mal den kompletten Bildschirminhalt im Backbuffer sichern, das rotierte Sprite zeichen, grabben, Backbuffer restoren, Sprite zeichen ... ich glaub jetzt hab ich alles *grübel*

Gernot muß doch nur die Funktion die er schon hat (ROTOSPRITE) kopieren und das von dieser Funktion erzeugte Ergebnis - also die gedrehten Pixel - anstatt auf den Bildschirm (bzw. Buffer) in den Speicherbereich mit dem zweiten Sprite schreiben - sonst nichts, oder?

Liebe Grüße

  Luckeie

[Quentin]

@luckeie
ich glaube so einfach ist das nicht. Bei Sprites mit quadratischer Grundfläche ginge das wohl recht einfach, aber davon kann man ja nicht ausgehen. Stell dir vor, dein Sprite in ein Balken, 20 Pixel breit und 100 Pixel hoch. Nun drehst du das Teil. Um jetzt die Grafik im Sprite zu speichern benötigst du schon einen größeren Bereich. Ich denke schon, daß der interne Rechenaufwand für diese Verwaltungsaktionen recht aufwändig werden können.

also etwa so
   |
   |    Original

   \
     \    gedreht

ähh, hoffe es ist verständlich

[Kitty Hello]

Oh weia! ROTOSPRITE verwendet die OpenGL funktionen und zeichnet ein gedrehtes Rechteck, das eine Textur hat. Damit macht das die Grafikkarte und es ist superschnell.
Wenn ich das für die Kollision drehen müsste, dann (wie auch bei PocketPC und GP2X) muss ich das PixelXPixel machen -> das kostet Zeit.
Also, wenn wirklich akkurate Prüfung nötig ist, dann lieber ein paar Grafiken mehr zeichnen/erstellen (GRABSPRITE - nur einmal beim Programmstart), und damit arbeiten, statt wirklich in Echtzeit das Ding drehen+testen.
Ich bau' euch gerne einen ROTOCOPY ein, aber das ist einfach schlechter Programmierstil. Ich kenne kein Spiel, das seine Kollisionen so abfragt, weil's einfach uneffektiv^3 ist.
Das soll jetzt keine Kritik, sondern ein guter Rat sein, OK?

[edit]
Schilder mal Deine Spielidee, dann sag' ich Dir wie's effektiv geht.

[Luckeie]

@luckeie
ich glaube so einfach ist das nicht. Bei Sprites mit quadratischer Grundfläche ginge das wohl recht einfach, aber davon kann man ja nicht ausgehen. Stell dir vor, dein Sprite in ein Balken, 20 Pixel breit und 100 Pixel hoch. Nun drehst du das Teil. Um jetzt die Grafik im Sprite zu speichern benötigst du schon einen größeren Bereich. Ich denke schon, daß der interne Rechenaufwand für diese Verwaltungsaktionen recht aufwändig werden können.

also etwa so
   |
   |    Original

   \
     \    gedreht

ähh, hoffe es ist verständlich

Hat Gernot und ich doch schon erklärt: Man muß halt den Spritebuffer etwas größer wählen und die Grafik mittig plazieren...

  Luckeie

[Luckeie]

Oh weia! ROTOSPRITE verwendet die OpenGL funktionen und zeichnet ein gedrehtes Rechteck, das eine Textur hat. Damit macht das die Grafikkarte und es ist superschnell.
Wenn ich das für die Kollision drehen müsste, dann (wie auch bei PocketPC und GP2X) muss ich das PixelXPixel machen -> das kostet Zeit.
Also, wenn wirklich akkurate Prüfung nötig ist, dann lieber ein paar Grafiken mehr zeichnen/erstellen (GRABSPRITE - nur einmal beim Programmstart), und damit arbeiten, statt wirklich in Echtzeit das Ding drehen+testen.
Ich bau' euch gerne einen ROTOCOPY ein, aber das ist einfach schlechter Programmierstil. Ich kenne kein Spiel, das seine Kollisionen so abfragt, weil's einfach uneffektiv^3 ist.
Das soll jetzt keine Kritik, sondern ein guter Rat sein, OK?

[edit]
Schilder mal Deine Spielidee, dann sag' ich Dir wie's effektiv geht.

Ok, dann verstehe ich das Problem, dann geht es halt nicht. Und für meine Spielidee ist dann der Vorschlag von Schranz0r ganz gut geeignet.

Aber so ähnlich wie Basic nicht unbedingt die effektivste Sprache für Spiele ist, es aber trotzdem nimmt, weil man beim Entwickeln schnell vorwärts kommt, wäre halt für mich der Einsatz von ROTOCOPY gewesen: Ich wäre schnell einen ganzen Schritt weiter gewesen.

Liebe Grüße

  Luckeie

[Schranz0r]

num                  = Spritenummer
drehungs_step  = fortschritt der Drehung pro Durchlauf
start_num         = Mit welchen Sprite die Drehung anfängt

Code: (glbasic) [Select]

FUNCTION ROTOCOPY: num, drehungs_step, start_num

GLOBAL Winkel
LOCAL XX, YY, Spitzenmass

GETSPRITESIZE num, XX, YY

Spitzenmass = SQR( POW(XX,2) + POW(YY,2) )



FOR Winkel = 0 TO 359 STEP drehungs_step

FILLRECT 0,0,Spitzenmass,Spitzenmass, RGB(0xff, 0x00, 0x80)
ROTOSPRITE num,(Spitzenmass-XX)/2, (Spitzenmass-YY)/2, Winkel

GRABSPRITE start_num + Winkel / drehungs_step, 0, 0, Spitzenmass, Spitzenmass
BLACKSCREEN
NEXT

ENDFUNCTIONWürde gehen, wenn Grabsprite auch Transparenz setzen würde, und nicht nur schwarz....


EDIT:

soll ichs unter Codeschnipsel auch reinmachen?

[Kitty Hello]

Hoi! BASIC nicht effektiv? Mach mal ein Benchmark gegen andere BASICs, dann bekommst Du große Augen.
Problem bei ROTOCOPY: Du musst das Ding noch verschieben:

Code: (glbasic) [Select]

FUNCTION ROTOCOPY: number, numberout, angle, BYREF dx, BYREF dy
LOCAL sx, sy, newx, newy
GETSPRITESIZE number, sx, sy
newx = sx*1.42
newy = sy*1.42
dx = (newx-sx)/2
dy = (newy-sy)/2
ROTOSPRITE number, dx,dy, angle
GRABSPRITE number2, 0,0,newx,newy
ENDFUNCTIONund dann:
SPRCOLL numberout, x-dx, y-dy, anderes_sprite,x,y

[Schranz0r]

@ Gernot

Meins war ja für vor die Hauptschleife!
Quasi die Sprites in den Speicher laden...

und wenn man dann immer noch das Sprite Middeln will, auf x und y ,dann kann man ja ganz einfach:

GETSPRITESIZE (eins der drehbilder), nehmen und die Position  -1/2 Spritesize setzen!

[Kitty Hello]

Stimmt. Klasse Idee.
Dann noch ein SPRCOLL_Center() machen, und feddig.

[Schranz0r]

Uff.. da muss man dann auch die Spritepositionen um jeweils die halbe Sprite breite und höhe versetzen ?

[Schranz0r]

Hier noch ein MidHandle für die ROTOSPRITE

Code: (glbasic) [Select]

FUNCTION Sprite_Mid: num, X, Y
LOCAL XX, YY
GETSPRITESIZE num , XX, YY

SPRITE num, X-XX/2, Y-YY/2

ENDFUNCTION