Problem with Tutorial 7

murray · Post by **murray** » Mon Aug 27, 2007 9:58 pm

Hello,

I want to get some experience with irrlicht.

I tried some tutorials, they run fine, all. But in tutorial 7 about "collision detect und response" I got a problem.

It compiles, it runs, but I cannot move the camera with the keyboard. This isnt normal, isnt it!?
I can look around with the mouse, but it ignores hitting the keyboard.
If I hit the keys very often and irregular, then I move sometimes one metre oder something...

I think its a problem with ISceneNodeAnimator. Without this animator I can move around in this level.

Btw.: I compiled irrlicht 1.3.1 on Linux Gentoo 64Bit and got the current tutorial from the sdk.

Maybe someone can help me with this issue?

lukrop · Post by **lukrop** » Sat Sep 01, 2007 5:05 pm

i'v got absoult the same problem, also gentoo 64 bit and compiled from portage...

edit: i also tried to compile the sdk from the .tar.gz and not via portage but same problem... i think there's something going wrong with 64bit.. maybe that's the problem... (under windows, it's working)

hybrid · Post by **hybrid** » Sat Sep 01, 2007 9:47 pm

No problem under 64bit. I'm using OpenSuse 10 x86-64 on an AMD X2 and it works for both the SDK and the latest SVN. Seems to be different stuff.

lukrop · Post by **lukrop** » Sun Sep 02, 2007 9:31 am

i also noticed, that i have to link against png and jpeg, within all examples, wheter i use the portage irrlicht version or the sdk version (build with non-modified makefile in sources directory)

what could be the problem? if it's not the engine, what could infect the collision detection? or why do i have to link against png and jpeg?

edit: here is the linker error -> http://lukaskrop.uttx.net/tmp/error.txt
edit2: also AMD X2 CPU here... (maybe interesting)

lukrop · Post by **lukrop** » Mon Sep 03, 2007 5:11 pm

sry, but I really need this built-in collision detection, because i'm not familiar with any physics engine which can do that, and I think I'm not envolved enough with the basics of irrlicht, that I begin to learn how to implement a physics engine like newton...

Does really no one have an idea what might could be the problem? Or where I maybe can look in the irrlicht source to fix it?

I'm going to checkout svn now, maybe it has been fixed already...
edit: svn also isn't working...

randomMesh · Post by **randomMesh** » Tue Sep 04, 2007 1:34 am

I had this problem, too.

The camera is stuck in the wall. Just edit the source and choose another position for it.

lukrop · Post by **lukrop** » Tue Sep 04, 2007 11:38 am

randomMesh wrote:I had this problem, too.

The camera is stuck in the wall. Just edit the source and choose another position for it.

but why should the exact same code and the exact same resources (map) do different things on diffrent plattforms? The camera is moving but it's like the elipsoid for collision detection is much too big...

i played around alot with the arguments of the createCollisionResponseAnimator and I think the Ellipsoid translation is messed up, there is collision detection and i can move but it's like the whole collision q3 level is in an other postion as the one I'm seeing...

MasterGod · Post by **MasterGod** » Tue Sep 04, 2007 4:57 pm

I'm not sure how to fix it but I suggest learn Irrlicht more deeper then learn how to use newton with it - from what i'v seen in other threads about newton it shouldn't be much hard, pretty easy even. I think you should go over the first 6 tutorials again and make sure you fully understand them then go learn newton.
Good luck!

lukrop · Post by **lukrop** » Tue Sep 04, 2007 5:13 pm

MasterGod wrote:I'm not sure how to fix it but I suggest learn Irrlicht more deeper then learn how to use newton with it - from what i'v seen in other threads about newton it shouldn't be much hard, pretty easy even. I think you should go over the first 6 tutorials again and make sure you fully understand them then go learn newton.
Good luck!

yeah, that's for sure the right way but I'm also sure, that this isn't the expected behavior of irrlichts collision response animator

thx for your help

murray · Post by **murray** » Tue Sep 04, 2007 5:16 pm

Well, good to hear, that some other people have the same problems.

lukrop wrote: but why should the exact same code and the exact same resources (map) do different things on diffrent plattforms? The camera is moving but it's like the elipsoid for collision detection is much too big...

i played around alot with the arguments of the createCollisionResponseAnimator and I think the Ellipsoid translation is messed up, there is collision detection and i can move but it's like the whole collision q3 level is in an other postion as the one I'm seeing...

yeah, i think you are right, i edit the position of the camera from
camera->setPosition(core::vector3df(-100,50,-150));
to
camera->setPosition(core::vector3df(-100,1000,-150));

Now i can move around, but the camera is over the castle..

Edit: I have a Single Core CPU (Athlon 64 3000+) and use the following linkers to compile the examples:
-lIrrlicht -lGL -lGLU -lpng -ljpeg -lXxf86vm

lukrop · Post by **lukrop** » Tue Sep 04, 2007 5:24 pm

murray wrote:Well, good to hear, that some other people have the same problems.

lukrop wrote: but why should the exact same code and the exact same resources (map) do different things on diffrent plattforms? The camera is moving but it's like the elipsoid for collision detection is much too big...

i played around alot with the arguments of the createCollisionResponseAnimator and I think the Ellipsoid translation is messed up, there is collision detection and i can move but it's like the whole collision q3 level is in an other postion as the one I'm seeing...
yeah, i think you are right, i edit the position of the camera from
camera->setPosition(core::vector3df(-100,50,-150));
to
camera->setPosition(core::vector3df(-100,1000,-150));

Now i can move around, but the camera is over the castle..

now the "collision-map" (i call it that way because i don't know how to call it correctly, hope you know what i mean, the invisible "walls") is over the map which is visible... if the Z coordinate is correct, you can't move "correctly" because X and Y are false... that's the reason I think but it seems impossible to me to get the absolut right X and Y coordinates..

edit: I think there is a offset between the displayed map and the invisible "collision-map"...

btw. sry, english isn't my mouther tongue, it's really hard for me to explain it in an other language then german

edit2: hm, doesn't look very good for using newton under 64bit linux... they've got non-64bit-compatible code... things like "unsigned int"

hybrid · Post by **hybrid** » Tue Sep 04, 2007 7:04 pm

Why would unsigned int be bad for 64bit?

lukrop · Post by **lukrop** » Tue Sep 04, 2007 7:23 pm

hybrid wrote:Why would unsigned int be bad for 64bit?

it simply isn't compiling but "unsigned long int" is compiling...

hybrid · Post by **hybrid** » Tue Sep 04, 2007 7:53 pm

unsigned int works just as all other types. However, you cannot cast pointers to ints as those are usually ony 32bits, while pointers are 64bit on 6bit systems. But that's bad code anyway