feat(flame_3d)!: Introduce RenderContext to make GraphicsDevice focused#3872
feat(flame_3d)!: Introduce RenderContext to make GraphicsDevice focused#3872wolfenrain wants to merge 11 commits intomainfrom
RenderContext to make GraphicsDevice focused#3872Conversation
…3d)/introduce-render-context
…3d)/introduce-render-context
wolfenrain
force-pushed
the
feat(flame_3d)/introduce-render-context
branch
from
8b014e2 to
fd3d22c
Compare
| /// render directly to a [GraphicsDevice] instead of the regular rendering. | ||
| /// {@endtemplate} | ||
| class World3D extends flame.World with flame.HasGameReference { | ||
| class World3D extends flame.World with flame.HasGameReference<FlameGame3D> { |
There was a problem hiding this comment.
does it make sense for it to declare T extends FlameGame3D, HasGameReference<T>, in case a user wants to extend World3D and also have a ref to their own game class?
| @@ -1,21 +1,37 @@ | |||
| // ignore_for_file: avoid_redundant_argument_values | |||
There was a problem hiding this comment.
do we need to disable it? can we just fix
There was a problem hiding this comment.
No, I decided to disable it be quiet explicit how our render config is setup
If flutter_gpu ever changes the values we wouldn't know on time until rendering goes weird
| j--; | ||
| } | ||
| _drawPool[j + 1] = entry; | ||
| } |
There was a problem hiding this comment.
isnt there any built-in sort-in-place-by algo on dart?
| if (_drawCount >= _drawPool.length) { | ||
| _drawPool.add(_DrawEntry()); | ||
| } | ||
| _drawPool[_drawCount] | ||
| ..distance = dx * dx + dy * dy + dz * dz | ||
| ..object = object; | ||
| _drawCount++; |
There was a problem hiding this comment.
I wonder if we could encasulate a generic Pool class that handles minimal allocation while you can just do set/get
There was a problem hiding this comment.
also we never de-allocate after increasing the size. a pool class could also handle that through some heuristic
| // values. | ||
| final dx = _cameraPosition.x - worldTransform.storage[12]; | ||
| final dy = _cameraPosition.y - worldTransform.storage[13]; | ||
| final dz = _cameraPosition.z - worldTransform.storage[14]; |
There was a problem hiding this comment.
are there no rows/col accessors that return a pre-allocated view over storage? 12-13-14 feel a bit arbitrary but if that is what we need to avoid vector3 allocation then it is what it is
There was a problem hiding this comment.
you are right, we do have .mNN getters I believe, didn't think about that!
| (-viewport.virtualSize / 2).toOffset() & | ||
| Size(viewport.virtualSize.x, viewport.virtualSize.y), | ||
| Offset.zero & renderSize, | ||
| Offset(-size.x / 2, -size.y / 2) & Size(size.x, size.y), |
There was a problem hiding this comment.
this could just be (-size / 2) & size right? (assuming size is Vector2)
There was a problem hiding this comment.
Yes but it would compute another vector so we wouldn't gain much
However we should just do a Rect.fromLTWH here honestly, that's the cheapest
luanpotter
left a comment
luanpotter
left a comment
There was a problem hiding this comment.
LGTM overall. left some considerations!
2 participants
Description
Introducing a
RenderContext3Dthat abstracts away actual rendering from theGraphicsDevice. This simplifies both binding, rendering and applying shaders in a way that is more sensible for game developers.We hide away the complexity of the
GraphicsDevicewhile still allowing complexity for those who need it.Checklist
docsand added dartdoc comments with///.examplesordocs.Breaking Change?
Related Issues