Integrating/Initializing custom middleware, dealing with scripting interfaces, VFS integration advice?

[Christopher Sosa]

Hi,

I was experimenting with the Helium engine code and i wanna use my own renderer engines, i replaced the WinAPI/GLFW Window Manager and the OIS Input Manager with SDL2, currently i'm integrating OGRE3D 2.1 for achieve this following the Bullet integration sample but i don't find any code where initialize it appropiately because OGRE 2.1 needs some special setup in order to run and i'm lost how to do it currently, since the BulletWorld class seems it's never used although and only i find .json data about the classes, probably if i know to handle this i can do a lot!.

Also for scripting what i have to take in consideration in order to add scripting to my Helium-based project?, although your philosophy said extending the enigne using C++ code but i feel is better adding some scripting (specially for people who wish to avoid C++) for now i'm using Qore as scripting language thanks to their thread safety and pretty C++ Embedding API..

At the last question is i'm a bit confused of how the Asset Location works because i want to integrate an VFS system to use Zip archives as their filesystem (like libraries such ZipIos++ or PhysFS)  and you use specialized paths in order to find it, thanks!

[Philip Degarmo]

Hello! Responses inline below. Hope this helps! Feel free to ask any questions!

Philip

On Fri, Sep 18, 2015 at 7:49 AM, Christopher Sosa <cristop...@gmail.com> wrote:

Hi,

I was experimenting with the Helium engine code and i wanna use my own renderer engines, i replaced the WinAPI/GLFW Window Manager and the OIS Input Manager with SDL2, currently i'm integrating OGRE3D 2.1 for achieve this following the Bullet integration sample but i don't find any code where initialize it appropiately because OGRE 2.1 needs some special setup in order to run and i'm lost how to do it currently, since the BulletWorld class seems it's never used although and only i find .json data about the classes, probably if i know to handle this i can do a lot!.

To integrate a new system like a rendering library, input system, etc., you should create a system component. (See BulletSystemComponent as an example). There is a two-phase init (Initialize() and FinalizeInit()) to handle circular dependencies between systems. In the physics example, \helium\Data\ExampleGames\PhysicsDemo includes the system component. The C++ code in the main() (\helium\Example\ExampleMain_PhysicsDemo\ExampleMainWin.cpp) has hardcoded paths for the system file, a level file (Which points to a world which has a bullet world in it). Then it creates a bunch of objects. BulletSystem is instantiated because it is in the system file (\helium\Data\ExampleGames\PhysicsDemo\System.json) BulletWorld is instantiated because it is in the world file (\helium\Data\ExampleGames\PhysicsDemo\WorldDefinition.json).

I do think it will be possible to integrate ogre or really anything you want using the system components. The included renderer could probably be done that way - but it existed before system components did so I don't think it uses them.

 

Also for scripting what i have to take in consideration in order to add scripting to my Helium-based project?, although your philosophy said extending the enigne using C++ code but i feel is better adding some scripting (specially for people who wish to avoid C++) for now i'm using Qore as scripting language thanks to their thread safety and pretty C++ Embedding API..

For scripting, I think the reflection system may really help you out. You can iterate the fields and methods registered on a class. See \helium\Reflect\Tests.cpp for example code for registering some fields and methods. You can also search the codebase for AddField to find extensive examples. BulletBodyDefinition is another example that is fairly minimal.

If you can iterate fields and methods on the classes, then you can probably use that to drive registration of types into the scripting language of your choice. Qore looks like only allows registration of member functions to objects, so you may have to generate getters and setters. Perhaps you could use FieldFlags::ReadOnly toskip generation of setters for certain values that script should be able to get but not set?

 

At the last question is i'm a bit confused of how the Asset Location works because i want to integrate an VFS system to use Zip archives as their filesystem (like libraries such ZipIos++ or PhysFS)  and you use specialized paths in order to find it, thanks!

Regarding handling assets, there are two paths that we support: Loose assets and cached assets. The intention is that during development all your assets are raw, unzipped files for convenience. When you run the game during the development, it will do post processing on those files and save them into large cache files in a structure that is efficient to read. (See the CachePC folder.) Does this built in system solve the problems you are wanting to solve by adding a VFS? If it does not, maybe you could describe specifically what problem you want the VFS to solve and I can make a suggestion on how to integrate it. But I'm hoping the cache system will work for you. In any case, you would probably want to extend the caching system (perhaps replacing the built in cache format with the VFS's format.) 

[Christopher Sosa]

Thanks you for your answer!, i was starting to lost hope.

Well this is a little complicated than i expected, then, so for now i created an simple singleton which initializes OGRE and the other OGRE components such Mesh, Camera and others will be implemented as Components instead, for now the Windowing system in SDL2 i did works as i expected so i don't think i have any problem, the Input System i have to test first in order to finish it, the Input System i don't have an API design in mind for now is a singleton class which you can add Delegates to listen key inputs from it.

in Scripting topic, i got it can iterate the fields and methods registered in that class, but sometimes maybe one needs to create an component or entity from scratch or inheriting one, i don't think Reflect can help me in that are (i think, using the registered fields of an existent Reflected class/struct maybe)  via scripting, i was thinking in the idea of using an "Proxy class" which sets the metadata from the script and when a member of the proxy class is called, makes an callback to the member of the class inside of the script, and they have to serialize/deserialize their fields manually (or with a help of an little lib) outside of Reflect. 

Regarding the VFS probably is because someday will need to patch certain categories or archives (audio, meshes, compiled scripts), obviously i want to implement the VFS for shipping products.

Another little questions: 

Why components requires Definitions? and there's why there's special components such EntityComponent?

Also i confused why components needs to Definitions at initialization and Finishing?, i saw ones like only needs definitions at the Finish.

Thanks a lot.

[Philip Degarmo]

Hey Christopher,

It is totally ok to completely skip the component system. If you prefer or feel more comfortable making singleton classes and hard-coding the game to init them, that is a completely fine way to make things work. Components are a newer and less mature part of the codebase and the vast majority of the codebase does not interact with them.

As far as the scripting integration goes, if a script object lives purely in script, it obviously doesn't need to have any reflect backing. But for getting data from native to script or script to native, the reflection system would be a way to data-drive that. Calling from native into script, you're right that reflect won't help you much there as reflect doesn't know what is in script. But I still think you could use reflect to serialize structs as parameters or otherwise shutting data out of script into native. It will depend a lot on how you want to use script though.

The patching scenario is a good one to consider. helium doesn't have any sort of built in patching although I don't think it would be terribly difficult to change the caching system to write out to a separate cache location to make a patch, and have the game check multiple cache files in order of patch "priority." I'm not very familiar with patching systems though. I would still try to work with loose assets and integrate the VFS system of your choice into the cache generation phase of the pipeline.

The reason components use definitions is to separate your configuration data and your instance data. There are a couple advantages of this. First, memory considerations. If you have a few thousand isntances of an object, keeping the configuration data out of instance data can save memory. The second is for live asset reloading. Helium has the ability to load assets and swap them at runtime (very experimental.. it's pretty recent functionality). If you keep your configuration data in definitions and your instances point at definitions, then updating all instances of objects to use the new configuration is accomplished by just reloading the definition. Definitions are generally supposed to be read-only data that is shared by instances of components.

As an aside most engines I am familiar with construct objects by cloning them. Definitions remove this necessity as well - they're a pointer instead of a full copy.

Regarding definitions being passed into Initialize and Finalize, these two functions are a two-phase init. Initialize is called on everything first, then Finalize. This is so that components can deal with circular dependencies on init. In retrospect, maybe Finalize() would have been better named "FinishInit()"

Philip 

--
You received this message because you are subscribed to the Google Groups "Helium Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heliumprojec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.