Irrlicht Engine

Finally found some time again ... yeah you're right. It's one of the too easy solutions you sometimes just don't see.

Simply forgot the fact Irrlicht is still linked dynamically so the runtime is running in its own memory area while that isn't the case when linked dynamically... arr... I hate those ...

I'd just use 2 boxes: One where the visible hover board is and one right below it (small gap - like the floating height). Then connect both using some kind of spring connection (I'm sure your physics library will support some kind of) and you're done imo.

Not really:

zlib: Do whatever you want but don't remove any copyright and don't claim it to be your own work.

lgpl: Do whatever you want but if you modify the code that's under this license you have to release the changes to the public.

Everything uses the static runtime (release/debug) files as well as the same libs. Tried adding
node->getMaterial(0).setTextureMatrix(0, matrix4());
to example 8 and got the same error.

Maybe something went wrong converting the projects to vc 2008? (Only one warning related to changed web ...

Imo it's personal preference. Ogre3D offers some more features and might be a little bit more mature but Irrlicht's design is more simple (regarding usability and deployment). For Irrlicht all you'll need is one DLL file (maybe 1 or 2 more if you want extra physics etc.) while Ogre has tons of DLLs ...

Alright, finally some dumb question to ask here. Just can't find the bug. ;)

ISceneNode *node = _smgr->addCubeSceneNode();
node->getMaterial(0).setTexture(0,_driver->getTexture("test.bmp"));
node->setMaterialFlag(EMF_LIGHTING,false);

So far, everything simple and working. I do a simple main loop ...

It fully depends on the type of your game etc. ;)

In a FPS distance based calculations might be useful but in a RTS/simulation you can't do that.

Just to name an example having a more or less bad implementation:
X³ uses accurate AI/simulation only in the area the player is in. Other areas are less ...

Not sure right now but I think within CDATA sections binary data is allowed as well as <, >, etc. just nothing that looks like the end of the CDATA section.

Ah ... in that context ... Guess you should provide a link for the jury (or everyone? don't ask me ...) to download your source code that's compiled into the exe or maybe just a download link to the exe ... don't know the original text.

I'd stick with "units per second" - so divide both inputs by 1000. Imo it's more convenient to define it that way without going on a "per millisecond" basis.

Think I've found a bug - I know I made some mistake somewhere too but it shouldn't happen anyway:

I created a waypoint as root, added 2 children waypoints and set their IDs to 0 and 1.
Then I added a NPC starting at node 0 - while creating the NPC the program crashes.

The AI manager was able to ...

"Amulet of Tricolor" or how it was called - just can't find the thread right now.

Assuming a screen resolution of 640 x 480 and I want the screen to be split into 4 text fields:

(Just some pseudo code.)

text1 = addstatictext(0,0,320,240); // top left
text2 = addstatictext(0,240,320,480); // bottom left
text3 = addstatictext(320,0,640,240); // top right
text4 = addstatictext(320 ...

Still similar problems:

#1: Move your "CurrentState()" call within "CGamePlay::Update()" to the beginning of the method - other way you'll call the driver before creating it.

#2 CGamePlay has a local variable "m_pDriver" but CGamePlayBoot still uses its own.

#3 "CGamePlayBoot::CreateDevice()" is ...

If you're doing 2D only, just increase your texture sizes so they'll become power of two values (see christianclavet's posting above). I guess Dark GDK does the same thing hidden from you. This won't decrease performance as much as the software driver does. :) Also you're missing some quite ...