Horde3D

Next-Generation Graphics Engine
It is currently 15.12.2018, 19:49

All times are UTC + 1 hour




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: 03.10.2009, 01:48 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
I've commited the port of the GameEngine in SVN.

This means, the: KeyFrameAnimComponent, PhysicsComponent (had to know about 16 and 32 bit triangle indices), SceneGraphComponent are all brought up to Horde 3D Beta 4. Other than as required porting, to contain non const pointers (could have made them const, but I would've had to const_cast it away for a memcpy, and unsigned int* TriangleBase has become unsigned int* TriangleBase32 and an unsigned short* TriangleBase16. This could be condensed a char* TriangleBase and a bool indices16 with a lot of casting, but it would be nasty to read.

NOTE: Animation layers not in use.

Files Changed:
/trunk/Tools/GameEngine/Samples/Coconut_shy/DosenApp.cpp
/trunk/Tools/GameEngine/Samples/DominoDemo/DemoApp.cpp
/trunk/Tools/GameEngine/src/GameAnimationComponent/KeyframeAnimComponent.cpp
/trunk/Tools/GameEngine/src/GameAnimationComponent/main.cpp
/trunk/Tools/GameEngine/src/GameBulletPhysicsComponent/PhysicsComponent.cpp
/trunk/Tools/GameEngine/src/GameEngineCore/GameEvent.h
/trunk/Tools/GameEngine/src/GameSceneGraphComponent/GameEngine_SceneGraph.cpp
/trunk/Tools/GameEngine/src/GameSceneGraphComponent/SceneGraph.cpp
/trunk/Tools/GameEngine/src/GameSceneGraphComponent/SceneGraphComponent.cpp
/trunk/Tools/GameEngine/src/GameSceneGraphComponent/SceneGraphComponent.h
/trunk/Tools/GameEngine/src/GameSceneGraphComponent/main.cpp

The port took about an hour and for anyone planning or about to port anything to Beta 4 it's stone simple.

Terrain seems to be sluggish though in Beta 4. Appears to be with the pixel shader (debug/wireframe don't suffer), I do see what appears to be shadowing in the DominoSzene on the terrain.

I'm currently working on two writeups, one for proposed additions and alterations to the GameEngine core (most of which I have implemented or are in progress) and the other a brief on the resource API (it felt intimidating to use at first, mostly just because of documentation).


Top
 Profile  
Reply with quote  
PostPosted: 04.10.2009, 08:00 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1149
Location: Germany
Thanks for your changes.
AcidFaucet wrote:
I've commited the port of the GameEngine in SVN.
Terrain seems to be sluggish though in Beta 4. Appears to be with the pixel shader (debug/wireframe don't suffer), I do see what appears to be shadowing in the DominoSzene on the terrain.

What do you mean with that? Until Beta 3 there was no shadow on the terrain at all, and now on my notebook with Beta 4 it looks equal to Beta 3.

AcidFaucet wrote:
I'm currently working on two writeups, one for proposed additions and alterations to the GameEngine core (most of which I have implemented or are in progress) and the other a brief on the resource API (it felt intimidating to use at first, mostly just because of documentation).


As you already mentioned in the PMs I aggree with your suggestion to rewrite the event system. It was far from being perfect, but only a quick and dirty solution by me, to have something running.


Top
 Profile  
Reply with quote  
PostPosted: 04.10.2009, 08:48 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks a lot for updating the game engine!

AcidFaucet wrote:
I'm currently working on two writeups, one for proposed additions and alterations to the GameEngine core (most of which I have implemented or are in progress) and the other a brief on the resource API (it felt intimidating to use at first, mostly just because of documentation).

Do you have any ideas for improvements for the resource API or do you rather think of better documentation?


Top
 Profile  
Reply with quote  
PostPosted: 04.10.2009, 15:41 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
Quote:
What do you mean with that? Until Beta 3 there was no shadow on the terrain at all, and now on my notebook with Beta 4 it looks equal to Beta 3.


What I mean, is that I recently redid the OS and had ancient video drivers.

Quote:
Do you have any ideas for improvements for the resource API or do you rather think of better documentation?


I think the API is a huge improvement, it's more just knowing what to expect to get back. Example being to get the expected vertex positions and indices you need to calculate an offset using the Mesh's parameters. It makes perfect sense after the fact, but isn't obvious.


Top
 Profile  
Reply with quote  
PostPosted: 06.10.2009, 03:07 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
I've been making some pretty massive changes to the GameEngine in SVN. I'm basically going through step by step and merging pieces from the core of my independent similar project and the lessons learned from that. So in a semi-random fashion here's a break down of what I've changed or have in progress.
__________________________________________

I’ve modified the event system to use an ‘EventManager’ class that handles the registration and identification of various events. In order to remove the current requirement that event classes be part of the engine core, I’ve changed ‘GameEvent’ into a simple class that contains its type identifier and a reference to a simple stream type class. When the event is handled, the components have read/write access to the stream.

The obvious problem with using a stream for passing the data around is knowing what’s in the data. Programmatically there is no means to know this, though I’ve considered adding a datatype identifier to each piece of data, so aside from a name the Event Manager can also take a description of the event as well as a ‘data profile’ that can be dumped to a text, xml, or html file to document the events currently in use.

Code:
class GameEvent
{

public:   
   GameEvent(unsigned short id, GameComponent* sender) : id_(id), m_sender(sender), data_(TBinArc()) {}
   GameEvent(unsigned short id, TBinArc& data, GameComponent* sender) : id_(id), data_(data), m_sender(sender) {}
   ~GameEvent() {}
   const GameEvent& operator= (const GameEvent& other) {
      id_ = other.id_;
      data_ = other.data_;
      m_sender = other.m_sender;
      return *this;
   }
   GameEvent(const GameEvent& other) : id_(other.id_), data_(other.data_), m_sender(other.m_sender) {
   }
   const unsigned short id() const {return id_;}
   TBinArc& data() {return data_;}
   const GameComponent* sender() const {return m_sender;}

protected:
   unsigned short id_;

private:
   TBinArc&            data_;
   const GameComponent*   m_sender;
};

I also whipped up a very plain macro syntax for plugins to use to register events and/or obtain their Ids for their manager’s to store as static members (static members being preferred over using the event manager’s getEventID(std::string) function to avoid a hash function followed by a map search. Events cannot have clashing names. Attempts to re-register an existing event will return the existing event id, meaning you can register every single event a plug-in needs without scrambling anything, assuming you are using it as all the others expect.
Code:
class EventManager
{
public:
   EventManager();
   EventID registerEvent(const std::string& aEventName, const std::string& aEventDesc = std::string(), const std::string& aDataDesc = std::string());
   EventID getEventID(const std::string& aEventName);
   std::string getEventName(EventID aEvent);
   void dump(const std::string& aFileName);
   size_t eventCount() {return events_.size();}
private:
   struct EventData {
      EventData(const std::string& aName, const std::string& aDesc = std::string(), const std::string& aData = std::string()) :
      name_(aName), desc_(aDesc), data_(aData)
   {}
      const std::string name_;
      const std::string desc_;
      const std::string data_;
   };
   EventID nextId_;
   std::map<EventID, EventData> events_;
    std::map<unsigned long, EventID> nameIds_;
};

Code:
#define EVENT_DEC(aEvent) static unsigned short aEvent;
#define BEGIN_EVENT_MAP(aClass) define E_MAP aClass \
    include <GameEngine/GameModules.h> \
    include <GameEngine/GameWorld.h>
#define EVENT_SET(aEvent) unsigned short E_MAP ## :: ## aEvent = GameModules::gameWorld()->getEventID( #aEvent );
#define EVENT_REG(aEvent, aDesc, aData) unsigned short E_MAP ## :: ## aEvent = GameModules::gameWorld()->registerEvent( #aEvent , aDesc, aData );
#define END_EVENT_MAP() undefine E_MAP
#define GET_EVENT(aEvent) E_MAP ## :: ## aEvent


Other changes include overhauling the scene format and implementing more thorough (de)serialization, to either a D.O.M. that can be written to a human readable file (XML and a C-like syntax are implemented), or any other parser/writer that can cope with a tree that could be added, or a binary stream. Any GameObject should be able to write itself out to an XML or w/e string through the API that could be dumped to a file or read into an editing tool as well as able to reinitialize itself and components from a string. Lastly, on serialization, components (and the GameObject) should be able to dump their XML requirements and possibilities (to the best of their ability to be intelligible). Serialization and deserialization is mostly there, just need to go through the components. Of course, this means that the configuration now comes from elsewhere.

Code:
<Scene>
   <Meta>
      <Name>Super Duper Scene of Awesomeness</Name>
      <Brief>One liner goes here</Brief>
      <Description>Insert some descriptive text here.</Description>
   </Meta>
   <Resources>
      <Res file=""/>
      <Res file="" cache="true" preload="false"/>
      <Res file="" cache="true" preload="true"/>
   </Resources>
   <Content>
      <Constant>
         <Group name="Trees"> <!-- Meaningless, intended to aid dev for partitioning stuff -->
            <GameObject name="">
               <Modules>
                  <Graphic resource=""/>
                  <Physics res="" />
               </Modules>
               <Properties>
                  <Vec3f name="position" value="1.09, 1.028, 12.0" />
               </Properties>
               <Data>
                  <Int name="boxes" value="23" />
                  <Int name="boxes" value="23" />
                  <Int name="boxes" value="23" />
                  <Int name="boxes" value="23" />
               </Data>
            </GameObject>
            <Reference file="" />
         </Group>
      </Constant>
      <Persistant>
         <!-- Objects and such that aren't constant go here -->
         
         <!-- Optionally feed a seperate persistance file to the parser
            to recover saved state data -->
      </Persistant>
   </Content>
</Scene>

The "meaningless" comment about groups can be ignored. Today I just set everything up to be able to serialize just a group as well as just read in a group, e.g. the ground level for paging.

A property registrar as a part of the GameObject, to which the object and any components can register members for braindead serialization, which also should be available through the API so that tool components like property grids can display and alter them. Here the component changes to no longer initialize itself when it loads its data, but does such when the entity decides to initialize its components. This way alot of the data can come straight from the dynamic and data set and property map, making setting up a component for serialization a jiff. Lastly on the properties and data issue, they're using OpenMP macros when setting and grabbing data for some thread safety.

A resource management class that can cope with caching and background loading to which GameObjects can subscribe to for notification that a resource is ready (<- todo) and conceals the differences between actual file based resources and archived (PAK-type) resources. Other than the packaged resource it's basically done as a core component manager that is automatically added (so that it can run during the thread loop to deal with some tasks like slowly releasing the cache and lazy loading).

Lastly every component should include a function to return the events that it is concerned about (yes, check event could be used but it typically does some checking and other processing too) which the GameObject can access and return through the API. Again, this is more of a tool support function but could be useful to components that may want to know if anyone is handling an event (e.g. a ScriptComponent may want to do some developer checking and say “uhhh, you told me to do this on this event, but that event is never going to occur”

Things still unimplemented and in the bag of tricks include event recording (undo/redo/playback)


Top
 Profile  
Reply with quote  
PostPosted: 06.10.2009, 05:56 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
Interesting work!

What compiler are you using that allows this kind of stuff?
Code:
#define BEGIN_EVENT_MAP(aClass) define E_MAP aClass \
    include <GameEngine/GameModules.h> \
    include <GameEngine/GameWorld.h>
#define END_EVENT_MAP() undefine E_MAP
The compiler I'm using at work (VS 2005) doesn't let you use pre-processor commands inside a #define like that.


Top
 Profile  
Reply with quote  
PostPosted: 06.10.2009, 06:38 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
That's interesting.

I don't even know what I'm using anymore, I think the VS2005 compiler. We have tons of stuff like that at work, most of which is even pre-VC6. I think most of the code is from '87 there, I don't know, a degree in programming and another in engineering isn't enough to understand 3m lines of K&R code only 20k of which I've written. Sadly, all I've done pertains there pertains to report printing. There could be some voodoo I'm overlooking though, we do use tons of custom tools at work to compile all of our international builds and such.

I should probably double check with building from VS2005 proper. I don't even know what I use to build (I define a *.all file that lists them and hit CTRL+B (smiley face character in 4NT)), other than it was discontinued before I was a coherent individual. Sigh, life from the command line and make files. Thanks for pointing that out, it does seem odd, I'll check up on it and report back.


Top
 Profile  
Reply with quote  
PostPosted: 06.10.2009, 08:34 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1149
Location: Germany
First big thanks for your contribution.

I haven't understood all of your changes yet, but I wanted to add two comments that might be helpful.
In the current GameEngine I avoided the usage of STL classes in the interface of the DLLs because of various problems that might occure. If I remember correctly we already got a problem with the current system, when we tried to link statically against the CRT libs. Although while searching through the log's I couldn't find the point where we changed it back to dynamic linking because of that error.

Another thing I might have to explain a bit, what was the reason for the checkEvent thing. I already did that in this post. To summerize this post, the reason for the checkEvent, was to allow components to block events that shouldn't be processed because the blocking component want's the handle the proposed change represented in the blocked event itself. I only wanted to add this comment because I wasn't sure what you mean with
Quote:
yes, check event could be used but it typically does some checking and other processing too


Top
 Profile  
Reply with quote  
PostPosted: 11.10.2009, 22:12 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
@DarkAngel, Yeap, can't do the recursive macro's natively. I'm using a custom preprocessor (sigh, copyrighted by my boss) So I had to tweak the macro 'language' slightly to be useable in other cases.

Yeah, other than the really basic STL types (string, pair, and vector) templates and DLLs don't like each other, even less so if the dlls come from different sources. std::map just outright explodes into FATAL_COMPILER_ERROR or something crazy IIRC.

Yeap, I hadn't looked at checkEvent since the last time I had looked at the GameEngine stuff.

Just about everything is working but it's kind of tough to track some stuff down. For instance, horde is telling me that the textures have been loaded in the log, but I have no clue where they are visually ... I'm assuming this has something to do with delaying loading.

Shot of no textures (not even a heightmap) in my WIP editor.
Attachment:
spitev001a_lowres.jpg
spitev001a_lowres.jpg [ 142.1 KiB | Viewed 11003 times ]


Top
 Profile  
Reply with quote  
PostPosted: 11.10.2009, 22:43 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
Kill me now ... for turning 'loadTextures' off


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group