FPS: collision with enemy,shooting,etc.

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
TheMrCerebro
Competition winner
Posts: 80
Joined: Tue Jun 29, 2010 10:06 pm
Location: Valencia, Spain

Re: FPS: collision with enemy,shooting,etc.

Post by TheMrCerebro »

:evil: Say clearly that you want that we build the code of your game. :evil:
These people should be ignored.

You do not have any problem with your code, simply you dont know anything for nothing.

Learn C + + and then give us a call, ok?
BYE.
Follow me on twitter: @themrcerebro
thoma91
Posts: 28
Joined: Tue Aug 09, 2011 10:00 am

Re: FPS: collision with enemy,shooting,etc.

Post by thoma91 »

serengeor wrote:Sorry I'm a bit forgetful. I read that when I wrote my first post in this thread and forgot it right now.
Never mind. :)
serengeor wrote:A simple suggestion would be to write a wrapper for physics engine.
I don't think I need to use a physics engine.
Collision with walls is solved.
Collision with enemy is solved.
The projectile can collide with the walls, see in Demo example..
..and if it can collide with walls, it can collide with enemies too. That's all I need I think, and Irrlicht itself can handle these.

By the way I figured out what can be the problem which makes the projectile fly through the wall.
In the shooting function, there's a condition, which checks if the bullet hits the wall or no.
It looks like this:

Code: Select all

 
// get intersection point with map
const scene::ISceneNode* hitNode;
if (sm->getSceneCollisionManager()->getCollisionPoint(
        line, selector, end, triangle, hitNode)
 
So it needs the selector, which is "attached" to the map itself.
The problem is, that it's in the main, and the shooting func. doesn't see it.
I tried to put the whole level loading code as global variables, but I got an error..
So how could I load my map's selector into that function?
TheMrCerebro wrote:Say clearly that you want that we build the code of your game.
Do not be mad at me, I didn't say that.
I'm just asking, when I'm stuck, and yes, maybe my questions are dumb, and not properly defined.
That's because I'm turning for your help fast, because I don't have time to waste.
And yes, I'm a beginner.. This is the Beginners Help topic. If you don't like that, please read Advanced Help questions only.
As I said in my first comment:
thoma91 wrote:if you just can say: "This isn't enough time" or "Try to learn more" or "Figure it out yourself", don't even bother with it.
I know this is not sympathetic attitude to write a program, but as I said I have no choice, I have to ask if I get stuck.
If someone helps me, I will be grateful to him.. But if someone doesn't want to help, please, at least don't kick me, when I'm on the ground already, I've got enough trouble without that.
Hope you'll all understand that. Thanks.
thoma91
Posts: 28
Joined: Tue Aug 09, 2011 10:00 am

Re: FPS: collision with enemy,shooting,etc.

Post by thoma91 »

Problem solved.
HerrAlmanack
Posts: 52
Joined: Mon Jun 13, 2011 3:50 pm

Re: FPS: collision with enemy,shooting,etc.

Post by HerrAlmanack »

I don't think I need to use a physics engine.
Collision with walls is solved.
Collision with enemy is solved.
The projectile can collide with the walls, see in Demo example..
..and if it can collide with walls, it can collide with enemies too. That's all I need I think, and Irrlicht itself can handle these.
if you don't realize the importance of using a physics engine and would rather use a debug physics system ( in this case, irrlichts' VERY slow collision detection ) then you're not going to get very far before you realize your mistake and end up having to tear apart your source and restart from scratch.

I'm speaking from experience here:

1. your program WILL require more computation power than you think.
2. write a nice facade class, that way if or when you decide to switch out physics backends, you only have to rewrite that "physics driver" rather than all the other components that use a non-abstracted physics backend
3. irrlichts physics should really only be used for debug purposes or just for showcase walkthroughs, with only static geometry, really I have NO clue why it would even occur to someone to use irrlicht physics for a full game. There are like three nice physics wrappers on the projects forum that you can use if you don't want to get into pure physics engine API.

just because it works at a decent framerate for a few basic collisions does not mean physics is said and done. what do you think will happen when you try to add a dozen moving entites? then with all those collision tests for bullets, rockets or whatever, then you'll probably have lots of static props that need collision with entities too. the computation needed with irrlichts debug collision detection will increase exponentially, while if you use a library ACTUALLY MADE for physics, it will not and everything will go much smoother for you.


EDIT: please, we're not trying to be rude (well most of us), but we see lots of cases like yours and we are trying to prevent you from walking off a hundred foot cliff down onto some jagged rocks. we're only trying to save people like you frustration that we already experience, and we want to show others our mistakes when we did something wrong, that way you don't have to make those same mistakes.
Post Reply