Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

154 Neutral

About IncidentRay

  • Rank
  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. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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; };
  10. 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.
  11.   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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?
  • 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!