Here is a first little video of the current test environement (inside NetRush) I use to test technologies. You can see it in better resolution on Vimeo or Youtube.
NetRush – Dev Test box – Consoles & Scripts from Klaim on Vimeo.
This is a simple test environement in the NetRush game. This video demonstrate the combination of several technologies :
- Ogre ( ogre3d.org ) as graphic engine – thanks Sinbad! ;
- Navi/Awesomium ( princeofcode.com ) to generate the textures of the 3D consoles: the display code is HTML/Javascript/CSS rendered in the texture via Chromium/Webkit – thanks Adam! ;
- Falcon (falconpl.org ) as scipt language/engine – thanks Jonnymind! ;
[programming stuff]
Last weeks, at night, I’ve been fighting with the Falcon source code to get it run in NetRush. With Jonnymind’s help (he is the creator of the language) we managed to spot and fix some bugs that blocked me. Some of these were from non-obvious usage of Falcon C++ objects that I missed. The documentation is not complete enough for the moment (it’s still a pretty young language) and the code was not obvious about some subtil things but once you got it right it runs really well.
After two weeks trying to set Falcon in NetRush I’ve been a bit angry that I lost so much time for something that some other people did right quicker. One of the reason is that I wanted to have the source code in the NetRush SVN to quiclky spot Falcon problems and provide fixes if I can. I had to use CMake to generate a project file for my project but in NetRush all the paths are relative to the root project directory and CMake only generate full paths. So I managed to create a custom Visual Studio project file that references the right sources and got it built. This makes it a bit “ninja” to update the source code, but I don’t think I’ll need to update very often – and I’ll only update for bugfix for the moment.
Another week have been lost in trying to run a simple test : execute “1+2″ in the console and get the result.
Some of the problems I got were some UNICODE conversion stuff that will be soon fixed in Falcon (easy to fix once spoted) but other were from my way to use the Falcon objects. There were some concepts subtilities I wasn’t aware of and as I followed the “simple” example of the provided Falcon console source code, I had to provide a lot of code and debug feedback to Jonnymind to make him spot where I did something wrong.
We agreed that some work would have to be done to ease understanding and using some objects of the language and some changes are currently work in progress.
The Navi integration was made months ago. I replaced the raw rendering of text on texture by getting the texture from a Navi. That Navi is fed with HTML/Javascript/CSS files and renders the result in the texture using Awesomium (Chromium/Webkit wrapper). That way, all the consoles (and almost all GUI) you see in NetRush is just plain HTML/Javascript/CSS code, sometime communicating with the core C++ code.
That way, it’s really easy to have the main behaviour of the game in C++, exposes it to Navi Javascript environement and let a graphic-skilled guy manipulate the rendering with HTML/CSS (and maybe javascript). Without any compilation.
The consoles and “applications” you see in the video are just tests I wrote quickly, that shows the power of those technologies together with some of my glue-code. I’m using that system in NetRush for gameplay (yes, you’ll understand later why) and eye candy.
The performance of all this is very promising. For the moment.
I think the next dev video i’ll post here will be more related to gameplay. Stay wired :)
This is what i love with C++ frameworks.
They are always either too big and complicated to integrate (especially when you are a one-man-team),
Or they are small and bugged,
Or only do one little thing and you have to integrate tons of them hence raising the complexicity of the software.
Add that to the fact that in everyone is using his own “garbage collecting system”….
And you’are easily in a nightmarish situation where integrating small things takes a stupidly long amount of time.
Well, this is mainly due to the lack of garbage collector, lack of dynamicity (compared to Java,C# or even python), and the C retro compatibilty.
But, executing a C/C++ software, rarely take hundred meg of memory
Yeah, we met a bit of problems integrating the interactive mode; this is because the interactive mode is extremely new and still experimental. Integration of the script engine itself is much less twisty and consists of just bringing up the engine DLL and call routines from the loaded scripts; this is used on several commercial applications right now and had been working for at least three years.
Btw, we have fixed the problem about UNICODE strings in the interactive compiler.
@Divagation> Well, not all libraries are that messy, that’s why I take a long time to check that the libraries I use are really what I need at the moment. But yes C++ libraries are not the most easy to integrate. I hope the “module” feature of the post-next-C++ standard will fix that. One day.
@jonnymind> I’ll not be able to get back home until a few days. I’ll update once I’m back. Thanks :)
“I hope the “module” feature of the post-next-C++ standard will fix that. One day.”
The issue, is that, because it’s an old language, even if there is a “module feature”, it will take a long time for people to switch their frameworks and their dependencies into the module feature.
Anyway, let’s hope that everything will just be fine :-D
Haha that’s right. I think they are making it more like a more conveninent way to provide libraries than the old (current) way. If it’s really easier it will be more used.
I think it’s the same problem with a lot of new C++1x features that are juste easier ways to express what was verbose and error prone.
”Anyway, let’s hope that everything will just be fine :-D”
Haha you are an optimist XD