Frage zur Sprite Kollission

Previous topic - Next topic

Luckeie

Meine schon beschriebenen Probleme wie 'Zeilenendeerkennung' und 'Läuft auf PC aber nicht auf GP2X' hat Gernot durch ein Update gelöst. Den GLBasic-Fehler einzugrenzen, hat mich aber einiges an Zeit gekostet - von wegen schnell mal mit GLBasic was entwickeln...

Neues Problem:

Aus den Beschreibungen zu BOXCOLL und SPRCOLL wird mir nicht klar, ob eine Sprite-Kollission nun wirklich pixelgenau ausgeführt wird. Genauer: Ein Sprite enthält ja eine Grafik, die durch die Farbe einzelner Pixel bestimmt wird. Beim Anzeigen des Sprites achtet man darauf, dass die die Grafik umgebenden Pixel transparent sind, so dass man den Hintergrund erkennen kann. Ich möchte nun gerne erreichen, dass die transparenten Pixel bei einer Kollissionsabfrage nicht einbezogen werden. Es scheint mir so, als ob dies mit GLBasic nicht möglich ist. Stimmt dass?

Wenn ich mich recht erinnere, machte dies z.B. beim C-64 die Hardware und ich erwartete eigentlich, dass GLBasic dies per Software nachbildet, dies scheint aber nicht so zu sein. Schade!

Wenn es aber tatsächlich nicht geht, dann möchte ich Euch fragen, wie Ihr dieses Problem lösen würdet?

Oder macht tastsächlich niemand eine pixelgenaue Kollissionsabfrage?

Liebe Grüße

  Luckeie

BumbleBee

BOXCOLL ist Boxkollision und SPRCOLL ist Pixelkollision. Geht 100%. Mach doch nen Test.:D
Bei schnellen Shootern brauchst du keine Pixelkollision. Das sieht eh keine Sau.:D

Cheers
The day will come...

CPU Intel(R) Core(TM) i5-3570k, 3.4GHz, AMD Radeon 7800 , 8 GB RAM, Windows 10 Home 64Bit

Luckeie

Quote from: BumbleBeeBOXCOLL ist Boxkollision und SPRCOLL ist Pixelkollision. Geht 100%. Mach doch nen Test.:D
Bei schnellen Shootern brauchst du keine Pixelkollision. Das sieht eh keine Sau.:D

Cheers
Es ist aber kein Shooter, es ist ein kleines Fahrzeug, welches in Geschwindigkeit und Winkel nahezu stufenlos bewegt werden kann und in einer Umgebung nicht an die Wand fahren darf...

Luckeie

Ich glaube, ich weiß jetzt warum es nicht geht: Ein gedrehtes Sprite wird trotz der Darstellung mit den ursprünglich gladenen Pixeln verglichen und nicht mit den durch die Drehung enstandenen. Trotzdem Danke für die Infos. Für mein Spiel ist das allerdings tödlich.

Liebe Grüße

  Luckeie

Quentin

Gut zu wissen.

Ein Ausweg aus deiner Misere wäre vielleicht noch, für jede Drehrichtung eine eigene Grafik zu erstellen, sodaß aus allen Grafiken quasi eine Animation entsteht. Weiß ja nicht, wieviele Grafiken du dafür bräuchtest. Könntest dann aber mit SPRITE statt ROTOSPRITE arbeiten und hättest deine gewünschte pixelgenaue Kollisionsabfrage.

Kitty Hello

ROTOSPRITE _zeichnet_ nur eine gedrehte Grafik - das Sprite ist dann nicht irgendwie an der Stelle. Hach - ich muss das dringend in BLIT umbenennen. Das verwirrt so...

Antidote

Heisst also, dass es nicht sinnig ist ... z.b. Die "Hauptfigur" mit rotosprite zu drehen??
Dann bietet sich das Rotosprite hauptsächlich für bewegte Objekt an, die nichts mit Kollision zu tun haben???
Ich frage, da ich auch gerade meine ersten Versuche Starte?!
PC Core2Duo e4300, 2GBRam, Geforce 8800GT-1gb, XPsp3
GP2x, Wii, XBox360, Wiz, psp, ps3 usw.

Kitty Hello

Sprite/RotoSprite usw. "kleben" nur eine Grafik auf den Backbuffer. Nichts weiter.

Schranz0r

Wo wir grad bei Collisionen sind, Gernot, gibts es eine Möglichkeit ein Sprite das peer Vector "gestreckt" wurde, auf Collision zu prüfen?


EDIT:

Dann könnte man einen GEILEN "Vector -Map-Editor" Basteln :D
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

Luckeie

