Change Set 8259

Dec 6, 2007 at 8:48 AM
The skeleton of the new framework is now available in the source code section, under change set 8259. First off, it is just a skeleton of the QSGame class and the beginnings of the graphics library, so no complaining about it only drawing a black screen! I know its preliminary and does very little (who am I kidding? It does nothing!), but its a starting point so we can all start getting a feel for how things will work.

The big changes to note are:
  • The old prototype has been moved to framework/prototype.
  • The new framework now resides in framework/code.
  • Sturm's original restructure is mostly intact, with the exception of the project names and locations.

As far as I can tell (it's been awhile since I've looked at the document), the framework code satisfies the coding guidelines drafted for the project. If there are any issues here, please let me know.

The next big step here is to integrate Sturm's message system into the framework and start getting some systems outlined and communicating. At the same time, I'm going to be working on the rendering library to get it to actually do something. :)
Dec 6, 2007 at 9:35 AM
BLACK SCREEN !?!?!?! Why you.........

I was at least expecting a Cornflower Blue screen :P
Coordinator
Dec 6, 2007 at 2:47 PM
I'll work on a camera system tonight to get you at least one very basic camera so that you can actually have view and proj matrices to render from. I guess you could always create a simple proj and view matrix for your own purpose until I upload a camera if you need.
Dec 6, 2007 at 4:51 PM
Im ready to get going with the basics of the network, but what kind of interface is there going to be for sub modules? Also I need to know how the message still will work please Sturm
Dec 6, 2007 at 6:33 PM
After a certain point, you just want to shoot someone after you see yet another Cornflower Blue screen. :)

mikelid109, I'm not entirely sure on the system interface at the moment. For one, the graphics system doesn't even use an interface, it's just a library of classes usable by engine and client alike. I'm not sure if we should just stick with the GameServices/GameComponent model, or continue to roll our own. Besides the messaging functionality, which will most likely be exposed to systems via QSGame, what would you need from the QSGame class to write your network code?
Dec 6, 2007 at 8:46 PM
Not much, as I only plan to use messages to interact with other systems. I will need threads, but I dont see the game having to be involved. Im mainly just relaying messages from local to remote. I dont plan to handle them personally, just convert network to local
Dec 6, 2007 at 9:30 PM
Why do you need Threads? What is your interaction model, are you aiming for any special processor afinity or are there any other conserns?
Dec 7, 2007 at 1:35 AM
Asynchronous sends/receives with queues for both are probably a good idea.


On a side note, I hope to have another commit ready tonight with some content pipeline code and improved rendering functionality. Of course, that's IF I can get Maya or XSI to cooperate. If anyone can shed some insight into either of these problems, I would be very grateful:

  • Maya: I use the FBX exporter, push the data through a custom model processor, and render it in the engine. Everything works fine (objects transformations are right, once you Freeze Transforms in Maya), except the coordinate system conversion. The FBX exporter has the option to flip the coordinate system to Z-up, but the XNA FBX importer apparently doesn't pick up on that option as its not part of any node's Transform matrix. I may have to end up doing the conversion myself in the processor, but I'd like to avoid that. Whose idea was it go with a Z-up coordinate system, anyway? ;)
  • XSI Mod Tool: Just straight up won't run. Installs fine, opens up, then hangs before the GUI is fully drawn. Found a little information on the internet about it, none of the solutions work.

Until I get one of these working, it's hard to test graphics code.
Coordinator
Dec 7, 2007 at 2:11 AM
Edited Dec 7, 2007 at 2:13 AM
Shaw, you'll have to manually rotate all models/entities once when they're created. If you'll notice in the template I initialize the rotation matrices. I forget the name of the variable, but I believe it is stored in the custom datatype QSMatrix as some kind of base rotation for our engine. I believe it is something like CreateRotationX( MathHelper.PiOver2 );

I guess it depends on the modeler you're using. The coordinate system in 3dsMax is the same as our engine. This makes it easy to make a model in 3dsMax, and have it come out the same way in the engine. This assumes of course we do that initial rotation.
Dec 7, 2007 at 2:29 AM
Well that's lame. I was hoping the XNA FBX importer would keep whatever coordinate system was exported. Oh well.
Coordinator
Dec 7, 2007 at 8:09 AM
Maybe when we get around to our own Custom Model Processor we can remove the part where XNA converts the up coords to +Y.
Dec 7, 2007 at 8:32 AM
It's in the importer, not the processor. I already wrote the processor for static models. I spent a large chunk of time today trying to figure out how to get at the right transformation data, only to find out that the FBX importer always converts to Y-up.
Dec 7, 2007 at 9:09 AM

Sturm wrote:
Why do you need Threads? What is your interaction model, are you aiming for any special processor afinity or are there any other conserns?


Asynchronous, Like shaw said. I want it so the engine can immediatly pass network messages to local, rather than waiting for the next update cycle. If I waited for the next update cycle, that means we already have lag built in, which is something we need to minimise if we want the engine capable of supporting online shooters. Also I wanted a seperare thread for the server code as this is even more important to have a rapid response, as all clients depend on it.
Dec 7, 2007 at 9:35 AM
I think it's too expensive taking a thread and use it solely for sending/recieving messages on the client. Doing it on update should be more than adequate as that's where any update happens anyway. Even if 10 messages com in between 2 updates nothing is going to happen to them before update anyway.
Dec 7, 2007 at 10:57 AM
Ok, ill defer on the client thread, as it a lot simpler also, but I still think the server should be a seperate thread. This would also help me with host migration.
Dec 7, 2007 at 11:20 AM
Having the server on a seperate thread makes sense at it needs to be able to run out of sync with clients (It is the one responsible for sync).
Dec 7, 2007 at 5:57 PM
Remember that in Live the client and server are one in the same. The "server" is just one of the clients designated to perform the processing of the server. There is no dedicated server process.

