Hi Christian,christianclavet wrote:Hi, Michael.
I've just finished looking your source. Everything is well written, I really think I will try to merge it in my project.
That look really good!
Regards,
Christian Clavet
Sirrf - Simple Irrlicht Framework - version 0.1.0 released!
Today the first official version of Sirrf, the Simple Irrlicht Framework, has been released. After two months of steady development Sirrf has finally reached the initial goals of Sirrf 0.1.0: being an extensive, but simple open source framework to enable rapid game development. In its current state Sirrf is able to do exactly that. That's also the reason why Sirrf has jumped directly from pre-alpha status to beta status.
But what can Sirrf do for you? In it's current state Sirrf offers game logic, graphics, scripting and sound control. Some noticeable features are:
You might be wondering, though, if Sirrf is really something for you. It's obvious that Sirrf is ideal for newcomers to Irrlicht and game development, but Sirrf should also be useful for experts. Especially now experts are more than welcome as Sirrf is still in beta status.
- Data Store
The Data Store allows you to store primitive value types such as integers, floats and doubles in a type-independent format. These variables can be accessed from anywhere within the framework, from both native and interpreted code, through the DataStore and DataStack classes.
Entity Management
In Sirrf entities are component-oriented. The idea behind Component Oriented Entities is to make entities data-driven. In order to do this the functionalities are split in various individual components. As a result an entity is in fact nothing more than a collection of components. So, what an entity represents, is defined by its components. Sirrf currently offers various components in the fields of graphics and sound. Furthermore Sirrf also provides an Entity Manager which should be seen as the central interface point to all entity related issues.
Event Management
Sirrf's event management is build upon sigslot. This means that Sirrf follows an observer model where objects have to subscribe to an event if they want to react to that event. Currently observers can subscribe to game logic events, input events (passed from Irrlicht) and GUI events (again, passed from Irrlicht).
Game Management
The Game Manager performs generic game initialization and deinitialization. It also provides functions to access sub-systems of the framework, such as the Event Manager and the Entity Manager. It's main function, though, is to control the flow of the game through game state management. This class provides various features to this end.
Scripting
Sirrf is almost completely accessible through AngelScript, a free and open source scripting language. AngelScript allows users to extend applications on run-time using scripts that follow a C/C++ like syntax. Furthermore it's easy to extend Sirrf's AngelScript bindings even further.
In the coming time focus will lie primarily at adding additional documentation. This will be an crucial step to make the framework more accessible to newcomers. And of course Sirrf will also be extended with new features.
Useful links
Development Hub - http://sourceforge.net/projects/sirrf
Downloads - https://sourceforge.net/project/showfil ... _id=260711
Help Wanted - http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=33606
Sirrf - Simple Irrlicht Framework - version 0.1.1 released!
It is only two weeks ago since the first official version of Sirrf, the Simple Irrlicht Framework, was released. But now it is already time for the next release: 0.1.1. In comparison to the previous release, this new release adds few new features. Yet the new release can be considered as an important one. Sirrf 0.1.1 brings an improved scripting architecture; all AngelScript binding code has been moved into its own dedicated directory. Not only does this tidy up the code, but it also to remove scripting quite easily (if desired). This has become even easier with the addition of compilation flags which can be used to easily enable/disable certain features of the framework. Furthermore the have been various small bug fixes and other improvements. See the change log for more information.
Useful links
SourceForge.net page - http://sourceforge.net/projects/sirrf
Downloads - http://sourceforge.net/project/showfile ... _id=260711 | http://www.ohloh.net/p/sirrf/download?package=Sirrf
I think that this would need to be a sort of, compile time option. The reason being that perhaps running multiple interpreters will get a little chunky, but i see other engines doing it too. Its an interesting idea though.Multiple scripting back ends (through abstracting the scripting interface) would be awesome.
christianclavet wrote: Great new release! With that other could look at your code and make bindings for another scripting system (squirrel, python, etc). Very nice.
Yeah, this new releases paves the way for the implementation of multiple scripting bindings. Multiple scripting back-ends are possible too, but it will need a good requirement analysis for the scripting interface abstraction. I'll keep it in my mind, but I'm not sure if it will make it into 0.2.0.aanderse wrote:I read through the code and like it as well. Multiple scripting back ends (through abstracting the scripting interface) would be awesome.
Well, you can already disable sound by undefining the __COMPILE_WITH_SFML_AUDIO__ flag. And removing sound completely shouldn't be a big task. Thanks to the compilation flags this has become even easier, as you now know exactly what you have to remove.christianclavet wrote:Do you think that this will also be possible for the audio part in a next release? (I'm not meaning the NEXT one) (I want to try to adapt the code for IRRKDlang)
The reason why I decided to use std::map and std::string, is because I'm more familiar with C++'s standard library. As a result I don't know what the advantages and disadvantages are of Irrlicht's core::map and core::string. Furthermore I was worried whether core::string would integrate in a good way with scripting.sio2 wrote:I'm curious: any specific reason why std::map and std::string was used instead of Irrlicht's core::map and core::string?
)Code: Select all
GameManager.obj : error LNK2019: unresolved external symbol __imp__createDevice referenced in the function "public: void __thiscall GameManager::init(void)" (?init@GameManager@@QAEXXZ)
1>C:\Users\Public\IRRlicht\sirrf-0.1.1\src\SirrF\Debug\SirrF.exe : fatal error LNK1120: 1 unresolved externalCode: Select all
#include <sigslot/sigslot.h>Code: Select all
#include <sigslot.h>Here is the line:>c:\users\public\irrlicht\sirrf-0.1.1\src\core\datastack.cpp(177) : warning C4018: '<' : signed/unsigned incompatibility
Code: Select all
for(unsigned int i = 25; i < fSize; i++)Code: Select all
1>LINK : fatal error LNK1181: failed to open the file in input 'angelscript.lib'EDIT2: Ok. It was forced on console in the project settings (Linking editor->system->subsystem - now is set on undefined)1>LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
I've set the project as a Window and it compile and build.1>LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Code: Select all
// Irrlicht
#include <irrlicht.h>
#pragma comment(lib, "Irrlicht.lib") Code: Select all
// Angelscript
#ifdef __COMPILE_WITH_ANGELSCRIPT__
#include <angelscript.h>
#pragma comment(lib, "angelscript.lib")
#endif