Winter Break
So I'm on winter break for the next week. No class. Relaxation. Coding.
I plan on doing as much coding as I can this week. I'm still trying to determine if I want to leave the engine alone and work on game specific stuff, or work on engine stuff. I think I've decided against switching to the virtual implementation that I posted earlier. After AC mentioned the Next-Gen impact it scared me off of virtual stuff a little bit, again. I've been thinking of either leaving it as is or doing what Scott Meyers refers to as the "is-implemented-in-terms-of" model, by allowing the Common class to have a Machine class pointer to the machines implementation. Neither solution seems as elegant as the virtual model did. That model just seems so clean and elegant, I just wish it didn't have the speed trade off that it does. And in gaming code, speed is top priority. If this was just a desktop application the speed issue wouldn't bother me.
On the game front I want to start creating level data. Everything needed for a level (collision information, sprites, etc..) will be bundled into a chunk file. I've already implemented a chunk file system in the engine. It's currently in use by fonts and textures.
Here's a brief description of how a chunk file works. Any binary data I use starts with the same chunk header. It specifies what type of data I'm pointing to, how big it is, and the offset to where it begins. The engine can then parse any binary file I have without knowing what the data it's pointing to is because the initial bytes of any file are all the same. If it doesn't know how to process a certain type of data it can ignore it.
What I need to add is what I call a Package chunk. If a file has more than one chunk in it, then it is considered a package and must have the Package chunk as its first chunk. This will contain a list of all the chunks in the file.
So I need to start by getting Packages working. I then plan to work on a game module for loading in the collision information for a level, drawing lines to represent the collision areas, and get the camera to move through the level with boundaries of where it can and can't move to. Then get my place holder character (a box) to run around the level, jump, collide with the collision objects, and make the camera follow the character. Hopefully I can get all of this done this week. Some of these pieces are already in place or started, but I'd like to get it all put together if possible.
I plan on doing as much coding as I can this week. I'm still trying to determine if I want to leave the engine alone and work on game specific stuff, or work on engine stuff. I think I've decided against switching to the virtual implementation that I posted earlier. After AC mentioned the Next-Gen impact it scared me off of virtual stuff a little bit, again. I've been thinking of either leaving it as is or doing what Scott Meyers refers to as the "is-implemented-in-terms-of" model, by allowing the Common class to have a Machine class pointer to the machines implementation. Neither solution seems as elegant as the virtual model did. That model just seems so clean and elegant, I just wish it didn't have the speed trade off that it does. And in gaming code, speed is top priority. If this was just a desktop application the speed issue wouldn't bother me.
On the game front I want to start creating level data. Everything needed for a level (collision information, sprites, etc..) will be bundled into a chunk file. I've already implemented a chunk file system in the engine. It's currently in use by fonts and textures.
Here's a brief description of how a chunk file works. Any binary data I use starts with the same chunk header. It specifies what type of data I'm pointing to, how big it is, and the offset to where it begins. The engine can then parse any binary file I have without knowing what the data it's pointing to is because the initial bytes of any file are all the same. If it doesn't know how to process a certain type of data it can ignore it.
What I need to add is what I call a Package chunk. If a file has more than one chunk in it, then it is considered a package and must have the Package chunk as its first chunk. This will contain a list of all the chunks in the file.
So I need to start by getting Packages working. I then plan to work on a game module for loading in the collision information for a level, drawing lines to represent the collision areas, and get the camera to move through the level with boundaries of where it can and can't move to. Then get my place holder character (a box) to run around the level, jump, collide with the collision objects, and make the camera follow the character. Hopefully I can get all of this done this week. Some of these pieces are already in place or started, but I'd like to get it all put together if possible.
posted by keith @ 10:33 AM
3 Comments:
When it comes time to work on your user input system, you may want to consider going out and buying a wired Xbox 360 controller (wireless won't work). The wired controllers work with PC's and can be programmed using the XInput library which is now part of DirectX 9c (December or later). It will be just like you were programming for the Xbox 1 again. No hassles with Direct Input. Unless of course you want to deal with keyboard and mouse stuff. But its nice to be on a PC with a real game controller.
Cool, I didn't know that. I take it the XBOX 360 uses standard USB ports then. I already implemented Direct Input for all devices though, although the code isn't 100% finished, and I use an adapter with my PS2 controller. The XBOX 360 controller is really nice though so I may have to pick one up. I haven't yet updated to the December release of DirectX 9c. Now I have another reason to.
I don't remember what the XBOX input API was like. Was it called XInput? And is it the same API now in DirectX? If so does XInput work with anything other than the XBOX 360 controller? I'm now going to browse over to microsoft's site and see if I can find some answers to my questions. ^_^
yeah I'm pretty sure Xbox1 was called XInput as well. Its a pretty streamlined interface for gamepad input. And yeah, the two APIs (DirectX and Xbox1 and Xbox360 are fairly similar) I think there may be a couple of differences but nothing that makes it difficult to port from one system to another. And XInput "should" work with any gamepad that windows recognizes.
However since you have everything already done in Direct Input, not much reason to go back and change it if it works.
I actually upgraded to the Feb 2006 release of DirectX... mainly because I thought it was going to help address my PIX tool issues on the PC (it didn't). However that is the "latest" version of the SDK - I don't recall if they called it a "beta" release or not.
Post a Comment
<< Home