Component Support

  ... the case you feel the need for a new feature or want to submit one.

Component Support

Postby dallonf » Sat Nov 27, 2010 6:10 pm

Who here has used Unity 3D? In that engine, they have a component model where a GameObject is just an empty container for components, and these components handle rendering, physics, and game logic.
I think that this should be implemented in AndEngine, especially for rendering.

For example, say I have an AnimatedSprite, and for some reason in the game, it has to change visual state, and that new state is in another TextureRegion. Right now I'd have to create another AnimatedSprite and replace the current one, or worse, if it was not a TiledTextureRegion, I'd have to replace it with a Sprite!

What I'd like to be able to do is something like this:
Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. entity.setRenderer(new SpriteRenderer(otherTextureRegion))
Parsed in 0.011 seconds, using GeSHi 1.0.8.4


I'd be happy to try to implement this, but I'm a bit busy right now and wanted to get the idea out there if somebody else wanted a crack at it.
dallonf
 
Posts: 18
Joined: Fri Oct 01, 2010 3:41 am

Re: Component Support

Postby Nicolas Gramlich » Sun Nov 28, 2010 2:09 pm

Hi,

basically this would be extending the already existing UpdateHandler mechanism to sth like a RenderHandler, right :?:

The good thing about this would be that you wouldn't have to change class-hierarchy anymore when deciding to go from Sprite to AnimatedSprite. :check: Also this would kind of make the GLShape class superfluous, as it would be part of the Renderer Hierarchy then. :check: The OpenGL specific applyTransformation/Rotation/Translation/etc... would not be a part of the Game-Objects themselves anymore. :check: Also this allows more possibilities as one can write a custom RenderHandler, that can be optimized to the current situation, without touching the Shape class itself. :check:

On the other hand, this would be a little "harder to understand" in the beginning :exclamation: , but: while this change would make the Sprite and Animated Sprite class superfluous, we could remain them while providing constructors that keep compatibility with older versions of AndEngine. :check:
Also, as the RenderHandlers can no more access the private/protected fields of the Shape class, everything needs to be done with Getters, what might cause a noticeable performance-impact. :exclamation:

All in all this still would be a pretty deep cut in AndEngine with probably a lot of things to be changed. :?

Best Regards,
Nicolas
Nicolas Gramlich
Site Admin
 
Posts: 1734
Joined: Mon Jun 07, 2010 6:20 pm
Location: Schriesheim, Germany

Re: Component Support

Postby dallonf » Sun Nov 28, 2010 5:56 pm

Yeah, it would be a pretty huge change. When I get a chance, I'll have to prototype this and see how it works, especially regarding the performance impact you noted.
dallonf
 
Posts: 18
Joined: Fri Oct 01, 2010 3:41 am

Re: Component Support

Postby Nicolas Gramlich » Sun Nov 28, 2010 7:08 pm

Hi,

I started implementing this in a local branch and what I think I will not like about this is that we would have something like this in the end, when we would i.e. animate Shape that has a AnimatedSpriteRenderer applied.

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. final Shape shape = new Shape(...);
  2. shape.setRenderer(new AnimatedSpriteRenderer(...));
  3. // ...
  4. ((AnimatedSpriteRenderer)shape.getRenderer()).animate(...);
Parsed in 0.010 seconds, using GeSHi 1.0.8.4

The cast just doesn't really feel natural anymore :(

Still we could have (as I said above) an AnimatedSprite class that would have the same methods as before, but simply pass them through its internal AnimatedSpriteRenderer.

Are we still on the same track here :?:

[Edit]Another thing that came up is that i.e. an AnimatedSpriteRenderer would not only implement IRenderer but also needs to implement IUpdateHandler. Again this could happen transparently in the AnimatedSprite convenience class, but feels a little weird. :| [/Edit]


[Edit2]Things are getting quite difficult :| Some questions that rise up:
  1. What class will be the correct location for the VertexBuffer :?:
  2. What about Lines, as they have additional basic information (X2 and Y2 coordinates). Store that in the LineRenderer too :?:
  3. Should the color be a part of Shape or the Renderers :?:
  4. Should the blendfunction be a part of Shape or the Renderers:?:

It feels like we would still need subclasses of Shape, like the current RectangularShape/Line/Text, to still make this work. But by doing so we didn't really gain much, did we :?: :(
[/Edit2]

Best Regards,
Nicolas
Nicolas Gramlich
Site Admin
 
Posts: 1734
Joined: Mon Jun 07, 2010 6:20 pm
Location: Schriesheim, Germany

Re: Component Support

Postby dallonf » Mon Nov 29, 2010 4:45 pm

Hmmm, maybe I'm approaching this the wrong way. I wonder if the other "Sprite Composition" suggestion would get the job done. Example: I want to change a sprite to another rendering method. I have a "PlayerEntity extends ContainerEntity" (assuming that ContainerEntity will be the name of an Entity that can contain other Entities):
Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. playerEntity.setVelocityX(200);
  2.  
  3. playerEntity.removeEntity(lastSprite);
  4. playerEntity.addEntity(newSprite)
  5.  
  6. //playerEntity will keep velocity, only its visible component changed.
Parsed in 0.010 seconds, using GeSHi 1.0.8.4
dallonf
 
Posts: 18
Joined: Fri Oct 01, 2010 3:41 am

Re: Component Support

Postby Nicolas Gramlich » Mon Nov 29, 2010 11:06 pm

Hi,

yes, that would result in a very similar possibilities.
I've been planning to add the "addEntity"/"removeEntity" at the lowest possible level in the Entity-Hierarchy (probably in the Shape class) because there needs to transform the coordinates for i.e. the TouchEvents.

Best Regards,
Nicolas
Nicolas Gramlich
Site Admin
 
Posts: 1734
Joined: Mon Jun 07, 2010 6:20 pm
Location: Schriesheim, Germany


Return to Features

Who is online

Users browsing this forum: No registered users and 6 guests