1 | #ifndef NX_PHYSICS_NXUSERENTITYREPORT
|
---|
2 | #define NX_PHYSICS_NXUSERENTITYREPORT
|
---|
3 | /*----------------------------------------------------------------------------*\
|
---|
4 | |
|
---|
5 | | Public Interface to NovodeX Technology
|
---|
6 | |
|
---|
7 | | www.novodex.com
|
---|
8 | |
|
---|
9 | \*----------------------------------------------------------------------------*/
|
---|
10 | /** \addtogroup physics
|
---|
11 | @{
|
---|
12 | */
|
---|
13 |
|
---|
14 | #include "Nxp.h"
|
---|
15 |
|
---|
16 | /**
|
---|
17 | \brief The user needs to pass an instance of this class to several of the scene collision
|
---|
18 | routines in NxScene.
|
---|
19 |
|
---|
20 | There are usually two ways to report a variable set of entities
|
---|
21 | to the user: using a dynamic array (e.g. an STL vector) or using a callback (called
|
---|
22 | for each entity). The first way is fast, but can lead to dynamic allocations and/or
|
---|
23 | wasted memory when it would just be possible to handle each entity on-the-fly. The
|
---|
24 | second way provides this, but suffers from call overhead. This class combines best
|
---|
25 | of both worlds by reporting a small number of entities to the user at the same time,
|
---|
26 | via a callback (the onEvent function). This number of entities is user-defined, hence
|
---|
27 | it is possible to fallback to the usual array or callback behaviours by adjusting it.
|
---|
28 | (Please refer to the comments below for details).
|
---|
29 |
|
---|
30 | Returning true lets the SDK continue the collision query, returning false stops it.
|
---|
31 |
|
---|
32 | NxUserEntityReport usage:
|
---|
33 |
|
---|
34 | A typical collision function will look like this:
|
---|
35 |
|
---|
36 | NxU32 someCollisionFunc(NxU32 nbEntities, const Entity** entities, NxUserEntityReport<const Entity*>* callback);
|
---|
37 |
|
---|
38 | You have multiple ways to use this:
|
---|
39 |
|
---|
40 | 1) Using a fixed-size array in your app. This can happen for example when you query
|
---|
41 | some entities, and you already have a buffer big enough to handle all of them. In
|
---|
42 | that case you don't have to worry about dynamic allocations or callbacks, just do:
|
---|
43 |
|
---|
44 | // maxEntities = size of entity buffer
|
---|
45 | // entityBuffer = a buffer large enough to contain all entities
|
---|
46 | NxU32 nbEntities = someCollisionFunc(maxEntities, entityBuffer, NULL);
|
---|
47 |
|
---|
48 | If the buffer is not large enough, the SDK will keep writing entities to the buffer
|
---|
49 | until it is full, and then return. You might miss some entities in this case.
|
---|
50 |
|
---|
51 | 2) Using a callback. This is the default way to use NxUserEntityReport.
|
---|
52 |
|
---|
53 | // First define your callback object
|
---|
54 |
|
---|
55 | class UserEntityReport : public NxUserEntityReport<Entity*>
|
---|
56 | {
|
---|
57 | public:
|
---|
58 |
|
---|
59 | virtual bool onEvent(NxU32 nbEntities, Entity** entities);
|
---|
60 | };
|
---|
61 |
|
---|
62 | UserEntityReport myReport;
|
---|
63 |
|
---|
64 | // Then later, do the collision calls
|
---|
65 |
|
---|
66 | NxU32 nbEntities = someCollisionFunc(0, NULL, &myReport);
|
---|
67 |
|
---|
68 | In this case, the SDK will report a limited set of entities at the same time
|
---|
69 | (usually 64), through the onEvent() function. The memory used to store
|
---|
70 | those entities is internally allocated on the stack.
|
---|
71 |
|
---|
72 | 3) Using a callback and your own memory buffers. this is the same as the previous
|
---|
73 | version, except you can customize the query by specifying both a memory buffer
|
---|
74 | and a callback:
|
---|
75 |
|
---|
76 | NxU32 nbEntities = someCollisionFunc(maxEntities, myBuffer, &myReport);
|
---|
77 |
|
---|
78 | In this case, entities are reported through the onEvent() function as in case 2),
|
---|
79 | but those differences apply:
|
---|
80 |
|
---|
81 | - the number of entities reported at the same time ("nbEntities" parameter in
|
---|
82 | onEvent) is lesser or equal to "maxEntities".
|
---|
83 |
|
---|
84 | - the memory used to store the entities ("entities" parameter in onEvent) is the
|
---|
85 | same as the user's input buffer ("myBuffer").
|
---|
86 |
|
---|
87 | This 3rd way to use NxUserEntityReport is only provided in sake of flexibility,
|
---|
88 | but should not be needed in most cases.
|
---|
89 |
|
---|
90 | <b>Threading:</b> It is not necessary to make this class thread safe as it will only be called in the context of the
|
---|
91 | user thread.
|
---|
92 |
|
---|
93 | */
|
---|
94 |
|
---|
95 | template<class T>
|
---|
96 | class NxUserEntityReport
|
---|
97 | {
|
---|
98 | public:
|
---|
99 |
|
---|
100 | /**
|
---|
101 | \brief This is called to report a number of entities to the user.
|
---|
102 |
|
---|
103 | 'nbEntities' is the number of returned entities, which are stored in the
|
---|
104 | 'entities' memory buffer.
|
---|
105 |
|
---|
106 | After processing the entities in your application, return true to continue
|
---|
107 | the query (in which case onEvent might get called again), or false to end it.
|
---|
108 |
|
---|
109 | \param[in] nbEntities The number of returned entities, which are stored in the 'entities' memory buffer.
|
---|
110 | \param[in] entities Array of entities.
|
---|
111 | \return true to continue processing, false to end processing.
|
---|
112 |
|
---|
113 | <b>Platform:</b>
|
---|
114 | \li PC SW: Yes
|
---|
115 | \li PPU : Yes
|
---|
116 | \li PS3 : Yes
|
---|
117 | \li XB360: Yes
|
---|
118 | */
|
---|
119 | virtual bool onEvent(NxU32 nbEntities, T* entities) = 0;
|
---|
120 | };
|
---|
121 |
|
---|
122 | /** @} */
|
---|
123 | #endif
|
---|
124 |
|
---|
125 |
|
---|
126 | //AGCOPYRIGHTBEGIN
|
---|
127 | ///////////////////////////////////////////////////////////////////////////
|
---|
128 | // Copyright © 2005 AGEIA Technologies.
|
---|
129 | // All rights reserved. www.ageia.com
|
---|
130 | ///////////////////////////////////////////////////////////////////////////
|
---|
131 | //AGCOPYRIGHTEND
|
---|
132 |
|
---|