Jump to content
  • Advertisement

Lantre

Member
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

229 Neutral

About Lantre

  • Rank
    Member
  1.   Exactly, the book is focused on how to model light in such as way as to be rendered by a computer in real time. Including a bunch of tricks you need to fake certain interactions.   Although I wouldn't say it's "what the graphics card is doing", unless you are counting shader programs as being done by the graphics card? That might get a bit confusing when comparing fixed function pipelines to modern ones.
  2. I did the the first half of the course and if I recall correctly Eric describes the course as a first step before you start with the content introduced in Real-time Rendering.   Real-time Rendering is by far the more comprehensive resource.
  3. You might need to clarify your question to get a helpful answer, perhaps using slightly more technically accurate terminology to avoid any ambiguities.   If you are talking about memory management, then I guess the answer to your question is "you don't". The .Net runtime is responsible for Garbage Collection so it will delete any objects in memory which are no longer being referenced.
  4. Ha yeah thanks just figured it out. Helps a lot to step back and try to explain what's going on. Got rid of the tunnel vision I've had for the past hour or so.     I find it quite interesting how much clarity you gain from merely explaining the problem to someone else, often the solution pops into your head right there. :)   I suppose that is why they say if you really want to master a topic you should try teach it to other people.
  5. Like the others have mentioned you need to figure out what information is being generated and when it is generated. Then map that to what should happen when you press a key, when you release a key and everything else in between.   Here is some (not very good) code I have for basic free-camera movement. It's using GLFW but you should get the idea. void GraphicsEngine::KeyboardEventHandler( int key, int scancode, int action, int mods ) { static const float walkingSpeed = 2.0f; static const float turningSpeed = 35.0f; auto cameraVelocity = m_camera.GetVelocity(); auto angularCameraVelocity = m_camera.GetAngularVelocity(); switch( key ) { case GLFW_KEY_W: if( action == GLFW_PRESS ) cameraVelocity.z += walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.z -= walkingSpeed; break; case GLFW_KEY_S: if( action == GLFW_PRESS ) cameraVelocity.z += -walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.z -= -walkingSpeed; break; case GLFW_KEY_A: if( action == GLFW_PRESS ) cameraVelocity.x += -walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.x -= -walkingSpeed; break; case GLFW_KEY_D: if( action == GLFW_PRESS ) cameraVelocity.x += walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.x -= walkingSpeed; break; case GLFW_KEY_E: if( action == GLFW_PRESS ) cameraVelocity.y += walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.y -= walkingSpeed; break; case GLFW_KEY_Q: if( action == GLFW_PRESS ) cameraVelocity.y += -walkingSpeed; if( action == GLFW_RELEASE ) cameraVelocity.y -= -walkingSpeed; break; case GLFW_KEY_Z: if( action == GLFW_PRESS ) angularCameraVelocity.y += turningSpeed; if( action == GLFW_RELEASE ) angularCameraVelocity.y -= turningSpeed; break; case GLFW_KEY_C: if( action == GLFW_PRESS ) angularCameraVelocity.y += -turningSpeed; if( action == GLFW_RELEASE ) angularCameraVelocity.y -= -turningSpeed; break; } m_camera.SetVelocity( cameraVelocity ); m_camera.SetAngularVelocity( angularCameraVelocity ); }
  6. If you're using a C++11 compliant compiler you can check out cereal, it's a new serialization library that supports xml, json and binary formats. I looks fairly easy to use though I haven't tried it myself, I just saw it pop up on isocpp.org.
  7.   In that case I would avoid the multi-chaining since it's hard to follow what the end result of construction will be. Rather call you 'main' constructor, i.e. the one doing all the work, directly from the others and make it explicit what each parameter is being set to.   Like so: public WiGoSpeed( ) : this( 0 ) { } public X(int speed) : this( speed, speed, 0, false, false ) { } public X(int left, int right) : this( left, right, 0, false, false ) { } public X(int left, int right, int time, bool breakWheel) : this( left, right, time, breakWheel, breakWheel ) { } public X(int left, int right, int time, bool breakLeft, bool breakRight) { Left = left; Right = right; BreakLeft = breakLeft; BreakRight = breakRight; BreakTime = time; }
  8. Lantre

    Managing OpenGL Resources

    That's actually what I do for resources, but the value is only used inside the render-device implementation  They're owned by an RAII value, and then references are given out to the user, e.g. //hidden internally, not seen by the user struct NativeBuffer : NonCopyable { /*GL, D3D, etc buffer handle member variable*/ NativeBuffer( ... ) { /*acquire handle*/ } ~NativeBuffer() { /* release handle*/ } }; //what the user gets: typedef Pool<NativeBuffer>::Handle BufferHandle; class Device { public: BufferHandle CreateBuffer(...); void ReleaseBuffer( BufferHandle ); ResourceLock MapBuffer( BufferHandle ); void UnmapBuffer( ResourceLock ); private: Pool<NativeBuffer> m_Buffers; } A system to allow shared ownership is implemented on top of this -- e.g. you might have a model-asset that owns some buffers, and then many model-instances that all share the one model-asset.     Once you give out references to their respective users what mechanism do you use to track usage in order to determine what should or shouldn't be cached? If that is even a relevant question for your framework.
  9. Lantre

    Help to understand my own misstake?

    Unless you can guarantee that the particular key you want is in the map you may instead want to consider using find and checking the returned iterator is valid.
  10. By the end of construction your object should be left in a valid state. You also want to reduce/eliminate code duplication. If you can't do this by chaining constructors then consider factoring out the common code into a separate method and calling that from within your constructor.
  11.   This particular scenario could probably be extended to cover any instance where you have a subject matter expert pairing with an implementation expert. I.E. when you have someone with significant knowledge of the problem space/domain (e.g. AI, physics, networking, etc...) and someone who is familiar with the solution space (e.g. C++, Unity, some framework or another, etc...).
  12. Lantre

    Managing OpenGL Resources

      This was my intuition of the situation, where for the most part you want shallow copies and reference semantics. If deep copies are required then that should be offered explicitly and cannot just happen 'by mistake'.   One option that hasn't been discussed is to use non-copyable values. This avoids the issue of expensive copies by out-right preventing them.   You might still use shared_ptrs to share access to these objects - but there is a big difference between "an object that moves with reference semantics" and "an object passed by reference". By still being a value it allows you to also pass them by the cheaper plain reference or raw pointer. It also allows them to be stored more efficiently in contiguous arrays.   The precise way in which access to the object is passed around is a choice for the client code, not enforced by the handle type itself.     This makes a lot of sense especially if you only have one point of control, e.g. a resource manager/resource cache, which owns the 'real' resource. Client code can then request weak/non-owning references to these resources.   This is something I'll probably be playing around with pretty soon for meshes and materials. At the moment I have each object naively loading (and owning) its own textures and meshes, which while convenient is not particularly clever.
  13. Lantre

    Managing OpenGL Resources

      I didn't say that it's useless, I said that its freaking hard to understand what it does, look : lambda list initializer + not-straightforward name 'm_programID' - clearly a mess at first sight. OR post more code so that everything would be clear   Here is an equivalent example of using a shared_ptr with a custom deleter to manage a D311Device and the same thing for automatically releasing an SDL_Surface. I'm not sure why programID would be a confusing name, it represents the unique ID assigned by OpenGL to that particular shader program. Sure I admit I'm not very good when it comes to naming things but that made sense in my head.   Edit: Oh and another example for managing files.
  14. Lantre

    Managing OpenGL Resources

      This was my intuition of the situation, where for the most part you want shallow copies and reference semantics. If deep copies are required then that should be offered explicitly and cannot just happen 'by mistake'.   Your shader implementation sounds quite interesting, it's pretty cool what can be done when you're familiar with the domain, especially when it comes to performance optimisations. Considering how important resource management is, I definitely need to spend some more time researching the topic.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!