Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

437 Neutral

About Eddycharly

  • Rank
  1. Eddycharly

    Shadows and light on Kepler 22

    Nice article, One thing though, shadows should not "subtract" light but "oclude" light. This way, lights affect only pixels that are not ocluded and the problem of shadows going across the walls goes away.
  2. I thought the handle came from the boost lib that's why i said it should not be exposed but i was mistaken, sorry. I realised my error when reading your code again. Anyway, what i like in promises is how they can be chained. It would be nice if your handle could handle that ;)
  3. Can't you have a sort of promise interface and an implementation wrapping the handle ? Of course you need to expose à cancelation flag, this is user responsibility to abort processing when requested. There's no way to do it from outside. As a personal preference, i like the bluebird implementation of js promises. I didnt write c++ code for a long time. Maybe ill give it a try for fun, but i can't promise ;)
  4. I'm not sure that passing the handle is a good idea. It should be an implémentation detail. You should go with the concept of promises like in Javascript, i like how simple and easy to use they are. Probably one of the best design for an async lib.
  5. C# is also pass by value, as is c++. I don't think you can pass the array without cloning it first in C#. In C# you can easily implement deep copy by serializing an object graph using a binary serializer, and then deserialize the object graph to obtain a clone. It's not a perfect solution, but at least it's a generic one, maybe you can do something similar in java ?
  6. Eddycharly

    BSP trees with modern OpenGL

    BSP trees allow to easily traverse the scene in back to front order from any point in space, so you can render a scene without z buffering. For a modern renderer BSP trees are too complex and restrictive. Z buffering is a lot more flexible.
  7. You have to marshal it. There's the marshal_as template function you can use. [color="blue"]#include [color="#a31515"]<msclr/marshal_cppstd.h> System::String^ path; marshal_as<std::string>(path);
  8. As you pass the maker template parameter, why don't you use it to inherit in WidgetMakerType ? instead of inheriting from WidgetMaker directly ? Like this : template <class base_object, class object, template<class,class> class maker, class id_datatype> class WidgetMakerType : public maker<base_object,id_datatype> { .... }; Now, writing WidgetMakerType<IGuiElement, Textbox, WidgetMaker, String> TextboxRegister(GUI_TEXTBOX_ID); can be problematic as it registers an object that could go out of scope, the problem is that it doesn't register the static field, but itself. For example, this code will break : void test () { { // register factory WidgetMakerType<IGuiElement, Textbox, WidgetMaker, String> TextboxRegister(GUI_TEXTBOX_ID); } // here factory goes out of scope // try to construct a text box WidgetMaker<IGuiElement, String>::construct(GUI_TEXTBOX_ID); // this is going to crash because we access the factory that is gone out of scope } You could unregister the factory in the destructor, but that's obviously not what you're trying to do. Anyways, the static WidgetMakerType m_RegisterThis; is never used, so it's removed by the linker. To force a reference to to m_RegistryThis, you need to tell the compiler/linker to reference it, so that it isn't removed. In MSVC it should be somewhere in the project settings, you must know the mangled symbol name tough. For GCC i don't know, it's probably a command line parameter to pass to the linker.
  9. If you need to work with raw data, the SignedChecker function should take a raw data pointer as parameter : bool SignedChecker( BYTE* pA, DWORD dwSize ) { if( dwSize == sizeof( SHORT ) ) pA++; else if( dwSize == sizeof( DWORD ) ) pA += 3; if( *pA & ( 1 << 7 ) ) return true; return false; } else just use the operator < semantics, there's no need to reimplement what operator < does.
  10. That's some seriously bad code, it assumes a DWORD * can be stored in a DWORD. It's not true, on a 64 bit platform, a DWORD is 32 bits and a DWORD * is 64 bits.
  11. In fact it is possible to write it by modifying the WidgetMakerType class declaration like this (at least it works in xcode 3.2.3) : namespace Lem { template <class base_object, class object, template <class,class> class mistery, class id_datatype> class WidgetMakerType : public Lem::WidgetMaker<base_object,id_datatype> { public: WidgetMakerType(id_datatype type) : Lem::WidgetMaker<base_object,id_datatype>(type) {} protected: object* create(void) const { object* o = new object; return o; } static const WidgetMakerType m_RegisterThis; }; } //namespace Lem Note that it only ensures that the third template parameter passed to WidgetMakerType is a template itself taking two classes as template parameters. That doesn't mean you can specify these template parameters in the caller, the receiver has to specify the template parameters itself. Given this : class A { }; class B: public A { }; class B_Type { }; template<class, class> class C { }; the following can be written : Lem::WidgetMakerType<A, B, C, B_Type> w1 (B_Type ());; but not the following : Lem::WidgetMakerType<A, B, C<int, float>, B_Type> w1 (B_Type ());;
  12. I don't understand the need for this parameter also, is it for some partial specialization things ? Are you trying to make factories register themselves automatically ? If so, i'm not sure if it will work except if you enforce a symbol reference to your static field, because if you don't, it will not be referenced and then never get instantiated, then not registered.
  13. Eddycharly

    Cache Coherence and Memory Barriers

    Regarding the code, it seems to be the same problem as this one (c#) : static void Main() { bool complete = false; var t = new Thread (() => { bool toggle = false; while (!complete) toggle = !toggle; }); t.Start(); Thread.Sleep (1000); complete = true; t.Join(); // Blocks indefinitely } In this case, the program never terminates because the complete variable is cached in a cpu register. But that's more a problem of the compiler optimizations than a cache coherency problem. One way to solve this problem is to make the complete variable volatile. When a variable is marked as volatile, the compiler will generate the necessary acquire/release fences to ensure the variable is up to date. It is better to instruct the compiler with the volatile keyword than messing with barriers by hand, but volatile can have its own kind of problems, most often because it doesn't prevent a write followed by a read from being swapped. Like in this example : class IfYouThinkYouUnderstandVolatile { volatile int x, y; void Test1() // Executed on one thread { x = 1; // Volatile write (release-fence) int a = y; // Volatile read (acquire-fence) ... } void Test2() // Executed on another thread { y = 1; // Volatile write (release-fence) int b = x; // Volatile read (acquire-fence) ... } } In this case, it is possible for a and b ending up with value 0, even with x and y marked as volatile, when Test1 and Test2 run simultaneously on different threads. This link explains the basics of nonblocking synchronization well : http://www.albahari.com/threading/part4.aspx. It's in c# but the concepts can easily be translated to c++.
  14. Eddycharly

    Cache Coherence and Memory Barriers

    I think it depends on the hardware/compiler. I believe that all processors used in desktop computers have a strict memory model, although it seems not be the case for processors like intel itaniums who have a weak memory model. It should be safe to say that cache coherency is not a concern from a developer point of view. That doesn't mean a developer shouldn't be aware of cache contention performance hit. Memory barriers are useful to prevent instructions reordering and out of order execution. Especially in the context of lock less programing.
  15. Eddycharly

    Best callback technique

    i would say generated free functions by templates are a good solution (because free functions pointers have a fixed size), that's not trivial to write such code though. interfaces is probably the simplest method but it is not very flexible imo.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!