Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Grrrr COLLISION (hair being ripped out)

Author
Message
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 25th Jan 2003 16:31
Ok, so we all know that the polygon collision doesnt work properly. Whether its for certain types of models, or for every model, who knows? The point it, it doesnt work properly. But guess what? Neight does sprite collision.

I just spent two days of recoding my top down 3D game into a 2D game, because poly collision doesnt work. First off, I was very happy with my 300FPS. It's almost a fair trade from 3D to 2D with that sort of speed. Unfortunately, I (stupidly) assumed that 2D collision was so simple in its theory that it'd work in DB, so I didn't test it. Then, as soon as I started programming in my collision, what do I see?? Sprites overlapping and not detecting collision, and sprites detecting collision when they're clearly far away from each other.

I dont know whether it's because the transparency is also checked for collision, or whether rotating the sprites causes collision to behave strangely, but it simply doesnt work for me.

I'm so totally disheartened now. I have the skill, time and patience to make a wickedly playable game, but nothing feckin works!!!

Please, Patch 4. Please. Help me. Please.
Machine: P4 2200, 512MB, GeForce4 64MB, Audigy Platinum

There's a junglist inside every coder. http://www.kontact-kru.com for my own personal breakbeat terrorism.
haggisman
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 25th Jan 2003 16:53
Maybe you did something wrong? Can't help you though as you didn't post any code. BTW you can't assume something is broken just because YOU can't get it to work.

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 25th Jan 2003 16:57
the major trick with collision is to actually make sure that it doesn't happen
i've not used sprites before but there was recently a pixel perfect collision snippet made.

would be worth checking out

Anata aru kowagaru no watashi!
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 25th Jan 2003 21:20
Haggisman, for some people, you may be right, but if I make sprite 1 and sprite 2, position them so that they're overlapping then run the sprite collision command and get a 0 back as a result, then I can pretty much catagorically say it doesn't work.

Also, I would post demo code if it wasn't tied up in a 30MB game file. I could spend half an hour ripping out the bits that matter to demonstrate the problem, but what would be the point? I know the problems there, and I know nobody will do anything about it, until they get round to it on there huge and comprehensive mountain of a bug fixing schedule.

I'm not having a go btw. I'm just tired of big fat huge bugs that any half decent company would've ironed out before releasing a product. (rant rant rant blah blah blah).

I JUST WANT TO MAKE A GAME!!!! With either free flight rotation, or polygon collision, or sprite collision. The correct operation of just one of those key game functions cannot be too much to ask.

I can't remember when I bought DBPro. Pretty much on the release date I think, and still, I've only made one working game, and for that I had to program my own sliding collision. (Sigh sigh sigh)

(Fingers still crossed) Patch 4. Please. Patch 4.

Thanks btw Raven. I'll check it out.

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum

There's a junglist inside every coder. http://www.kontact-kru.com for my own personal breakbeat terrorism.
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 25th Jan 2003 21:50
you could always access the backbuffer ptr
that has the screen and you just check the pixels ... personally i think this is probably the best way for 2d collision - basically setup and array with the screen width and height ... and use a boolean setup the pixels so that transparency = 0 and solid = 1
and place the game things there that required to be collision sensitive

then check to see if there is already a pixel there in the array ... if the answer is yes then collision = 1

it would also mean you've checking all possible collisions at once rather than just the one that happens.

Anata aru kowagaru no watashi!
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 25th Jan 2003 22:00
That's not a bad idea, but I have a couple of problems.

First, it's a top down space sim. The screen scrolls (virtually), so I'm actually checking an area of 10000x10000 pixels. Optimisations taken into consideration, it could still be pretty fast, but the back buffer only contains the screen info, doesnt it? I need to calculate off-screen sprite collision also.

I suppose I could make my own virtual screen. ie. An array of about 400x400, then make a memblock from a the rotated sprite (if that's possible), read the info relative to its coordinate on screen, and the info in the memblock, and paste it into the virtual screen array. Then use the technique you described above. As I paste in the next non-transparent pixel into the array, I check to see if there is a pixel already there.

The question is, is there a make memblock from sprite command (I dont have db at this PC)? And would this be fast enough? I cant use make memblock from image, because you cant rotate images, and I'm sure if I start programming my own pixel rotation procedure in db, it'll be rediculously slow. I cant rotate the sprite, paste it, then grab the image either, because the background would also be captured, and I cant draw it to an alternative blank bitmap, because I've tried swapping bitmaps on every program loop and capturing an image and it's incredibly slow (300FPS to 60FPS with a few lines of code).

All relies on the make memblock from sprite command, if there is one.

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum

There's a junglist inside every coder. http://www.kontact-kru.com for my own personal breakbeat terrorism.
Kangaroo2
22
Years of Service
User Offline
Joined: 26th Sep 2002
Location: United Kingdom
Posted: 26th Jan 2003 00:20
"the major trick with collision is to actually make sure that it doesn't happen"
I've been doing this for years, collision detection in DB1 and enhanced was so slow it slowed a 50fps game to a 2fps game, with only 1 collision detection line! so I ended up writing my own in math!

However, sprite collision in Pro works perfectly for me, as does box and sphere collision. No Poly collision yet, it just crashes, but still I'm counting blessings lol

Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 26th Jan 2003 01:52
Out of interest, do you rotate your sprites, and have you offsetted the x and y origins? I'm only guessing this is what causes the problems.

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum

There's a junglist inside every coder. http://www.kontact-kru.com for my own personal breakbeat terrorism.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 26th Jan 2003 02:05
It sounds like he does rotate sprites - which leaves either some sort of maths collision, or some rather slow work-arounds.

Login to post a reply

Server time is: 2025-05-17 06:26:04
Your offset time is: 2025-05-17 06:26:04