@chronozphere
Great idea with the ComposeMatrix and user configurabe update methods, i will probably go this route.
Yeah that might be better to keep that as a implement-if-needed thingy.Originally Posted by chronozphere
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.Originally Posted by Traveler
Is this solved with some kind of visitor pattern or what? Id love to hear more about this
Among othersOriginally Posted by Traveler
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.Originally Posted by Traveler
Yeah that was the idea that you can load in the constructor and is serialized in the sprite file, basically a Map<String, Variant>.Originally Posted by Traveler
Originally Posted by TravelerThe 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.Originally Posted by Traveler
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.Originally Posted by Traveler
Bookmarks