Haven't tried it yet, but I'm not certain it is possible with the commands available.
Does any know if it can work or a possible work around?
At worst I'll just have to make a custom one but still use the box collision to trigger it.
as far as I know SPRCOLL is always working with the orginal sprite. So if you use e.g. ROTOSPRITE, you may receive unexpected results.
To avoid this, you may use CREATESCREEN/USESCREEN in combination with ROTOSPRITE/ROTOZOOMSPRITE and so on. Someone did an example on how to use it, but unfortuneatly the thread is not present anymore.
I'll look into that, thanks.
I did rotating collision with my Balloonacy game, pretty much how Quentin described it.
do you have an example on how to use it? I'm interested too :)
Here's a quick and well commented example
// Rotation collision example (c) 2010 Ian Price
// This code can be used freely
// Open up a screen window
SETSCREEN 640,480,1
// Draw rectangle and grab for sprite #1
DRAWRECT 0,0,64,8,RGB(255,255,255)
GRABSPRITE 1,0,0,64,8
// Draw square and grab for sprite #2
DRAWRECT 0,0,16,16,RGB(255,0,0)
GRABSPRITE 2,0,0,16,16
// Rotation angle
GLOBAL angle#
// Mouse position and button variables
GLOBAL mx,my,b1,b2
// Repeat until user presses ESC
WHILE TRUE
// Set red square to mouse position
MOUSESTATE mx,my,b1,b2
// Draw magenta image mask for background
DRAWRECT 0,0,64,80,RGB(255,0,128)
// Increase rotation angle
INC angle#
// Rotate sprite #1
ROTOZOOMSPRITE 1,0,32,angle#,1.0
// Grab the rotated image and use as sprite #3
GRABSPRITE 3,0,0,64,80
// Clear screen so that you can't see the graphic being rotated ready for grabbing
DRAWRECT 0,0,640,480,RGB(0,0,0)
// Inform user of controls
PRINT "MOVE RED SQUARE WITH MOUSE",10,10
// Draw rotating sprite
DRAWSPRITE 3,320,120
// Draw red square sprite (#2) at mouse position
DRAWSPRITE 2,mx,my
// Test for collision between red square and rotating sprite
col=SPRCOLL(3,320,120, 2,mx,my)
// If collision occurs then inform user
IF col<>0 THEN PRINT "HIT",mx,my-10
SHOWSCREEN
WEND
END
This is pixel perfect and should do exactly what you need :)
Or you can use CREATESCREEN and USESCREEN like this:
// Open up a screen window
SETSCREEN 640,480,1
// Draw rectangle and grab for sprite #1
DRAWRECT 0,0,64,8,RGB(255,255,255)
GRABSPRITE 1,0,0,64,8
// Draw square and grab for sprite #2
DRAWRECT 0,0,16,16,RGB(255,0,0)
GRABSPRITE 2,0,0,16,16
// Rotation angle
GLOBAL angle#
// Mouse position and button variables
GLOBAL mx,my,b1,b2
// Repeat until user presses ESC
WHILE TRUE
// Set red square to mouse position
MOUSESTATE mx,my,b1,b2
// Draw color background to check that sprite is transparent
DRAWRECT 0,0,640,480,RGB(0,angle,0)
// Create a new sprite as screen_id 1, sprite_id 3, width and height
CREATESCREEN 1, 3, 64,80
// Use the created sprite as draw-target for all grafics
USESCREEN 1
// Increase rotation angle
INC angle#
// Rotate sprite #1 and draw it to sprite 3
ROTOZOOMSPRITE 1,0,32,angle#,1.0
// Use backbuffer again for drawing
USESCREEN -1
// Inform user of controls, no need to clear the screen first
PRINT "MOVE RED SQUARE WITH MOUSE",10,10
// Draw rotating sprite
DRAWSPRITE 3,320,120
// Draw red square sprite (#2) at mouse position
DRAWSPRITE 2,mx,my
// Test for collision between red square and rotating sprite
col=SPRCOLL(3,320,120, 2,mx,my)
// If collision occurs then inform user
IF col<>0 THEN PRINT "HIT",mx,my-10
SHOWSCREEN
WEND
END
Okay, I think this will work really well.
Although I think I'll do something along the lines of using the CREATESCREEN during the collision phase.
I have like 13 different blocks, only 8 or so rotate. So I decided to reserve some sprite indexes for masks.
Block's angle stored in a type, drawing stage will draw all blocks, during collision phase I can check to see if the angle is not 0(meaning a mask would be needed) and slot that mask into a sprite index.
I'm not at a computer that has glbasic but I think that might work. Any thoughts?
My intent with this is to attempt to remake this -> Shield Breaker EX (http://gamejolt.com/freeware/games/puzzle/shield-breaker-ex/1505/)
Do it however you think it will work for your needs.
The above works well on GP2X/Wiz for one or two sprites at a time with no slowdown, so 8 on a pc should be OK. Obviously I didn't use Types in this example (to keep it as simple as possible) but I could have.
However, having just played the game, I think you'd be better off capturing all the sprites as images to use in-game (at start-up), rather than rotating in real-time. That's certainly how I'd do it.
Let us know how you get on.
Well I'll play around with some ideas tonight, I'll let you guys know which one worked out the best.
In other basic languages I've used, real-time rotation has been frowned apon as it's not a very fast task. It might be a good idea to prerotate and used those saved images (as suggested) if for no other reason than it will (most likely) make for more efficient code.
Well since I only need to update the a mask image for collision, would it be more efficient to render the blocks to the screen with polyvector? I considered using it since it also handles vertex coloring and all the blocks are a gray-white color prior to being colored.
The pre-rotated images will still be more efficient than what I believe you are considering. You can pre-rotate polyvector images to obtain different coloured sprites. A little bit of time at the start of the game creating the images is surely to be more beneficial than doing the same in-game in real-time.
I did that for my game "WizSticks", too. But !!! On the iPhone the "grab" is too slow in real time. (I have to glReadPixels the alpha information).
Just test before you take too much time on that.
Using pre-rendered images might be a better option sometimes.
I'll see what will work best. As of now I really am not planning on porting this to mobile devices, so I'm basicly using my netbook as a base for testing performance.
I'm kind of reluctant to preload a bunch of images, being that there is maybe 8 blocks that have rotations, and that gets multiplied by the amount of frames needed for some smooth animation. But I'll give that a shot.
In my case, I ended up making a 8 pixel raster of 1 pixel SPRCOLL calls.
I tried one of my games on a few netbooks just before Christmas 2009, when I needed a laptop replacement. Performance was terrible. I was getting over 300FPS on my old lappy and around 30-40FPS on several netbooks.
In saying that though I haven't tried my games on my son's netbook which runs games like Torchlight surprisingly well.
Torchlight runs on a netbook?!?!? :blink:
Yep. :D
On a PC the reading of alpha pixels is a tad faster, since I can directly read the alpha layer. On the OpenGL|ES of the iPhone I have to read RGBA data (quadripple the size)
Quote from: Ian Price on 2010-Feb-01
Yep. :D
I might have to seriously look at getting one then and maybe retiring my laptop (I've been meaning to get another desktop for a while now anyway).
This has, I believe rotated pixel perfect collision detection : http://www.virtualrealm.com.au/blogs/xna-rotated-perpixel-collision/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+mykre+(Mykres+Space)
Its in C#, but may be possible to convert. Whilst performance would be poor, taking the advice from the poster at the bottom could help speed things up.
It wouldn't be trivial :) And would really be a waste of time...
I do that myself actually :)
However that only works if either object is roughly "square" (ie its dimensions are almost equal). If one (or both) of the objects is rectangular, then this won't work, so alternative solutions should be sought.
Theres some benefits to netbooks, size, weight, and a good way to limit yourself when developing. I'll have to look into Torchlight.
Not having a powerhouse pc keeps you developement slimmer since you're forced to make things run efficiently.
Still haven't had a chance to put some pixel-collision through some test yet, but thanks for all who gave me plenty of tips to get it started.
Just wanted to say that I found this thread very useful with my current project, so thanks guys.
Gernot - might be worthwhile updating the SPRCOLL command in the online help to show that it only works with original, non rotated images, and make this thread a sticky as its likely a fairly common problem.