On the sockets side of things, I dont agree that having a separate thread is a waste. recv is a blocking call, and the alternative (if the .NET library supports it) is a select/recv scheme that can be done synchronously without blocking but may become a hassle when you have many packets coming in per frame. Having a blocking, repeating recv call just running on its own thread is a simple solution, and since its just sitting there waiting most of the time it hardly takes up any cpu cycles.
Dec 7, 2007 at 6:18 PM
I know, Its giving me no end of headaches. I may ditch the seperate thread, except for sockets as its just a hassle. I cant get both the server and client to recieve data as they are effectively the same user, so if one recieves, the other cant. I may have the server recieve all messages and pass them onto the local client through a shared buffer, or inter system messages. I havent figured it out yet.
Dec 7, 2007 at 6:50 PM
With Live, a client/server approach can just be implemented as clients always send messages to the NetworkSession.Host (or wherever that property is, it exists somewhere) gamer object. The server (hosts) will receive these messages, and internally the engine will know its the host. Now, the complication comes up when trying to abstract this enough to fit both the Live and Sockets models. You can just designate a certain address as the host's address and send all messages there.

Then again, I'm not convinced that this is an efficient solution.
Dec 8, 2007 at 10:44 AM
Edited Dec 8, 2007 at 12:34 PM

shawmishrak wrote:
With Live, a client/server approach can just be implemented as clients always send messages to the NetworkSession.Host (or wherever that property is, it exists somewhere) gamer object. The server (hosts) will receive these messages, and internally the engine will know its the host. Now, the complication comes up when trying to abstract this enough to fit both the Live and Sockets models. You can just designate a certain address as the host's address and send all messages there.

Then again, I'm not convinced that this is an efficient solution.


A trick I like with sockets is to simply have tyhe server on a different channel. Ie all peer-to-peer on UDP 2001, all server on 2002. That way it seperates the traffic neatly. I need to really think about sockets though in greater depth, as there is so much Live implements that id have to hand code (especially matchmaking). Im about 10% through my intial Live code, but itll take me a lot longer for sockets.

On the subject of live, ive have decided to use a single thread for the entire network. Splitting the client and server code is a pointless hassle. Instead Im goign to merge it into a single class. The server part reads the messages first, then the client part. If the client isnt host the server section doesnt run.

As for customisation, I have to ideas. One is that the user extends tge Live, Local or Socket class, overriding the HandleMessage and HandleServerMessage functions to add their own code, then calling the relevant base methods to let the engine handle its messages. An alternative is the user passes in two delegates, one for custom server code, adn one for custom cleint code. I beleive I read delegates are slower, so im leaning towards the extended class implementation. What does everyone think?
Dec 8, 2007 at 1:04 PM
Edited Dec 8, 2007 at 1:04 PM
I think inheritence and then register the networking handler is the ideal solution.
Dec 8, 2007 at 1:17 PM
Could you expand please Sturm? I dont understand what you mean by register.
Dec 8, 2007 at 1:41 PM
You would have a NetworkManager class which I, as a modder would inherit from i.e. CustomNetworkManager. Then in the configuration file I would simply add a entry for my manager, there wouldn't have to be done any changes en the engine code as it works on the generic base class. In the Initialize of the game it would contain something like:
public void Initialize()
{
    Type networkManagerType = ConfigutationManager.GetNetworkManager();
    this.NetworkManager = Activator.CreateInstance(networkManagerType) as NetworkManager;
}
From here on you would simply work with Game.NetworkManager and not care about the implementation.
Dec 8, 2007 at 1:48 PM

Sturm wrote:
You would have a NetworkManager class which I, as a modder would inherit from i.e. CustomNetworkManager. Then in the configuration file I would simply add a entry for my manager, there wouldn't have to be done any changes en the engine code as it works on the generic base class. In the Initialize of the game it would contain something like:
public void Initialize()
{
    Type networkManagerType = ConfigutationManager.GetNetworkManager();
    this.NetworkManager = Activator.CreateInstance(networkManagerType) as NetworkManager;
}
From here on you would simply work with Game.NetworkManager and not care about the implementation.


Thats really interesting, its not something I was aware of. So I should I just make my class and leave a CustomServer and CustomClient method blank, to be inherited and expanded? I would call these from the recieve and send data methods.
Dec 10, 2007 at 7:14 PM
Ok, I think I get this. Out of interest whos responsible for the ConfigurationManager?
Dec 10, 2007 at 8:12 PM
Onone at the moment. But I'm implementing the general interface for it for the input manager. If you need something in now go ahead and inplement it, then lets discuss the interface.
Dec 10, 2007 at 8:58 PM

Sturm wrote:
Onone at the moment. But I'm implementing the general interface for it for the input manager. If you need something in now go ahead and inplement it, then lets discuss the interface.


No rush, ive got other bits to do first.