Quote from: GernotFrischROTOSPRITE _zeichnet_ nur eine gedrehte Grafik - das Sprite ist dann nicht irgendwie an der Stelle. Hach - ich muss das dringend in BLIT umbenennen. Das verwirrt so...
Könntest Du nicht einen neuen Befehl einbauen, der die durch die Rotation zur Ausgabe berechneten Pixel in das für die Rotation benutzte Sprite hinein schreibt? ... Ah, wahrscheinlich wird es dann immer unansehnlicher ... aber vielleicht eine Kombination aus zwei Spriteplätzen? In einem Sprite hat man ein Original-Muster welches durch Rotation in einen zweiten Spriteplatz geschrieben wird, welchen man wiederum anzeigt und zur Kollisionserkennung benutzt? Das könntest Du doch machen, oder (Könnte ROTOCOPY oder so heißen)? ;-)

Liebe Grüße

  Luckeie

Quentin

ich denke, das kann man mit den vorhandenen Befehlen ja schon erreichen. Ich denke ich probier das heute abend mal aus.

Vorgehen wäre folgendes:
- Sprite rotiert und/oder gezoomt darstellen
- dieses Sprite mit GRABSPRITE einfangen
- und damit die Kollisionsabfrage machen

kommt mir grad so, kanns im Moment aber nicht austesten.

Schranz0r

Mach doch vor der Hautpschleife Rotosprite, und speicher jede Drehung in ein neues Sprite(GRABSPRITE).
Hintergrund mit Fillrect und RGB (255,0,128) machen !!!!

Dann die "Animation" in der Hauptschleife machen, und schon hat man eine Pixelgenaue Collision.

Achja man muss ja nicht jedes Grad ein neues Sprite machen! ( ich sag nur STEP) :)


EDIT:

Scheisse Quentin war schneller ...
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

Kitty Hello

Aber: Das Sprite wird um Faktor 1.41 (Wurzel 2) größer. Diesen Unterschied muss man dann wieder von der Sprite-Position bei SPRCOLL abziehen. Ausser, man zeichnet ein Sprite so groß, dass Platz für das gedrehte Sprite ist, dann geht's auch so.

Ich glaube übrigens, dass keine Sprache gedrehte Pixel-Kolllision unterstützt. Da geht der Rechner ganz schön in die Knie mit sowas.

Luckeie

Quote from: GernotFrischAber: Das Sprite wird um Faktor 1.41 (Wurzel 2) größer. Diesen Unterschied muss man dann wieder von der Sprite-Position bei SPRCOLL abziehen. Ausser, man zeichnet ein Sprite so groß, dass Platz für das gedrehte Sprite ist, dann geht's auch so.

Ich glaube übrigens, dass keine Sprache gedrehte Pixel-Kolllision unterstützt. Da geht der Rechner ganz schön in die Knie mit sowas.
Mag sein, aber in meinem Programm wird ja zur Darstellung eh schon gedreht und ich denke, dass da die Hauptzeit verbraten wird. Man muß ja nur die für die Ausgabe eh schon gedrehten Pixel in den Spritebuffer schreiben - sonst nichts. Und wegen der Speed: Mein Programm läuft ja soweit schnell genug. Also so ein ROTOCOPY wäre eine recht elegante Sache und um Größenprobleme auszugleichen, muß man halt den die Grafik umschließenden rechteckigen Bereich des Sprites etwas größer als die Ausgangsgrafik wählen. Aber das ist dem Entwickler des Spiels sein Problem.

Es wäre dann so einfach:

Beim Start:
LOADSPRITE "originalsprite.bmp", 1
LOADSPRITE "dummy.bmp", 2

In der Schleife immer wieder:
ROTOCOPY Sprite1, Sprite2, Grad
SPRCOLL 2, XCoordSpr2, YCoordSpr2, TestSpriteID, XCoordTSpr, YCoordTSpr
SPRITE Sprite2, XCoord, YCoord

oder ähnlich.

Bitte, bitte!

Liebe Grüße

  Luckeie

Luckeie

Quote from: Schranz0rMach doch vor der Hautpschleife Rotosprite, und speicher jede Drehung in ein neues Sprite(GRABSPRITE).
Hintergrund mit Fillrect und RGB (255,0,128) machen !!!!

Dann die "Animation" in der Hauptschleife machen, und schon hat man eine Pixelgenaue Collision.

Achja man muss ja nicht jedes Grad ein neues Sprite machen! ( ich sag nur STEP) :)


EDIT:

Scheisse Quentin war schneller ...
Da muß ich viel mehr programmieren und testen... ;-) Aber Du hast schon recht - performanter wäre das auch. Aber nicht elegant: Erst alles in den Bildshcirmbuffer schreiben, dann wieder herausgrabben und dann doch auch noch den Bereich löschen, oder?

  Luckeie