Horde3D

I thought about using boost as well, especially for the event system. But I didn't like the big dependency and the way boost implements the signal slot mechanism. Maybe I was spoilt by Qt's signal slot implementation. But since I won't have the time to further develop the GameEngine, I won't keep anyone from improving the engine by using boost. Maybe I can take a look at least at the sound problem today...

I am not a huge fan of using boost itself, but boost::any can be adapted to a single header - take a look at Ogre::Any. As for the signals, boost::signals tends to have too much overhead for use in a game event loop, maybe look at the very, very fast event library, although the usage is very similar to boost::signals.

_________________
Tristam MacDonald - [swiftcoding]

I added a sound to the ball within the Coconut Shy example, opened it in the editor and couldn't reproduce it. I committed the sound now to the scene. Perhaps it helps to figure out where the reactivation problem may occur.

I haven't been able to reproduce it any recent builds either. Unfortunately I'm heading out in a few minutes to do the holiday visitation routine for two weeks. I'll take a look at it when I get back.

The audio bug may have just been driver related, I didn't think about it but I've updated them in between "bug" and "no-bug" occurences.

What I've been up to with it:
- Finished a ScriptComponent and bound every DLL exported function to squirrel

- Added nonsolid collision objects, true static colliders, first hit raycasting, and collision filtering by class (multiple hit raycasting and constraints still to-do)

- Added automatic naming if an entity doesn't have a specified name, assumption being that scripting will destroy the entity when necessary

- Added component templates for most components

- Clear planning and direction for PathNode, SteerController, SteerEffector (point, field, and line), and BlackBoard AI related components

- Thinking about database "check last" during development and "check first" for release with gzip for compression of data as both a storage container and for scene descriptions of both entities and resource requirements

- Thinking about GUIs, networking, serialization, and paging/streaming but not too hard

Just tying up loose ends left before putting to-do's on hold to finish up a demo. I think SVN and I are destined to be mortal foes, so I'll just stick to linking to zip files, it's safer when in my hands.

That sound's really great! Looking forward for a first demo.

If you have any trouble with the SVN don't hesitate to ask me. Concerning the GUI elements I may be able to develop a FreeType2 implementation based on rendering text into textures as an Horde3D extension if that would be helpful. Don't know maybe the current system is faster and/or flexible enough so you don't need it.

I've already whipped up a super simple GUI consisting a GUIControl class from which GUICanvas and GUIText controls are derived. Just the basic blueprints and probably as far as I'm going to go with it as both controls can operate like a button. For anything serious GUI wise in my future I'll be sticking with CEGUI, LibUFO, or AntTweakBar depending on needs.

Recent Additions

- Multiple Hit Raycasting and refined raycasting

- Improved Collision filtering, with colliders now able to belong to multiple classes and specify targets to ignore based on worldID

- Added several utility classes: 3d Bezier curve 'n' mid-points calculator, Templated Freelist (GPG4), PropertyMap (GPG2), Bitstream, and a GenericTree template that requires a passed GenericTreeOperator template to determine what occurs for splits, inclusion tests, insertion validation, and removal; fetching can be precise or can step up a defined number of tiers and then collect everything beneath

- Wrapped up most loose ends with Component Templates, only remaining issue is with physics that use a mesh

- Added animation "trips" that throw "E_ANIM_TRIP" when an animation passes a certain timing point but is still within a defined threshold

- Only things that are on my "to-do at a later date" list (other than AI and net components) are lazyLoading, basic paging, database access, finishing up the missing Lua bindings, Lua-styling the script component, and physics constraints

Current target date for demo completion looks like a realistic 31st, unless I get hit by a bus.

Really looking forward to it,... keep up the good work...

For the most part everything is going well. Basic premise works with a ball, that drives like the warthog in halo (look and go that way). Of course, scripting deals with the ball and camera, though camera control is super quirky, nauseatingly so. Everything should get UV'ed and cleaned up over the next week. Then the ball will go bye-bye for an automobile.

But does it fishtail?

Nice work on the game engine, btw.

_________________
Tristam MacDonald - [swiftcoding]

Something I had problems with when playing with bullet. I set the friction to various values but it seems like this does not affect anything.
BTW.: I just noticed that I had never added the domino demo based on the GameEngine to the community branch, I made up for that now.

From my understanding, the warthog handling was largely the result of a physics engine bug in the original Halo, and took considerable work to duplicate in Halo 2

_________________
Tristam MacDonald - [swiftcoding]