Sprites and Entities

[Andreaz]

@chronozphere

Great idea with the ComposeMatrix and user configurabe update methods, i will probably go this route.

That would be great, allthough i think that properties like color should not always be inherited. I'd give the programmer a way to prevent the parent from setting the child's color.

Yeah that might be better to keep that as a implement-if-needed thingy.

Regarding sprites. There are advantages for both suggestions I can agree with. From personal experience I found the method in the 'old' Phoenix insufficient. I quickly resorted to my own version of a 'spriteengine' where I had more control over animations vs object states, as well as a different way of loading textures for game objects.

Seeing how I eventually wrote my own sprite classes and even added tools to support those, I would now rather have a sprite object with separate texture objects. Meaning every sprite still has a draw function, but the texture object defines how it gets drawn. Hmmm, I think that is even different from what you are suggesting right now

This sounds quite interesting, so you're saying that you separated the rendering of sprites completely from the sprite engine? In my world a texture is basically a bunch of pixels and settings and knows nothing about rendering itself.

Is this solved with some kind of visitor pattern or what? Id love to hear more about this

# Parent->Child relationship with relative transformations
That's cool, so we can use something like a particle trail on a spaceship.

Among others

# Plugins instead of inheritance.
I'm not yet convinced yet about the advantages of plugins. Inheritance is just too cool

The plugins solves the "Has A" property of a sprite. For instance TFerrari is a TCar witch is inheritance and it has a TPlayerController or TAIController to steer it. Solved with a plugin.

# Sprite properties
How does this work exactly? Are these fixed properties for a sprite object?

Yeah that was the idea that you can load in the constructor and is serialized in the sprite file, basically a Map<String, Variant>.

# Sprite tags
Could be good. But like you said, too vague yet.

# Sprite classes
very interesting, especially the triggersprite!

The trigger sprite might be moved to the TileEngine, and not be a sprite per say, as in you can define a rectangle in the editor and then create a collision object that does something when it collides.

As always, looking very much forward to the next update. How long do think for a more final version?

Well the ground work is there, window handling, rendering and support functions, so those parts is quite final, some polishing mostly. But ten its a question of how much features to add, tiles, particles, collisions, sound, lighting, shaders, d3d renderer etc.