StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
15414523
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-03-14T16:12:48.150
FavoriteCount
0
LastActivityDate
2013-03-14T16:12:48.150
LastEditDate
LastEditorUserId
0
OwnerUserId
2170447
ParentId
15384968
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
The solution is actually accepting that there are limits on how far you can optimize. Solving the gap problem will only cause the following to be introduced: <ul> <li>If statements (branches) to handle the data exceptions (entities which are missing component).</li> <li>Introducing holes meaning you may as well iterate lists randomly. The power of DoD is that all data is tightly packed and ordered in the way it will be processed.</li> </ul> What you may want to do: Create different lists optimized for different systems / cases. Every frame: copy the properties from one system to another system only for the entities that require it (which have that specific component). Having the following simplified lists and their attributes: <ul> <li>rigidbody (force, velocity, transform)</li> <li>collision (boundingbox, transform)</li> <li>drawable (texture_id, shader_id, transform)</li> <li>rigidbody_to_collision (rigidbody_index, collision_index)</li> <li>collision_to_rigidbody (collision_index, rigidbody_index)</li> <li>rigidbody_to_drawable (rigidbody_index, drawable_index)</li> </ul> etc... For the processes / jobs you may want the following: <ul> <li>RigidbodyApplyForces(...), apply forces (ex. gravity) to velocities</li> <li>RigidbodyIntegrate(...), apply velocities to transforms.</li> <li>RigidbodyToCollision(...), copy rigidbody transforms to collision transforms only for entities that have the collision component. The "rigidbody_to_collision" list contains the indices of which rigidbody ID should be copied to which collision ID. This keeps the collision list tightly packed.</li> <li>RigidbodyToDrawable(...), copy rigidbody transforms to drawable transforms for entities that have the draw component. The "rigidbody_to_drawable" list contains the indices of which rigidbody ID should be copied to which drawable ID. This keeps the drawabkl list tightly packed.</li> <li>CollisionUpdateBoundingBoxes(...), update bounding boxes using new transforms.</li> <li>CollisionRecalculateHashgrid(...), update hashgrid using bounding boxes. You may want to execute this divided over several frames to distribute load.</li> <li>CollisionBroadphaseResolve(...), calculate possible collisions using hashgrid etc....</li> <li>CollisionMidphaseResolve(...), calculate collision using bounding boxes for broadphase etc....</li> <li>CollisionNarrowphaseResolve(...), calculate collision using polygons from midphase etc....</li> <li>CollisionToRigidbody(...), add reactive forces of colliding objects to rigidbody forces. The "collision_to_rigidbody" list contains the indices from which collision ID the force should be added to which rigidbody ID. You may also create another list called "reactive_forces_to_be_added". You can use that to delay the addition of the forces.</li> <li>RenderDrawable(...), render the drawables to screen (renderer is just simplified).</li> </ul> Of course you'll need a lot more processes / jobs. You probably want to occlude and sort the drawables, add a transform graph system between the physics and drawables (see Sony presentation about how you may do this) etc. The execution of the jobs can be executed distributed over multiple cores. This is very easy when everything is just a list as they can be divided into multiple lists. When an entity is being created the component data will also be created together and stored in the same order. Meaning the lists will stay mostly in the same order. In the case of the "copy object to object" processes. If the skipping of holes really is becoming a problem you can always create a "reorder objects" process which will at the end of every frame, distributed over multiple frames, reorder objects into the most optimal order. The order which requires the least skipping of holes. The skipping of holes is the price to pay to keep all lists as tightly packed as possible and also allows it to be ordered in the way it is going to be processed.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POData oriented access to several indexed data arrays
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USMike Machuidel
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.