BASIC

Author Topic: Frage zur Sprite Kollission  (Read 8830 times)

Luckeie

  • Guest
Frage zur Sprite Kollission
« on: 2007-Jun-23 »
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

Offline BumbleBee

  • Global Moderator
  • Prof. Inline
  • *******
  • Posts: 891
    • View Profile
Frage zur Sprite Kollission
« Reply #1 on: 2007-Jun-23 »
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

  • Guest
Frage zur Sprite Kollission
« Reply #2 on: 2007-Jun-23 »
Quote from: 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
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

  • Guest
Frage zur Sprite Kollission
« Reply #3 on: 2007-Jun-23 »
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

Offline Quentin

  • Prof. Inline
  • *****
  • Posts: 899
    • View Profile
Frage zur Sprite Kollission
« Reply #4 on: 2007-Jun-23 »
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.

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10661
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Frage zur Sprite Kollission
« Reply #5 on: 2007-Jun-24 »
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...

Offline Antidote

  • Mr. Polyvector
  • ***
  • Posts: 164
    • View Profile
    • http://antidotes.wordpress.com
Frage zur Sprite Kollission
« Reply #6 on: 2007-Jun-25 »
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.

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10661
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Frage zur Sprite Kollission
« Reply #7 on: 2007-Jun-25 »
Sprite/RotoSprite usw. "kleben" nur eine Grafik auf den Backbuffer. Nichts weiter.

Offline Schranz0r

  • Premium User :)
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 4971
  • O Rly?
    • View Profile
Frage zur Sprite Kollission
« Reply #8 on: 2007-Jun-25 »
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 1700 @3.9Ghz, 16GB HyperX Fury 2666Mhz Ram, ASUS ROG GTX 1060 STRIX 6GB, Windows 10 Pro 64Bit, MSi Tomahawk B350 Mainboard

Luckeie

  • Guest
Frage zur Sprite Kollission
« Reply #9 on: 2007-Jun-26 »
Quote from: GernotFrisch
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...
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

Offline Quentin

  • Prof. Inline
  • *****
  • Posts: 899
    • View Profile
Frage zur Sprite Kollission
« Reply #10 on: 2007-Jun-26 »
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.

Offline Schranz0r

  • Premium User :)
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 4971
  • O Rly?
    • View Profile
Frage zur Sprite Kollission
« Reply #11 on: 2007-Jun-26 »
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 1700 @3.9Ghz, 16GB HyperX Fury 2666Mhz Ram, ASUS ROG GTX 1060 STRIX 6GB, Windows 10 Pro 64Bit, MSi Tomahawk B350 Mainboard

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10661
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Frage zur Sprite Kollission
« Reply #12 on: 2007-Jun-26 »
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

  • Guest
Frage zur Sprite Kollission
« Reply #13 on: 2007-Jun-26 »
Quote from: GernotFrisch
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.
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

  • Guest
Frage zur Sprite Kollission
« Reply #14 on: 2007-Jun-26 »
Quote from: 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 ...
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