Rapid prototyping with Ogre and C++

[Mikachu]

Hi,

More often than not, I feel a bit annoyed by C++ compile times when doing some quick prototyping, especially if all I want to do subtle tweaking to a scene, then see the result, then tweak again...
Also, having some "scene state" or "game state" makes things harder, since reproducing that state adds up to compile time.

I'd like to know what technique people usually use to get around this issue?

So far, I've thought about 3 techniques :
1. Use a scene description format/editor.
I know it's a good way of doing things when you have an established organisation, but it's not appropriate when you do some relatively custom stuff, for example testing a library you're writing.

2. Use a scripting language with bindings.
Scripting languages usually compile fast/don't need to compile at all, are more flexible than a file format, but you still need to have bindings to Ogre. I know there are some Ogre bindings around here, but what if you also want to bind some of your own functions? Having to modify bindings each time you change your c++ functions can be a boring task...
There's also automatic binding software, such as SWIG, but even if you could theoretically just #include your main header, I haven't succeeded to make it work out-of-the box.

3. Use debugger features such as VS's "edit-and-continue"
On the paper, it's ideal : access to full API without having to write binding code.
I've not tested it yet, but is it widely used?

Which technique do you tend to favor, or are you using another trick to do that?

[Transporter]

Have a look at my presentation: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=71656
I use MyGUI to build GUI elements to select database and models. The specific settings are stored in an lua script file. I also have a small lua wrapper for ogreprocedual to create and place geometry on the fly.

[Zonder]

This one reason I use MOGRE as I know if I really need to get that extra bit of speed the code is easily translated over to c++ and use ogre directly.

[saejox]

i use 1 and 2 both.

edit-and-continue never works as intended.

there is a 4th alternative,

- your game is a separate dynamic library
- save program state
- unload dll
- recompile and link
- load dll
- load previous state

technically possible. easier said than done.
i think unreal 4 has this feature.

[Mikachu]

edit-and-continue never works as intended.

I guess there's no miracle solution, then
I'll give a more thorough look at binding my code and a part of ogre code and see where I get... maybe with SWIG, as I'd like to keep the binding effort as low as possible

[Mikachu]

Finally, I managed to use SWIG to generate lua bindings, and I can reload the lua script from my test program at will.
As I thought, it's quite flexible, and the fact that bindings are auto-generated means minimal work when function signatures change.

I only bound the few Ogre headers I needed (Vectors, Quaternion, Math..), plus my own headers.

For reference, if someone else is looking for a quickstart about scripting : (sorry if it sounds trivial to some, but that's a beginners' forum )

The SWIG interface file

Code: Select all

