CPPDemo on Stable release. (When do you expect next release?)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. download svn repo
2. cmake svn repo
3. use generated svn repo

What is the expected output? What do you see instead?
Expected: Something functional. Instead: Error messages, failures, and lack of 
support for scenegraphs.

What version of the product are you using? On what operating system?
Newest. Windows xp.

Please provide any additional information below.
I know the Wiki states that the SVN repo was buggy. I didn't realize it would 
be completely inoperable. 
The worst part is that the CPPDemo only operates with the InstanceManager, 
which is only available on SVN. Meaning the stable version of this engine ONLY 
allows blender scenes, crafted by LUA. Which is retarded.
So. WHen do you expect to have a release out from svn, that is stable?

And if you don't expect such a thing to occur in the near future, what can I do 
to speed that up and make it happen by next week or so?
Thank you for attempting to provide something wonderful, though.

Original issue reported on code.google.com by dcyu...@gmail.com on 7 Jan 2011 at 1:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Also. It's extremely difficult to upgrade Ogre, since you stripped it of it's 
central features... Including all the dependencies as well. I'm stuck at 
revision 6 months behind schedule by using your product. Either that, or go 
through hell just to fix the code - which I'm now forced to do anyway since it 
lack's support for anything but .blend.

And another thing.. it takes like 5 hours to build this, because you decided to 
use static library's instead of dll's. Perhaps it's better for debugging, but 
I'm dying from old age during the build process.

I'm not trying to be a dick about it, especially considering you did ALOT of 
work on making something truly wonderful, and further it's open source.
I'm just stating the obvious, the thing's that should be changed and/or made 
optional in the future of this project if you want it to be successful on a 
broad spectrum.
Straight up. 

I appreciate any feedback, and look forward to releasing my code changes so 
that you may review them for possible SVN updates.
OgreKit is a great idea, and should definitely be fixed and upgraded from it's 
current state.

Original comment by dcyu...@gmail.com on 7 Jan 2011 at 2:02

[GoogleCodeExporter]

Hi,

 * We try to keep svn as stable as possible and correct bug as soon as we can. Specially crashes, and building errors. Last time I checked (a few commits ago) the cppDemo was working ok but sometimes crashed on exit. Today however, svn does not compile because of a bullet building error:

In file included from 
/home/xavier/Projects/Gamekit/gamekit-release/bullet/src/BulletCollision/NarrowP
haseCollision/btPersistentManifold.h:22,
                 from /home/xavier/Projects/Gamekit/gamekit-release/bullet/src/BulletCollision/CollisionDispatch/btCollisionDispatcher.h:20,
                 from /home/xavier/Projects/Gamekit/gamekit-release/bullet/src/BulletCollision/CollisionDispatch/btActivatingCollisionAlgorithm.cpp:17:
/home/xavier/Projects/Gamekit/gamekit-release/bullet/src/BulletCollision/NarrowP
haseCollision/btManifoldPoint.h:23:67: error: 
physics_effects\base_level\solver\pfx_constraint_row.h: Arquivo ou diretório 
não encontrado

I do not have time right now to look at it, but will do it as soon as I can 
(maybe later today) you can still compile gamekit svn by "downgrading" bullet 
in bullet/src with svn.

 * Gamekit is still in development and the binary packages are for easy testing but not considered as stable. For advanced usage I would recommand svn, it is not less stable but sometimes can be broken for a short time, in that case use a previous version with "svn up -r versionnumber".

 * You can help the project in different ways: Provide an updated binary package, report bugs, send patch that you find can be useful for every gamekit user and not your project only (more feature, bug fixes, more scripting API, ...) or write some doc/tips that you have learned using Gamekit. If you plan on contributing regularly Erwin can give you necessary rights (svn commit and/or wiki editing)

 * We only use the Ogre core sources and some plugins but not the whole source tree, we also uses custom CMake files instead of the one coming with Ogre. It require more maintenance work but it ease the configuration step and minimize compile time and binary size. However Gamekit svn is up to date with the latest Ogre stable release (props to Harkon).

 * Compile time is awful and binary size too, although here it take only 7 min to do a fresh compilation. If you need some tips to speed it up, you can try: multi-threaded build (make -j numthread), stripping the freeimage lib of some unused image formats, use clang with precompiled headers. For reference i am on a AMD Phenom II x4 3.0GHz with 4G RAM and compile with g++ 4.4.5 on debian squeeze 64 bit with "make -j4" but i disabled wxwidget build and everything that requires it. If you come with a patch that optimise this in any way (config option that help minimizing the binary size and the compile time) please post it here. 

