Something easy: Sprcol not working?

Previous topic - Next topic

Det

Hi folks,
here's some question that should be easily answered:
Obviously SPRCOL is not handling transparent pixels that are defined as "pink" RGB(255,0,128)? My Colliosiondetection is quite ugly.
What am I supposed to do to have a pixel-collision only with non-transparent pixels=
Thank's a lot
Det

Adopt, adapt and improve

mentalthink

HI Det don't care whit the pink color... if you do an .png whit black background... works perfectlly...
You only have to remenber when you save your image from Photoshop or another soft , in example a 3D suite, remenber leave working the Alpha Channel...

Yes I think Gernnot comment about the Sprcoll looks the transparents parts of the Sprite

Try whit the file I attached, have to work fine... if you put ok the pos and all the params...  :good:


Det

Strange: Does not seem ok, even with you code.
Perhaps an issue with scaling (ROTOZOOMSPRITE)?

If you like look at my code (quit ugly hack, just to check things out)...

Code (glbasic) Select
// --------------------------------- //
// Project: Testprojekt
// Start: Friday, March 08, 2013
// IDE Version: 10.202


SETCURRENTDIR("Media") // go to media files

LOADBMP "hintergrund.jpg"
LOADSPRITE "spr_hexagonal_Enemy_02.png", 1
LOADSPRITE "spr_hexagonal_Enemy_02.png",2
LOADSPRITE "YOUWIN.png",3
LOADSPRITE "youloose.png",4
SETSCREEN 1600,900,0

Nochmal:


xPos = 800
yPos = 450
geschwindigkeit=1

richtung=1



hauptspiel:

IF (KEY(30)=1)
richtung=2
ENDIF
IF (KEY(32)=1)
richtung=1
ENDIF
IF (KEY(17)=1)
richtung=4
ENDIF
IF (KEY(31)=1)
richtung=3
ENDIF

IF (KEY(200)=1)
geschwindigkeit=geschwindigkeit+1
ENDIF

IF (KEY(208)=1)

geschwindigkeit=geschwindigkeit-1
IF (geschwindigkeit<0)
geschwindigkeit=0
ENDIF

ENDIF


IF (richtung=1)
xPos=xPos+geschwindigkeit
ROTOZOOMSPRITE 1, xPos,yPos, 270, 0.5
ELSEIF (richtung=2)
xPos=xPos-geschwindigkeit
ROTOZOOMSPRITE 1, xPos,yPos, 90, 0.5
ELSEIF (richtung=3)
yPos=yPos+geschwindigkeit
ROTOZOOMSPRITE 1, xPos,yPos, 180, 0.5
ELSEIF (richtung=4)
yPos=yPos-geschwindigkeit
ROTOZOOMSPRITE 1, xPos,yPos, 0, 0.5
ENDIF
DRAWSPRITE 2 ,50,600
//ZOOMSPRITE 1, xPos, yPos, 0.5, 0.5
richtungschonangepasst=richtungschonangepasst-1
IF SPRCOLL(1,xPos,yPos,2,50,600)
IF (richtung=3 AND geschwindigkeit <3 )
GOTO youwin
ENDIF
GOTO youloose
ENDIF
SHOWSCREEN
GOTO hauptspiel

youwin:


DRAWSPRITE 3, 100, 100

SHOWSCREEN

IF (KEY(57)=1)
GOTO ende
ENDIF
GOTO youwin

youloose:
DRAWSPRITE 4, 100, 100

SHOWSCREEN

IF (KEY(57)=1)
GOTO ende
ENDIF
GOTO youloose

ende:
GOTO Nochmal
END
Adopt, adapt and improve

erico

I just ran the code, maybe there is an issue with the rotozoom?
Objects are colliding on a block style instead of per pixel here.

tried on glb10

mentalthink

The problem it's RotozoomSprite... I rebember when you make a rotozoom or zoomsprite the collisions whit Sprcoll don't works fine...

Little trick if you need the same sprite but you need more or less size...