%module Procedural
 %include "std_map.i"
 %include "std_string.i" 
 %{ 
 #include "Ogre.h"
 #include "Procedural.h"
 #include "LuaTests.h"
 using namespace Procedural;
 #include <hash_map>
 %}
 %include "OgrePlatform.h"
 %include "OgrePrerequisites.h"
 %include "OgreVector2.h"
 %include "OgreVector3.h"
 %include "OgreVector4.h"
 %include "OgreQuaternion.h"
 %include "ProceduralPlatform.h"
 %include "ProceduralTriangleBuffer.h"
 %include "ProceduralMeshGenerator.h"
 %include "LuaTests.h"
 %include "ProceduralShapeGenerators.h"
 %include "ProceduralPathGenerators.h"
 %template (mg1) Procedural::MeshGenerator<Procedural::SphereGenerator>;
 %template (mg2) Procedural::MeshGenerator<Procedural::BoxGenerator>;
 %template (mg3) Procedural::MeshGenerator<Procedural::CapsuleGenerator>;
 %template (mg4) Procedural::MeshGenerator<Procedural::CylinderGenerator>;
 %template (mg5) Procedural::MeshGenerator<Procedural::IcoSphereGenerator>;
 %template (mg6) Procedural::MeshGenerator<Procedural::RoundedBoxGenerator>;
 %template (mg7) Procedural::MeshGenerator<Procedural::TorusGenerator>;
 %template (mg8) Procedural::MeshGenerator<Procedural::TorusKnotGenerator>;
 %template (mg9) Procedural::MeshGenerator<Procedural::TubeGenerator>;
 %template (mg10) Procedural::MeshGenerator<Procedural::PlaneGenerator>;
 %template (mg11) Procedural::MeshGenerator<Procedural::Extruder>;
 %template (mg12) Procedural::MeshGenerator<Procedural::ConeGenerator>;
 %template (mg13) Procedural::MeshGenerator<Procedural::Lathe>;
 %template (mg14) Procedural::MeshGenerator<Procedural::Triangulator>;
 %template (mg15) Procedural::MeshGenerator<Procedural::Boolean>;
 %template (mg16) Procedural::MeshGenerator<Procedural::SpringGenerator>;
 %template(bs1) Procedural::BaseSpline2< CubicHermiteSpline2>;
 %template(bs2) Procedural::BaseSpline2< CatmullRomSpline2>;
 %template(bs3) Procedural::BaseSpline2< KochanekBartelsSpline2>;
 %template(bs4) Procedural::BaseSpline2< RoundedCornerSpline2>;
 %template(bs5) Procedural::BaseSpline2< BezierCurve2>;
 %template(bs6) Procedural::BaseSpline3< CubicHermiteSpline3>;
 %template(bs7) Procedural::BaseSpline3< CatmullRomSpline3>;
 %template(bs8) Procedural::BaseSpline3< RoundedCornerSpline3>;
 %template(bs9) Procedural::BaseSpline3< BezierCurve3>;
 
 %include "ProceduralSphereGenerator.h"
 %include "ProceduralBoxGenerator.h"
 %include "ProceduralCapsuleGenerator.h"
 %include "ProceduralConeGenerator.h"
 %include "ProceduralCylinderGenerator.h"
 %include "ProceduralIcoSphereGenerator.h"
 %include "ProceduralRoundedBoxGenerator.h"
 %include "ProceduralTorusGenerator.h"
 %include "ProceduralTorusKnotGenerator.h"
 %include "ProceduralTubeGenerator.h"
 %include "ProceduralPlaneGenerator.h"
 %include "ProceduralExtruder.h"
 %include "ProceduralLathe.h"
 %include "ProceduralShape.h"
 %include "ProceduralMultiShape.h"
 %include "ProceduralPath.h"
 %include "ProceduralTriangulator.h"
 %include "ProceduralTrack.h"
 %include "ProceduralBoolean.h"
 %include "ProceduralSpringGenerator.h"
 %include "ProceduralSVG.h"

