• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

183 Neutral

About pauls_1979

  • Rank
  1. Custom Visual Studio Build Step/Rule

    I managed to get compile time string hashing working in no time, and I recommend anyone looking to use string based ids take a look at the article... it's a great solution [smile]. I was initially worried about hash collisions (I realize chances of this happening are slim but I like to err on the side of caution), because this method won't automatically flag any issues, but I reckon I can keep track of strings and ids separately in systems (e.g. the entity system) where hash collisions might be an issue. Thanks again guys.
  2. Custom Visual Studio Build Step/Rule

    Thanks for the swift replies guys. @_fastcall - I did do some research into compile-time hashing, but never managed to find anything that worked very well (and I should mention that I develop for consoles, so no C++ 0x support I'm afraid). However, your 'parameter-limited macro chain' link looks quite promising, so I might follow that up... it would be the ideal solution. @NewBreed - Don't worry, I'm well aware of the complexities involved in ACTUALLY parsing C++ source, so I guess what I should have said is 'my application SCANS the source'. I literally just search for STRING_ID, and replace the following string with a hash value. Anyway, your suggestion doesn't sound like such a dirty hack, however I do work in quite a big team (with literally hundreds of source files), so I want be able to make good use of Visual Studio's dependency checking. Oh, and it needs to work with Incredibuild! @KulSeran - Nice idea, I think I might do that if I don't manage to get compile time hashing working. I would still like to automate the process however; it would be all too easy for someone to change a string and forget to update the hash.
  3. I recently wrote a very simple command line application that parses C/C++ source files in order to pre-hash strings ids (identified by a STRING_ID macro). The tool works very nicely, and it allows me to write code like this: void OnMsg(unsigned int msg, const MsgData &data) { switch(msg) { case STRING_ID("Damage"): { Damage(data); break; } case STRING_ID("Heal"): { Heal(data); break; } } } Which, once processed, will become: void OnMsg(unsigned int msg, const MsgData &data) { switch(msg) { case 0x12e083d6: { Damage(data); break; } case 0x147e0f1: { Heal(data); break; } } } Now I want to automate the process so that when I build a project in Visual Studio 2008, it runs my string id tool first to generate a set of intermediate files, then compiles those intermediate files instead of the original source. So far I've tried creating a custom build step, and also a custom rule. Both of these options work in a fashion, but they also seem to override the actual compilation stage, meaning I would then have to add the intermediate files to the project in order to compile them (not ideal for big projects as you can imagine). Has anyone here attempted something similar? And if so did you have much luck? I've a horrible feeling I may need to go down the makefile route, but I'd like to avoid that if at all possible.
  4. This depends on which platforms you want to support. Do you plan to develop for consoles? It's unlikely that Sony or Nintendo (or even Microsoft) will support the new standard anytime soon.
  5. C++ Default value for bool

    Quote:I think bools are initialized to 0 if they're globals. Under no circumstances would I recommend you ever rely on this being the case.
  6. Calculating corner points of frustum

    Thanks guys, this link looks like it might provide the answer (and more importantly it's nicely documented), I'll post the results if I manage to get it working.
  7. Is it possible to calculate the corner points of an arbitrary frustum given only the 6 planes that define it, and if so how? A thorough search on google resulted in plenty of hits, but all the examples I found seem to cheat by using the view matrix, near clipping plane, far clipping plane and field of view in their calculations. I have a feeling that the solution involves intersecting three planes at each corner, but I can't quite figure out how to do this. Any source code, pseudo-code or links would be greatly appreciated, thanks in advance.
  8. Scene Management Design Issues

    Quote:Original post by Gage64 If the entity has an Update function where it does all that stuff, you can pass the scene as an argument to that function. This will also make it easier to support multiple scenes - you just pass the scene the entity is currently in. Well that is an extremely simple solution, but usually the simple solutions are also the best, so I might just give it a try. Entities themselves don't actually have an update function, but they are built from components, and I could probably pass a pointer to the scene as a parameter of any component functions that might need access to the scene. Of course I'm still open to any other suggestions, scene management is one of those topics that can be tackled from so many different angles and I'm interested in hearing how other people solve these problems.
  9. Scene Management Design Issues

    Thanks guys. Quote:Original post by Gage64 But that's all you need. Did you try this: // Forward declaration of scene class. class Scene; // Entity class. class Entity { private: SmartPtr<Scene> m_pScene; }; I have tried that yeah, but because the smart pointer uses intrusive ownership it needs to access the scene's reference counter (which unfortunately it doesn't know anything about because it's just a forward declaration). Does this mean that there's something wrong with my smart pointer class? I might give it a go with a good old fashioned boost::shared_ptr and see if that works. Quote:Original post by extralongpants Do you really need a smart pointer to the scene in every entity (not saying you don't)? I don't know how your system works, but are scenes determined unused/removable when there are no entities in them? This seems like a strange scenario. Do you need the ownership aspects of the pointer in the Entity class? You're right, I don't need a smart pointer inside the entity (like you say the ownership aspects aren't necessary), however I would at least like to be able to do something like this: class Entity { public: inline ScenePtr GetScene() { return(ScenePtr(m_pScene)); } private: Scene *m_pScene; }; This would ensure that ownership outside the entity class is handled safely. I'm just wondering if I need this pointer at all? Could anyone describe how other games/engines might handle situations such as the player querying the scene's collision system to find the height of the ground, or perhaps a camera searching to find the position of it's target? Could a simple messaging system be the solution?
  10. I’m in the process of writing a new scene management system, and I've encountered a design issue which I was hoping someone out there might be able to help me with. When an entity is added to a scene I want to be able to store a pointer to that scene within the entity, so that the entity’s components can query the scene (for interactions, collision, lighting and so on). In previous systems I've be able to use a simple forward declaration like this: // Forward declaration of scene class. class Scene; // Entity class. class Entity { private: Scene *m_pScene; }; In my new system I'm using smart pointers with intrusive ownership, and this makes the forward declaration method impossible because the compiler only lets you instantiate pointers or references to a forward declared class. I could get around this by storing a native pointer and manually incrementing/decrementing the scene's reference counter, but this feels like a last resort rather than a solution. Now I’m wondering whether there’s a better way of orgainising things. Would it be possible to create a system where you don’t even need to store a scene pointer within an entity? I don't want to go down the route of limiting myself to just one scene, but I can't think of another way in which an entity could find out which scene it belongs to. Any suggestions would be greatly appreciated, thanks in advance. [Edited by - pauls_1979 on October 15, 2009 11:26:49 AM]
  11. Best looking Wii game?

    I think that the best looking Wii games are those with strong art direction such as Okami, Resident Evil 4 and Zelda Wind Waker (even if technically speaking the last two are Gamecube games). Mario Galaxy is probably the best and most popular example, but even that seems to rely on a fairly limited set of 'next gen' effects such as rim lighting, bump maps, environment maps and so on. I guess if we're including Gamecube games you could also consider Factor 5's Star Wars games, they had some very nice lighting and scattering effects. The last game to try anything that really pushed the harware was The Conduit, but if you ask me that ended up being quite an ugly game (although High Voltage's next game, The Grinder looks pretty impressive). The future's looking a little brighter (or should I say shinier), so maybe developers and publishers are starting to take the hardware a little more seriously at last. The new Resident Evil game looks like it's packing some fancy effects, and Dead Space looks a lot closer to it's HD counterparts than I expected it would.
  12. Classes and static members

    I'm not sure this is exactly what you're after, but hopefully it's enough to get you started. class UniqueID { public: UniqueID() { static int value = 0; m_value = ++ value; } inline int GetValue() const { return(m_value); } private: int m_value; }; template <typename TYPE> class HasUniqueID { public: static inline int GetUniqueID() { return(ms_uniqueID.GetValue()); } private: static const UniqueID ms_uniqueID; }; template <typename TYPE> const UniqueID HasUniqueID<TYPE>::ms_uniqueID; class Base { }; class ChildA : public Base, public HasUniqueID<ChildA> { }; class ChildB : public Base, public HasUniqueID<ChildB> { }; void CheckUniqueIDs() { assert(ChildA::GetUniqueID() != ChildB::GetUniqueID()); }
  13. C++ class help

    Quote:Break the mutual dependency. If you introduce something like a bounding box (or bounding circle) object, then the wizard will have function to get its bounding shape, and the projectile can test for collision with the bounding shape. What he said... Basically, a forward declaration of the wizard class will fix the compile errors, but it won't fix the underlying design flaws. Assuming you have a reasonable understanding of inheritance, I would suggest that you create a simple abstraction, and separate the collision functionality into a new class (from which wizard can then be derived). Here's what I mean: class CollisionObject { public: BBox GetBBox(); }; class Projectile { public: void Collide(CollisionObject *pCollisionObject); }; class Wizard : public CollisionObject { }; The major advantage of this method is that when you come to introduce new classes, you won't need to create new collide methods within your projectile class in order to support them, you can simply inherit from CollisionObject instead. Hope that helps.
  14. I don't have a great deal to add to this debate, 'cause I agree with the general consensus (i.e. you should go with stl). One thing I would recommend however is that you create typedefs for the various stl containers, that way if you do need to replace one, it should be pretty painless to swap in and out. Here's a quick example of what I mean: typedef std::string myString; template <class _Ty, class _Ax = std::allocator<_Ty> > struct myVector { typedef std::vector<_Ty, _Ax> Type; };
  15. C++ Red Black Tree Template Class

    Quote:I'd suggest finding a C implementation and going from there Thanks, I think I'll try that first. I have no problem implementing C++ templates, I just need something fairly easy to read and most importantly stable to get me started, so that might be a good way forward.
  • Advertisement