Yckx's GameDev Journal
While typing the above, I thought of doing it in the MeshCache. It makes decent sense--the Cache creates, stores and fills requests for mesh data. It will require some small interface redesign, but it's doable. Why didn't I think of this before? I wish I'd come to this realization before 1am. My coding life is filled with eureka moments immediately after powering down the pc or as I'm turning out the light. Or even moments before I would have fallen asleep had the epiphany not occurred. And I'm still working on resuming a normal sleep schedule; so while I could stay up and implement it (I'm exhausted by my damnable sleep patterns, but not really feeling tired at the moment), I really should take a sedative and go to bed.
There's (almost) always tomorrow ;)
And to be honest, I don't care that it's taken me a while. I'm having fun, I'm happy and satisfied with the improved quality of (most of) my code, and I have mo deadline to meet. Sure, I'd love to see this project reach a completed state, but there are days when it feels like working on DRON is the only thing keeping me focused enough to maintain mental stability. None of my other hobbies or interests currently provide that comfort, so I look to the eventual completion of this project with some small trepidation ;)
I still need to get rid of that ungodly flat shader. That's high on my list, but I also want to get the maze mesh into a default buffer since it doesn't need to be updated per frame. Also, I'd like to get scripting set up so that I can throw the maze definition parsing (it's defined as a char string for easy editing) and maze generation code into a Lua script.
The below screenshot doesn't look like much, but it shows a few things:
The active GameState passes a std::vector of Entities to the Renderer, which sorts all the entities with a RenderableComponent into batches, and then renders each batch (currently with a crappy flat-color shader). Color and transformation are instanced data. There are multiple instances of two meshes: a straight wall section and a right-angle wall section. One wall section is colored differently, and the bottom wall section is non-uniformly scaled to stretch from one angle to the other.
Eventually I'll transform the maze bits once at the beginning and store the transformed data in a larger buffer, since it's static. But now it serves a useful purpose letting me test the Renderer changes as I make them.
I wish I were more productive with my time, and had more time to spend, but I've decided to choose sedatives over coding on my sleepless nights (in the interest of promoting good mental health), and my days are surprisingly filled with other things that need to be done while the rest of the world is predisposed to social interaction.
It's not a complete refactor yet--there are still a couple vertex buffers I need to deal with, and some minor bits of the draw routine. But I'm pleased with it. Also, there's some DirectXMath library stuff still going on in the Renderer class that I'm not sure if I want to try to encapsulate or not. I'd like to be able to completely encapsulate/abstract away DrectX from the Renderer class, but I'd just have to replace it with another math library. I'm not convinced it's worth the effort.
I hope to have something worthy of screenshotting soon....
[source lang="cpp"]Entity e = entity_system.CreateNewEntity();entity_system.AttachComponent( e, COMPONENT_XFORM );/* e can now have position, scale and rotation, but how to initialize it? It * feels kludgy to dispatch a message or fire an event *after* * creating/attaching the component to initialize it, so I'm thinking of adding * a parameter to AttachComponent() to pass a struct of initialization data. * I don't really want to derive all component data structs from a base type, * but templates don't feel right either. Le sigh... */[/source]I guess I'll spend some time pondering my approach.
For the moment, I've changed my approach somewhat, to this:
[source lang="cpp"]Entity entity = entity_system.CreateNewEntity();BaseComponent* bc = entity_system.CreateComponent( COMPONENT_RENDERABLE );dynamic_cast< RenderableComponent* >( bc )->SetData( data );entity_system.AttachComponent( test_entity, bc );[/source]I don't really like the idea of handing out pointers to components, but it is workable enough for me to move forward until I can come up with a cleaner solution. I guess what I really need to do is something like entity_system.CreateAndAttachComponent( entity, COMPONENT_TYPE, component_type_data_struct ). After thinking about it, it really seems the cleanest way from an interface perspective. Unless someone has a better idea.
But it's 1a.m. and I really need to try to resume a more normal sleep schedule or I'm going to sleep through my early morning Important Doctor's Appointment on Monday. So no more coding for me tonight
There's a reason the guys on the fora tell newbs to start with Pong. But I'm stubborn and I'm having fun, so fie on all detractors
And in the spirit of starting over:
I've taken a first pass at an entity/component system. I've neither written nor used such a system before, and while this code compiles and preliminary tests produce expected results, I suspect there may be pitfalls in my design. Also, my brain is a little fried at the moment.
The approach is that entities are integer ids, components only contain data, and that other systems (logic, input, collision, etc.) use and act on components relevant to their purview. I've liberally adopted code from and been inspired by numerous websites and -pages over the last couple days, and I'm too close and too frazzled to it to spot trouble spots. If you react with a WTF please let me know. Thank you.
ComponentTypes.hpp, incomplete--just a few to test out the system
XformComponent.hpp, sample component