You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow per-sprite data (that are passed with each Draw() call) to be easily passed into effects -- without beginning new batches or needing to use DrawUserIndexedPrimitive(). The user will be able to access the per-sprite data in the Vertex Shader of the effect, and can therefore easily perform different sub-effects per-sprite. Having extra data per vertex will increase batch item size, but the user will be able to choose whether or not they need to use this new functionality (by using an old overload or setting the new overload's parameter to its default value).
Possible Solution
Create an overload SpriteBatch.Draw(OTHER_OLD_PARAMS, params float[] customFloats). The framework throws an error if customFloats.Length exceeds some threshold (so that the user cannot put in a float[] of length 100000 for fun) or if the given customFloats array is null.
A possible implementation of the new SpriteBatch.Draw overload might be one of the following (I only dug around the MonoGame code a little bit, so these may be impossible):
There would be a few new MonoGame internal structs created, each representing a custom vertex of a set number of floats (e.g., a VertexPositionColorTextureF1, VertexPositionColorTextureF2, VertexPositionColorTextureF3,... that supports 1, 2, and 3 extra floating-point data on vertices respectively). The new structs would extend IVertexType. The new Draw overload adds one of these into the batch depending on the length of customFloats.
A new MonoGame internal struct VertexPositionColorTextureSingles : IVertexType can be created that dynamically changes its VertexDeclaration size based on the number of extra floating parameters to the Draw overload.
If the SpriteBatch must send batches of vertices of the same struct size, then the batcher could either send the batch of vertices based on the maximum Length of customFloats stored in the batch or instead, add a new optional parameter to SpriteBatch.Begin() that specifies the number of extra floats to carry per vertex/Draw call.
Either way, this solution would achieve the goal of easily sending custom data to each effect per sprite, essentially allowing different effect parameters in a single batch.
Motivation
2D games that need to use multiple effects may find beginning a new sprite batch for each effect very slow (this is what happened in my game). A way to achieve multiple effects with fewer sprite batches is to write a master effect that is a collection of all effects in one single effect file. A custom vertex (that extends IVertexType) can then be used to send an extra per-vertex floating-point identifier variable to the vertex shader, which can then choose to apply one or more of the sub-effects of the master effect based on the received identifier. Right now, there is no way that I know of that allows custom vertices in SpriteBatch. To achieve the sub-effect selection described above, GraphicsDevice.DrawUserIndexedPrimitives() would be used, meaning that the user would need to remake the SpriteBatch's sorting functionality, matrix calculations, etc.
The user may also wish to send other per-sprite data to the vertex shader. Beginning a new SpriteBatch to set uniform shader variables for each sprite that has a different shader data or manually drawing the object vertices with DrawUserIndexedPrimitives() are both unattractive options, as mentioned above.
The text was updated successfully, but these errors were encountered:
Intent
Allow per-sprite data (that are passed with each
Draw()
call) to be easily passed into effects -- without beginning new batches or needing to useDrawUserIndexedPrimitive()
. The user will be able to access the per-sprite data in the Vertex Shader of the effect, and can therefore easily perform different sub-effects per-sprite. Having extra data per vertex will increase batch item size, but the user will be able to choose whether or not they need to use this new functionality (by using an old overload or setting the new overload's parameter to its default value).Possible Solution
Create an overload
SpriteBatch.Draw(OTHER_OLD_PARAMS, params float[] customFloats)
. The framework throws an error ifcustomFloats.Length
exceeds some threshold (so that the user cannot put in afloat[]
of length 100000 for fun) or if the givencustomFloats
array isnull
.A possible implementation of the new
SpriteBatch.Draw
overload might be one of the following (I only dug around the MonoGame code a little bit, so these may be impossible):There would be a few new MonoGame internal
struct
s created, each representing a custom vertex of a set number of floats (e.g., aVertexPositionColorTextureF1
,VertexPositionColorTextureF2
,VertexPositionColorTextureF3
,... that supports 1, 2, and 3 extra floating-point data on vertices respectively). The new structs would extendIVertexType
. The newDraw
overload adds one of these into the batch depending on the length ofcustomFloats
.A new MonoGame internal
struct VertexPositionColorTextureSingles : IVertexType
can be created that dynamically changes itsVertexDeclaration
size based on the number of extra floating parameters to theDraw
overload.If the SpriteBatch must send batches of vertices of the same struct size, then the batcher could either send the batch of vertices based on the maximum Length of
customFloats
stored in the batch or instead, add a new optional parameter toSpriteBatch.Begin()
that specifies the number of extra floats to carry per vertex/Draw
call.Either way, this solution would achieve the goal of easily sending custom data to each effect per sprite, essentially allowing different effect parameters in a single batch.
Motivation
2D games that need to use multiple effects may find beginning a new sprite batch for each effect very slow (this is what happened in my game). A way to achieve multiple effects with fewer sprite batches is to write a master effect that is a collection of all effects in one single effect file. A custom vertex (that extends
IVertexType
) can then be used to send an extra per-vertex floating-point identifier variable to the vertex shader, which can then choose to apply one or more of the sub-effects of the master effect based on the received identifier. Right now, there is no way that I know of that allows custom vertices in SpriteBatch. To achieve the sub-effect selection described above,GraphicsDevice.DrawUserIndexedPrimitives()
would be used, meaning that the user would need to remake the SpriteBatch's sorting functionality, matrix calculations, etc.The user may also wish to send other per-sprite data to the vertex shader. Beginning a new
SpriteBatch
to set uniform shader variables for each sprite that has a different shader data or manually drawing the object vertices withDrawUserIndexedPrimitives()
are both unattractive options, as mentioned above.The text was updated successfully, but these errors were encountered: