AzurVeda is a set of libraries designed to conduct the development of applications. Basically, it is an experimental C++ framework, and can be seen as a C++ extension, which adds features that lacks to C++, like automatic serialization and other methods seen in java and C#, amongst other original features like context management or hardware abstraction. It is thought for system independance, interface experimentations, math experimentations, sound and graphical experimentations, 3D and more. It is open enough for portability to both modern and minimal systems, like embedded hardware, game consoles, and old hardware.
Example of tool browsing classes and objects in a context.
An interface can be built automatically from an object shape.
Fingerprint image built with package VedaLibImage
A preview of a 3D Object built with package VedaLib3DEngine
Classes can manage sounds the same way as images or 3D!
|Context Export |
Executables can be built from Libs and serialization for any platform!
Extending this base Framework, a set of Libraries offers Math,Image, 3D and sound functionnalities, that can be themselves extended:
Use AzurVeda 's base types for your class members and class registration, and your class will get the AzurVeda features.
Context management is done by class BaseContext, and you can have many context by applications. (Yes, that's what is called multicontext applications.) Contextes are like factories; By example, to have a 3D modeler, you should code some 3D object classes, some texture classes, some camera classes, and register those classes to a context... And that's all. A user interface project will be able to create an application from the context, and manage automatically Object creation, Edition and deletion for all the classes, and also the serialization of the whole context state with file reading, writting... and merging. You can even merge 2 contextes that has not exactly the same classes registered: two different applications made with AzurVeda on different subjects can be quickly melt to share their objects. You can use a first context with a first class set for your use, and a second context with a complete different class set, for another use, in the same application. An undo/redo stack is also automatically managed by each contextes, no need for additional code at any level. But the most interesting feature must be the dynamic pointer management: an object within a context can point others objects with a special pointer type. It makes possible the last following features:
Before you go further, Note that this documentation is generated from the source comments; But Browsing by class inheritage is certainly not a good idea. We suggest you to read the paragraphs sorted by Theme Groups, as they are in the "Modules" page up there.
- Destroying an object automatically unlink all pointers to it.
- Object dependance tracing: You can ask if an object is dependant or not from another, even indirectly throught many pointers.
- It makes possible to extract the exact dependant object set for a given object used as an entry point, to flush unused objects.
- It also makes possible what I will call delayed modification: If you modify or destroy an object that is used by anothers (even during in a realtime rendering by example), all the dependant objects will be locked in the time the modification ends.
To finish this list of features, the AzurVeda context objects can be edited on one thread while their methods are used by other threads, using a lock mecanism.
AzurVeda makes a point to bring independance everywhere: that is why the base package provides a pure virtual class that defines a Machine. This class will keep 100% independant from other classes, and provides methods for graphics, sounds, and more. You can choose to use the context features with or without the virtual machine, or use a virtual machine alone, with or without the context features. The real machine-specific code is managed by each VedaMachine's specific package, included in the releases.
the VirtualMachine class used by most AzurVeda project provides an original way to manage sounds. In classic applications, Each time you want a sound, music or anything, you have two possibilities:
- You use a separate library that will play a given format. InThat case,these libraries manage their own sound threads, but often lack some features, or will forbid the application portage because it will lack on other platform. You will have problem if you want to throw multiple library inits. If you want to throw some other sample of some sort, you will have to recode another thread, etc...
- You code yourself a sound server. In that case, you got to manage a system specific sound thread yourself, which is quite problematic for portage.
AzurVeda 's VirtualMachine got a better solution: It plays a sound thread with a float buffer, and you can register mixing objects that will add their signals to it. This way, you are far more free to throw music, and experiment with sounds ! Furthermore, you can choose to use context-managed class VirtualMedia, which allows to use this system transparently, just by extending one method.
AzurVeda project targets at least a minimal machine that would have a floating point unit and more than 4Mb of memory, according to your application needs. In order to assume these features, The libraries that extends objects from the AzurVeda base lib should apply to these code rules:
For some applications, we just need a context with objects that take a shape at inition, and then do not change. In that case, all the edition, serialization output, and events code should not be linked in the application. AzurVeda use a processor word, _ENGINE_EDITABLE_ that sort out all the code that could be useless in such application, and so ensure the minimal size for an executable. if you want the full features, use word processor _ENGINE_EDITABLE_ in your compilation project (usually, -D_ENGINE_EDITABLE_). Note: this processor word trick may not be continued in further versions, as linkers should manage the culling of useless methods.
Each AzurVeda libraries in the AzurVeda workspace get a specific license when they're created. a 'COPYING' file defines these licenses in each directories under the workspace, and this license only applies to the files under this directory. You should read those files. VedaLib, the base package, containing the classes to extend, is released under the GNU LESSER GENERAL PUBLIC LICENSE Version 2.1( Copyright (C) 1991, 1999 Free Software Foundation, Inc) It means, you can link this library into free or non-free programs. This license encourages " the widest possible use of this library, so that it becomes a de-facto standard". So you may release the sources of it or not in your applications.
- Re-entrant code. It means you must not use global variables, and be careful with static members: Keep in mind we can have many contextes at the same time. If you have to access a table as a resource, declare it as 'static const'.
- No assembler or machine-specific code should be used in the extended libraries that inherit BaseObject, for portability purposes.
- You can use assembler or machine-specific optimisations in Libraries that Extend the VirtualMachine. They exist for this purpose.
- If you extend your own Library in order to share it, the totality of the code it depends on should belong the AzurVeda Workspace, in the shape of source. It means you shouldn't include standard template library, or anything. From now on, the only standard header used by some classes is <math.h>. If you want special types, use the Base package. You shouldn't use external libraries under the form of link libraries, all this could break a portage. Of course, you can just choose to not follow this rules for your own use.
- All Memory access should work in Big or Little Endians: Be aware that differents processors doesn't write bytes in the same order. ( Intel processors are Little Endian, PowerPC and motorola are Big Endian.) If you code a simple way, this should'nt happen.
- Please, the more possible: align your tables in memory in a way float and int types keep aligned on 4 bytes. Try to use less possible int-to-float casts. (These optimisation laws doesn't accelerate much an intel, but are critics for PowerPC and other processors.)
- You will not find any C++ operator overriding in AzurVeda libraries, It is a choice: Keeping an understandable code is a need. We don't use templates for the same reason. We have short-code necessities, and templates inflate the binaries at each use.
- We follow C++ for everything else: we use virtual methods, and const operators a lot.
VedaLibMath, VedaLibImage, VedaLib3DEngine, the example dir, plus VedaMachineOGL, VedaMachineLinux, VedaMachineOGLWinDxSound, and more, are also under the same license for the same reasons, but are only presenting possible standards, that may evolve: (It could be possible to have more than one Image standard in the same context, for example).
Other Libraries and applications under the AzurVeda Workspace directory may have a LGPL license or not. In the download section, we will provide with each new releases:
- a free LGPL version of the workspace, which will only feature the directories that are under a GNU GENERAL PUBLIC LICENSE or a LESSER GNU GENERAL PUBLIC LICENSE, with full sources for these directories.
- a full opensource version of the workspace, including the LGPL packages with their sources, plus other packages with other license types, GPL or any other opensource license.
- We provide free binary tools for various platforms (like UVeda) from this sourceforge website.
The AzurVeda Workspace library content is decided by the authors of VedaLib, the base package, and more contributions may be included with it in the future.
Updated on 2007/04/06
/\/\ 4 N k ! N D
_______ _ __ ___ _____ ___ _ _ ____
___________ __//___ /________ |/ / ___________\_______/ \
/ _ _ \/ _ / _ / _/_/____/ _ __ /
/ / / / / / \ \/ / / \ \ /
\\___/___/___/ ¯ _____/_____/ ______\___/_____/\________\\
\________/_ ___ __ l____\ /elD!