Irrlicht Engine

for fpstest, at the begining, the terrain just falls down forerver

=> That's probably not the terrain but a trimesh, just walk forwards until you reach the terrain (maybe you have to increase the speed in the tests/fpstest/entities/player/server.lua)

it crashed when exiting the game, it seems to ...

Yeah, that's a known bugt, that happens when not all points in the level have a rotation set. You can just add a check like "if (index >= rotations.size()) { return Vector3D(0, 0, 0);}" there, I didn't have enough time to add that.

1.
I use ODE 0.9 on both windows and linux and it works except one incompatibility with GIMPACT on 64bit systwems.

2.
Never tested it with MSVC, so no idea here

3.
There are incompatibilities between enet 1.1 and enet 1.2 which cannot easily be worked around in the code, so you have to define ...

I use 1.4 and Linux/OpenGL. There is a patch somewhere here which I tried to apply without any luck.

thx ^^

Looks like a finished product to me.

Wait. WTF? Did you even look at the engine?
It's nowhere near complete, my problem is lack of both motivation and help atm.

EDIT: And limitations concerning Irrlicht. Rendering to textures with transparent background seems not to be possible.

All executables are placed in that bin folder, even on Windows, I do not plan to create Linux executables for download. (I develop on Linux as you can see on the screenshot)


Do you plan to add an AI engine that we could script to having NPC?

I do. But there are things which are way more ...

http://en.wikipedia.org/wiki/64-bit#64-bit_data_models

Here on Linux an int on amd64 is always 32bit long.

You could try disabling compiz? That caused similar issues for me.

http://img365.imageshack.us/img365/9069/peakengineez1.th.jpg

PeakEngine is a scripted multi-genre game engine. Our goal is to make it as easy to use as possible. Nevertheless this is work in a very early stage of development :)
It is licensed unter the X11-License which means that you are free to ...

add "-lIrrlicht" and make sure that g++ finds the Irrlicht.a (The dll should work as well, but afair only with other options)
Also maybe code from the PSDK doesn't work with g++ as well...

Huh?

I definately wanted to do what Luben said.
roxaz:
*var <- that's dereferencing, the same is done by class->somefunction(), which can be written (*class).somefuntion()
With that you'll sure change the value, and not the pointer.
I mean, that's what *I* am using, I don't know your Compiler ;)

That should be right.

I think C++ is used more widely, it is faster for it does not use interpreted bytecode as .NET, but if it is more stable really should depend on you, maybe it is a bit more tricky to use somtimes (I don't have any experience with .NET, but that's what is said...).

I prefer C++.

http://www.die.net/doc/linux/man/man3/swprintf.3.html
(wchar.h declares swprintf)
(That is for GCC, but as MinGW uses GCC, that should be correct?)
EDIT: Yes, my MinGW knows that function...

I thought about that problem some time ago, and in my opinion getting a "perfect" mirror is simple. You need a second camera looking onto the mirror, but from the other side. And everything between this second cam and the mirror needs to be clipped. That second cam is rendered to a texture, and that ...