Dusty Engine v0.2

[roninmagus]

After a long bit of work, I've gotten Dusty Engine v0.2 to a point where it is ready to be released.

Also, I've created a fairy thorough tutorial which shows how to create a simple task and use it with Dusty Engine, which explains very well it's main purposes and uses.

The focus of this release was the center upon Dusty Engine's task core, allowing the tasks to become more effective, flexible, and useful.

I've fixed several bugs, and made many enhancements. I now consider it to be a stable, reliable, useful task engine!

Here's a copy of the changelog, showing all the modifications, enhancements, and bugfixes.

Code: Select all

Dusty Engine
A Task Engine for Irrlicht
by Dave Andrews

http://www.daveandrews.org

======================
Changes in Version 0.2
======================

	Modifications:
	--------------
	* A big bug was fixed in the pausing of tasks, where they would
	  not have the correct timedelta when unpaused which led to tasks
	  being executed sometimes more than they should have.  Now tasks
	  should seamlessly pause and unpause, even if they had been paused
	  by a propogation of their parent being paused.

	* The task tree is now guaranteed to execute a pre-order traversal
	  of nodes.  A parent node will be executed before it's children.
	  Also, the DoUpdates function allows for the addition of other
	  styles (such as postorder, but it's not in this release) in
	  the future.

	* All DE classes now use Irrlicht's built-in logger class for
	  output.

	* Tasks' OnUpdate function has been changed to allow more interaction
	  with Dusty Engine.  Each task now receives a pointer to the Dusty 
	  Driver to which the tree belongs.  You can use this pointer to get 
	  the random number generator, the time server, and the task tree 
	  itself.  This allows all tasks to have all the options to work with 
	  Dusty Engine that the main application has, such as 
	  creating/deleting/pausing/unpausing tasks.

	* Tasks' priority is now stored in the task class, rather than in a
	  node in the task tree.  This allows tasks to change their own
	  priority, and allows anything to change any tasks's priority by
	  using DustyTaskTree->GetTask(<id>)->SetPriority(<priority>).

	* New function in the task tree TaskTree::IsPaused(<task_id>) returns
	  true if the task identified by task_id is paused, and false if not.

	Bugs fixed:
	-----------
	* A possible segfault when deleting the task tree was fixed. Some
	  programs crashed at the end of execution.  This should fix that
	  bug.

	* Fixed a bug in DeleteNode in the task tree which caused a segfault
	  when it was sent a NULL pointer.

	* Fixed a bug in GetNode which crashed if getting a node which did
	  not exist.

==============================
Changes in V0.1
==============================

Original release.

Let me know what you think!

[guest1]

Thank you, mr. andrews... your code explained to me many things I did not understand the easy way to do... While I cannot use DustyEngine directly 100%, I copy+paste major portions of your code...

Thanks MUCH again
Kenny

[roninmagus]

Thank YOU, very much That means a lot to me, glad I've written something someone got some help from!

[guest1]

You may see more use out of it (and maybe even inclusion into the engine) if you wrote it more like an advanced animator.

-------------

What I ended up doing with your code (cause it wouldn't work "out of the box" like this) is to start work on a particle system that does all sorts of cool things... For example... with your code (and tree based design) it seems easy to me to be able to make something like this:

a center point and a circle of 10 points rotating on the x axis 10 units away from the center... every one of those ten points has another ten points around that point about 2 units away from the point and those are rotating on the counter clockwise on the y axis...

You see, something like that is easy... What I will eventually do is (just like the name implies) make an engine that can simulate dust floating around, where different "wind effects" apply different rotational vectors to the particles...

Sounds complicated... *sigh* -- work on it more later

[roninmagus]

Does not work out of the box? I misunderstand what you mean.. Is there a bug you have found? Let me know if so.

I didn't want to do this project as an animator for 2 reasons, really. 1 is that the tasks in DE are not limited to affecting Irrlicht nodes. That's a big use, yeah, but they can serve unlimited other purposes.

The second is because this is an experiment for myself; a learning experience. For instance, I've learned to create a library that links to a DLL on windows and statically in Linux.. something I've never done before. It's been a lot of fun really. I'd like to see anything you come up with!

[guest1]

I will certainly send you any bugs I find.

What I mean about it not working out of the box is this: It works fine, but I modified it for my own purposes.

The first thing I did was I deleted your newly passed references to the driver in the event function (I did not need this, because I keep my irrDriver as global data so I can use it anywhere in the code (I find passing it around is so redundant, when it will never change throughout the entire time I use the engine... Anyway...

I also deleted your configfile stuff, cause the stl stuff was adding unecessary 55KB to my executable or something like that....

After those, I did some stuff that you may think is absurd, but I decided that I would create more events for the tasks... I made it so every task referrs to an IScreenNode (normal) and there is an onUpdate method, but that wasn't powerful enough for me. I created another scene node called ICollideableSceneNode (not sure if I spelled it right but who cares) and it contains all of the stuff for ODE... all of the update intervals are all hardcoded at 10ms (globally changable through define) which also happens to be equiv to a worldstep in ODE...

Possibly (if I have enough time) I'll make a quick demo for you in a few days, but my final result could look something like this:

I have a particle emitter (represented by the root node) this emitter emits particles in whatever fasion... well, the root node of that emitter, goes through all of the children and it applies wind to each one of them...

Right now it looks funny, but I can see the potential for greatness if I were to modify it this way: (assuming I'm making light smoke that blows in the wind)

every x amount of milliseconds all of the smoke particles are named siblings of eachother. each time a particle gets effected, it affects each one of the parents, the children and the two siblings to the left and the right... It would look kinda like a web if you were to draw lines between the particles. I want to make it like do some cool rotation things, so it "curls" like cigarette smoke does... or maybe make an "envelope effect" so smoke can "billow" and be puffy...

I dunno... I thought of some other cool ideas for your engine such as "affectors" on the water for a lake... of course, you're going to have to write some really nifty rendering code to be able to translate all of the affectors into waves and calm water, so I'll just ditch that idea for now... One of the reasons why I like your engine, is, theoretically speaking, if everything was coded correctly, you could create a "world" and just let it run itself... I like that.

The more I play with dusty, the more I like him.

I'll let you know if I get any brilliant ideas as to how to make the tasks more effective modifying its world (probably by making it more aware of it's surroundings.)

----------------------

I know this is getting long, but I just got an idea... You saw how I had to modify some stuff to get dusty to work... well, what if your dustydriver was more "customizable" and your task system was created using a template class. I'll have to play around with it later, cause I can see the modifications in my head already, and I think it'd be easier for me at least, if I didn't have to copy and paste your classes every time I wanted to make a new one

Ok, I'm really going this time

[roninmagus]

Those are all good ideas! I'm not quite following you though on making tasks templated or making them scene nodes.

There are 2 things, though that you have enticed me to do for the next release:

1) Get rid of all STL objects.. use irrlicht's list/string classes
2) In file classes (TextFile and ConfigFile) I need to figure out something to use to read/write files instead of stl files. I'm vague on the use of irrlicht's new readfile/writefile classes.

[guest1]

well, I decided to stick to hardcoding it instead of templating it, cause it would be nightmare for me (new to advanced C++ stuff like templates) to make a template TaskTreeNode and template Task for deployment anywhere, as long as you tell the TaskTree about it.. It could end up being pretty difficult.

Right now I'm still chopping up your code. I did notice a "bug" though... In dustytasktree.cpp line 105 and 107 should be removed.

Why? because unless you make another variable to say that it's not yet started, you will never never call the OnStart function if you start the task paused... I always thought of OnStart as the function that should be renamed to "OnCreation"

just my 2cents...

P.S. great to hear about the removal of STL. BTW, I can send you a patch to remove stl::stack from dustytasktreenode.cpp and instead use irr::array

[guest1]

sorry for spamming.

I thought I might share this with you, so you can see how bad I chopped up Dusty...

Right now it's setup like this: (if you are used to database schemas, this shouldn't be foreign)

World HAS MANY Object HAS MANY Task

CInteractive
virtual: OnCreation
virtual: OnDestruction
virtual: OnPause
virtual: OnUnpause
virtual: OnUpdate

World : CInteractive
DoUpdates
DoCollisions

Object : CInteractive
OnCollision

Task : CInteractive
none

It may be obvious to you the reason why I set it up that way, but if it isn't... I placed inside of world dWorldID from ODE and all that good stuff. It makes sure all my collideable (I'm making up words here ) objects get calculated inside of ODE.

You may be thinking to yourself "why didn't you just use dusty how it is right now? You could have done that without modification." I felt it ODE integration was a good idea and also I needed an Object tree.

So that's the brief description of where it's at now. Take it or leave it, your engine is good for reuse.

thanks again,
Kenny

[roninmagus]

BTW, I can send you a patch to remove stl::stack from dustytasktreenode.cpp and instead use irr::array

Sure, that'd be great. Send it to me at dustyengine@daveandrews.org

Also, I have a forum up for DE, for conversations like this. it's at http://dustyengine.proboards3.com so we won't bother niko's forums with all the rampant discussion of DE (yeah right hehe)

Thanks for your help kenny, I'm going to put several of your suggestions and that bugfix into the next version.