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!


jmakitalo

Member Since 05 Apr 2006
Offline Last Active Mar 04 2015 02:47 PM

Posts I've Made

In Topic: Entity-Component Confusion

13 February 2015 - 08:06 AM


What confuses me though is how do you store the component in an efficient way? My understanding of the entity-component system is that it simplify things, and reduces cache misses, right?

 

I have similar topic http://www.gamedev.net/topic/662559-entity-component-system-data-locality-vs-templates/ and I was directed to this bitsquid blog that I found very helpful. Making a manager for each type of component avoids problems with storing inhomogeneous data in arrays. I also liked their idea not to constrain the component managers that much. Different type of components may benefit from different type of component storage and entity<->component indirection. I personally would create base component manager classes for some most typical situations to avoid code dublication.

 


I.E. When a player shoots a ship, and the ship is now dead. It should be removed. So it's flagged as such, and at the end of the loop, it gets removed from the list, and everything gets shifted down to keep data clustered tightly.

 

Use the "swap and resize": move the last item to the place of the removed one and reduce the array size by one. Of course if entities refer directly to component arrays, the one moved component will no longer point to the correct entity. You need to add a layer of indirection: one array stores components, the other maps entities to the components.


In Topic: Entity component system: data locality vs. templates

13 February 2015 - 07:54 AM


The way I deal with this in dustArtemis is much like Artemis, each entity has a bit set, each component type has an index, you check if an entity has a component by testing:

 

This limits entities of having only one component of a given type. Not necessarily that bad constraint, but kind of unnecessary.

 


Then components are essentially stored as arrays of pointers

 

At least in C++, I would try to achieve data locality and avoid such storage.

 


Component c = cmpArray[entityID];

 

This is reasonable, but you need to have space for all entities in all component arrays. Some components may be used by only a few entities.

 

I'm currently experimenting with an approach inspired by the bitsquid blog linked above, where component managers may implement different types of component<->entity indirections. For widely used components, the manager stores a vector of indices to components. For infrequently used components, the manager uses a map. I implemented base component manager classes for these two cases, but nothing prevents component managers from implementing some different indirection.


In Topic: Projection into Spherical Harmonic Basis

25 January 2015 - 12:08 PM


I am picking N random direction samples, interpolating between the closest 3 of the original measured samples, and then integrating over those instead. It seems to produce much better results and convergence.

 

This is strange. If you just interpolate the original measurement points to create more data, you are creating data that is linearly dependent on the original data. No new information should emerge.

 

Did you take the original measurements at the correct quadrature points, i.e., the points where the integration weights are defined? Keep in mind that you don't "integrate over sample points". Surface integral over a set of isolated points vanishes. What you do is make and approximation to a surface integral in the form

 

int_S f( r ) dS = sum_n w_n*f(r_n)

 

where w_n are the weights and r_n the nodes of the quadrature rule.

 

For 2D surface integrals with smooth surface S, you can use the Fubini's theorem to write your spherical integration as

 

int_0^pi int_0^2pi f(theta, phi)*sin(theta) dphi dtheta = sum_n sum_m w_n*w_m*f(theta_n, phi_m)*sin(theta_n) + E

 

where E is some error that we are willing to neglect and the weights and nodes are now for some integration over finite 1D interval (trapezoidal, Simpson's, Gaussians, etc.)

 

The nodes theta_n and phi_m should coincide with your measurement points. If you can choose your measurement points, you should choose

them to match the nodes of the quadrature rule.


In Topic: Quick texture array question

21 January 2015 - 03:07 PM


Which doesn't work. The shadow map doesn't seem to be accessible. Again, the texture array on its own is working fine, and the shadow map, when bound with individual textures, works fine as well. But, when I try to use the shadow map, while using an array for the other textures, things aren't rendering properly. To be clear though, there are no errors reported, but the shader is clearly not reading the shadowmap correctly.
 
If this code looks relatively fine, then my issue is likely elsewhere.

 

The code looks fine to me as far as I can interpret it without further information. Are you sure that your uniform ids are properly resolved? Are you binding the shaders before calling glUniform etc?


In Topic: Resource Manager Design

21 January 2015 - 03:28 AM


Nono, I don't store the frames parameter in Resource.

This map is defined in Resource:

std::map m_parameters;

Then each class that derive from Resource, needs to implement an initialise() function which has to at least do one thing to work with the ResourceManager: set the "class" to the class name. Read my other reply again.



Either way; I disagree that it's wasteful, because it's not like you'll have thousands of resources loaded at once. Even then, it's not that bad. We're talking some kilobytes in total.

I'll agree there probably is a better way to do it though.

 

Ok, replying to this goes somewhat off topic, but this is very timely for me.

 

So you do store the parameters as name-value pairs like I suggested. It's a map. I guess that the Parameter class stores some union of admissible parameter types? Anyway, if you don't cache the values to some C++ types, each time you request a parameter from a resource you will need to make O(logN) lookup of the map, performing string comparisons. This may be neglible in some simple 2D game with a few resources, but I would not use it for rendering complex 3D scenes with hundreds of resources (with multitude of parameters) accessed each frame.

 

Storing the names may not take more than a few kilobytes, but usually such degeneracy suggests that the design could be improved.


PARTNERS