Original comment by xavier.thomas.1980@gmail.com on 7 Jan 2011 at 7:49

[GoogleCodeExporter]

I'll fix the Bullet issue as soon as possible.

Original comment by erwin.coumans on 7 Jan 2011 at 8:15

[GoogleCodeExporter]

The Bullet errors should be fixed now, can you try it?

Original comment by erwin.coumans on 7 Jan 2011 at 9:08

[GoogleCodeExporter]

Why do you need to fix the code, what format do you want to load instead of 
.blend?

Original comment by erwin.coumans on 7 Jan 2011 at 9:14

[GoogleCodeExporter]

I can confirm the bullet errors are fixed now. Thanks Erwin.

Original comment by xavier.thomas.1980@gmail.com on 7 Jan 2011 at 10:02

[GoogleCodeExporter]

Thanks Xavier.

It seems that momo doesn't move anymore in OgreKit/LogicDemo, can you confirm?

Original comment by erwin.coumans on 7 Jan 2011 at 10:06

[GoogleCodeExporter]

Personally, I prefer the static lib builds over the possibility of DLL hell. 
I'm a fan of single executable builds and would be somewhat put out if this 
feature was removed. Not that I consider myself more important than others, 
just ensuring the fact that not all of us want DLL's is known

Original comment by BenT.Sol...@gmail.com on 7 Jan 2011 at 11:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

By default we will keep static linkage.

If someone wants to add a cmake option to enable DLL hell (perhaps it exists?), 
we can add it as an option.

Original comment by erwin.coumans on 8 Jan 2011 at 1:27

[GoogleCodeExporter]

Erwin, I cannot reproduce the bug, all animations are playing fine in logic 
demo for me.

Regarding the static/dynamic libraries, I made a modif in CMake to use 
freeimage dynamically and it is quite simple. As long as we use the dynamic 
libraries available in the system and do not provide precompiled binaries, then 
it is quite easy to add an option in cmake to use the system lib instead of 
linking statically.

Original comment by xavier.thomas.1980@gmail.com on 8 Jan 2011 at 4:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the replies and assistance, and for the speedy Bullet fix erwin.

In regards to dll hell, I followed your recommendations xavier, aside removal 
of un-necessaries; ended up updating ogre to full(non-lite) most recent 
release, as well as dependencies. I'm just gonna have to learn to be more 
patient; though I'll admit it(45 minutes ogre + engine for me) isn't helping my 
smoking addiction :P

I suppose my beef with .blend is that I didn't have direct access to Ogre right 
off the bat.. I was ready to drop my .scene files from ogitor and cg particles 
right in.

I suppose I'm much more of a fan for toolkit's designed for the engine, rather 
than visa versa. So I'm working on getting Ogitor's .scene files into OgreKit. 
Will submit  if it comes out as nice as I'm planning. Definitely can't compare 
to the power of blender and your blendparser - but atleast I can get skyx, 
hydrax, etc right into it quick and easy - no python dabbling. Planning on 
using it as a dual-effort; .blend for generic scene, and resource 
modelling/animation etc; and Ogitor as my... "cooker". Not sure if others would 
want this; after reading ba.org thread 155310 and it's origins... sounds much 
more like this was designed for the artists of blender, than the users of Ogre 
- which makes sense; but is more of a stepping stone for me.

Thanks again for all your efforts, and continued support. I'll try and do what 
I can to help(I can't wait to get your ragdoll demo working, as ghetto as it 
may be using current primitives & logic). 
I still think this engine is a hotcake, despite the steep learning curve I just 
went through in last 48 hours.

Original comment by dcyu...@gmail.com on 13 Jan 2011 at 7:53