Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


IncidentRay

Member Since 23 Dec 2012
Offline Last Active Apr 22 2014 01:18 AM

Posts I've Made

In Topic: single responsibility principle in practice

08 June 2013 - 01:37 AM

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?


In Topic: Class instances gone wrong!

21 March 2013 - 10:52 PM

template void safe_delete(T* x) { delete x; x = NULL; }

 

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


In Topic: Women vs Tropes in Video Games

10 March 2013 - 12:57 PM

Why turn this at the extreme case ? For what I know most fathers and mothers say that the best thing that happens in their live is the coming of their little babies. So yes the live is more fun when there are men and women. 

 

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


In Topic: Women vs Tropes in Video Games

09 March 2013 - 02:54 AM

 

We need to be different, and as long as those differences add up to the same overall value—which they do—then why all the fuss?

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.

 

Women, want to get revenge on the men?
Disappear from the Earth.  That would drive the men absolutely batshit crazy.  A sign of females’ value to men despite any perceived objectification.

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?


In Topic: Advanced Render Queue API

13 January 2013 - 06:12 PM

First up, if you want to research this, the technique of loading your runtime data structures straight out of a file with no (or little) on-load processing is usually called "load-in-place" or "in-place memory", or something similar. There's a gamasutra article here.
 
For pointers within a particular asset (e.g. a pointer from a model header to an array of state-group pointers, to a state-group) I use the Offset (relative address) and Address (absolute address) classes in this header -- i.e. I don't use actual pointers.

 

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.

 

Yeah, my states are variable size, and the group-header doesn't contain the actual offset of each state. Therefore to iterate through the group, you have to inspect each state in a linear order, and determine the current state's size to know how far to jump ahead to find the next state. The bitfield does allow you to halt this iteration early if you know that you've already inspected all of the 'interesting' states in the group though.
 
As an alternative, you could allocate an array of size numStates in/after the header and write the offset of each state into this array. If you then ordered the states by their ID value, you'd be able to quickly jump to a particular state that you're interested in without iterating through each one.

 

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.


PARTNERS