Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Nov 2004
Offline Last Active Nov 27 2015 02:35 PM

Posts I've Made

In Topic: Sorting draw calls when stages are executed multiple times

18 April 2013 - 11:34 PM

How do you generate the indices that point to each render item? I'm assuming you would need to have some way to uniquely identify render items?


If we look at a Light Pre-Pass rendering pipeline, the first stage would require the queue to be sorted by depth and the material stage sorted by material/shader/state BUT both stages utilize the same cull results (unless my understanding is incorrect). How is this handled? We have two different sort orders that use the same set of culled objects.

In Topic: Sorting draw calls when stages are executed multiple times

18 April 2013 - 12:12 AM

I figured I'd jump in on this thread as I have a similar question.


I'm working on a data-driven renderer (similar to Horde) where you can define a rendering pipeline via a script.




a) a set of visible objects determined from the culling phase




b) a pipeline can have multiple stages each possibly requiring the objects sorted differently (back-to-front, front-to-back, material/state changes, etc)


What is the best way to perform sorting?


To me it'd seem that each stage with a sort option specified would have to loop through each object/drawcall/renderitem and generate a new sort key before sorting. That or each object would need to be filled with all necessary information so that custom sort functions could be written and choose what info to sort on instead of just doing the simple default integer sort using a key value.


Maybe I'm going about this completely wrong. Some insight would be great!

In Topic: Multiple Inheritance vs. Composition

09 October 2012 - 04:47 PM

I kind of agree with you but for practicality sake I chose to inherit Component/Property containers because an entity is a collection of components and properties. It doesn't re-implement the methods of the containers (though it could but isn't necessary). I figured it'd be better than having wrap all the collection methods ie:

class Entity : public Serializable, public NetworkObject

	 void AddComponent(Component* c) { components.AddComponent©; }

	 ComponentContainer components;

Entity e;

In Topic: AES Encrypting and Decrypting

25 September 2012 - 07:22 PM

I'm not familiar with java's encryption routines but I recently did some work with AES in PHP and iOS and one thing I had to do to get things working was to pad the message using PKCS7 padding before I encrypted it and remove the padding after decrypting. In your code I don't see you doing any padding but if java does this padding for you then disregard this.

In Topic: Complex Components in Entity Systems

25 September 2012 - 07:04 PM

There are a number of ways to implement a component based entity system. The system I have been working on works a bit like this:
  • Components provide the data/properties/attributes and can provide behavior.
  • Components register their properties with the parent entity so other components can access common data (eg. physics/render both need access to transform data).
  • Sub-systems manage and update the components.

For the majority of things you will already have a bunch of sub-systems that are part of the core engine (physics, rendering, animation, etc) and so a lot of your components plug into these systems nicely.

For your spaceship/bullet example you could try tackle the problem in a more generic way. What makes up a bullet? In the most basic sense it has some kind of visual representation along with some physical properties. You could therefore create a bullet entity that is made from a couple of components:
  • TransformComponent
  • PhysicsCapsuleComponent
  • SpriteComponent or ModelComponent
For the above, the TransformComponent is there to provide the world/local transform that the physics/render systems can read/write too. The PhysicsCapsuleComponent is managed by the physics sub-system and it's attributes define the physical properties (velocity, acceleration, friction, collision mesh, etc) which the physics sub-system uses to simulate the object. The SpriteComponent or ModelComponent provides the visual representation and it is managed by the rendering sub-system.

The rendering components can be broken down even further but I find in most cases your components will generally map to an existing higher level sub-system, you just need to think in general terms of what actually makes up the object you're trying to create.