Page 4 of 5
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 11:02 am
by frostbyte
sleep time for me...probably some mix with msvc/ogre configuration....i'll find my way ...
thanks anyway...

Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 5:37 pm
by icaro56
Could you help me with error in CMake?
Code: Select all
CMake Error at D:/Visual_Projects/engine/dependences/qt/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:16 (message):
Failed to find "glu32" in "".
Call Stack (most recent call first):
D:/Visual_Projects/engine/dependences/qt/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:50 (_qt5gui_find_extra_libs)
D:/Visual_Projects/engine/dependences/qt/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:127 (include)
D:/Visual_Projects/engine/dependences/qt/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:83 (find_package)
GenericTextEditor/CMakeLists.txt:17 (find_package)
It happens when try to compile as Ogitor as Ogitor v2.
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 5:51 pm
by stealth977
What platform are you using? If windows, open CMAKE GUI, point the source directory and decide a build directory (somewhere else). Hit configure then hit Generate.
Also before running CMake, do not forget to set CMAKE_PREFIX_PATH as described in QT Documentation, for example mine is:
something like : My Computer->Advanced->Environment Variables
CMAKE_PREFIX_PATH
C:\Qt_540\5.4\msvc2010_opengl\
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 5:56 pm
by icaro56
This error happens in configure pass.
I will have compile QT again. My QT haven't this opengl folder.
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 5:56 pm
by stealth977
Compile QT?? Why? Just download and install the one that is suitable for your compiler...
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 6:05 pm
by stealth977
http://www.qt.io/download-open-source/# for prebuilt QT libraries...
Go down the page to "View All Downloads" -> OFFLINE INSTALLERS, Windows Host topic. There pick the one that is suitable for your compiler...
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 6:33 pm
by icaro56
My Visual Studio is 2012 and the version of Qt Project is only win32.
In my projects I needed the version x64. Is Ogitor using the version win32?
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 6:37 pm
by stealth977
I compile Ogitor as 32bit and jacmoe compiles it 64bit so Ogitor works on both...
try setting CMAKE_PREFIX_PATH to where Qt's "bin" "lib" etc directories are, probably in your case it is "D:/Visual_Projects/engine/dependences/qt/"
Re: Ogitor for OGRE 2.0
Posted: Thu Feb 12, 2015 6:43 pm
by stealth977
There are also pre-compiled Qt binaries at
http://tver-soft.org/qt64 but i never tried it...
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 2:30 am
by jacmoe
I haven't bothered to build Qt in a long time - download it here:
http://www.qt.io/download-open-source/#
I can recommend the online installer because it enables you to have more than one version of Qt installed, but the offline installers works great.
I am using 64bit.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 3:04 am
by jacmoe
Ok, I see your problem. Why don't you upgrade to vs2013, then?
There is no reason to be using 2012 because 2013 is both faster and supports c++11 better.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 9:09 am
by Zonder
jacmoe wrote:Ok, I see your problem. Why don't you upgrade to vs2013, then?
There is no reason to be using 2012 because 2013 is both faster and supports c++11 better.
You can still keep your copy of 2012 if you need it for some reason they can side by side install I have 2010, 2012 and 2013 installed.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 11:21 am
by icaro56
Physx dlls are generate until Visual Studio 2012 in Physx SDK.
I will go to install Visual Studio 2013. If it is more faster than 2012.
Thank you.
I'm sorry by my nuisance. Now, there is a problem with IrrKlang. In the Dependencies->IrrKlang project the error:
Code: Select all
Error 1 error MSB6006: "cmd.exe" exited with code 1. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets 172
log
Code: Select all
1>------ Build started: Project: IrrKlang, Configuration: Debug x64 ------
1> Creating directories for 'IrrKlang'
1> Copying IrrKlang DLL...
1> Error copying file "D:/Visual_Projects/ogitor_v2_build/Dependencies/IrrKlang/bin/winx64-visualStudio/irrKlang.dll" to "D:/Visual_Projects/ogitor_v2_build/RunPath/bin/irrKlang.dll".
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5): error MSB6006: "cmd.exe" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
This folder IrrKlang doen't exist.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 12:42 pm
by frostbyte
Error copying file "D:/Visual_Projects/ogitor_v2_build/Dependencies/IrrKlang/bin/winx64-visualStudio/irrKlang.dll" to "D:/Visual_Projects/ogitor_v2_build/RunPath/bin/irrKlang.dll"
just download irrklang from offical website...unzip... change dir name to irrKlang and copy it to D:/Visual_Projects/ogitor_v2_build/Dependencies/
oh...and i think ogitor is using bullet, not physx...
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 12:46 pm
by icaro56
Ogitor uses bullet.
I was trying to use the same environment to ogitor repository and my repository that uses physx.
Thanks. It works.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 4:43 pm
by hydexon
@Stealth777, i have a few inquiries about the adoption of the "Multi-threaded System" is excellent and using it in my game engine and i found many flaws in his design.
Intel's Smoke Demo has some Criticism because from the beginning of the design has some flaws, and researched
a bit more. i explored the source and has his flaws, for my engine deleted the Windows-specific taskmanager (TaskManagerTP) and kept the TBB one, but still uses Semaphore and CreateEvent from Win32 API which i want to get rid of without writting platform specific code, i replaced SpinWait and SpinWait::Lock with TBB's Spin_Mutex and ScopedLock which proves is a bit more portable.
And i'm very glad of Ogitor uses Bullet instead of PhysX, for me PhysX gives me nothing than problems, i know is good for the AAA industry but the game inherits his PhysX problems like: Forced driver installation, bugs, low performance in non-NVIDIA cards (why i'm not surprised?) meanwhile Bullet is GPU-Manufacturer independient (i guess so), i don't need to install any additional driver, and with the upcoming Bullet 3.x with OpenCL support, will more better too.
About the sound engine, there's one called
YSE originally using JUCE Toolkit but later removed, i think uses C++11 features, has many features for Audio Designers and games, like Multi-threading, and the most interesant of everything (for me): Sound Occlusion, it's EPL (Eclipse Public License) licensed.
Re: Ogitor for OGRE 2.0
Posted: Fri Feb 13, 2015 7:12 pm
by stealth977
My latest Stress Test with 1024 Objects...
[youtube]H6-1gltD47g[/youtube]
In this scene there are 1024 objects each controlled by 1024 script controllers, to make them move continuously each frame and making sound when they reach their predefined edge. Also all of them have collision shapes defined and processed by the physics engine...
I currently get 90+ fps with profiling turned on (which has quite a big impact on speed due to multithread profiling protecting against concurrent profiling data updates)
Sample Profiling Data:
Code: Select all
PROFILER UPDATE: 94 frames in 1.0 seconds
Total Tick Ratio: 640.3154 on 8 HTs
Internal Usage : 43.9 - 71768172 ticks per frame
Geometry System : 0.0
Graphics System : 7.2
Physics System : 0.5
Scripting System: 48.4
Input System : 0.0
Re: Ogitor for OGRE 2.0
Posted: Sat Feb 14, 2015 3:14 am
by Zonder
nice
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 16, 2015 9:12 pm
by stealth977
Currently we are changing Object Properties Window to be more useful. New design will be showing Vector and Quaternion types as single line and will also have both object specific and component specific buttons, toolbars, icons right inside the properties window. It will look like (using DarkSkin skin mode & toolbars and advanced views are not implemented yet) :
It will also display Sliders for values that have a predefined max/min range and will be able to set Quaternions using Euclid transforms...
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 16, 2015 9:16 pm
by Wolfmanfx
Cok guezel
I like it
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 23, 2015 6:38 pm
by boyamer
Very good news, saw your progress, neat stuff you're doing, the only one think I don't really like is the LGPL license, but that will be fine for almost of the users.
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 23, 2015 8:14 pm
by stealth977
LGPL is a temporary situation since we havent officially made it public yet. Some parts of it will definitely go MIT, but some parts may or may not...
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 23, 2015 8:33 pm
by c6burns
I would have absolutely no issue with LGPL if there weren't issues with static linking. Some platforms (like mobile devices) you are really going to want to static link, but my understanding is that it is a violation of the LGPL to do that and not license the entire work under LGPL. Whereas dynamic linking is fine, which just seems like a ridiculous distinction to me.
My understanding of the intent of the LGPL is to allow commercial use while still maintaining reciprocity of source code, and I agree with the spirit of that, but the technicalities hurt me.
Anyway just my 2 cents
EDIT: anyway editor parts under LGPL I think is fine, because dynamic linking on platforms where the editor part will run (win/mac/*nix) is not a problem, but its not my code so its not my decision ... just being nosey!
Re: Ogitor for OGRE 2.0
Posted: Mon Feb 23, 2015 9:03 pm
by jacmoe
LGPL would be a good fit for the editor framework, simply because it means that we can statically link to Qt if we choose to do so. But, as Stealth977 says: everything is wet paint at the moment.

Re: Ogitor for OGRE 2.0
Posted: Mon Feb 23, 2015 9:10 pm
by c6burns
Oh wait I just remembered ... it's not that statically linking an LGPL lib means the combined work must be LGPL. It's that you must provide everything necessary for end users to be able to re-link the application. So any license would be fine, but closed commercial source cannot statically link an LGPL library. This is where my problem with the LGPL lies, in terms of it being applied to code I want to use in my application's runtime. I might release all of my work under MIT in the end, but I would prefer not to be shoehorned into that just because I had to static link some tiny LGPL library for a mobile platform.
Not that I forsee Ogitor causing this to be a problem, just venting about LGPL in general. I have faith in the sensibility of Ogitor's creators