(Note that most of the file is about instancing, it's the ogre stuff at the beginning that matters)

The CMake script to generate the wrapper

Code: Select all

find_package(Lua52 REQUIRED)

if (NOT DEFINED SWIG_DIR)
	message(SEND_ERROR "Please define a variable SWIG_DIR, pointing to SWIG's root directory")
endif()

set( HDRS
		../../samples/common/include/BaseApplication.h
		include/LuaTests.h
	)

set( SRCS
		../../samples/common/src/BaseApplication.cpp
		"${CMAKE_CURRENT_SOURCE_DIR}/procedural_wrap.cxx"
		src/LuaTests.cpp
	)

include_directories( ${OIS_INCLUDE_DIRS}
	${OGRE_INCLUDE_DIRS}
	../../samples/common/include
	${CMAKE_CURRENT_SOURCE_DIR}/include
	${LUA_INCLUDE_DIR}
)

add_custom_command(OUTPUT "${CMAKE_CURRENT_SOURCE_DIR}/procedural_wrap.cxx"
                     COMMAND ${SWIG_DIR}/swig.exe ARGS -c++ -lua -v -I"${OGRE_INCLUDE_DIR}" -I"${CMAKE_CURRENT_SOURCE_DIR}/../../library/include" -I"${CMAKE_CURRENT_SOURCE_DIR}/include" procedural.i
                     WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
					 DEPENDS procedural.i)

procedural_add_executable(LuaTests WIN32 ${HDRS} ${SRCS})

set_target_properties(LuaTests PROPERTIES DEBUG_POSTFIX _d)

target_link_libraries(LuaTests ${OGRE_LIBRARIES} ${OIS_LIBRARIES} ${OgreProcedural_LIBRARIES} ${LUA_LIBRARIES})

procedural_create_vcproj_userfile(LuaTests)

.. and then, the C++ code that loads the lua code and executes it

Code: Select all

void LuaTests::reloadScript()
        {
                ConfigFile cf;
                cf.load(mResourcesCfg);
                StringVector sv = cf.getMultiSetting("FileSystem", "Scripts");
                if (sv.size()<1)
                        return;
                String path = *sv.begin();

                lua_State *L; 
                L=luaL_newstate();
                luaopen_base(L);        // load basic libs (eg. print)
                luaopen_Procedural(L);  // load the wrappered module

                destroyScene();

                if (luaL_loadfile(L,(path + "/luaTest.lua").c_str())==0)
                {
                        if (lua_pcall(L,0,0,0) ==0)
                        {
                                mTextMessage->setCaption("OK");
                                mCamera->getViewport()->setBackgroundColour(ColourValue(0.2f,0.4f,0.2f));
                        }
                        else
                        {
                                mTextMessage->setCaption(lua_tostring(L,-1));
                                mCamera->getViewport()->setBackgroundColour(ColourValue(0.4f,0.2f,0.2f));
                        }
                } else
                {
                        mTextMessage->setCaption(lua_tostring(L,-1));
                }
                lua_close(L);
        }

The full sample is the "luatests" subproject in default branch of OgreProcedural.

[saejox]

SWIG always surprises me with its awesomeness.

i am binding Ogre to Angelscript too.
but i dont have swig or any other generator.

i am about 10k lines of binding code.
ogre-procedural included it has same syntax as C++.
lots of mindless work, but it is worth it.

i rarely write c++ code. no more link errors, null pointer crashes, painfully long compile times, circular dependencies etc...

[lonewolff]

Out of interest, what do you call a 'long' compile time?

My three year old rig can compile my Ogre projects in around eight seconds. I am happy to wait eight seconds to see a result.

I must be particularly patient or something.

[Mikachu]

Out of interest, what do you call a 'long' compile time?

My three year old rig can compile my Ogre projects in around eight seconds. I am happy to wait eight seconds to see a result.

These days, I tend to use my laptop to write code, and it has a quite slow hard drive.
It leads to 20+ seconds compile time, even with PCH or Unity Build enabled.
I think that the link time is also quite long...

That's not a particularly long time if you launch your program once in a while, for example after a 30 minutes implementing a new feature, but it starts to get annoying while tweaking use cases for a lib.
That's the same problem I'm trying to solve as AshMcConnell does with TwOgre/AntTweakBar.

I now take less than 1 second to reload the script and see the result, and also the camera position is not reset since I don't restart the program.

All this setup with swig and lua had its learning curve, but I know I could now do the same for any project

[Klaim]

Out of interest, what do you call a 'long' compile time?

My three year old rig can compile my Ogre projects in around eight seconds. I am happy to wait eight seconds to see a result.

I must be particularly patient or something.

You mean, incrementally?
If not, what config do you have? I don't know anyone able to compile Ogre fully in less than 2 minutes, with Unity build enabled.

[saejox]

Out of interest, what do you call a 'long' compile time?

small cpp edits are 6-7 seconds. but .h edits take much longer.
script compile time is almost non-existing. i press start it starts.

[bstone]

You mean, incrementally?
If not, what config do you have? I don't know anyone able to compile Ogre fully in less than 2 minutes, with Unity build enabled.

Why would you recompile Ogre for every edit in a project that just uses it?

[jacmoe]

For rapid prototyping without scripting I tend to use config files.
Perhaps in combination with a debug console.

[Klaim]

You mean, incrementally?
If not, what config do you have? I don't know anyone able to compile Ogre fully in less than 2 minutes, with Unity build enabled.

Why would you recompile Ogre for every edit in a project that just uses it?

Did I said so?

It happens that you need to rebuild everything in a project at some point.
It also happen that you need to recompile Ogre because of modifications you're making to it.
Or when you upgrade Ogre.

Whatever the case when you need to recompile Ogre, that's not the point, nor the question I ask.

[bstone]

Just look at your post that I referred to. lonewolff said it takes eight seconds for him to recompile his Ogre (related) projects. And you said you don't know anybody who can recompile Ogre in less than two minutes. I think the context of my comment was pretty clear.

[Klaim]

I'm asking if he does compile incrementally and recompile Ogre too. I assume, as you apparently, that he does, but I was asking confirmation, like clarity of assertion.

[bstone]

Ok, that clarifies it.

Incremental linking helps in that regard. One thing I used to avoid recompiling Ogre when I needed that kind of modification is splitting off a subject class into a copy and work on it as part of my project. Then I could recompile Ogre once with the qualified changes. Not feasible for all cases but thanks to Ogre's flexibility that can be done for most of it.

Another consideration is linking against DLLs as opposed to static libs. I had to use static linking for debug builds at some point because I couldn't stand the iterator debugging options implied by the debug CRT DLLs and it was noticeably slower than linking against DLLs. If you can live with full iterator debugging (slow nasty stupid piece of ...) then you should link against Ogre DLLs, obviously.

There's also a nice balance between full optimized release builds and not so optimized once your debug builds can't catch up with performance requirements and you lose the incremental linking option. Like turning off whole code optimization and link-time code generation. That speeds compilation times a bit. Both should be on for production builds though.

As for the scripting... well.. that might look bright and wonderful for simple things. But as soon as you go deep enough it will bite you with all inherent issues like run-time syntax checking, lack of debugging facilities, language inferiority, etc. So it's questionable to some extent. I would spend some extra effort to separate the actively developed C++ code into a DLL that would be loaded dynamically. And add some extra code to make it possible to hot-swap the DLL. So you could keep your game running and recompile and reload the hot codebase. That will require a good level of abstraction but it's a good thing anyway.

[lonewolff]

I am talking about editing my source (or.h) press F5, twiddle thumbs for 8 seconds, test my app, rinse and repeat.

I have no need to edit the Ogre source and recompile the entire Ogre code, everytime I want to see if a 'plant' is in the position I want. Who does that?

It seems the OP doesn't.

More often than not, I feel a bit annoyed by C++ compile times when doing some quick prototyping, especially if all I want to do subtle tweaking to a scene, then see the result, then tweak again...

So for what the OP is asking. I stand by my answer - 8 seconds.

[jacmoe]

I stand by my recommendation: ini files.
Especially for rapid tweaks, I haven't got 8 seconds to spare - I want immediate results!!

Lua was actually created for that purpose, but just use a regular ini file parser and that's it.

[Klaim]

Or include ChaiScript header? Isn't that quicker than adding Lua or your home ini solution?

Currently I tend to just use Boost.PropertyTree for this kind of things. Allows more than ini files but is not too complex. Also, I'm using boost anyway so it's always available to me.

[jacmoe]

Actually, I think the fastest and leanest is to use RapidXML - one single header - just add that to your project.
Boost and Chaiscript, etc - all nice, but they add overhead.
RapidXML - one header solution - is truly minimal.
Come to think of it, it's better than an inifile class/helper.

[thebluefish]

Actually, I think the fastest and leanest is to use RapidXML - one single header - just add that to your project.
Boost and Chaiscript, etc - all nice, but they add overhead.
RapidXML - one header solution - is truly minimal.
Come to think of it, it's better than an inifile class/helper.

Well in that regard, even something such as Angelscript (What I'm currently using) would suffice. I'm currently working on a configurable menu example that I may release at some point using this exact same thing. Binding commonly-used methods such as camera info, audio, etc... to a single file that can be compiled near-instantly is a huge bonus. I can make all the edits I want such as camera pathing, music, etc... and press 1 button in-game to instantly reload and see the results. Let your engine handle the logic, such as bindings (functions, buttons, etc) and flow. For the actual game content, scenes, etc... should be left to something that can be easily edited and loaded without compiling.

If your edits are to main game logic in that scripting really won't help with, you're just going to have to manage with it :p Really though, 8 seconds is mostly just overhead from visual studio more than anything, if you had 5x as many files affected, it would only add another second or two.

[jacmoe]

I don't think anyone disagrees with that if you are already using a scripting system then - d'oh! it will be foolish to not use what it lends itself to the most: rapid prototyping.

However, if you don't have such a system in place, then one header and one function is the way to go if you're concerned about overhead.

Just sayin'.

[Deboraha]

Hi,

I need help adding something to my C-written program. Since there isn't any programming section, I thought I would post it here.

So I want to add some info to my exe. So when the user had view mode on details he or she sees the program name and so on. This also means I want to add some info to the properties->details page of the program. This includes company name, version, copyright info, etc.

Thank you for the help in advance,

[Transporter]

So I want to add some info to my exe. So when the user had view mode on details he or she sees the program name and so on. This also means I want to add some info to the properties->details page of the program. This includes company name, version, copyright info, etc.

This is the right forum but your questions are a new topic. To set meta data to your program just add a windows VERSIONINFO resource.