before the program it's in the main bucle...
rotozoom sprite  whit you new sizes
grabsprite (this it's for make a copy of this part of screen, and put into a ID)
shoscreen   (I never remenber if this command goes up Grabsprite or down... try it)

and now you have this sprite, but really works... don't need use sritezoom for more greater size...


In the code you can see when you pixels collides, the sprite goes to the middle of the Screen + or -

Code (glbasic) Select
// --------------------------------- //
// Project: testing
// --------------------------------- //
// Project: Testprojekt
// Start: Friday, March 08, 2013
// IDE Version: 10.202


SETCURRENTDIR("Media") // go to media files

LOADBMP "hintergrund.jpg"
LOADSPRITE "spr_hexagonal_Enemy_01.png", 1
LOADSPRITE "spr_hexagonal_Enemy_02.png",2
LOADSPRITE "YOUWIN.png",3
LOADSPRITE "youloose.png",4
SETSCREEN 800,600,0

Nochmal:


xPos = 800
yPos = 450
geschwindigkeit=1

richtung=1



hauptspiel:

IF (KEY(30)=1)
richtung=2
ENDIF
IF (KEY(32)=1)
richtung=1
ENDIF
IF (KEY(17)=1)
richtung=4
ENDIF
IF (KEY(31)=1)
richtung=3
ENDIF


IF (KEY(200)=1)
geschwindigkeit=geschwindigkeit+1
ENDIF

IF (KEY(208)=1)

geschwindigkeit=geschwindigkeit-1
IF (geschwindigkeit<0)
geschwindigkeit=0
ENDIF

ENDIF


IF (richtung=1)
xPos=xPos+geschwindigkeit
DRAWSPRITE 1, xPos,yPos
ELSEIF (richtung=2)
xPos=xPos-geschwindigkeit
DRAWSPRITE 1, xPos,yPos
ELSEIF (richtung=3)
yPos=yPos+geschwindigkeit
DRAWSPRITE 1, xPos,yPos
ELSEIF (richtung=4)
yPos=yPos-geschwindigkeit
DRAWSPRITE 1, xPos,yPos
ENDIF
DRAWSPRITE 2 ,50,500
//ZOOMSPRITE 1, xPos, yPos, 0.5, 0.5
IF SPRCOLL(1,xPos,yPos,2,50,500)
xPos = 300
yPos = 200
ENDIF

richtungschonangepasst=richtungschonangepasst-1

// IF (richtung=3 AND geschwindigkeit <3 )
// GOTO youwin
// ENDIF
// GOTO youloose
SHOWSCREEN
GOTO hauptspiel

youwin:


DRAWSPRITE 3, 100, 100

SHOWSCREEN

IF (KEY(57)=1)
GOTO ende
ENDIF
GOTO youwin

youloose:
DRAWSPRITE 4, 100, 100

SHOWSCREEN

IF (KEY(57)=1)
GOTO ende
ENDIF
GOTO youloose

ende:
GOTO Nochmal
END

kanonet

Of cause SPRCOLL does not work with rotated or scale sprites. It is no bug its just by design.

You can draw a sprite multiple times, on multiple sizes and multiple rotations. So if you call SPRCOLL after you have drawn it many times in many different ways, how should the computer know which one you want to test for collision? It always just test for collisions in the sprites, at zoomfactor=1 and rotation=0. If you want to test a rotozoomes sprite you need a 2nd sprite that already is rotated and scaled the same way - but if you have that you dont need to rotozoom at all, right? So if you want to use pixel perfect collisions, dont zoom/rotate your sprites.

Of cause you could suggest Kitty to add zoom and scale parameters to the collision commands...
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Det

Thanks all,
now I now what to do (the grabsprite-idea should work, i'll check it out).
But somewhere I'm missing the point: between kanonet's "ue can't use scaled or rotatet sprites as the computer does not know which state of the sprite you ment to use for your collisioncheck" and the existance of a grabsprite that is designed for just that purpose: get me the sprite as it is when drawn on screen. I'd thought it would be a good default to use the copy that "grabsprites" would deliver for collsiontesting as well.
Anyway: I'm new to glbasic and so I'm not the one to discuss design-issues.

Thank you, so I can at least work on this "father and son" projekt whilst I'm stuck on my other questions


Adopt, adapt and improve