Jump to content
  • Advertisement

IncidentRay

Member
  • Content Count

    23
  • Joined

  • Last visited

Everything posted by IncidentRay

  1. Just wondering, Hodgman, with this design at what point are the references to the Model and RigidBody components removed from the PhysicsWorld and VisualScene objects?  If the Player struct calls a remove method in its destructor, then the Player would need to store a reference/pointer to the PhysicsWorld and VisualScene, which seems a bit inelegant IMHO.  Or is storing these references actually the right way to do it?
  2. IncidentRay

    Class instances gone wrong!

      This should probably be safe_delete(T*& x) as otherwise you're only assigning the local variable to NULL.
  3. IncidentRay

    Women vs Tropes in Video Games

      This is certainly true.  However, I don't think it's what L. Spiro meant to imply.
  4. IncidentRay

    Women vs Tropes in Video Games

    I would like to see some justification for this claim, please. On the face of it, it makes no sense to me.   I think it is fairly obvious. Would you prefer that we are all exactly the same? Being different keep things interesting. But I know that keeping a mix in things is much more important to me than it is to most others. L. Spiro Read http://pervocracy.blogspot.co.nz/2011/03/gray-coveralls.html please.   Also, do you really need to repeat this tired old cliche?  Actually, back in this thread (http://www.gamedev.net/topic/639144-sony-and-the-ps4-im-impressed-your-thoughts/page-3) you were rightly criticizing the stereotyping of men as "sex-hungry dolts".  So why the change?
  5. I'd like to make a content pipeline for some of my games/engines/etc I'm working on, and I'm not quite sure what would be the best language to use.  I'm using C++ for the actual runtime, but this seems very unproductive for tools.  I've seen C# recommended several times for Windows-only content pipelines, but I'd like to know if there's anything more cross-platform.   Here are some features that an ideal language would provide: It also should provide some abstraction of OS-specific functionality such as directory iteration, etc.  It should also be easy to use high-level features such as regular expressions and other text-manipulation techniques. Integrating this language with Lua should be simple, as I want to use Lua as a data-description language for several resource types. Calling external processes shouldn't be too hard -- for example, I might want to use the Cg toolkit's cgc program to compile shaders. I suppose C++ could work if I used heaps of boost libraries -- this does seem a bit cumbersome though, and I imagine it would cause a large hit on compile times.   Anyone have any suggestions for a good language to use?
  6. IncidentRay

    Advanced Render Queue API

      I had heard of this technique before; I was more wondering about the specific case of state-groups, where it seems that a lot of states would need to store pointers.  For example, pointers to shaders, textures, vertex buffers, index buffers, cbuffer data, etc.  Your example of model assets cleared up my questions about this, though.  I wasn't quite sure what the name for this technique was, however, so your suggestions for terms to research look helpful.  I'll have a look at the article you linked as well.   So in general, the idea is to also store the actual data as well as the state groups, then in place of an actual pointer use an offset or address to the data, and then perform pointer-patching when loading.     I think linear iteration would probably be fine for me as well.  Using the bitfield to skip the rest of a state-group if possible sounds like a good idea.
  7. IncidentRay

    Advanced Render Queue API

    [quote name='Hodgman' timestamp='1358051934' post='5020960'] If you're going for memory efficiency, be aware of your compiler's padding behaviour when designing your header structures [/quote]   Yeah, that StateGroup struct was just a quick example; I'd definitely worry about padding in real code.   [quote name='Hodgman' timestamp='1358051934' post='5020960'] e.g. I put state-groups directly in my engine's model, material and technique files [/quote]   Putting the state groups in resources files is an intriguing idea.  How do you deal with pointers in this case, as obviously they will have different values each time you run the engine? I suppose you could store some other data in the pointer field, and then fix the pointers at runtime -- e.g. maybe a hash of a filename.  Or do you do something else?     [quote name='Hodgman' timestamp='1358051934' post='5020960'] I do pretty much the same thing that you've thought of here, except I also put a bitfield in the header, with one bit for each type of state. [/quote]   Your recommendation of storing a state bitfield sounds good -- that looks like it would be quite useful.  As I understand it, the bitfield can be used to quickly check whether a state group can be totally ignored, but if not, the next step is to check each state individually?   Thanks for the detailed example of how you might generate state groups; that answers several questions I had.
  8. IncidentRay

    Advanced Render Queue API

        Moving the errors to compile time is definitely a good thing.  So then the RenderItem struct can have a pointer to a DrawCall rather than just a pointer to a Command. I'm not quite sure how it would work for the state-group, however.  I was thinking of having a StateGroup struct which actually just stores the header -- i.e. the number of states, the size in bytes, etc.  Then the actual commands would be allocated contiguously after the header.  For example,   struct StateGroup { u8 numStates; u32 sizeInBytes; }; void Foo(StateGroup* group) { State* states = (State*)((u8*)group + sizeof(StateGroup)); }   I can't see a way to stop the user from putting DrawCalls in the state group.  Do you implement StateGroups differently, or is there something I'm missing?       Yeah, I forgot that linkers can do that; thanks for the reminder.  TiagoCosta's use of templates is probably completely fine then.   EDIT: This editor seems to keep messing up the angle brackets for templates, so I can't get the quote above right.
  9. IncidentRay

    Advanced Render Queue API

    [quote name='TiagoCosta' timestamp='1358025244' post='5020848'] I'm pretty sure you just need a single level of inheritance [/quote]   You're right, it does look like a single level of inheritance would be fine.  I was wondering about the purpose of the State struct, as I can't think of what data members it would have.   About templates (sorry, not Hodgman!): I'm pretty sure templates are a purely compile-time feature, so it shouldn't have too much of a runtime-performance penalty.  However, melbow has a good point: templates often do increase the size of the compiled code.  I think there probably wouldn't be much benefit if you implemented exactly the same thing but without using templates (e.g. just copying and pasting your classes/structs/functions and changing the variable types).  Templated functions could possibly cause cache-misses if the compiler hasn't placed the code for both implementations nearby.  In your example, if the instructions for next<int> and next<BindVertexShaderCommand> aren't nearby, this might cause an i-cache miss.  However, this only applies if they're not inlined, so if they are inlined, you should be fine.  I've only started learning about how caches work recently, though, so someone should correct me if I'm wrong.
  10. IncidentRay

    Advanced Render Queue API

    Thanks for the reply, Hodgman.  Memcpy does seem to work on non-POD types in this case.  I'm interested in the alternate design you suggested using composition rather than inheritance.  That looks like it work quite well for one level of inheritance, but I'm not sure about how you would extend this to multiple levels of inheritance.  For this renderer design, I think you might need two levels of inheritance -- you mentioned that State inherits from Command, and then, in my understanding, you have multiple render-state structs derived from State.  Would you just do something like this? struct Command { u8 id; }; struct State { Command baseClass; // other members... }; struct BindShader { State baseClass; Shader* shader; };
  11. IncidentRay

    Advanced Render Queue API

    [quote name='Hodgman' timestamp='1357784838' post='5019739'] I get around the undefined behaviour with inheritance... [/quote]   But if you use inheritance, don't the structs become non-POD types?  That might create more undefined behavior to deal with -- for example, I was thinking of using memcmp for detecting redundant state-changes in the RenderGroup class, but that would only work if the structs were POD.
  12.   Yeah, availability of useful libraries is definitely an important factor -- that's why I was mentioning text manipulation and Lua integration in the original post.   I actually am writing the game itself in C++, but in this case I think reusing code between the engine and tools isn't too important. These are mostly data-conversion tools, which will write files in a format known to the engine, so the tools and the engine don't need to interact directly.  The idea you mentioned of being able to move some asset conditioning steps from the pipeline to the game could be useful, but for the types of files I am converting, this would probably not be too practical.  For example, I would prefer if the game didn't have a dependency on the Cg framework, so this means the shaders will have to be compiled offline.  So what I'm saying is that in my case I think it's okay if the tools are written in a different language to the game.     Hmm, that looks like a reasonable idea; I don't know too much about web development though, and getting the interaction right between the UI and the back-end looks tricky.
  13. Yes, I am writing this only for me, but as this is also intended as a learning exercise, I would prefer if I could write something cross-platform.  As to the suggestion of using Objective-C, I find Objective-C overly verbose and hard to read.  I agree that it might be the best choice if I need something with a complicated GUI, but I don't, so I don't think it's worth it.
  14. Yes, what I meant is that I use a Mac.  I'm not sure what you mean by your first sentence; are you saying that I could use a Mac-specific programming language?   I had heard of Mono, but I wasn't sure how practical it was, so thanks for the input.  From what you've said, using C# with Mono sounds like a good choice then.   EDIT: My line of reasoning for wanting to make it cross-platform was that most people seem to make their tools Windows-only, so if I need to support another platform, it's probably better to support Windows as well.
  15. Thanks for the responses!   Yes, I'm just making offline tools, so as you say, load time isn't too important.  I don't like Java much, but I'm interested in the possibility of using C# as a cross-platform language.     Mostly because I don't have a PC.  Also I just think it's theoretically a bit nicer.     Wow, that stuff looks great; I'm quite intrigued by the idea of using C# now.     Okay, I'll look into Mono.
  16. IncidentRay

    Advanced Render Queue API

      Thanks for the example.  Would you still need the Command struct with this design?  Also, I was wondering whether you think it's worth trying to always avoid breaking the strict aliasing rule, or do you think it's better to just risk the undefined behavior if it's the simplest option?
  17. IncidentRay

    Advanced Render Queue API

    Hodgman, wouldn't this violate the strict aliasing rule when you cast a Command reference to a Foo or Bar reference, or vice versa?
  18. Hi all,   I'm looking for an elegant way to design a rendering API abstraction layer, but I keeping running into problems because of OpenGL's bind-to-edit model.  For example, one thing I want to do is cache/shadow the current render state to avoid redundant state changes, but bind-to-edit makes this especially difficult.   Here's some pseudocode (I'm pretending there is only one texture unit, for the sake of simplicity): class Texture { public: void Create() { glBindTexture(GL_TEXTURE_2D, m_name); // the wrong texture is now bound ... // code to create texture } GLuint GetGLName() const { return m_name; } private: GLuint m_name; }; class GraphicsDevice { public: void SetTexture(Texture* texture) { if (texture != m_texture) { glBindTexture(GL_TEXTURE_2D, texture->GetGLName()); m_texture = texture; } } private: Texture* m_texture; };   As you can see, the texture class needs to bind itself in order to create the OpenGL texture object, and so the the GraphicsDevice class now thinks a different texture is bound than the one that actually is.   The obvious way to fix this problem is to add a glGet(GL_TEXTURE_BINDING_2D) call in Texture::Create so that the previous texture can be bound afterwards, but glGet() calls are supposed to be avoided, right?   The only other solutions I can think of involve various ugly techniques such as circular dependencies, global variables, etc.   Is there a better way of solving this problem?    
  19. IncidentRay

    Dealing with bind-to-edit in OpenGL

    [quote name='max343' timestamp='1356516002' post='5014372'] This is problematic. Best way to deal with this is to let GraphicsDevice to deallocate the texture (instead of leaving it to Texture). If deallocating currently bound texture, then just reset the texture pointer to NULL. There's also the option of using one texture unit as a temporary unit for all those things like creating textures. This is less pretty, and leaves you with one unit less, but it'll help minimize the amount of rebinds. [/quote]   Yeah, moving the deallocation function into the GraphicsDevice class is probably the best solution.  Reserving one texture unit for modifying/creating textures would work fairly well, but I don't think it's worth losing the extra texture unit, and this approach doesn't extend to other resource types (buffer objects, shaders, FBOs, etc.)     [quote name='beans222' timestamp='1356498994' post='5014334'] Do you really need to create a texture in the middle of a time when the GraphicsDevice will be caring which texture is bound? [/quote]   This is a good point, but as mhagain says, there likely are some cases where you may need to modify or create resources in the middle of rendering.  In any case, I'd prefer a system where you can create resources whenever you want; I think it's exposing an implementation detail if you restrict users to only doing so at the start of a frame.
  20. IncidentRay

    Dealing with bind-to-edit in OpenGL

    That looks useful for debugging, but how would you rewrite this code so that it doesn't cause the assert to fail? GraphicsDevice device; Texture* texture1 = device.CreateTexture(...); device.SetTexture(texture1); delete texture1; Texture* texture2 = device.CreateTexture(...); // device dereferences dangling pointer; crash     Should I just just add a device.SetTexture(NULL) call before deleting the texture1 object?  This could become quite tedious in the generic case, with multiple texture units, though.  For example, before deleting any texture you would have to do, for (unsigned i = 0; i < device.GetNumTextureUnits(); ++i) { if (device.GetTexture(i) == texture) { device.SetTexture(i, NULL); } }
  21. IncidentRay

    Dealing with bind-to-edit in OpenGL

    Thanks for the replies!     This would definitely work, but I just prefer it if the caching is implemented in the graphics API layer, so that the user doesn't have to worry about it.  It seems to me that you might end up implementing render state caching multiple times, for each type of graphics you need to draw; e.g., the actual game world, the UI, etc.  I also think this could pose a problem if you are dynamically generating geometry -- i.e., filling a vertex buffer with data, then drawing it, filling it with new data, and so on.  How would you have a list of objects in this case?       As a general rule, anything responsible for allocating memory should be responsible for deleting it: void GraphicsDevice::DestroyTexture(Texture t) { ... }   This is a good idea.  What's interesting though, is the texture class doesn't really do anything in this case -- it just stores a texture name and returns it.  Also, if you need an instance of GraphicsDevice to destroy a texture, it would then be necessary to pass a pointer/reference to it around more.  For example, if an object creates a texture in its constructor, and destroys it in its destructor, it would need to maintain either a pointer or a reference to the GraphicsDevice, so that it could call DestroyTexture.  This wouldn't be needed if you could delete a texture without needing the device, but I'm not quite sure how to get around this.     [quote name='max343' timestamp='1356428689' post='5014135'] FL9 is feature level 9 mode of D3D11. [/quote]   Ah ok, I'm not too familiar with D3D terminology.   [quote name='max343' timestamp='1356428689' post='5014135'] As for your first question, then yes it could potentially cause a problem, though this problem is much easier to identify with a simple assert during bind, just check whether the texture name seems valid (for instance, you can keep track on how many textures you've allocated). This way of deletion is just how D3D does things, you don't have to do the same. As Aldacron already said, your GraphicsDevice can handle the deletion (and check if what you're deleting is currently bound). However, as far as the state goes textures can delete themselves because for that you don't need to bind them (you don't alter the state). [/quote]   I'm having trouble understanding how this would be implemented.  How would you get the texture name without calling a function of the Texture object (which might have been deleted)?  I'm also not sure how keeping a count of the number of textures allocated would help you determine whether a texture name is valid.  I thought OpenGL wasn't required to return a contiguous range of texture names.  I do like the idea of being able to model D3D on this -- could you maybe give a simple example of some code for this?  Many thanks.
  22. IncidentRay

    Dealing with bind-to-edit in OpenGL

    Ok, that solution sounds good.   However, one thing I just thought of that could be a problem with both these designs is texture deletion.  Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.   Do you have any ideas on how to fix this issue?   Also, what's FL9?  I googled it but I can't seem to find anything.
  23. IncidentRay

    Dealing with bind-to-edit in OpenGL

    Direct state access does indeed look like a great solution, but I think the hardware requirements might be a bit high.  Interesting point about whether glGet values will be cached -- I'll remember that.         That technique looks excellent, but unfortunately I need to support Mac OS X versions earlier than Lion, so I only have OpenGL 2.1 available.  If you have any suggestions that could work for OpenGL 2.1, that would be great.  I'm interested in your idea about having the device create the textures.  How would you implement this?  Would you just create the OpenGL texture object in a function in the GraphicsDevice class and then pass the GLuint into the Texture constructor? Or something else?         Yeah, that's what I thought.  Do you have any pointers on how I could approach re-designing this so that I wouldn't need to use glGet?   Thanks!
  • 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!