Did you read the tutorials through to number 7, which explains collision? If so, exactly what part are you stuck on?
I don't see any collision manager or collision-related code at all in your posted code - is it in another file or am I missing something here?
Edit: I also noticed that you're trying to rotate the camera, if you want to do this direct with setRotation() I believe you would need to use the "bindTargetAndRotation" function for the camera's node. Otherwise you might have headaches down the road.
i have a question about physics now..will i be able to use newton to add physics with addCubeSceneNode? or will i have to create a newton box or something..:S
still new to all this
Hm, search around in the forum for more info about physic wrappers. I think mostly you will set geometry primitives like boxes just once more in the physics engine. Or actually in many cases you only set them in the physics engine as your collision geometry is usually a lot simpler than your level-geometry. The polygon-soup of the world can sometimes be shared between 3D engine and physics engine (not sure about newton+irrlicht right now, but I suppose it should be possible), but once again you sometimes just copy it and give the physic-engine a copy (which is pre-processed with some polygon reduction) ... that kind of stuff really depends on the situation.
For ping-pong... hm... I guess you will give the ball some sphere. And for the table and the paddles you should probably try to go with shared polygons between Irrlicht and the physics engine. Not sure about the net... any static geometry will probably not behave perfect, but for a start it's fine. Another possibility would probably be to simplify the table to a box + another box for the net.
hmm i see..which physic wrapper would be recommended ?
aren't most wrappers outdated and won't work with 1.7? correct me if i'm wrong.
also for irrphysx, don't you need a physx-enabled GPU card?
Irrlicht 1.7 interfaces have not changed that much. So even if a wrapper is outdated it would probably be easy to fix. And I don't think you need a gpu for physx - it would just be faster. But I don't think speed is of concern in a ping-pong game as there are probably not enough polygons for real trouble.
But I haven't worked with physics in combination with Irrlicht so far myself, so just speaking from theory here. So I can't tell you which engine to use. I do prefer using engines which are opensource, so I would probably use either Bullets or ODE. You might also consider writing your own physics for this. It's an easy case as you don't have to care about any kind of chain-reactions (one ball hitting another etc) and so it would be a good way to learn a little about physics.
doesn't irrlicht have a built in physics engine ? thought i read about it somewhere ;;
making my own basic physics class would be cool, though i don't know how to start, how would you get(or set) node attributes(mass/kg etc..)
No real physics. Irrlicht has a collision system which can be used. And it has a simple physic for moving characters around.
Doing your own physics, well - you would write a class containing all object attributes (size, mass). Then you would write a class containing your physic-state (forces, velocity). Then you would write a class which contains an Irrlicht-SceneNode and your classes for physic state and physic attributes. Next you would write some function (in yet another class usually) which takes the current physic state of all physic objects, changes it according to attributes and physical formulas and maybe set the resulting position for the Irrlicht SceneNode. The formulas you would need are those for Newton mechanics. You would need to look up at least acceleration, gravity and air-resistance. I found out that school-books are often very good sources for that. And you have to think how to handle collisions - Irrlicht can help you find out where they happen, but you have to decide how to react on that (like ball-paddle: add a force-vector to the ball. Ball-table: ... some sort of impulse thing).
Well... certainly you can also just use a physic engine, but you would learn a lot doing that yourself once ;-)
Delta time is the time between two calls to your physic.
time() is part of the standard c-lib, so not sure how you get an unresolved external for this. But Irrlicht also has an ITimer interface which you can get from the IrrlichtDevice. And the ITimer has a function getTime ().