Jump to content

  • Log In with Google      Sign In   
  • Create Account

Yckx's GameDev Journal


Posted by , 01 December 2011 - - - - - - · 631 views

I actually did some coding yesterday and today. GitHub says it's been about six weeks since I've committed any changes. I blame Batman: Arkham City, Dark Souls, Assassin's Creed: Revelations and Star Wars: Tho Old Republic beta weekends, and various holiday preparations. I imagine I won't get any more real coding time in until the second week of January. Regardless of any progress I can point to, I'm still continually thinking about it, so it's not abandoned by any means, just simmering on the back burner at the moment.

Decisions, Decisions. And an Aha!

Posted by , 12 October 2011 - - - - - - · 318 views

I've thought all day about how to compile all the maze meshes into one static vertex buffer. Right now, each corner and straight section is its own mesh, which gets transformed every frame. That's 1632 needless transformations. The issue is how and where to create an ID3D11Buffer* initialized with the pretransformed verts of all the wall meshes. The Maze and GFXDevice classes know nothing about each other, and I don't want them to. Passing a vector of entities to the Renderer (which owns the GFXDevice), or vice versa, feels kludgy--I don't want to have to call the renderer when I load a new maze before I actually need to draw it.

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 ;)

Return of the Cage

Posted by , 11 October 2011 - - - - - - · 371 views

It took longer than I'd expected to return to this point, but here I am:

Posted Image

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.


Posted by , 06 October 2011 - - - - - - · 434 views

I've taken a lot of time and care over the rendering code the last several days. I'm also using DirectXMath SIMD optimized datatypes and functions. Memory alignment is something I'd never really dealt with before, and it took a bit of time to get used to, but things are going swimmingly now.

The below screenshot doesn't look like much, but it shows a few things:

Posted Image

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.


Posted by , 01 October 2011 - - - - - - · 457 views

I've spent my coding time the last couple of days refactoring my Renderer class. Up until this point, all the D3D code was in Renderer. It worked, but it was difficult to easily pick out what was going on when looking at the code. So I decided to create wrapper classes for the various D3D11 interfaces I was using. My code is much cleaner now, and I can more easily see and isolate what's being done where.

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....

Design Flaw

Posted by , 21 September 2011 - - - - - - · 329 views

I've realized a design flaw in my entity/component system: I don't have a good way to actually initialize component data! Looky here:
[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 :(

Square One

Posted by , 12 September 2011 - - - - - - · 353 views

I had coded myself into a corner a while back, not being able to effectively manage the ghosts. Also, I didn't like how some sections of my code were working out. It became evident that it would be easier to start over than to try to shoehorn fixes into the existing code. Well, I actually can use much of the existing code, but it was easier to restructure and refactor from scratch rather than directly modifying the existing code. So I started a new project and created a cleaner design, copying and pasting much of the existing code, but leaving behind large chunks of it as well. I also took the time to create an entity/component system, rethink my Lua strategy, and convert my renderer to D3D 11. This is, oh, perhaps the eighth or ninth time I've done this since I came up with the game idea back in 2003.

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 :D

And in the spirit of starting over:
Posted Image

Please Critique my Entity System

Posted by , 08 September 2011 - - - - - - · 465 views

I code in a vacuum. I learned C++ from books and the 'Net, never took a class, and all my friends are humanities types. So I can't get any kind of RW peer review. That's where you come in.

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


January 2017 »

22 232425262728

Recent Entries

Recent Comments

Recent Entries

Recent Comments